为什么选择RocketMQ消息中间件？
主流的MQ有很多，比如ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等。
之前阿里巴巴也是使用ActiveMQ，随着业务发展，ActiveMQ IO 模块出现瓶颈，后来阿里巴巴 通过一系列优化但是还是不能很好的解决，之后阿里巴巴把注意力放到了主流消息中间件kafka上面，但是kafka并不能满足他们的要求，尤其是低延迟和高可靠性。
所以RocketMQ是站在巨人的肩膀上（kafka），又对其进行了优化让其更满足互联网公司的特点。它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。 RocketMQ目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
下面的内容是来自阿里中间件团队博客关于一些RocketMQ与其他中间件的差异，以及性能等。
RocketMQ与kafka对比（18项差异）【转】
淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
数据可靠性
RocketMQ支持异步实时刷盘，同步刷盘，同步复制，异步复制
卡夫卡使用异步刷盘方式，异步复制/同步复制
总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。Kafka同步Replication理论上性能低于RocketMQ的同步Replication，原因是Kafka的数据以分区为单位组织，意味着一个Kafka实例上会有几百个数据分区，RocketMQ一个实例上只有一个数据分区，RocketMQ可以充分利用IO组Commit机制，批量传输数据，配置同步Replication与异步Replication相比，性能损耗约20%~30%，Kafka没有亲自测试过，但是个人认为理论上会低于RocketMQ。
性能对比
卡夫卡单机写入TPS约在百万条/秒，消息大小10个字节
RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节
总结：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。 RocketMQ为什么没有这么做？
制片人通常使用的Java语言，缓存过多消息，GC是个很严重的问题
Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错
Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。
缓存的功能完全可以由上层业务完成。
单机支持的队列数
Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长。Kafka分区数无法过多的问题
RocketMQ单机支持最高5万个队列，负载不会发生明显变化
队列多有什么好处？
单机可以创建更多话题，因为每个主题都是由一批队列组成
消费者的集群规模和队列数成正比，队列越多，消费类集群可以越大
消息投递实时性
Kafka使用短轮询方式，实时性取决于轮询间隔时间，0.8以后版本支持长轮询。
RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。
消费失败重试
卡夫卡消费失败不支持重试。
RocketMQ消费失败支持定时重试，每次重试间隔时间顺延
总结：例如充值类应用，当前时刻调用运营商网关，充值失败，可能是对方压
力过多，稍后再调用就会成功，如支付宝到银行扣款也是类似需求。
这里的重试需要可靠的重试，即失败重试的消息不因为Consumer宕机导致丢失。
严格的消息顺序
卡夫卡支持消息顺序，但是一台代理宕机后，就会产生消息乱序
RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序
MySQL的二进制日志分发需要严格的消息顺序
定时消息
卡夫卡不支持定时消息
RocketMQ支持两类定时消息
开源版本RocketMQ仅支持定时级别，定时级用户可定制
阿里云MQ指定的毫秒级别的延时时间
分布式事务消息
卡夫卡不支持分布式事务消息
阿里云MQ支持分布式事务消息，未来开源版本的RocketMQ也有计划支持分布式事务消息
消息查询
卡夫卡不支持消息查询
RocketMQ支持根据消息标识查询消息，也支持根据消息内容查询消息（发送消息时指定一个消息密钥，任意字符串，例如指定为订单编号）
总结：消息查询对于定位消息丢失问题非常有帮助，例如某个订单处理失败，是消息没收到还是收到处理出错了。
消息回溯
卡夫卡理论上可以按照偏移来回溯消息
RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息
总结：典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。
消费并行度
Kafka的消费并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行消费（每台机器只能开启一个线程），或者一台机器消费（10个线程并行消费）。即消费并行度和分区数一致。
RocketMQ消费并行度分两种情况
顺序消费方式并行度同卡夫卡完全一致
乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。
消息轨迹
卡夫卡不支持消息轨迹
阿里云MQ支持消息轨迹
开发语言友好性
卡夫卡采用scala编写
RocketMQ采用的Java语言编写
券商端消息过滤
卡夫卡不支持代理端的消息过滤
RocketMQ支持两种代理端消息过滤方式
根据消息变量来过滤，相当于子主题概念
向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message身体的过滤拆分。
消息堆积能力
理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也可以支持亿级的消息堆积能力，我们认为这个堆积能力已经完全可以满足业务需求。
开源社区活跃度
卡夫卡社区更新较慢
RocketMQ的GitHub的社区有250个个人，公司用户登记了联系方式，QQ群超过1000人。 MQ ###商业支持
卡夫卡原开发团队成立新公司，目前暂没有相关产品看到
RocketMQ在阿里云已经商业化，目前以云服务形式供大家商用，并向用户承诺99.99%的可靠性，同时彻底解决了用户自己搭建MQ产品的运维复杂性问题
成熟度
卡夫卡在日志领域比较成熟
RocketMQ在阿里集团内部有大量的应用在使用，每天都产生海量的消息，并且顺利支持了多次天猫双十一海量消息考验，是数据削峰填谷的利器。
Kafka、RabbitMQ、RocketMQ消息中间件的对比 —— 消息发送性能 【转】
引言
分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。
那么,消息中间件性能究竟哪家强?
带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性能比较。
Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
测试目的
对比Kafka、RabbitMQ、RocketMQ发送小消息(124字节)的性能。这次压测我们只关注服务端的性能指标,所以压测的标准是:
不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时服务端已出现性能瓶颈,可以获得相应的系统最佳吞吐量。
测试场景
在同步发送场景中，三个消息中间件的表现区分明显：
Kafka的吞吐量高达17.3w/s，不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈。
RocketMQ也表现不俗，吞吐量在11.6w/s，磁盘IO %util已接近100%。RocketMQ的消息写入内存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。
RabbitMQ的吞吐量5.95w/s，CPU资源消耗较高。它支持AMQP协议，实现非常重量级，为了保证消息的可靠性在吞吐量上做了取舍。我们还做了RabbitMQ在消息持久化场景下的性能测试，吞吐量在2.6w/s左右。
测试结论
在服务端处理同步发送的性能上，Kafka>RocketMQ>RabbitMQ。
附录：
测试环境
服务端为单机部署，机器配置如下：
应用版本：
测试脚本
Kafka vs RocketMQ—— Topic数量对单机性能的影响【转】
引言
上一期我们对比了三类消息产品(Kafka、RabbitMQ、RocketMQ)单纯发送小消息的性能，受到了程序猿们的广泛关注，其中大家对这种单纯的发送场景感到并不过瘾，因为没有任何一个网站的业务只有发送消息。本期，我们就来模拟一个真实的场景：
消息的发送和订阅一定是共存的
要支持多个订阅端订阅自己感兴趣的消息 鉴于上一期Kafka和RocketMQ的指标和关注度很高，本期我们将只针对这两个产品，对比在上述场景中，究竟谁更胜一筹。在正式开始测试之前，首先要向大家明确2个概念：
Topic为何物
Topic是消息中间件里一个重要的概念，每一个Topic代表了一类消息，有了多个Topic，就可以对消息进行归类与隔离。
可以参照下图的动物园喂食模型，每一种动物都只能消费相对应的食品。
分区为何物
Kafka和RocketMQ都是磁盘消息队列的模式，对于同一个消费组，一个分区只支持一个消费线程来消费消息。过少的分区，会导致消费速度大大落后于消息的生产速度。所以在实际生产环境中，一个Topic会设置成多分区的模式，来支持多个消费者，参照下图：
在互联网企业的实际生产环境中，Topic数量和分区都会比较多，这就要求消息中间件在多Topic共存的时候，依然能够保证服务的稳定性。下面就进入测试环节，看看消息发送端，订阅端共存时，Kafka和RocketMQ对多Topic的处理能力。
测试目的
对比发送端、接收端共存情况下，Topic数量对Kafka、RocketMQ的性能影响，分区数采用8个分区。这次压测我们只关注服务端的性能指标，所以压测的退出标准是:
不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。此时服务端出现性能瓶颈，获取相应的系统最佳吞吐量，整个过程中保证消息没有累积。
测试场景
默认每个Topic的分区数为8，每个Topic对应一个订阅者，逐步增加Topic数量。得到如下数据：
| 产品 | Topic数量 | 发送端并发数 | 发送端RT（ms） | 发送端TPS | 消费端TPS |
|---|---|---|---|---|---|
| RocketMQ | 64 | 800 | 8 | 9w | 8.6w |
| 128 | 800 | 9 | 7.8w | 7.7w | |
| 256 | 800 | 10 | 7.5w | 7.5w | |
| Kafka | 64 | 800 | 5 | 13.6w | 13.6w |
| 128 | 256 | 23 | 8500 | 8500 | |
| 256 | 256 | 133 | 2215 | 2352 |
可以看到，不论Topic数量是多少，Kafka和RocketMQ均能保证发送端和消费端的TPS持平，就是说，保证了消息没有累积。
根据Topic数量的变化，画出二者的消息处理能力的对比曲线如下图：
从图上可以看出：
Kafka在Topic数量由64增长到256时，吞吐量下降了98.37%。
RocketMQ在Topic数量由64增长到256时，吞吐量只下降了16%。
为什么两个产品的表现如此悬殊呢？这是因为Kafka的每个Topic、每个分区都会对应一个物理文件。当Topic数量增加时，消息分散的落盘策略会导致磁盘IO竞争激烈成为瓶颈。而RocketMQ所有的消息是保存在同一个物理文件中的，Topic和分区数对RocketMQ也只是逻辑概念上的划分，所以Topic数的增加对RocketMQ的性能不会造成太大的影响。
测试结论
在消息发送端，消费端共存的场景下，随着Topic数的增加Kafka吞吐量会急剧下降，而RocketMQ则表现稳定。因此Kafka适合Topic和消费端都比较少的业务场景，而RocketMQ更适合多Topic，多消费端的业务场景。
附录：
测试环境
服务端为单机部署，机器配置如下：
| CPU | 24核 |
|---|---|
| 内存 | 94G |
| 硬盘 | Seagate Constellation ES (SATA 6Gb/s) 2,000,398,934,016 bytes [2.00 TB] 7202 rpm |
| 网卡 | 1000Mb/s |
应用版本：
| 消息中间件 | 版本 |
|---|---|
| Kafka | 0.8.2 |
| RocketMQ | 3.4.6 |
测试脚本
| 压力端 | Jmeter的java客户端 |
|---|---|
| 消息大小 | 128字节 |
| 并发数 | 能达到服务端最大TPS的最优并发 |
| Topic分区数量 | 8 |
| 刷盘策略 | 异步落盘 |
未完待续
经过上面的测试，RocketMQ几乎是完胜Kafka，其实这并不奇怪，因为RocketMQ就是针对互联网的生产要求孕育而生的，读者现在也应该明白为什么RocketMQ可以支撑阿里集团的海量消息业务了吧。
本期测试暂时告一段落了，测试中涉及到的多Topic场景，其实压测时间均只有20分钟，对于一个消息中间件产品来说，过短的执行时间是无法判断它们的稳定性的。下一期我们会继续探索多分区场景下，Kafka和RocketMQ对外服务的稳定性。敬请期待后续的比拼！
Kafka vs RocketMQ——多Topic对性能稳定性的影响【转】
引言
上期我们对比了RocketMQ和Kafka在多Topic场景下，收发消息的对比测试，RocketMQ表现稳定，而Kafka的TPS在64个Topic时可以保持13万，到了128个Topic就跌至0.85万，导致无法完成测试。我们不禁要问：
为什么看不到Kafka性能暴跌的趋势呢？
今天的测试，就来排查一下这个问题，然后验证一下两个系统对外服务的稳定性。本次测试，要引入“稳定性测试”这个概念，那什么是稳定性测试呢？我们先来看一下定义：
稳定性测试：测试系统的长期稳定运行能力。在系统运行过程中，对系统施压，观察系统的各种性能指标以及服务器的负载指标。
好像有点抽象，我们还是看一个例子吧。
下面的测试对比图，是用来评测汗血宝马和蒸汽机车谁快的一组竞速曲线：
图1 汗血宝马和蒸汽火车的速度稳定性对比
上图的横轴表示测试时间，纵轴表示火车和马的速度，可以看到，马的加速和最高速度均好于火车。但是由于体力原因，15分钟后，马就很难维持最高速度，只能稍作休息再加速，直至体力耗尽；而火车全程达到最高速度就基本不会变了。所以结论很明显，火车的速度稳定性优于汗血宝马。
假想一下：如果测试时间只取15分钟会得到什么结论呢？汗血宝马无论是加速，还是最高速度，乃至单位时间内通过的路程均完胜火车。所以如果是要对长途运输做一个评测的话，那么正确的测试方式是——拉长测试时间，以观察被测对象的稳定性。
OK，再次回到我们上次测试留下的疑问——暴跌无趋势。其原因很可能是，在早期的32Topic，64Topic时，Kafka就已经出现了下跌的趋势，只是我们压测的时间不够，算作测试通过了。
本期测试，我们沿用上一期的测试方式，唯一不同的就是把压测时间从15分钟拉长到1小时，看看在较长的压力时间内，Kafka和RocketMQ哪一个产品对外服务更稳定。
测试目的
消息收发端共存的情况下，RocketMQ和Kafka各运行约1个小时，观察不同Topic数量时，Kafka、RocketMQ性能指标（TPS&响应时间）的波动性。
测试场景
默认每个Topic的分区数为8，每个Topic对应一个订阅者，逐步增加Topic的数量，这里性能是否抖动根据趋势图做直观的判断，数据如下：
做完全部的测试场景后会发现，正如之前的猜测，Kafka在32和64个Topic时，就已经出现了不稳定的情况。下面看一下32和64个Topic的详细数据，如下图所示：
图2. 32个Topic性能曲线对比
蓝色Kafka的TPS曲线在18分钟以后，就开始上下波动，毫无规律，而RocketMQ则表现稳定。下面再看64个Topic的情况，如下图所示：
图3. 64个Topic性能曲线对比
图4. 64个Topic客户端发送响应时间对比
Kafka的TPS在前20分钟保持稳定，并大幅度领先RocketMQ。20分钟后又开始出现不规则波动，这些波动直接导致响应时间的变化（图4），某个时刻Kafka的客户端响应时间会达到25毫秒，而RocketMQ全程都是5毫秒。 这次的对比3个场景中， Kafka胜出一个，就是8个Topic的场景，如图5所示，由于Topic个数和分区数的限制，导致Kafka只适合小规模的业务系统。
图5. 8个Topic性能曲线对比
测试结论
Topic数的增加对RocketMQ无影响，长时间运行服务非常稳定。
Kafka 的Topic数量建议不要超过8个。8个以上的Topic会导致Kafka响应时间的剧烈波动，造成部分客户端的响应时间过长，影响客户端投递的实时性以及客户端的业务吞吐量。
附录
测试环境
服务端为单机部署，机器配置如下：
| CPU | 24核 |
|---|---|
| 内存 | 94G |
| 硬盘 | Seagate Constellation ES (SATA 6Gb/s) 2.00 TB 7202 rpm |
| 网卡 | 1000Mb/s |
应用版本：
| 消息中间件 | 版本 |
|---|---|
| Kafka | 0.8.2 |
| RocketMQ | 3.4.8 |
测试脚本:
| 压力端 | Jmeter的java客户端 |
|---|---|
| 消息大小 | 128 字节 |
| 并发数 | 能达到服务端最大TPS的最优并发 |
| Topic分区数量 | 8 |
| 刷盘策略 | 异步落盘 |
未完待续
经过本期的测试，RocketMQ在稳定性上也是完胜Kafka，如果只是小规模的业务，Kafka可以满足需求，但要是对业务的复杂度和稳定性有更高的要求，RocketMQ则是更好的选择。
本期测试暂时告一段落了，但Kafka和RocketMQ的对战并没有停止，更多的场景对比还在后面，敬请期待后续的比拼！
Kafka vs RocketMQ——单机系统可靠性 【转】
引言
前几期的评测中，我们对比了Kafka和RocketMQ的吞吐量和稳定性，本期我们要引入一个新的评测标准——软件可靠性。
何为
“可靠性”？
先看下面这种情况：有A，B两辆越野汽车，在城市的周边地区均能很好应对泥泞的路况。当一同开去穿越西藏，A车会因为西藏本地的汽油不达标，导致油路受阻无法点火，而B车顺利完成了穿越。因此我们说，B车的可靠性比A车高。
何为
“软件可靠性”？
“软件的可靠性”就是考察软件在各种异常突发的情况下的应对能力。常见的软件异常有：磁盘损坏、进程意外退出、宿主机宕机等情况。
何为
“消息中间件的可靠性”？
对于消息中间件来说，“可靠性”最直接的指标就是——消息数据不丢失。此外，消息不重投、服务一主多备等特性也可以用来评估可靠性。
那么Kafka和RocketMQ（以下简称RMQ）在可靠性上孰优孰劣呢？和我们走进本期的测试比拼吧！
测试目的
在消息收发的过程中，分别模拟Broker服务进程被Kill、物理机器掉电的异常场景，多次实验，查看极端情况下消息系统的可靠性。
测试场景
以下场景使用多个发送端向一个Topic发送消息，发送方式为同步发送，分区数为8，只启动一个订阅者。
场景1. 模拟进程退出
在消息收发过程中，利用Kill -9 命令使Broker进程终止，然后重新启动，得到可靠性数据如下：
注：以上测试场景中Kafka的异步刷盘间隔为1秒钟，同步发送需设置request.required.acks=1，否则会出现消息丢失。
在Broker进程被终止重启，Kafka和RMQ都能保证同步发送的消息不丢，因为进程退出后操作系统能确保将该进程遗留在内存的数据刷到磁盘上。实验中，Kafka出现了极少量的消息重复。再次可以确定此场景中，二者的可靠性都很高。
场景2. 模拟机器掉电
在消息收发过程中，直接拔掉Broker所在的宿主机电源，然后重启宿主机和Broker应用。因受到机房断电限制，我们在本场景测试中使用的是普通PC机器。得到可靠性数据如下：
测试发现，即使在并发很低的情况下，Kafka和RMQ都无法保证掉电后不丢消息。这个时候，就需要改变刷盘策略了。我们把刷盘策略由“异步刷盘”变更为“同步刷盘”，就是说，让每一条消息都完成存储后才返回，以保证消息不丢失。 注：关于两种刷盘模式的详细区别可以参照文档最下方的说明
重新执行上面的测试，得到数据如下：
首先，设置同步刷盘时，二者都没出现消息丢失的情况。限于我们使用的是普通PC机器，两者吞吐量都不高。此时Kafka的最高TPS仅有500条/秒，RMQ可以达到4000条/秒，已经是Kafka的8倍。
为什么Kafka的吞吐量如此低呢？因为Kafka本身是没有实现任何同步刷盘机制的，就是说在这种场景下测试，Kafka注定是要丢消息的。但要想做到每一条消息都在落盘后才返回，我们可以通过修改异步刷盘的频率来实现。设置参数log.flush.interval.messages=1，即每条消息都刷一次磁盘。这样的做法，Kafka也不会丢消息了，但是频繁的磁盘读写直接导致性能的下降。
另外，二者在服务恢复后，均出现了消息重复消费的情况，这说明消费位点的提交并不是同步落盘的。不过，幸好Kafka和RMQ都提供了自定义消费位点的接口，来避免大量的重复消费。
测试结论
在Broker进程被Kill的场景， Kafka和RocketMQ都能在保证吞吐量的情况下，不丢消息，可靠性都比较高。
在宿主机掉电的场景，Kafka与RocketMQ均能做到不丢消息，此时Kafka的吞吐量会急剧下跌，几乎不可用。RocketMQ则仍能保持较高的吞吐量。
在单机可靠性方面，RocketMQ综合表现优于Kafka。
附录:
测试环境
服务端为单机部署，机器配置如下：
应用版本：
测试脚本
同步刷盘和异步刷盘的区别
同步刷盘是在每条消息都确认落盘了之后才向发送者返回响应；而异步刷盘中，只要消息保存到Broker的内存就向发送者返回响应，Broker会有专门的线程对内存中的消息进行批量存储。所以异步刷盘的策略下，当机器突然掉电时，Broker内存中的消息因无法刷到磁盘导致丢失。
未完待续
本期测试中，RocketMQ比Kafka具有更高的单机可靠性。对于普通业务，部署异步刷盘模式可以得到更高的性能；对于丢消息零容忍的业务，则更适用RocketMQ同步刷盘的模式，在享受高可靠性保障的同时，又能拥有较高的吞吐量。
实际上，单机可靠性只是软件可靠性测试的一个环节，Kafka和RocketMQ都提供了主备机模式，来解决服务器的单点故障。这点我们在后续会继续实验摸索，敬请期待接下来的比拼！