【领取见面礼】限量 100份 GeekOnline加油包！等你来拿置顶

该作品由两位选手共同完成，分别是熟悉前端、WebRTC 方向的“红鲤鱼”和熟悉后端、大数据方向的“绿鲤鱼”。这是一款帮忙新手程序员迅速熟悉融云 SDK 的小游戏，通过识别二维码拼图的游戏，让了解融云的过程有趣味性。该作品层次丰富，第一层需要用户集成融云 SDK、掌握融云的基本概念，第二层需要用户做一定程度的视频后处理，第三层需要用户做一些图像识别。

季军团队 - youweyoung

获得第三名的团队包含了一位拥有前后端多年开发经验的选手。作品基于 Android 操作系统使用 RTC 混合开发，最终做出了音视频通话应用 —— IYI网络剧场，将角色扮演类的剧本杀游戏以视频形式展现，每个场景有不同的主题人物并且可以替换，人物则是以皮影、动画等形式展现，适用于远程视频讲故事或玩剧本杀，有一定新颖性。

科技创新奖团队 - 萍水相逢的生活

这支队伍只有一位选手，他是一个心怀想法的程序员，做的产品是一个基于事务的陌生人聊天系统，事务场景可以是租房加中介的联系方式、街头偶遇添加好友、发布大字报等，这款产品的设计思路旨在为大家生活提供便利的软件。

商业价值奖团队 - MAXFLOAT

MAXFLOAT 是一支有实力，有梦想，有创意，敢拼搏，即想即做的队伍。他们认为当前城市化生活环境下人与人的交流越来越少，宠物逐渐替代朋友成为更好的伙伴，养宠物的越来越多，但随之而来的是更多的问题，比如宠物的遗失、被抛弃造成了流浪宠物越来越多，而宠物的健康，有时也不能及时得到重视。因此他们做了一款以宠物招领、寄养、寻回、宠物医生等为主，以宠物信息普及、宠物疾病普及为辅的 APP 帮助广大宠物爱好者。

包含获奖团队在内的 15 组团队，作品各具特色，即为评委以及线上观众们展示了自身的产品创意，也展示了 RTC 技术在实际应用中的能力与延展性，很多选手的作品获得了评委们的高度评价。我们对获奖团队进行了单独的采访，内容会于后续发出，敬请期待。

在选手们精彩的分享以及答辩之后，四位评委嘉宾分别给出了对于参加本次比赛的感受。

“融云始于 IM，又不止于 IM。通过融云提供的技术以及服务能力，开发者们可以更加关注线上的优化与迭代，期待更多开发者利用融云SDK，开发更创新、强大的产品。” —— 陈昱

“本次的决赛中我有很多印象深刻的作品，有的非常符合开发者的口味，有的对于使用场景有着很深入的思考。因为疫情，通信云技术的需求正在变得越来越大、越来越丰富，有很多场景需要我们去开拓，很值得开发者们关注并付出行动。” —— 祁宁

“选手们有很多创意创新点都很好，将很多现实中生活化的场景融入到比赛中，也有一些具有极客特质的项目，这些都是融云自身生态开发能力非常好的体现。对于融云来说，开发者是宝贵的资源，而通信云的生态也需要非常广泛的群体参与，共同完善。” —— 杨扬

“很高兴的看到，决赛中有很多作品提到了人们的心理问题，除开产品技术本身，还致力于解决人文层面的诉求。基于 IM 的核心能力，选手们提供了很多在线的沟通场景，比如剧本杀、狼人杀等等，基于这些实时互动的模式，通信能力已经变成了现代应用的一种基础设施，能为产业、产品和应用场景提供帮助，这让我们既感到压力，也感受到了更强大的动力。” —— 杨攀

结语

通过选手们的展示，我们可以了解到通信云技术的发展和提升不仅仅可以作用于工作和学习，关于实时音视频和即时通讯技术的应用，还有更多创新的场景等待我们用全新的思维来发掘。

Geek Online 2020 编程挑战赛虽然是第一次举办，但已经收获了参赛选手以及观看决赛路演直播观众们的一致好评，部分选手在路演结束后已经联系主办方咨询第二届比赛的安排，想要提前报名。

融云作为专注于通信的 PaaS 云服务平台，想要通过底层的基础模块支持，帮助企业与开发者构建「云通信」的能力。举办此次编程挑战赛的目的，也是希望让开发者们碰撞出技术的思维火花，加速潮流技术的应用创新，也为开发者们搭建了一个沟通、交流、合作的平台，希望能够掀起一股通信技术应用的探索与实践热潮。

点击进入大赛官网，查看更多比赛信息

Gitee八周年，一起创造无限可能的未来

科技创新 • 梅川酷子发表了文章 • 0 个评论 • 67 次浏览 • 2021-05-27 11:26 • 来自相关话题

「∞」，代表着无穷、无限、没有边界第「8」年的 Gitee 再次全新出发和Gitee最新入职的吉祥物「马建仓」一起以协作为蓝图，创造你我不设边界的未来⚠️前排提醒⚠️：文末有福利哦～来看一看学生王志、开源项目作者张硕、研发团队 Leader 李慕然和 Gite... ...查看全部

「∞」，代表着无穷、无限、没有边界

第「8」年的 Gitee 再次全新出发

和Gitee最新入职的吉祥物「马建仓」一起

以协作为蓝图，创造你我不设边界的未来

⚠️前排提醒⚠️：文末有福利哦～

来看一看学生王志、开源项目作者张硕、研发团队 Leader 李慕然和 Gitee 的故事吧。不论是开源作者还是研发团队，都能在 Gitee 上开创自己不设边界的未来。各位旅客请扶稳坐好，您的开源之旅即将发车，本次开源之旅共有三站，每到达一站Gitee都会有惊喜大礼等你赢取。

Gitee 企业版已经助力超过 18 万家企业/机构实现了协作的「新概念」：

全流程、无边界带来的极致高效。

在八周年活动时间内，我们为 Gitee 企业版的用户带来了超棒的优惠福利，简单粗暴，买就送哦～

感谢

4款MySQL Binlog日志处理工具对比

科技创新 • 苏道发表了文章 • 0 个评论 • 78 次浏览 • 2021-05-25 15:58 • 来自相关话题

Canal定位：基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了mysql。原理：canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议mysql master收到du... ...查看全部

Canal

定位：基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了mysql。

原理：

canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
mysql master收到dump请求，开始推送binary log给slave(也就是canal)
canal解析binary log对象(原始为byte流)

整个parser过程大致可分为几步：

Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点）
Connection建立连接，发生BINLOG_DUMP命令
Mysql开始推送Binary Log
接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息
传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
存储成功后，定时记录Binary Log位置

数据过滤：支持通配符的过滤模式，表名，字段内容等
数据路由/分发：解决1:n (1个parser对应多个store的模式)
数据归并：解决n:1 (多个parser对应1个store)
数据加工：在进入store之前进行额外的处理，比如join

Maxwell

canal 由Java开发，分为服务端和客户端，拥有众多的衍生应用，性能稳定，功能强大；canal 需要自己编写客户端来消费canal解析到的数据。

maxwell相对于canal的优势是使用简单，它直接将数据变更输出为json字符串，不需要再编写客户端。

Databus

Databus是一种低延迟变化捕获系统，已成为LinkedIn数据处理管道不可或缺的一部分。Databus解决了可靠捕获，流动和处理主要数据更改的基本要求。Databus提供以下功能：

源与消费者之间的隔离
保证按顺序和至少一次交付具有高可用性
从更改流中的任意时间点开始消耗，包括整个数据的完全引导功能。
分区消费
源一致性保存

阿里云的数据传输服务DTS

数据传输服务（Data Transmission Service，简称DTS）是阿里云提供的一种支持 RDBMS（关系型数据库）、NoSQL、OLAP 等多种数据源之间数据交互的数据流服务。

DTS提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力，可实现不停服数据迁移、数据异地灾备、异地多活(单元化)、跨境数据同步、实时数据仓库、查询报表分流、缓存更新、异步消息通知等多种业务应用场景，助您构建高安全、可扩展、高可用的数据架构。

优势

数据传输（Data Transmission）服务 DTS 支持 RDBMS、NoSQL、OLAP 等多种数据源间的数据传输。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输方式。相对于第三方数据流工具，数据传输服务 DTS 提供更丰富多样、高性能、高安全可靠的传输链路，同时它提供了诸多便利功能，极大得方便了传输链路的创建及管理。

个人理解：就是一个消息队列，会给你推送它包装过的sql对象，可以自己做个服务去解析这些sql对象。

免去部署维护的昂贵使用成本。DTS针对阿里云RDS（在线关系型数据库）、DRDS等产品进行了适配，解决了Binlog日志回收，主备切换、VPC网络切换等场景下的订阅高可用问题。同时，针对RDS进行了针对性的性能优化。出于稳定性、性能及成本的考虑，推荐使用。

Kafka 2.8.0发布，快来看看有哪些不同！

科技创新 • fanta2 发表了文章 • 0 个评论 • 72 次浏览 • 2021-05-25 15:58 • 来自相关话题

平时关注 Kafka 的小伙伴要注意了，2021年4月19日，Kafka 2.8.0正式发布！这次升级包括了很多重要的改动，其中最引人瞩目的就是kafka通过自我管理的仲裁来替代ZooKeeper，通俗的说，Kafka将不再需要ZooKeeper，正式分手！其... ...查看全部

平时关注 Kafka 的小伙伴要注意了，2021年4月19日，Kafka 2.8.0正式发布！

这次升级包括了很多重要的改动，其中最引人瞩目的就是kafka通过自我管理的仲裁来替代ZooKeeper，通俗的说，Kafka将不再需要ZooKeeper，正式分手！

其实早在19年，就有人在社区中提出要移除Kafka对Zookeeper依赖的想法，当时被视为几乎不可能，但随着众人齐心协力踌躇满志，竟然真的一步一步逐渐实现了。

2.8.0版本将是第一个不需要ZooKeeper就可以运行Kafka的版本，而这也被称为Kafka Raft Metadata mode（Kafka Raft 元数据模式），或许就是一个会被后人铭记的版本。

可能有一些刚接触Kafka的小伙伴还不明白这到底代表着什么。

Kafka的一大优点就是能够提供高效率和吞吐量，对先前刚接触的小伙伴来说，提交日志的底层实现往往是需要学习的第一个任务。

Kafka 的代码库中还有很大一部分是负责在多个集群中安排日志、分配领导权、处理故障等。这使的 Kafka 成为一个可靠和可信的分布式系统。而ZooKeeper就是分布式代码工作的关键。在以往的版本中，ZooKeeper 提供了权威的元数据存储，这些元数据存储了系统中最重要的东西，例如分区可以存在哪里，哪个组件是主导等等等等。

但不管怎么样，ZooKeeper 是一个基于一致日志的特殊文件系统/触发器API。而Kafka 是一个建立在一致日志之上的发布/订阅系统。

这个无法改变的现实使得实际使用中，运维人员需要跨两个日志实现、两个网络层和两个安全实现(每个实现都有不同的工具和监视钩子)对通信和性能进行调优、配置、监视、保护和评估，这就使得系统变得相当复杂！

所以和ZooKeeper的友好分手短期可能会有阵痛，但对于Kafka的长远发展利大于弊。

除了和ZooKeeper分开，本次更新还新增了三个功能：

[KAFKA-10500]-添加API以启动和停止流线程

[KAFKA-10700]-支持使用SASL_SSL侦听器实现相互TLS身份验证

[KAFKA-10749]-通过连接速率添加IP限制

而优化及修改bug更是多达百个。

一些重要的更新例如：

[KAFKA-5488]-KStream.branch不应返回必须通过已知索引访问的流数组

[KAFKA-6687]-允许多次阅读主题

[KAFKA-6943]-如果任何线程崩溃，或者如果所有线程崩溃，可以选择干净地关闭KS

[KAFKA-9023]-生产者网络异常响应应记录更多信息

[KAFKA-12327]-删除CompressionType中的MethodHandle用法

[KAFKA-12365]-kip-500代理/控制器不支持块API（目前）

[KAFKA-12394]-考虑主题id存在和授权错误

[KAFKA-4748]-需要一种方法同时关闭Streams应用程序中的所有工作进程

[KAFKA-10722]-即使不需要，也使用时间戳存储

[KAFKA-10723]-LogManager在关闭期间泄漏内部线程池活动

如果对具体的更新内容感兴趣，可以直接登陆官网进行查看

如何使用 Redis 实现一个轻量级的搜索引擎

科技创新 • fanta2 发表了文章 • 0 个评论 • 65 次浏览 • 2021-05-25 15:58 • 来自相关话题

场景大家如果是做后端开发的，想必都实现过列表查询的接口，当然有的查询条件很简单，一条 SQL 就搞定了，但有的查询条件极其复杂，再加上库表中设计的各种不合理，导致查询接口特别难写，然后加班什么的就不用说了（不知各位有没有这种感受呢~）。下面以一个例子开始，这是... ...查看全部

场景

大家如果是做后端开发的，想必都实现过列表查询的接口，当然有的查询条件很简单，一条 SQL 就搞定了，但有的查询条件极其复杂，再加上库表中设计的各种不合理，导致查询接口特别难写，然后加班什么的就不用说了（不知各位有没有这种感受呢~）。

下面以一个例子开始，这是某购物网站的搜索条件，如果让你实现这样的一个搜索接口，你会如何实现？（当然你说借助搜索引擎，像 Elasticsearch 之类的，你完全可以实现。但我这里想说的是，如果要你自己实现呢？）

从上图中可以看出，搜索总共分为6大类，每大类中又分了各个子类。这中间，各大类条件之间是取的交集，各子类中有单选、多选、以及自定义的情况，最终输出符合条件的结果集。

好了，既然需求很明确了，我们就开始来实现。

实现1

率先登场是小A同学，他是写 SQL 方面的“专家”。小A信心满满的说：“不就是一个查询接口吗？看着条件很多，但凭着我丰富的 SQL 经验，这点还是难不倒我的。”

于是乎就写出了下面这段代码（这里以 MYSQL 为例）：select … from table_1left join table_2left join table_3left join (select … from table_x where …) tmp_1 …where …order by …limit m,n

代码在测试环境跑了一把，结果好像都匹配上了，于是准备上预发。这一上预发，问题就开始暴露出来。预发为了尽可能的逼真线上环境，所以数据量自然而然要比测试大的多。所以这么一个复杂的 SQL，它的执行效率可想而知。测试同学果断把小A的代码给打了回来。

实现2

总结了小A失败的教训，小B开始对SQL进行了优化，先是通过了explain关键字进行SQL性能分析，对该加索引的地方都加上了索引。同时将一条复杂SQL拆分成了多条SQL，计算结果在程序内存中进行计算。

伪代码如下：$result_1 = query(‘select … from table_1 where …’);$result_2 = query(‘select … from table_2 where …’);$result_3 = query(‘select … from table_3 where …’); …$result = array_intersect($result_1, $result_2, $result_3, …);

这种方案从性能上明显比第一种要好很多，可是在功能验收的时候，产品经理还是觉得查询速度不够快。小B自己也知道，每次查询都会向数据库查询多次，而且有些历史原因，部分条件是做不到单表查询的，所以查询等待的时间是避免不了的。

实现3

小C从上面的方案中看到了优化的空间。他发现小B在思路上是没问题的，将复杂条件拆分，计算各个子维度的结果集，最后将所有的子结果集进行一个汇总合并，得到最终想要的结果。

于是他突发奇想，能否事先将各个子维度的结果集给缓存起来，这要查询的时候直接去取想要的子集，而不用每次去查库计算。

这里小C采用 Redis 来存储缓存数据，用它的主要原因是，它提供了多种数据结构，并且在 Redis 中进行集合的交并集操作是一件很容易的事情。

具体方案，如图所示：

这里每个条件都事先将计算好的结果集ID存入对应的key中，选用的数据结构是集合（Set）。查询操作包括：

子类单选：直接根据条件 key，获取对应结果集；
子类多选：根据多个条件 Key，进行并集操作，获取对应结果集；
最终结果：将获取的所有子类结果集进行交集操作，得到最终结果；

*这其实就是所谓的反向索引。*

这里会发现，漏了一个价格的条件。从需求中可知，价格条件是个区间，并且是无穷举的。所以上述的这种穷举条件的 Key-Value 方式是做不到的。这里我们采用 Redis 的另一种数据结构进行实现，有序集合（Sorted Set）：

将所有商品加入 Key 为价格的有序集合中，值为商品ID，每个值对应的分数为商品价格的数值。这样在 Redis 的有序集合中就可以通过ZRANGEBYSCORE命令，根据分数（价格）区间，获取相应结果集。

至此，方案三的优化已全部结束，将数据的查询与计算通过缓存的手段，进行了分离。在每次查找时，只需要简单的查找 Redis 几次就能得出结果。查询速度上符合了验收的要求。

扩展

分页

这里你或许发现了一个严重的功能缺陷，列表查询怎么能没有分页。是的，我们马上来看 Redis 是如何实现分页的。

分页主要涉及排序，这里简单起见，就以创建时间为例。

如图所示：

图中蓝色部分是以创建时间为分值的商品有序集合，蓝色下方的结果集即为条件计算而得的结果，通过ZINTERSTORE命令，赋结果集权重为0，商品时间结果为1，取交集而得的结果集赋予创建时间分值的新有序集合。对新结果集的操作即能得到分页所需的各个数据：

页面总数为：ZCOUNT命令
当前页内容：ZRANGE命令
若以倒序排列：ZREVRANGE命令

数据更新

关于索引数据更新的问题，有两种方式来进行。一种是通过商品数据的修改，来即时触发更新操作，一种是通过定时脚本来进行批量更新。这里要注意的是，关于索引内容的更新，如果暴力的删除 Key，再重新设置 Key。因为 Redis 中两个操作不会是原子性进行的，所以中间可能存在空白间隙，建议采用仅移除集合中失效元素，添加新元素的方式进行。

性能优化

Redis 是内存级操作，所以单次的查询会很快。但是如果我们的实现中会进行多次的 Redis 操作，Redis 的多次连接时间可能是不必要时间消耗。通过使用MULTI命令，开启一个事务，将 Redis 的多次操作放在一个事务中，最后通过EXEC来进行原子性执行（*注意：这里所谓的事务，只是将多个操作在一次连接中执行，如果执行过程中遇到失败，是不会回滚的 *）。

总结

这里只是一个采用 Redis 优化查询搜索的一个简单 Demo，和现有的开源搜索引擎相比，它更轻量，学习成本页相应低些。其次，它的一些思想与开源搜索引擎是类似的，如果再加上词语解析，也可以实现类似全文检索的功能。

转载于公众号“程序猿DD”

1. 阿里云DataV

使用手机号或邮箱注册账号，会获得7天的体验期。阿里云DataV有强大的组件库，可以制作不同的样式，还可以链接数据库或API接口，炫酷的可视化大屏可以轻松完成。

缺点：

（1）试用期比较短，试用期过了，需要几千或者几万的续期费用，对于工薪阶层来说，这是一笔不小的费用。（2）数据源的配置有点复杂，用户的学习成本有点高。

2. 积木报表jimureport

积木报表是 JeecgBoot 旗下的一款免费制作报表和大屏的软件，主打开源。跟阿里和百度一样，手机号一键注册，便可永久使用，重要的是：免费！免费！免费！积木报表采用类word风格，可以随意拖动组件，想怎么设计怎么设计，可以像百度和阿里一样，设计出炫酷的可视化大屏！

缺点：

等你来发现呦！

3. 百度Sugar

跟阿里一样，手机号一键注册，会有30天的体验期，制作效果同样炫酷。

缺点：

（1）试用期不长，试用期一过，需要花钱续费；

4. 帆软

帆软是业内做报表比较久的一家公司，使用类excel风格的界面，可添加图表和数据源，也可实现大屏效果。

缺点：

（1）只能拖动块的固定排版，对于大屏的随意排版、随意拖动很不方便；（2）需下载软件，本地制作，软件占用空间较大，打卡比较慢；（3）需要安装许多插件才可以实现一些动态效果；

通知设置 新通知

发现

【领取见面礼】限量 100份 GeekOnline加油包！等你来拿 置顶

【征稿活动】Geek Online 社区第一期投稿激励计划已启动！ 置顶

【社区精华|持续更新】收录本社区精华内容，手把手教学IM/RTC开发！ 置顶

【融云集成常见问题整理】Geek Online 2020 编程挑战赛选手提问整理 置顶

2 个月激烈角逐，15 支队伍突围决赛路演！Geek Online 2020 编程挑战赛完美收官！ 置顶

决赛路演，大屏直播互动

部分参赛选手作品展示 & 评委点评

结语

Canal

原理：

Maxwell

Databus

阿里云的数据传输服务DTS

优势

场景

实现1

实现2

实现3

扩展

分页

数据更新

性能优化

总结

1. 阿里云DataV

缺点：

2. 积木报表jimureport

缺点：

3. 百度Sugar

缺点：

4. 帆软

缺点：

热门文章

热门用户

友情链接 申请友链

通知设置新通知

【领取见面礼】限量 100份 GeekOnline加油包！等你来拿置顶

【征稿活动】Geek Online 社区第一期投稿激励计划已启动！置顶

【社区精华|持续更新】收录本社区精华内容，手把手教学IM/RTC开发！置顶

【融云集成常见问题整理】Geek Online 2020 编程挑战赛选手提问整理置顶

2 个月激烈角逐，15 支队伍突围决赛路演！Geek Online 2020 编程挑战赛完美收官！置顶

友情链接申请友链