腾讯“疯狂”开源

AI科技大本营 · 公众号 · AI · 2019-11-30 15:07

正文

作者 | 马超

责编 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

近日，腾讯自研的万亿级分布式消息中间件TubeMQ正式开源，并捐赠给Apache基金会，成为基金会官方认可的Incubator项目。

我们知道与TubeMQ功能类似的kafka是领英公司在早在10年前捐赠给Apache基金会的金牌项目，而那时的腾讯还在忙于3Q大战，公司文化也相对封闭，甚至连目前社交领域的绝对领跑者-微信都是腾讯内部竞争，获得胜出的产品，所以谁也没想到腾讯竟然有今天的转变，成为了一家全面拥抱开源的科技公司。

走向开源的腾讯

在近日举办的腾讯Techo开发者大会上，腾讯正式对外表示将改变过去“自下而上”的开源模式，向“自下而上”与“自上而下”相结合的协同式开发演进。

其开源将在内部协同共建的基础上，推动更底层、更重磅的技术对外开放，紧密参与开源社区建设，不断完善开源治理，打造开发者共建的生态。

并建立对外开源管理办公室，对开源项目进行指导和帮助，为开发者提供社区合作交流机会，建设以开源为核心的技术生态圈。

而且腾讯还真的不是只做所谓PPT开源，笔者刚刚在Github上做了一下统计，目前腾讯在Github上发布的总项目数达到90个，Star数破26万；

而且其开源项目很多都堪称重磅，如在18年腾讯将其高性能RPC开发框架TARS及其轻量化名字服务方案TSeer捐赠给Linux基金会，当时就获得了业内的广泛好评，今年以来腾讯开源势头更盛，先是开源了物联网操作系统Tencent OS Tiny，而近期开源的TubeMQ算得上是社交巨头腾讯的最核心技术了。

腾讯为何拥抱开源

笔者曾经分析过开源对于与IT技术发展的关系，此番再度思考之后笔者认为开源对于巨头们来说有如下三个战略意义：

开源之争就是标准之争：目前的开源之争就是20年前的标准与知识产权之争。比如谷歌的深度学习框架Tensorflow成为人工智能方面的行业标准，靠的就是开源用户的口口相传，可以说谁掌握了最流行的开源项目，谁就掌握了话语权，从而主导行业的发展方向。

开源之争就是入口之争：目前各大IT厂商之所以纷纷推出自己的loT操作系统、深度学习框架等开源项目，其实本质的商业逻辑还是争夺用户的入口流量，掌握入口就能在未来竞争中掌握主动。

开源之争就是全栈之争：为了保证自己的基业长青，各巨头基本要采用全技术栈不留死角的竞争策略，才能让自己保持基业长青，目前类似于腾讯这样的企业将自身从前端到后端的所有技术全部开源，供行业其它参考者模仿，就是要巩固自身在行业内部的领先优势，为自身的品牌价值及技术能力宣传造势。

所以开源实际是最高形式的竞争，整个技术社区的认可才能保证自己永不落后。

万亿交易量成就的TubeMQ

TubeMQ的诞生

TubeMQ(Github地址：https://github.com/Tencent/TubeMQ)是2013年腾讯开始自研的分布式消息中间件系统，专注服务大数据场景下海量数据的高性能存储和传输。经过近7年日均25万亿的天量数据的打磨，较之于其它竞品TubeMQ绝对堪称是千锤百炼，在海量实践应用场景下绝对无人能出其右。

TubeMQ的适用场景

与一般的MQ类似，TubeMQ也比较适合及流式数据的处理场景，如用户的使用日志，实时广告的推荐等场景。

TubeMQ与其它MQ的比较：可以说TubeMQ最核心的优势就是历经考验了，我们可以看到其它的TubeMQ的竞品，几乎都有不同策略的数据副本同步机制，而只要存在这种策略，并一定要有一致性的保证机制，从而造成一定的性能消耗，TubeMQ则放弃了数据同步的策略，以尽可能的提升效率，并且加入了消息的服务端过滤功能。

比较项	TubeMQ	Hippo	Kafka	Pulsar
数据时延	10毫秒	20毫秒级	250毫秒	10毫秒
请求TPS	单机14W+/s	不适用	单机10W+/s	10W+/s (大压力下不稳定)
过滤消费	支持服务端过滤	客户端过滤，不支持服务端过滤	客户端过滤，不支持服务端过滤	客户端过滤，不支持服务端过滤
数据副本同步策略	无，通过RAID10磁盘备份+低时延消费解决	类Paxos算法保障	多机异步备份	多机异步备份
数据可靠性	无数据同步策略，故单机故障未消费的数据存在丢失风险	高	一般，master未同步的数据存在丢失风险	一般，master未同步的数据存在丢失风险
系统稳定性	高，日均25万亿交易量，稳定运行5年	无TubeMQ类似的运营场景	无TubeMQ类似的运营场景	无TubeMQ类似的运营场景
易用性	一般，只提供Java和C++的Lib	一般，只提供Java和C++的Lib	高，有很多配套插件使用	高，有很多配套插件使用

TubeMQ的技术架构

Portal：包括API和Web两块，API对接集群之外的管理系统，Web是在API基础上对日常运维功能做的页面封装；

Control：由1个或多个Master节点组成，Master HA通过Master节点间心跳保活、实时热备切换完成（这是大家使用TubeMQ的Lib时需要填写对应集群所有Master节点地址的原因），主Master负责管理整个集群的状态、资源调度、权限检查、元数据查询等；

Store：由相互之间独立的Broker节点组成，每个Broker节点对本节点内的Topic集合进行管理，包括Topic的增、删、改、查，Topic内的消息存储、消费、老化、分区扩容、数据消费的offset记录等，集群对外能力，包括Topic数目、吞吐量、容量等，通过水平扩展Broker节点来完成；

Client：以Lib形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于Pull消费模式，支持业务通过客户端重置精确offset以支持业务extractly-once消费，同时，消费端新推出跨集群切换免重启的BidConsumer客户端；

Zookeerper：仅做offset的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。

总的来说，Kafka按照顺序写顺序块读的模式实现，单实例下性能数据很强，但随着实例数增多，它的性能就呈现不稳定下降状态；TubeMQ采用顺序写 + 随机读的模式，即使在最大限制下系统仍可以做到长期稳定的1G以上的入流量，同时，结合服务端过滤，过滤消费非常顺畅。

与kafka的技术方案相比

在TubeMQ的最大不同在于以下几个方面

1、TubeMQ使用Java语言开发,kafka则使用相对小众的scala语言，再二次开发的难度TubeMQ占据优势

2、使用内嵌数据库存储元数据：与Kafka的Zookeeper模块管理元数据的策略不同，TubeMQ系统的主节点通过采用内嵌数据库BDB完成集群内元数据的存储、更新以及HA热切功能，负责TubeMQ集群的运行管控和配置管理操作，对外提供接口，从而减轻维护复杂度

3、服务端的消息过滤：TubeMQ支持服务端的消息过滤及负载均衡的方案，更便于均衡算法升级；

4、引入行级锁防重复：TubeMQ的Broker在中间状态的并发操作采用行级锁的策略，避免重复问题。

腾讯“疯狂”开源

正文

请到「今天看啥」查看全文