2022-06-23 ==========================================
告诉大家一个好消息，Apache InLong毕业了！！
从2019年9月我们一起播下了一颗种子，终于在2022年6月一起见证项目成功地从Apache孵化毕业，这是腾讯公司发起的第一个在Apache社区进行孵化并以顶级身份毕业的项目，也是第一个以全链条形式开源的一站式大数据集成项目。
作为项目其中的一员，我很自豪，也很感慨，同时饱含感谢，感谢这一路以来大家的相伴相随，感谢国内外各位专家的引导、指点，特别感谢社区里每一行代码后的挚爱与坚守者--我们社区的贡献者们为梦想所做的努力！
个人因为这个项目而与大家结缘，也在长久的执行过程中想过放弃这个帖子，但总觉得差一点交代，有开始有结束，是时候说再见的时候了，大家后会有期，再次恭喜Apache InLong项目毕业，有幸成为项目其中一员我感到骄傲和自豪！！
2022-06-19 ==========================================
今天父亲节，想写点什么
6月15日，是一个值得纪念的日子，Apache董事会开会，讨论并投票确定Apache InLong项目是否可以毕业，那晚我搬了个小板凳坐在场外等着消息公布，终于在午夜快过去的时候等来了好消息，激动的在朋友圈写下一句“跨过午夜就是新的一天到来”。几天过去了，细细回味，有些喜悦，有些激动，有些期待，又有些平静和繁忙。
这个周五的晚上线上搞活动轮到我值守，同时我也在守候一位从来没有打过交道的Press负责人jzb上线交流一些事情。稍微感到一些无聊的时候，隔着屏幕问还在线上的导师，周末了准备做啥？以前多是工作上的事情，很少涉及私人生活。Justin Mclean回的最快，告诉我周末要授几堂课，他还说他准备做顿好吃的，我说最近特意看了下你现在住的城市是什么气候类型，他还给我发了他之前做的几道菜，很有卖相可以上餐桌的那种，鱼块上还点缀了些白芝麻，一看就是很讲究的行家，我说我只会吃，不会做，他说这是他的爱好，我说我好像没有爱好，如果有，可能就是写代码，他说“Also a great hobby to have”，嗯，好吧；JB Onofré也回复了，稍微迟了些，他说他在机场，刚从都柏林回来，我说没啥事就是突然想起你来问候下你，你肯定忙着处理事情和回家，你忙吧，他说好的，周末再聊，他最有意思，每次找他他都是“I Will”但都当不得真，我想这应该是很大原因吧。
11点多的时候jzb终于上线了，打字速度好快，这感觉就像什么呢？就像我们刚从驾校培训场出来，你还在门口犹豫这就要开车上路了？还在想着是先打灯还是先扭钥匙打火时候，一辆接一辆的大货车从你旁边拖长声音地呼啸而过，心有余悸的同时感觉到整个车子都在震动，嗯，就是这个味。好在jzb是老司机了很有耐心地和我们交流完，好吧我们搞错了，培训时第一条开车安全第一条“系好安全带”都忘记了，赶紧的。
交流完值班也结束了，第二天醒来时候已是大上午，有点想说的冲动，就在微信里把以前的前同事，还有项目一起交流、探讨又很久没有联系的人找了出来，单独骚扰了下。我还给项目开始以来我一直念念不忘的一位网友Netroby发了一封邮件，告诉了下他项目的近况，也提到他对我的触动，在项目该如何为用户服务，更好的为用户服务，在项目开始的时候他给我及时的上了一堂课，很及时，这个感悟让我很受用，一直到现在，我把这个用户的概念扩展开来，不论是内部的用户，还是外部的用户，发现都是一样的，给他发邮件表达我的感谢，我觉得是必须的。后来Netroby回了邮件，聊了下。
时光荏苒，2年半的时间匆匆而过，好多人，好多事，好多感悟，那每一天就如昨天一样能清晰的回忆起细枝末节来，而当前的每一天都如刚刚收到消息又要全员核酸了一样，充满了未知的挑战和对未来的期待，这个感觉就像我朋友圈里的背景图，漫漫黄沙的月牙山上背负着行囊在爬坡，一起同行的同事mayozhang给我拍的，收到后第一眼看到我立马给他发了一个6.66的红包表示感谢，很喜欢它的意境。没有开源前自己还有点守着那点小提升偷着乐的乐呵，觉得其他项目的不过如此云云，项目开源了后，感觉就像空空如也的玻璃杯，自己也经常会发现这里还没做好，那里还需要改进，在感觉还有好多的事情还需要完善起来时新的阶段又开始了，有的时候也在想，做到什么程度才是好，我说不上来，但个人觉得项目毕业并不是，它只是一个新阶段的开始，说不上来但我感觉这就像蓝天白云下，远处是巍峨的群山之巅，一群追求技术梦想的人在辽阔的草地上朝着目标前行着，偶尔一回头，之前驻留的地方已离得很远。
今天父亲节，就这样，我得给老爸打个电话。作为项目的一份子我现在对项目的想法是什么呢，就如交流时Netroby说的：“不要急，慢慢稳步前行。一定会做的更好。”，我觉得他的这句话说出了我的心声，嗯，这里我再次感谢Netroby！
2022-05-14 ==========================================
大数据的大，到底有多大？大家所说的大和我们所说的大，是不是一样的大？
在大数据的数据集成环节，有些什么样的挑战，如何以最小的成本从数据中获取最大的价值？基于这个主题，今天下午和InLong、SeaTunnel工程师以及用户一起进行了线上技术交流，讨论两个Apache项目在数据接入领域遇到过的挑战，应对的方案，以及后面的改进思考。
活动组织者很给力，参加完活动没多久就出回放了，供阅，同时欢迎大家加入，一起继续交流探讨：
这次的交流主要讲的是InLong在消息中间件上的改进，感兴趣的可以看看（我个人部分大约从01:01:00开始），总结起来就是几个点：
- 消息中间件TubeMQ的自研效果介绍：由于我们最开始200亿条/天的接入量级，并且数据在不断的爬坡，而2013、2014年的Kafka并不是很稳定，我们选择了自研的道路构造出了TubeMQ，并根据线上情况不断的改进该系统，一直到现在。这个部分我们主要是要降成本，同时减少系统运维人力，按照目前的情况看我们的策略是有效的：从测试以及各个Kafka组件的业务使用方的情况看，TubeMQ和Kafka的机器成本耗费比大概是1 : 4 ~ 5左右，1万亿条/天的量级时Kafka大概要耗费200台机器，而TubeMQ只需要50台，按照目前接近100万亿条的量级看，Kafka大概要2万台，而TubeMQ大概约5000台，按照机器每台10万元计算，两个组件在100万亿条的量级下大概就会呈现上10亿元的机器成本差距；同时我们的运维人力很少，主要得益于系统在关键环节做了自动化处理，减少了不必要的变量引入，自动化程度提高必然带来人力的减少，对于管道性质的组件，就可以达到比较低的运维资源效果。在改进过程中介绍了一些比较重要的技术方案，从验证有效后的逆向角度来看，我们采用的技术方案确实普通不是最NP，但从满足业务需要、技术围绕业务需要进行展开的主旨出发，如何应用技术达到业务需要才是我们应该要考虑的核心目标，要不，再NB、再独一无二的技术，解决不了问题也是枉然。
- 在线上服务时我们对MQ的使用其实是组合拳：我们不仅仅有AP的业务，我们还有CP需求，虽然量很少，但确实有，我们在InLong框架里采用了Pulsar来完成高可靠的业务服务。选用的原因在于我们对支持副本同步机制的各个MQ的调研分析：Pulsar副本同步采用的是服务器端主动同步模式，相比于其他组件，比如Kafka，Pulsar的同步机制的分析我们觉得更有效更稳定。这块我们借助社区力量服务起公司内部的业务，并且我们也投入了大量的开发资源进行问题改进、功能新增及优化，一起推动Pulsar更稳定（线上时间有限，这块想表达的意思没有展开出来，这里文字总结下）；
- 最近阶段我们在MQ上的思考总结：基于TubeMQ开源，从2019年开始我们和公司内外的很多厂家、用户进行了交流和讨论，大家都提了很多问题，从个人的考虑来看，我们面对的最大问题仍是机器成本的问题，如何通过改造数据接入集成这块的实现来达到进一步缩减机器成本，仍是需要考虑的重点。从目前100万亿条的情况看，机器成本5000台按照10万块成本计算仍有5个亿，如果通过改造达到再缩减1000台，或者仍维持5000台但将接入量提升到120万亿条的话，我们就可以再节约1个亿的成本，从线上数据来看，我们也是可以达到的，不过需要改进的地方会非常的多。
本文的第一句话获得也挺有意思的，偶然所得：张晓栋Q&A答疑环节，听到线上观众提到为什么不直接用Flink的Reader对接到业务数据时候，自己偶然蹦出来的一句话。大家都在提大数据，大数据，到底多大的数据才是大呢？大家谈论的大，是不是一样的大？这个或许就是大家咋看到同一个事物进行交流的时候会遇到的一个沟通障碍，对齐了就好。而这句话个人感觉可以作为整个交流的吸引点，还有点押韵，就留在了第一行。
2022-04-03 ==========================================
InLong贡献者的故事，最近评选的Shink个人觉得挺有意思的，分享下：2021年，犀牛鸟，在校大学生，CI优化，容器优化，开源。
和他接触是去年的一次校企合作的犀牛鸟项目，负责这个活动的同事从各个部门里找出一批项目来，把这些项目介绍给到各个高校让感兴趣的同学去报名，各个项目负责人再从报名的人里挑选几位一起，针对某个课题按照我们日常的工作方式协同构建。整个周期看项目情况，一般2个月左右也可能更长，中间项目课题负责人会阶段性的在线上对齐答疑，以及对齐任务完成情况进行总结并分解下一个阶段的任务，整个活动阶段参加者可根据自身情况随时退出非强制。
说实话最初对效果的预期是比较低的：这是InLong头次参与这类活动，参与者双方都是陌生的，参与方式还都是线上神交，做Demo就是浪费彼此的投入，拿实际需求来做又有可能超出对方能力，或者，活有点复杂进度又压得太紧人家直接不玩了，他的导师、现在InLong项目负责人dockerzhang派任务的时候的讨论就是：看看先，行我们就继续“压榨”，看看最后能成啥样；不行我们就算一次不太成功的尝试，下次再改进。
由这个事情后大家也放开了，我就常跟报我负责的课题的同学说：如果太忙、太难、了解后不感兴趣想退出，或者就是不想做没意思等，没有问题，这本身就是自由的；由于我们是开源项目，大家的投入都会被系统记录，任何一个人都可以通过公开的途径看到和了解到你的贡献以及你的能力输出，你不会被埋没，所以你可以按你的意愿来发挥；因为是对外开源的，你可以随时进行贡献持续的输出，不必局限于这活动的1、2个月时间里去急着突破，因为我们项目是长期持续的。
这个是Shink在项目里的活动记录：https://github.com/apache/incubator-inlong/pulls?page=2&q=is%3Apr+author%3Ashink+is%3Aclosed，对他来说，一名在校在读学生，一个陌生的项目，一个线上实际运行的项目要求，从点滴做起，把InLong项目的CI整顺畅把容器那块做完善，这里的辛苦付出相信他有更清晰的记忆。
忙起来也挺忙的，有的时候别人问个问题还要停一下才能从思绪里出来听明白说的是啥，前一段忽然想起Shink来了（ :)，实际是他在输出排行榜里已经比较靠前了），大家通过private邮件讨论了下，都觉得确实做的不错，值得送给他一个IDea的全家桶表达下他对项目贡献的感谢，恰好4月1日走完全流程，不过不是愚人的，流程很早就开始的:)。据说今年的犀牛鸟项目又要开始了，期待新的新星。
最近忙啥呢，在对照Apache能力成熟度模型整理整个项目，有的时候也不得不感慨，Apache的这些基础规则在设计上还是很有道理的，让我们从更深层次来考虑一个产品要怎么做，而不仅仅是功能该怎样设计，唯一的问题就是资源投入太大:(，基于此，TubeMQ模块的功能又会暂停一段。
就这样。
2022-02-27 ==========================================
1.0.0版本发布 开源新发布 | Apache InLong(incubating) 进入1.0 时代！，主版本号改变了，说明离计划的主体目标也近了一步，继续构建。
随着关注项目的人越来越多，“你们InLong项目和xxx，yyy项目有什么不一样？是不是同一个东西呢？”的问题经常被问及。有什么不一样，是不是一个东西，个人觉得，把关注的项目按照文档指引撸一把，获得更多的第一手材料有了感性认识后可能会更确切一点，每个项目对外开源的时候，它基本的要求就是按照文档能够在其他环境将它所表达的内容复原出来。
InLong是腾讯TEG大数据平台部门对外开源并放到Apache上进行孵化的接入集成项目，由于它的量级达到了日均过85万亿条/天的数据量，并且是服务整个腾讯各个BG的数据接入，所以，同一个东西，在对成本、系统稳定性，以及数据端到端时延的考虑的不同，它在架构设计和代码实现上会和大家接触到的接入集成系统不太一样。观察下这个项目合入的PR，大家可以得到几个信息：1. 它所提交的PR是越来越好正向的，包括注释、单测用例、文档；2. 它所改动的地方，是比修改之前在考虑上有改进和完善的；3. 它没有为了提PR而提PR，每一处都是如issue里提到的修改内容介绍，为一个特定的功能在处理，有些可能要做上几遍才最终罢手；4. 修改不是一蹴而就，而是有计划的在展开........，可能还有其他的信息，等等，从资源角度来看，这都是需要花费很多人力物力才会去做的事情。
提及这些，想表达的是什么呢，这是一个活着的项目，并且是基于线上业务需要正在构建的项目。如果你是同行，对类似的地方有同样的切肤之痛以及对如何做有更好的见解，欢迎一起来讨论，项目后面有很多同行的人，大家可以一起来交流；如果你发现了系统中存在的问题，不论大小多少，提给社区，会有人来分析你的见解并记录下你的贡献，让你不被埋没；如果你是系统的用户，不用讲情面，用的地方存在不合理的地方，直接表达，会有这块的负责人来分析你的诉求。
欢迎大家基于自己的需要一起来共建InLong！
2021-12-31 ==========================================
0.12.0版本很顺利地发布了，没想到国内外热外开源的人还是那么多，在2个比较重要的假期里仍然有不少热爱开源的人帮忙review版本并投票，感谢！
回想起来，过的好快，年初大家决定将项目转向到大数据接入，而不单单是TubeMQ开始，做项目更名调研，与Mentor讨论怎么做，给项目起名字直到走完名字变更全流程，到最后做TubeMQ元数据存储抽象，版本的内部环境验证及升级，和内部跨BG的团队进行技术融合的交流，与外部公司及高校同学交流，不知不觉一年就过去了。这一年里，我们已经把0.10.0版本的TubeMQ服务侧全量上线，还不错，性能较之前版本提升了至少4%；除此以外，这个模块的内部服务也已走内外一体的模式运作，不管是公司外部的用户还是内部用户，只要是用了这个系统的，都将需求和问题直接提到Github的issue上进行透明化操作，如果愿意，问题提出人还可以直接提PR修改，个人觉得，这是一个好的开始，后面还会更彻底的进行运作，所有文档、测试方案、需求排版，都进行透明化的操作，个人想法是用外部开源的运作方式+内部系统的问题责任制模式来运作这种基础件，这样操作对系统，对合作方可能会更有益，我已经看到内部有越来越多的小伙伴做对接测试时自己按照文档用docker搭环境玩起来，个人觉得挺好的；这一年也是学习反思的一年，和不同的团队和个人交流讨论线上的业务需要，怎么做有了更深入的一层思考，计划在0.12.0基础上叠加内部最急需的功能验证上线后，再进行这块的铺开，欢迎这方面感兴趣的同学一起交流探讨怎么做更合适。这个也是几年前说过的，我们的环境面临着一个比较特殊的性能、成本和稳定性压力，基于这个压力，这个系统我们每年都会针对突出的问题做一个尝试性的调整，然后再进行彻底的构造，以期达到更好的性能、稳定性，或者能力扩充，相信2022年的系统会比现在更好。
还有一个很值得关注的，大数据接入方面的项目，越来越多的项目开始涌现，闭源的、开源的等等，进入Apache上孵化的，除了InLong在孵化外，这几天又有一个项目SeaTunnel也在这几天里进入到了孵化期，明年接入这块会不会更热闹，值得期待。
就这样，再见2021，你好2022！
2021-11-19 ==========================================
最近大家建立了一个Apache InLong的官方公众号，定期同步项目的动态，以及入群讨论什么的，版本发布节奏也开始按照1.5个月的样子滚动；前几天CosCon'21的线下交流，从大咖那里取得了不少的干货，一些做的不够的地方也在逐步的开始落实，比之前要好了。对于TubeMQ来说：
回来第一件事就是重新完善使用用例[1]：简化示例代码，并详细注释关键步骤，让用户更快上手；按照代立冬大师还有刘天栋大哥的说法，我们要想一想，作为一个外部用户他首先关注的是什么，项目应该从这个地方着手改进，用户入手并且有感觉后，大家才会有可能继续去了解你是怎么做的，产品的思维角度，很受用。
再一个就是增加客户端完全管控分区的分配[2]：之前TubeMQ是服务器侧分区分配，优势是客户端实现简单，不足在于消费端启动到数据被消费到的时间间隔有点长，至少是一个服务器分区分配的周期长度（可配置，缺省30秒），在我们单Topic达到过万的分区、单一消费组的客户端数量上千个的场景里，时间会更久一点，如何将这个等待时间缩短到5秒以内，被业务压着走，模块最近做了这方面的改进，相关文档会在近期整理好了发出来；
最近模块线上还有一些优化点需要处理，这块也在逐步的改造、验证、上线、发布，为了确保需求快速有效的解决，有的时候确实慢不下来，这也是像我这种做内部项目至今仍不习惯的地方：半个小时的一个对齐交流按照社区玩法得耗上很长时间才能定下来，讨论半天还不如按照想法改了拿数据对齐，清清楚楚；不过社区的慢也是很有帮助，文字写下来后能让自己静下来思考下，哪里还有需要完善的地方，并且是否有更好的想法和思路，这块感觉还是有可取和值得学习的，不完全是不足，也许是还没有到它的那个高度。
就这样，0.12.0版本轮到我发了，到时大家再见。
2021-08-22 ==========================================
前一段时间参加ApacheCon Asia项目，介绍我们的InLong项目是什么，和目前类似的接入平台相比它的特点是什么，我们后面会怎么演进这个项目，以及我们的分拣落地系统Sort是怎么做的：ApacheConAsia2021 大数据0807B：Goson，Leo-Apache InLong，一个一站式流数据集成解决方案-中文_哔哩哔哩_bilibili。
按照计划，InLong第二个版本0.10.0这个月底进行版本发布，还是老规矩，首先解决易用性问题（刚从内网线上拿下来没觉得，实际使用自己也发现这太难了:(，但没有办法，一般线上真实的、形成平台的东西都会是一个涉及前端、后台、运营等同学的组织一起来完成的，集成在一起对外发布确实存在一些标准上的差异，只能逐步的优化迭代），这个版本里针对大家反馈的易用性问题做了改进，提供docker一键化部署，把系统快速搭建起来快速上手，同时重构了一些模块局部功能，比如TubeMQ的WebAPI：这个也是前期有使用过的同学反馈的，为啥API调用后还要手工reload，能不能自动reload？系统做元数据reload的时候API调用能不能并发进行，而不是等上一轮reload完了才能做下一批？能不能由系统自己每次reload的份数，而不是外部人工管控？....... 这个版本针对这块做了改进优化，并发操作，系统自动reload，系统自动控制哪些配置刷新，同时针对Web API的实现，我们也做了实现上的重构，让这块的代码逻辑模块化更高，可读性更好，更便于大家根据需要扩展。其实这些问题也是有原因的，最初系统人工操作的，配置变更也是定期、批量进行，并且要求逐步的更替，前期的实现是满足业务需求的；而随着系统间集成度更高，对API调度访问的操作逐渐增多，这块的改进也开始有更高的要求，结合内外部用户的建议，我们这块进行了自底向上的重构，希望满足这块业务需要。
最近看到 @tison 朋友圈发的一条介绍他对社区是什么的解读，“社区是引力中心，不同人被吸引的程度不同”，同时更进一步解释，社区不是一个漏斗，应该维护这个生态的繁荣和特性的发展，而不是榨取转换中的价值。我看到这个的时候也在想，如果按照tison的思路来解析，InLong的社区应该是什么样呢？
2021-07-04 ==========================================
上图是我们数平线上日均接入量超过40万亿条/天量级的接入平台架构图，再过几天，我们把图里面所有的组件都开源出去，相关初始代码已在导入INLONG-613分支
大家也知道，一个线上运行多年、之前从未考虑过对外开源的系统要想完全剥离出来会有些难度，所以，首版本以能全流程跑通全流程为目标，用户通过Mananger基于【tube - chunk】数据模型配置接入系统的数据信息；用户手工部署文件Agent后，数据通过文件Agent实时采集并以私有协议上报给DataProxy，然后转存到TubeMQ，Sort实时消费并做简单ETL后，数据进行汇聚并存储到指定的Hive集群。最终，我们会基于首版本代码，结合社区的力量，把InLong（应龙）打造成完整的数据服务而非某个或某几个组件能力的整体开源，整合数据采集，汇聚，存储，分拣等数据处理全流程。
这里大家可能会问，相比同类产品，比如小规模厂家用的flume+kakfa，稍大规模的商业软件比如datahub，还有同类开源的Gobblin，开源的InLong最大的优势是什么？或者，它在哪方面让这里用户愿意去选择它？
个人觉得，InLong最大的优势就在于一站式，以及经实践打磨了的万亿级的高性能处理能力。一站式，用户只需要配置好数据源头、数据服务质量、数据预处理要求，以及数据落地地址，平台就可以将数据端到端的集成解决，而不需要还要额外再编写代码适配不同组件。实践打磨，类似InLong开源的前身TubeMQ，实际上这些组件都是从现网直接扒下来的正在使用的系统（从一些注释以及写法上大家应该也能感受到），我们团队是国内乃至全球的TopN大数据接入服务团队，服务的数据规模都是非常巨大的量级，我相信我们所遇到的问题大家一定将遇到或者在寻求更好处理方法，我们团队响应公司的开源号召，将线上稳定运行的这块拿出来对外，希望和大家一起面对接入这块的挑战，也许这个举动最终会化作一种借鉴思路，我个人觉得没有关系，因为这也是一种贡献和促进，而我们仍然会继续优化迭代。
当然，由于InLong是内部系统演化而来，其不足在于内部环境更聚焦，要让系统满足外部各类业务需要，还需要做更多的适配改造，比如不同语言的SDK，详尽的监控指标集成（我们通过第三方工具完成，相对而言集成在一起不是很合适），不同场景下的流入、流出系统的对接能力等。而这也是我们的初衷，结合社区的力量，按照社区的习惯和方式将系统改造为适应更多场景、更实用的一站式接入平台。
2021-04-29 ==========================================
最近Kafka发布了一个PR《深度解读：Kafka 放弃 ZooKeeper，消息系统兴起二次革命》，最新版本的Kafka已经去掉了Zookeeper，怎么说呢，英雄所见略同吧，很高兴有更多的同行选择了我们选取的路径，TubeMQ的核心逻辑已在2017年左右已经放弃了Zookeeper。不过由于BDB的LICENSE问题，我们又要做成可以依赖Zookeeper的版本，直到这块找到更好的替代组件，或者自研。
从2019年做开源，个人觉得开源最有意思的地方就在于，通过开源可以找到很多和你有同样甚至更妙想法的人，开源让大家清楚知道某个平行空间里一定有知音的存在；同时开源也是很有挑战的地方，软件不同于其他实体产品，外观一致但实现怎样只有开源了才知道做的怎样，开源后你做的怎样，是不是如你说的做的那么好，是不是在吹泡泡，拿你开源的东西溜两圈大家就清楚了；而Apache上开源又是另外一层感悟，对外开源了还不是终点，你还得让大家愿意用你的产品，不仅用了说好，还要能让用户自愿的站出来维护和改进这个产品，让它变得更好。所以哪天碰到不计报酬免费交流免费讲解，还愿意拿出commtter、pmc等角色一起共建这个项目的时候，“这猴子是谁，要做啥”，千万别误会，按照Apache规则，除了原创团队外，不仅要有个人身份的贡献者参与项目，还至少要有多家外部组织来一起参与和维护项目，才能达到毕业标准，所以，挺有挑战的，比写代码难多了：）。
再，我们项目更名完成了，由Apache TubeMQ更名为Apache InLong(应龙，中国远古引流入海神兽，借喻接入流的服务平台)，相关的链接还是有效，但最终会映射到https://github.com/apache/incubator-inlong 。从12月份向Apache提正式的更名申请到4月10日Apache完成更名实施，大概花了4个月时间，对更名时间有过长的估计，但没有预料到这个事项会耗费这么长，之前聚集的资源需要各个负责人将手头工作扫尾完成后才能再聚集起来，过一段时间，项目会动起来。从我们分析来看，数据接入这块是存在提供公共服务的可能的，比如大家用的多的用flunme + kafka，或者自研的其他采集、汇聚、分拣等，其实模式都是差不多的，InLong的整体架构如上，希望把各个环境在大数据场景下都需要重复迭代的内容进行抽象统一化，不仅给到社区，也是我们自己环境内部的一次项目改进升级。
TubeMQ仍然存在于InLong中，但不再单独出现，所以，对于这个《如何评价腾讯开源的消息中间件TubeMQ？》主题应该要让位于InLong了，有开始有结束，后面还会以TubeMQ发表一篇运维同学如何运维TubeMQ的文档，TubeMQ相关的开发改进继续在InLong的仓库里进行。毕竟研发时间投入挺长的，出彩的特性点需要时间的打磨和积累，如果有交流或者提议的时候，通过社区邮箱dev@inlong.apache.org，或者我个人的邮箱gosonzhang ，都可以找到在做这块项目的同学进行解答和交流。
就这样吧，感谢写这篇《如何评价腾讯开源的消息中间件TubeMQ？》文章的同学，让我有了说的冲动，并且还说了这么久，感谢！！
2021-03-11 ==========================================
很久没有过来了，最近发布了一个版本0.8.0-RC4，这个版本主要是在性能、易用性，可读性方面做了改进和尝试，发布和以往不同，这次的发布过程有些曲折，在我们搞清楚由于依赖的组件存在一些LICENSE问题需要处理，项目需要大改才能去掉“-WIP”发布后，本轮我们仍选择以“-WIP”形式发布，作为项目调整的一个承前启后版本。
接下来我们要整理下项目的LICENSE问题：我们元数据管理和主备切换依赖了BDB组件，而BDB的LICENSE不是标准的Apache V2协议，接下来我们要改掉元数据和主备切换的处理逻辑，过去实现的时候没有想到还有这个问题，这块实现耦合得很紧。已有的8个元数据表，再加上一些本次想新增的特性表，之上的交互逻辑，HTTP的接口，势必要花不少时间来调整，充分的测试及验证后才会发布新版本。0.8.0-RC4的这个版本可以作为前期的改进收拢，让现有的及新的使用者有一个稳定的最新版本可用；这个版本也是我们内部的现网集群升级的基础，相当于是一个大的发布版本。
除了处理LICENSE问题，项目在进行项目改名操作：项目会由现在的“TubeMQ”更换为“InLong”（应龙），应龙，中国神话故事里的神兽，引流入海，引申我们想做一个一站式的数据接入平台，通过这个平台业务基于主题的发布和订阅，即可快捷的完成数据流接入和流出服务。这也是最初开源时候我们所介绍的，我们将会把承载过40万亿条/天接入量的整个系统全部开源出来，按照Apache的规范和要求来孵化，而MQ的定位不能涵盖它的这个整体的目标，虽然TubeMQ作为它的子模块，仍继续朝高性能、高吞吐、高稳定性和低成本方向发展。我们现在正在Mentor的指导下完成这个改名操作，相关的事项还有点多，势必需要一段时间的整理和完善。相关的操作不影响现有项目的发展，如果大家有问题，或者需求，仍可以通过已有的jira，邮件组，或者slack上同名的inlong讨论组交流。
本周六，计划和一家实际的TubeMQ用户做一次线下的面对面技术交流，期待和大家一起探讨下，在大数据场景里，对MQ这块我们近几年的研究和实践情况，TubeMQ的优势，以及我们后续的考虑；其实，除了MQ，在上10万亿量级下，数据接入服务整个链条上的各个组件都值得细细的打磨，比如我们该如何用更少的机器做数据分拣，将简单ETL后的数据分发到不同的目标服务上，相对而言，MQ只是一个引子。
有机会的话我们一起多交流。
2020-12-10 ==========================================
很久没有过来说下了，总结下近况：我们现在的版本已经发布到0.7.0，正在准备0.8.0版本；年中计划的一些特性随着版本滚动在逐步的达成，既满足我们自身的业务需求，也应用到社区供有需要的外部业务使用，比如之前提到的C/C++的SDK，上线几个月后稳定得我们都已忘记了它的存在 :）；最近调研了下同类产品，有些功能性的东西会往后放，组件如何让使用者更易用会优先考虑，这里存在一个环境切换的问题，没有开源前，从系统稳定性考虑会把一些功能剥离并通过第三方系统辅助对接完成，开源出来后，如何让社区的同学更易用就值得考虑，这块正在构建中，也遇到一些还可以深挖的点，但暂时会先满足基本能力后再扩展（说实话有些点之前没深入做过还没有找到好方法不太好弄，比如做cli命令时现在是用的Cli-command组件做参数解码，但有些cli命令，我想除了主命令带参数，还想再个带子命令，子命令里又带参数怎么做才好呢？有了解的同学可以给我们贡献一把，我给你加星:) ）。
这近一年的时间，从项目被开源出去，到各种不同环境不同思想的交流碰撞，不同知识点的学习和了解，个人觉得项目的功能和能力相比开源前更进了一步，希望继续通过这个项目连到不同平行宇宙的大家，一起针对这个方面的问题学习与交流，寻找一个最优的解决办法，对于系统中的实现，有什么希望试验你的想法的地方，可以邮件告诉我（gosonzhang@apache.org）我可以找比较BT的环境验证你想法可行性；这段时间还有个个人觉得有意思的事情，开源前埋的一个彩蛋有更多的人发现，帖子里也有提到过，TubeMQ端到端的吞吐可以做到10W TPS以上，时延可以做到10ms以下，而且还有一个前提，是在单机broker上配置1000个topic，每个topic有10个partition，1份生产2份消费，1K的包大小；有同学给我反馈端到端时延好像不是这样的，好像不是10ms，而是很多都在5ms以下，我想说的是，不仅是端到端时延，TPS也是如此，开源前已验证过多轮，最终选了一个不是极致的中间数，希望用的时候大家能发现一个小惊喜，典型的技术人员思维 :(。
就这些，欢迎大家继续关注我们项目：https://tubemq.apache.org/en-us/
2020-09-16 ==========================================
预告下，ApacheCon中国区，9月30日下午6:20，40分钟，一起来聊TubeMQ：https://apachecon.com/acah2020/tracks/mandarin.html
现在社区在准备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的关注！