简介：快手须要建设一个次要面向在线业务的音讯零碎作为 Kafka 的补充，低提早、高并发、高可用、高牢靠的分布式消息中间件 RocketMQ 正是咱们所需的。
作者：黄理
黄理，10多年软件开发和架构教训，热衷于代码和性能优化，开发和参加过多个开源我的项目。曾在淘宝任业务架构师多年，以后在快手负责在线音讯零碎建设工作。
为什么建设在线音讯零碎
在引入RocketMQ之前，快手曾经在大量的应用Kafka了，但并非所有状况下Kafka都是最合适的，比方以下场景：
- 业务心愿个别生产失败当前能够重试，并且不梗塞后续其它音讯的生产。
- 业务心愿音讯能够提早一段时间再投递。
- 业务须要发送的时候保障数据库操作和音讯发送是统一的（也就是事务发送）。
- 为了排查问题，有的时候业务须要肯定的单个音讯查问能力。
为了应答以上这类场景，咱们须要建设一个次要面向在线业务的音讯零碎，作为Kafka的补充。在考查的一些消息中间件中，RocketMQ和业务需要匹配度比拟高，同时部署构造简略，应用的公司也比拟多，于是最初咱们就采纳了RocketMQ。
部署模式和落地策略
在一个已有的体系内落地一个开软软件，通常大略有两种形式：
形式一，在开源软件的根底上做深度批改，很容易实现公司内须要的定制性能。但和社区开源版本各奔前程，当前如何降级？
形式二，尽量不批改社区版本（或缩小不兼容的批改），而是在它的外围或者下层进一步包装来实现公司外部须要的定制性能。
注：上图形式一的图画的比拟极其，实际上很多公司是形式一、形式二联合的。
咱们抉择了形式二。最早的时候，咱们应用的是4.5.2版本，起初社区4.7版本大幅减小了同步复制的提早，正好咱们的部署模式就是同步复制，于是就很轻松的降级了4.7系列，享受了新版本的红利。
在部署集群的时候，还会面临很多部署策略的抉择：
• 大集群 vs 小集群
• 抉择正本数
• 同步刷盘 vs 异步刷盘
• 同步复制 vs 异步复制
• SSD vs 机械硬盘
大集群会有更好的性能弹性，而小集群具备更好的隔离型，此外小集群能够不须要跨可用区/IDC部署，所以会有更好的健壮性，咱们十分看重稳定性，因而抉择了小集群。集群同步复制异步刷盘，首选SSD。
客户端封装策略
如上所述，咱们没有在Rocketmq外面做深度批改，所以须要提供一个SDK来提供公司内的须要的定制性能，这个SDK大略是这样的：
对外只提供最根本的API，所有拜访必须通过咱们提供的接口。简洁的API就像冰山的一个角，除了对外的简略接口，上面所有的货色都能够降级更换，而不会毁坏兼容性。
业务开发起来也很简略，只有须要提供Topic（全局惟一）和Group就能够生产和生产，不必提供环境、Name Server地址等。SDK外部会依据Topic解析出集群Name Server的地址，而后连贯相应的集群。生产环境和测试环境环境会解析出不同的地址，从而实现了隔离。
上图分为3层，第二层是通用的，第三层才对应具体的MQ实现，因而，实践上能够更换为其它消息中间件，而客户端程序不须要批改。
SDK外部集成了热变更机制，能够在不重启client的状况下做动静配置，比方下发路由策略（更换集群name server的地址，或者连贯到别的集群去），Client的线程数、超时工夫等。通过maven强制更新机制，能够保障业务应用的SDK基本上是最新的。
集群负载平衡 & 机房灾备
所有的Topic默认都调配到两个可用区，生产者和消费者会同时连贯至多两个独立集群（散布在不同的可用区），如下图：
生产者同时连贯两个集群，如果可用区A呈现故障，流量就会主动切换到可用区B的集群2去。咱们开发了一个小组件来实现自适应的集群负载平衡，它蕴含以下能力：
• 千万级OPS
• 灵便的权重调整策略
• 健康检查反对/事件告诉
• 并发度管制（主动升高响应慢的服务器的申请数）
• 资源优先级（相似Envoy，实现本地机房优先，或是被调服务器很多的时候选取一个子集来调用）
• 主动优先级治理
• 增量热变更
实际上它并不仅仅用于音讯生产者，而是一个通用的主调方负载平衡类库，能够在github上找到：
https://github.com/PhantomThief/simple-failover-java
外围的SimpleFailover接口和PriorityFailover类没有传递第三方依赖，非常容易整合。
多样的音讯性能
提早音讯
提早音讯是十分重要的业务性能，不过RocketMQ内置的提早音讯只能反对几个固定的提早级别，所以咱们又开发了独自的Delay Server来调度提早音讯：
上图这个构造没有间接将提早音讯发到Delay Server，而是更换Topic当前存入RocketMQ。这样的益处是能够复用现有的音讯发送接口（以及下面的所有扩大能力）。对业务来说，只须要在结构音讯的时候额定指定一个延迟时间字段即可，其它用法都不变。
事务音讯
RocketMQ 4.3版本当前反对了事务音讯，能够保障本地事务和生产发送同时胜利或者失败，对于一些业务场景很有帮忙。事务音讯的用法和原理有很多材料，这里就不细述了。但对于事务音讯的实际网上材料较少，咱们能够给出一些倡议。
首先，事务音讯性能始终在不断完善，应该应用最新的版本，至多是4.6.1当前的版本，能够防止很多问题。
其次，事务音讯性能是不如一般音讯的，它在外部实际上会生成3个音讯（一阶段1个，二阶段2个），所以性能大概只有一般音讯的1/3，如果事务音讯量大的话，要做好容量布局。回查调度线程也只有1个，不要用极限压力去考验它。
最初有一些参数注意事项。在broker的配置中：
- transientStorePoolEnable这个参数必须放弃默认值false，否则会有重大的问题。
- endTransactionThreadPoolNums是事务音讯二阶段解决线程大小，sendMessageThreadPoolNums则指定一阶段解决线程池大小。如果二阶段的处理速度跟不上一阶段，就会造成二阶段音讯失落导致大量回查，所以倡议endTransactionThreadPoolNums应该大于sendMessageThreadPoolNums，倡议至多4倍。
- useReentrantLockWhenPutMessage设置为true（默认值是false），免得线程抢锁呈现重大的不偏心，导致二阶段解决线程长时间抢不到锁。
- transactionTimeOut默认值6秒太短了，如果事务执行工夫超过6秒，就可能导致音讯失落。倡议改到1分钟左右。
生产者client也有一个注意事项，如果有多组broker，并且是2正本（有1个Slave），应该关上retryAnotherBrokerWhenNotStoreOK，免得某个Slave呈现故障当前，大量音讯发送失败。
分布式对账监控
除了比拟一些惯例的监控伎俩以外，咱们开发了一个监控程序做分布式对账。能够发现咱们的集群以及咱们提供的SDK是否有异样。
具体做法是在每个Broker上都建设一个监控专用的Topic，监控程序应用咱们本人提供的SDK框架来连贯集群（就像咱们的业务用户那样），监控生产者会给每个集群发送大量音讯。而后查看发送是否胜利：
| 发送胜利 | 胜利 |
| 刷盘超时 | |
| Slave超时 | |
| Slave不可用 | |
| 发送失败 | 具体错误码 |
| 参数 | 默认值 | 阐明 |
| flushCommitLogTimed | False | 默认值不合理，异步刷盘这个参数应该设置成true，导致频繁刷盘，对性能影响极大 |
| deleteWhen | 04 | 几点删除过期文件的工夫，删除文件时有很多磁盘读，这个默认值是正当的，有条件的话还是倡议低峰删除 |
| sendMessageThreadPoolNums | 1 | 解决生产音讯的线程数，这个线程干的事件很多，倡议设置为2～4，但太多也没有什么用。因为最终写commit log的时候只有一个线程能拿到锁。 |
| useReentrantLockWhenPutMessage | False | 如果前一个参数设置比拟大，这个最好设置为True，防止高负载下自旋锁空转耗费CPU。 |
| sendThreadPoolQueueCapacity | 10000 | 解决生产音讯的队列大小，默认值可能有点小，比方5万TPS（异步发送）的状况下，卡200ms就会爆。设置比拟小的数字可能是放心有大量大音讯撑爆内存（比方100K的话，1万个的音讯大略占用1G内存，也还好），具体能够本人算，如果都是小音讯，能够把这个数字改大。能够批改broker参数限度client发送大音讯。 |
| brokerFastFailureEnable | True | Broker端疾速失败（限流），和上面两个参数配合。这个机制可能有争议，client设置了超时工夫，如果client还违心等，并且sendThreadPoolQueue还没有满，不应该失败，sendThreadPoolQueue满了天然会回绝新的申请。但如果client设置的超时工夫很短，没有这个机制可能导致音讯反复。能够自行决定是否开启。现实状况下，能依据client设置的超时工夫来清理队列是最好的。 |
| waitTimeMillsInSendQueue | 200 | 200ms很容易导致发送失败，倡议改大，比方1000 |
| osPageCacheBusyTimeOutMills | 1000 | Page cache超时工夫，如果内存比拟多，比方32G以上，倡议改大点 |