快手基于RocketMQ的在线消息系统建设实践

推荐学习：

• 这可能是全网Java学习路线最完整，最详细的版本了，没有之一

 

为什么建设在线消息系统

在引入 RocketMQ 之前，快手已经在大量的使用 Kafka 了，但并非所有情况下 Kafka 都是最合适的，比如以下场景：

• 业务希望个别消费失败以后可以重试，并且不堵塞后续其它消息的消费。
• 业务希望消息可以延迟一段时间再投递。
• 业务需要发送的时候保证数据库操作和消息发送是一致的（也就是事务发送）。
• 为了排查问题，有的时候业务需要一定的单个消息查询能力。

为了应对以上这类场景，我们需要建设一个主要面向在线业务的消息系统，作为 Kafka 的补充。在考察的一些消息中间件中，RocketMQ 和业务需求匹配度比较高，同时部署结构简单，使用的公司也比较多，于是最后我们就采用了 RocketMQ。

部署模式和落地策略

在一个已有的体系内落地一个开软软件，通常大概有两种方式：

 

方式一：在开源软件的基础上做深度修改，很容易实现公司内需要的定制功能。但和社区开源版本分道扬镳，以后如何升级？

方式二：尽量不修改社区版本（或减少不兼容的修改），而是在它的外围或者上层进一步包装来实现公司内部需要的定制功能。

注：上图方式一的图画的比较极端，实际上很多公司是方式一、方式二结合的。

我们选择了方式二。最早的时候，我们使用的是 4.5.2 版本，后来社区 4.7 版本大幅减小了同步复制的延迟，正好我们的部署模式就是同步复制，于是就很轻松的升级了 4.7 系列，享受了新版本的红利。

在部署集群的时候，还会面临很多部署策略的选择：

• 大集群 vs 小集群
• 选择副本数
• 同步刷盘 vs 异步刷盘
• 同步复制 vs 异