腾讯：MQ 技术产品井喷，今天来详聊一下腾讯开源消息中间件 TubeMQ

服务器侧消费负载均衡：TubeMQ采用的是服务侧负载均衡的方案，而不是客户端侧操作，提升系统的管控能力同时简化客户端实现，更便于均衡算法升级；

系统行级锁操作：对于Broker消息读写中存在中间状态的并发操作采用行级锁，避免重复问题；

Offset管理调整：Offset由各个Broker独自管理， ZK只作数据持久化存储用（最初考虑完全去掉ZK依赖，考虑到后续的功能扩展就暂时保留）；

消息读取机制的改进：相比于Kafka的顺序块读,TubeMQ采用的是消息随机读取模式,同时为了降低消息时延又增加了内存缓存读写,对于带SSD设备的机器,增加消息滞后转SSD消费的处理，解决消费严重滞后时吞吐量下降以及SSD磁盘容量小、刷盘次数有限的问题，使其满足业务快速生产消费的需求（后面章节详细介绍）；

消费者行为管控：支持通过策略实时动态地控制系统接入的消费者行为，包括系统负载高时对特定业务的限流、暂停消费，动态调整数据拉取的频率等；

服务分级管控：针对系统运维、业务特点、机器负载状态的不同需求，系统支持运维通过策略来动态控制不同消费者的消费行为，比如是否有权限消费、消费时延分级保证、消费限流控制，以及数据拉取频率控制等；

系统安全管控：根据业务不同的数据服务需要，以及系统运维安全的考虑， TubeMQ系统增加了TLS传输层加密管道，生产和消费服务的认证、授权，以及针对分布式访问控制的访问令牌管理，满足业务和系统运维在系统安全方面的需求；

资源利用率提升改进：相比于Kafka ， TubeMQ采用连接复用模式，减少连接资源消耗；通过逻辑分区构造，减少系统对文件句柄数的占用，通过服务器端过滤模式，减少网络带宽资源使用率；通过剥离对Zookeeper的使用，减少Zookeeper的强依赖及瓶颈限制；

客户端改进：基于业务使用上的便利性以，我们简化了客户端逻辑，使其做到最小的功能集合，我们采用基于响应消息的接收质量统计算法来自动剔出坏的Broker节点，基于首次使用时作连接尝试来避免大数据量发送时发送受阻（具体内容见后面章节介绍）。

这一块基本上说清楚了特点，以及与其他MQ的一些特色的地方，其实可以猜到，一直在和kafka做对比，很多地方参与并改进了kafka ，在管理能力上做了不少思考和新的实现。
TubeMQ客户端的演进：
业务与TubeMQ接触得最多的是消费侧，怎样更适应业务特点、更方便业务使用我们在这块做了比较多的改进：
数据拉取模式支持Push、Pull：

Push客户端：TubeMQ最初消费端版本只提供Push模式的消费，这种模式能比较快速地消费数据，减轻服务端压力，但同时也带来一个问题，业务使用的时候因为无法控制拉取频率，从而容易形成数据积压数据处理不过来；

带消费中止/继续的Push客户端：在收到业务反馈能否控制Push拉取动作的需求后，我们增加了resumeConsume/pauseConsume函数对，让业务可以模拟水位线控制机制，状态比较繁忙时调用pauseConsume函数来中止Lib后台的数据拉取，在状态恢复后，再调用resumeConsume通知Lib后台继续拉取数据；
Pull客户端：我们后来版本里增加了Pull客户端，该客户端有别于 – Push客户端，是由业务而非Lib主动的拉取消息并对数据处理的结果进行成功与否的确认，将数据处理的主动权留给业务。这样处理后，虽然服务端压力有所提升，但业务消费时积压情况可大大缓解。