引言
在前几期的消息中间件对比中，我们为Kafka和RocketMQ设定了几个性能场景（单机系统可靠性、多Topic对性能稳定性的影响以及Topic数量对单机性能的影响），这些场景大都是以服务端的吞吐能力为对比焦点。这一期，我们将从客户端的角度出发，为大家带来Kafka和RocketMQ消息及时性的对比。
何谓消息及时性?
消息及时性是指对于一条消息来说，从消息发送到消息中间件这一时刻起，到最终到达消费端所消耗的总时间。
是不是有点抽象？我们来看个物流公司配送的例子，便于理解：
卖家把货物投递给物流公司就不再关心这笔交易了，但买家此时却更希望早点收到货品，这时就到了物流公司之间比拼运送能力的时候了，如果用飞机，买家就幸福了，而轮船呢，就只能默默等待了。这个过程里买家所等待的时间，就是一次物流的整体耗时，因此我说：整体耗时越短，及时性就越好，反之，及时性就是越差
通过上面的解释明白此次试验的目的了吧，就是对于同样数量的消息，Kafka和RocketMQ哪一个会用更短的时间处理完，以减少业务等待的时间
测试目的
在消息同步收发的情况下，Kafka和RocketMQ各自发送并处理200万条128字节大小的消息，测算消息中间件从消息生产者发送第一条消息到消费者处理完最后一条消息所消耗的时间，对不同并发数下的Kafka和RocketMQ的消息及时性进行对比。
测试场景
场景描述
测试过程中，Kafka和RocketMQ均使用相同的测试环境和客户端逻辑,接收端每接收2条消息，产生1ms的时间延迟来模拟消费端的处理耗时，消息队列数均设置为8，分别记录Kafka和RocketMQ在不同的发端并发数下，从生产者发送第一条消息到消费者接收到第200W条消息的耗时.
- 测试数据如下：
我们可以看到，当发送端的并发数小的时候，Kafka和RocketMQ的接收端速度都能与之持平，Kafka表现稍好，随着发送端并发数的增加，消息处理量增大，Kafka对于发送端消息的存储能力强于RocketMQ，但是把消息投递给消费端的能力非常弱，导致消息处理的时间几乎是RocketMQ的两倍，此时RocketMQ的消息及时性远胜Kafka。
测试结论
在测试过程中，Kafka就好像是一个仓库无穷大的物流公司，货物入仓库很快，但是配送多用轮船和汽车，送货速度很慢，比如（某达速运，某通速运）。RocketMQ则像是一个仓库容量有界限的物流公司，货物入库的速度是一定的，但是配送多用飞机和汽车，送货很快（比如某丰速运）
如果公司的业务量非常小，一天中几乎不存在高峰的时段，那么Kafka或RocketMQ都可以。而当消息的处理数量上升后，Kafka累积消息的能力强于RocketMQ，但是把消息投递给消费的能力大幅下降，导致消耗过多的时间（Kafka要133秒，RocketMQ要65秒）。在消息及时性这个场景，RocketMQ完胜Kafka
附录
测试环境
服务端为单机部署，机器配置如下：
应用版本
测试脚本
未完待续
RocketMQ在这场消息及时性测试中表现优异，原因一点不奇怪，RocketMQ的索引机制起到了关键作用。消息类的对比测试也并未结束，我们会陆续加入新的评测场景，敬请期待！
12万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
