2020-09-16 ==========================================

现在社区在准备0.6.0版本，支持多语言SDK：由于相关实现属于长周期，相关贡献者属于业余时间贡献，出现了很多计划外的事情，所以本次只纳入C/C++的SDK，其他部分在下一个版本里提供；据贡献这个模块的同学说，在TS60(我们的性能评测机)下单进程单对象多线程拉取消费，纯粹的数据拉取性能可以跑到2G以上，不知道是不是吹，到今晚我才做完近60项的功能测试，结束的时候已经开了个环境长期跑跑看；大家可能也注意到项目更新比以前少，这并不是没有再更新，而是因为我们目前是维护内外一套版本形式运作，对外发布同时也即在对内发布，而仅这个SDK测试就花了约2周多的时间。

完成0.6.0版本准备后，0.7.0计划除提供其他多语言SDK外，还会引入tubemq-manager这个模块，大家之前也看到我们有发布过一个独立的前端分支，就是为这个内容提前构建；tubemq-manager思路是将我们日常的运维系统从内部环境抽离出来，让外部的业务对接接口即可直接使用，预期的效果是业务只需要提供topic，希望部署的集群，初始的流量量级，后面关于这个topic的配置、部署和调度就交给tubemq-manager来做。项目刚开始，有个新的小伙伴加入了进来，到时候有什么需要探讨的大家可以直接在社区里进行交流。

2020-08-04 ==========================================

TubeMQ 【https://tubemq.apache.org】按照Apache社区流程正式发布了0.5.0-release版本；接下来会在多语言SDK支持上进行加强。

0.5.0-release版本在项目组内外贡献者的合作努力下，基于易用为主题进行了101+项的完善，包括文档整理、上下游管道组件包支持、容器上运行的支持，以及配置模型上的调整等，补齐了在大数据场景下使用TubeMQ的上下游辅助。如果是需要在大数据场景下使用MQ业务，希望MQ系统稳定、管控方便、高性能、低时延、少维护，TubeMQ或许是你的一个新选择。

接下来计划朝KoT上进行靠拢，进一步降低业务使用TubeMQ的门槛，这块存在一些挑战，需要贡献的同学对Kafka比较的熟悉，同时能够捕捉到两者的差异点，从而做到无缝的对接。对于这点，欢迎感兴趣的同学一起来共建。

2020-06-21 ==========================================

TubeMQ 【https://tubemq.apache.org】按照Apache社区流程正式发布了0.3.0-release版本；正在进行TubeMQ-0.5.0版本的发布准备。

这是TubeMQ的一个分水岭，0.3.0版本由公司内同学开发完成，0.5.0版本是按照社区方式运作，公司内外部同学共同参与的版本；该版本以易用为主题进行构造，包括文档整理，基于docker、k8s容器运行支持，数据上报管道上下游的支持(包括基于flume的数据接入，基于flink、spark的source、sink支持)等；针对@陈大白提到的问题这个版本做了实现调整，性能相比之前确实要更好，这里表示感谢！还有一部分性能提升优化项还在继续实施中，最终效果有望比0.3.0好不少，敬请期待。

2020-05-12 ==========================================

TubeMQ已经在现网稳定的运行近2个月时间，客户端也在推进升级；接下来我们将进行新版本的开发，把内部开发搬到网上实时对接，可以预计将会有很多需要学习的地方。

MQ现在已经有这么多产品情况下，对于TubeMQ，它的定位是什么呢？目前可控的范围，我个人理解是 把它做成一款基于服务端管控的以SAAS模式对外服务的高可靠、高性能、低延迟、低成本的分布式消息中间件，接下来的开发也都将围绕这个项目定位进行展开。这也是目前的MQ里比较少的切入点，从而可以满足到内部，或者外部对这块有需求的业务。大家提到的多副本问题，最近也在分析中，包括ratis，sofa-jraft等raft协议，可能会启动一个分支进行调研并在合适时候切入主线中。

项目也开始收到有关注的同学提的issue或者pr，欢迎有兴趣的同学一起来参与，共建这个项目。

2020-03-14 ==========================================

经过了多轮线上灰度，如下链接对应内容是正在线上环境全量铺设的版本，供有需要的同学使用：

我们在之前版本发现了一些问题，其中影响比较大的一个问题就是数据文件老化时文件句柄没有释放问题，都已在这个版本里解决。然后，有一个版本兼容问题影响到消费端的代码整洁：我们内部提了一个消费数据时需要获取对端的相关信息需求，比如对端broker的ip信息，之前是考虑不把内部服务器信息暴露外部，后分析合理；但原有MessageListener不好扩展，只好增加了MessageV2Listener。大家使用时可以直接修改下，避免这个地方大家误解：

如果大家使用，以这个版本最合适；版本的release正在进行中，头次按照apache标准执行着做，发现还有点工作量，学习下先。

我会在这里定期单向的同步项目的最新信息，供有需要的、正在用这个项目的同学使用，项目实现相关的问题请大家通过jira进行对接和交流

同时，欢迎大家一起来共建这个项目，谢谢大家！

2020-01-06 ==========================================

我们代码工程已经迁入到Apache下，同时采用Jira进行需求及问题的管理，原有Tencent/TubeMQ项目设置为只读，欢迎大家关注：

2019-12-31 ==========================================

这是12月21日参加腾讯云+社区技术交流会的PPT和现场视频，供有需要的同学参考：

2019-12-17 ==========================================

大家能否支持到TubeMQ，提供各种语言版本的SDK,以及方便的维护工具呢？

关于SDK，目前我们团队掌握的语言技能仅限于Java和C++，短、中期的精力会投入到核心处理流程的改进上，因而比较难在短时间内依靠现有的团队力量做到对其他语言的使用支持。您是否有兴趣，在您擅长的语言领域给予TubeMQ项目以帮助，比如提供Go,Python,或者其他语言的SDK，一起来完善TubeMQ项目，让更多有需要的人受益的同时也感谢您的付出呢？

关于使用工具，我们环境是DO分离模式，大家日常使用的工具，我们开发可能还没有很好的理解，您是否愿意提供一些对应的思路，或者提供一些实际工具，一起丰富TubeMQ在这块的运营维护呢？

思想上的分歧会随着时间逐步的理解、消化，进而趋同，不知不觉过去了3个月，我们已发布通过完整测试并且内部准备灰度的Release-0.2.0版本，同时我们在最近时间也和公司内外的同学做了一些项目开源、设计上的分享和交流，这个周六准备继续： https://zhuanlan.zhihu.com/p/94310917。

欢迎大家使用和交流TubeMQ，并给我们项目提issue或者pr，或者在项目中贡献您的给予，谢谢！

2019-11-17 ==========================================

这个主题在9月18日被人匿名发上来时我们就关注到了，一直等了几个月也没有人出来指出其中的问题，感觉当时大家回复存在对项目的推广使用有影响，我在11月11日基于一次交流会的资料进行了答复，短短1周时间没想到突然有这么多人的关注。这块不是我的专长，也没有太多时间耗费在这上面。从哪开始从哪结束，由于@陈大白的回复提到可靠性的问题，我感觉如果不澄清下，会影响到大家对TubeMQ的认识，因此还想说下最后2个问题，不讨论：

1. 高可靠和高性能是否可以兼得：

我觉得是可以，但对应的就是高成本。按照目前已公开的资料，只有用paxos或者raft协议采用多节点同步模式才有可能做到完全的不丢数据，但总体的TPS和机器成本就变得非常的高；除此之外，还没有看到有公开资料介绍成本又低性能又好又不丢数据的技术资料或者系统。基于这个算法理论基础，高可靠和高性能作为是1或0的问题，在结合成本和吞吐量的考虑，同时存在就形成了一个悖论。因此，为了兼顾性能，成本，尽可能高的可靠性要求，非金融领域的MQ,基本上就只有选择异步存储模式。

2.非金融领域场景下，其他MQ的数据丢失率比TubeMQ又能低多少？

基于第1点，非金融领域场景下的MQ，当为了性能、成本考虑时只有选择不可靠的服务才能鱼与熊掌兼得，同意这个观点的话，问题就转为各个MQ数据丢失率有多高问题了。如帖子里我对大白分析的回复所说，排除实现BUG,各个MQ都逃不过机器断电导致已回复确认但没有刷盘，以及无法恢复的磁盘故障异常导致的数据丢失场景。以Kafka为例，大家也许会说，我通过多节点异步同步方式可以解决这个问题，我的考虑是，异步也存在已回复但还没有同步到备份节点情况，这个是会丢数据的；或许同学会说我通过多副本ACK确认机制，指定多个节点确认再做回复，这个问题就又回到多节点同步确认保证高可靠但保证不了高性能的点上了，拿同步概念来套异步场景，偷换了前提；还有同学会说，你说的那些都是极端情况，我可以容忍，但磁盘会坏情况下怎么办，如果不多节点复制，整个数据全完，这个问题我是这样看的，其实大家对MQ的使用通常是 管道 + 存储 两种模式叠加，有数据持久化的需求在里面。这种模式在少量数据场景下是可以的，但你换成大数据场景下，拿一台读写频率过10W TPS的机器做存储，本身就不是合适的设计，因此最佳方案就是管道与存储相分离，管道解决管道的问题，存储解决存储的问题；也许有同学说，你说错了，我就实现了，指标如何如何，这种情况下，借用我们TEG当前流行语“show me your code”。

基于上面的分析，我相信大家基本上可以认同，非金融领域场景下各个MQ基于性能、成本的考虑都存在数据丢失问题。那问题就来了，其他MQ的数据丢失率比TubeMQ又能低多少？ 直接下结论，还是以Kafka为例，两者都丢的场景下，极端情况TubeMQ只会比Kafka丢失率多2%,换做量来说就是TubeMQ只会比Kafka多丢每个Topic 2M内存的数据大小；而借助TubeMQ比Kafka低25倍的数据时延(按测试报告场景里10ms VS 250ms计算，实际上测试场景测试数据是可以低到5ms以下的，不知道复核数据的同学发现没有:))，业务如果不滞后消费数据丢失率可以做到0。为什么这么说，大家真实使用这个系统后就会发现为什么。

这段有点烧脑，但值得有需要的同学静下来思考下，看是不是说的确实如此；然后，如果做不到完全的可靠性，是否有必要花2倍或者3倍的机器成本来应用？用一个极端情况下只会多2%的可能损失率但成本、性能、可靠性极高的方案是不是更合适？相信我们通过实践打磨出来的产品可以实际有效的帮助到这块领域各位。

然后，大家也关注到了TubeMQ的目录，都是以"tubemq_"开始，因为接入这块除了MQ,还有其他的组件，如果后续公司持续开源配套能力也会持续跟进对外，大家也可以把自己做的好的贡献到我们项目里，促进这块的发展。再，因为已经是孵化项目，后面TubeMQ会迁移到Apache目录下，大家根据本文链接想给项目提issue或者pr找不到项目时，那是正常情况，直接搜TubeMQ就好

结束，谢谢大家对TubeMQ项目的关注！

2019-11-11 ==========================================

首先，作为TubeMQ的项目负责人，谢谢大家对TubeMQ的关注

平时也上知乎，不过都是潜水翻几页看看就走，对于这个主题，我觉得有必要出来说下：

１. 是不是KPI项目：是，又不是。是是说，TubeMQ是腾讯大数据平台部门应用的核心组件，在目前日均接入量过３３万亿的背景下，部门每年都会针对它制定KPI指标，来保证系统能稳定运行，并且持续改进以提高性能，降低成本；不是是说，TubeMQ对外开源采用的是内外一套系统进行，同时为了解决后续项目持续的稳定对外问题，我们对Apache进行了开源捐献，并请了5位Apache的重量级人物来辅导项目毕业，包括Apache的MEMBER,EVP，从阵容上大家也可以看到，我们是认真的。

2. 项目是不是真如说的那么好：是不是说的那么好，是不是在吹泡泡，我觉得项目开源后，怎么做的，哪些地方借鉴了哪些项目，有什么独特的，特别见功底的，做得特别到位的，以及还有需要改进的地方，一览无余，同时，我们明确清晰的定义了我们内部的测试方案，以及测试报告，为的就是让大家可以很容易的复核数据，并进行横向的对比，看看是不是这样，所以这个大家试了就知道。

３. 这个项目对我有什么好处：如果大家的日均接入数据量只有几亿，几十亿，其实用什么MQ都可以，如果数据量到白亿，千亿，万亿，上十万亿，这个量级下，按照我们２０１８年和２０１９年持续评估的情况，TubeMQ在系统稳定性，性能和成本方面，仍是领先的。所以，如果大家需要在使用TubeMQ方面有什么需要详细了解的，有需求或者场景需要详细讨论澄清的，有因为文档没有到位导致理解需要澄清的，请告诉我们，我们有不同量级的使用沉淀，我们可以解决大家在TubeMQ应用中遇到的问题。

为了使大家更好的将项目应用到生产环境，以及一起探讨MQ的相关问题，我们建立了一个微信群"Apache TubeMQ社区群",有问题大家可以多交流。

最后，一句话总结：　如果大家觉得TubeMQ好用，请给项目点个赞(https://github.com/Tencent/TubeMQ)；如果发现TubeMQ存在问题或者可以改进得更好的地方，请提issue或者pr，让我们把它变得更好

谢谢大家对TubeMQ的关注！