RocketMQ和kafka基本认识以及应用场景

一、rocketMQ

RocketMQ联合创始人：选择MQ时，要注意的有哪些？
参考URL: https://blog.csdn.net/weixin_34241036/article/details/86720807

RocketMQ 是一个来自阿里巴巴的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache 顶级项目。据了解，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在 RocketMQ 之上，并且最近几年的双十一大促中，RocketMQ 都有抢眼表现。

随着 2011 年 Kafka 从 Apache 顶级项目毕业，其自研存储引擎带来的海量消息堆积，高效的持久化特性走入我们的视野。但它特殊的日志通道定位，是不能完全满足阿里巴巴高频的在线交易场景，为此团队设计并研发了新一代消息引擎 RocketMQ（内部叫 MetaQ），从最初的日志传输领域到后来阿里集团全维度在线业务的支撑，RocketMQ 被广泛用在交易，数据同步，缓存同步，IM 通讯，流计算，IoT 等场景。

说起数据表现，RocketMQ 在 2017 年双十一当天的万亿级数据洪峰下，做到了 99.996% 的毫秒级响应，每秒支撑千万级消息发布，每条消息发布平均响应时间不超过 3 毫秒，最大不超过 20 毫秒，而核心交易链路平均 Response Time 仅 3ms，在全球 Messaging 领域做到了领先水平。

RocketMQ 在低延迟，消息重试与追踪，海量 Topic，多租户，一致性多副本，数据可靠性等问题上进行了大量优化，对电商，金融领域的用户来说，是一大利好。

二、Kafka

Kafka最初产生于LinkedIn，用于支撑LinkedIn的activity stream data 和operational metrics分析，被誉为LinkedIn的“中枢神经系统”。2011年完成Apache开源 ，2012年10月完成孵化，2014年ApacheKafka中三位核心人员Jay Kreps，NehaNarkhede和 Jun Rao联合成立Confluent公司，致力于为企业提供实时数处理服务解决方案。

Apache Kafka 为日志处理而生，目前从社区来看，发力重点在流计算，IoT 等领域，和 Apache Spark Streaming，Apache Flink，Apache Storm 等一站式流计算平台不同，它从 Apache Samza 这种轻量级方案汲取了养分，提供给用户的是一个异步编程框架，用户基于类库编程，不需要考虑分发，部署，调度等一系列传统流计算框架带来的繁琐工作。这种轻量级的解决方案在一些日志处理，ETL 等场景更受大家欢迎。

三、应用场景对比

• Kafka
  Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。

总结: Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。

大型公司建议可以选用，如果有日志采集功能，肯定是首选kafka了。

• RocketMQ
  RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

总结：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。

RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ。

应对一些高并发，高可靠以及高可用比较苛刻的场景，Apache RocketMQ 是一个不错的选择。最近留意到一个有趣的现象，国内一些中大型规模的公司普遍部署了两套消息引擎，一套选择 Apache RocketMQ 用在交易，数据分发等核心链路上，一套选择 Apache Kafka 用在大数据等在线、离线分析链路上。毫无疑问，Kafka 目前在大数据生态建设这块，确实具备一定的先发优势。
目前，国内很多金融领域的领军企业在构建自己的分布式金融体系时，也都不约而同地选择了 RocketMQ。

四、RocketMQ和Kafka对比

1. 吞吐量对比

Kafka的吞吐量最高，RocketMQ所有的消息均是顺序写文件（磁盘顺序读写速度超过内存随机读写）。
kafka在topic数量由64增长到256时，吞吐量下降了98%，rocmq只下降了16%。

原因：
这是因为Kafka的每个Topic、每个分区都会对应一个物理文件。当Topic数量增加时，消息分散的落盘策略会导致磁盘IO竞争激烈成为瓶颈。而RocketMQ所有的消息是保存在同一个物理文件中的，Topic和分区数对RocketMQ也只是逻辑概念上的划分，所以Topic数的增加对RocketMQ的性能不会造成太大的影响。

• Kafka
  Kafka的吞吐量高达17.3w/s，不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈。
• RocketMQ
  RocketMQ也表现不俗，吞吐量在11.6w/s，磁盘IO %util已接近100%。RocketMQ的消息写入内存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。

五、为什么阿里会自研RocketMQ？

（1）Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够

（2）阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高。

kafka针对海量数据，但是对数据的正确度要求不是十分严格。而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适

（3）当业务成长到一定规模，采用开源方案的技术成本会变高.

开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容都可能是问题；运维角度，Kafka使用 scala 编写，而阿里是java系。Kafka 的后续维护是个问题。

（4）阿里在团队、成本、资源投入等方面约束性条件几乎没有.

综上，阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka 不能满足或者 ActiveMQ 等其他消息中间件不能满足，财大气粗能力又强业务还复杂，所以就自己开发了。

另外认为kafka是用于日志传输，所以不适合系统的业务事件是个更大的误区，Kafka本身在最早实现时的确是为了传输日志，但后来经过多年发展，其适用范围早不限于日志，并且很多采取Kafka的公司并非用它来处理日志，kafka背后的 Confluence公司提供了很多基于kafka来简化系统实现的例子。

大家都在发展，功能的差异会很快抹平的。

RocketMQ 可以理解为是Java版 的kafka。

六、分布式消息队列RocketMQ与Kafka架构上的巨大差异之1 – 为什么RocketMQ要去除ZK依赖？

分布式消息队列RocketMQ与Kafka架构上的巨大差异之1 – 为什么RocketMQ要去除ZK依赖？
参考URL: https://blog.csdn.net/gh670011677/article/details/75095460

在早期的RocketMQ版本中，是有依赖ZK的。而现在的版本中，是去掉了对ZK的依赖，转而使用自己开发的NameSrv。

并且这个NameSrv是无状态的，你可以随意的部署多台，其代码也非常简单，非常轻量。

那不禁要问了：ZooKeeper是业界用来管理集群的一个非常常用的中间件，比如Kafka就是依赖的ZK。那为什么RocketMQ要自己造轮子，自己做集群的管理呢？纯粹就是再做一个Zookeeper吗？

• Master/Slave概念差异
  Kafka: Master/Slave是个逻辑概念，1台机器，同时具有Master角色和Slave角色。
  RocketMQ: Master/Slave是个物理概念，1台机器，只能是Master或者Slave。在集群初始配置的时候，指定死的。其中Master的broker id = 0，Slave的broker id > 0。

• Broker概念差异
  Kafka: Broker是个物理概念，1个broker就对应1台机器。
  RocketMQ：Broker是个逻辑概念，1个broker = 1个master + 多个slave。所以才有master broker, slave broker这样的概念。

那这里，master和slave是如何配对的呢？ 答案是通过broker name。具有同1个broker name的master和slave进行配对。

所以这里可以看出：RokcetMQ和Kafka关于这2对概念的定义，刚好是反过来的！Kafka是先有Broker，然后产生出Master/Slave；RokcetMQ是先定义Master/Slave，然后组合出Broker。

答案：为什么可以去ZK?

1. 在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
   而在RocketMQ中，不需要选举，Master/Slave的角色也是固定的。当一个Master挂了之后，你可以写到其他Master上，但不会说一个Slave切换成Master。

这种简化，使得RocketMQ可以不依赖ZK就很好的管理Topic/queue和物理机器的映射关系了，也实现了高可用。

说到这，答案基本就知道了：RocketMQ不需要像Kafka那样有很重的选举逻辑，它把这个问题简化了。剩下的就是topic/queue的路由信息，那用个简单的NameServer就搞定了，很轻量，还无状态，可靠性也能得到很好保证。

参考

RocketMQ联合创始人：选择MQ时，要注意的有哪些？
参考URL: https://blog.csdn.net/weixin_34241036/article/details/86720807
高并发架构系列：Kafka、RocketMQ、RabbitMQ的优劣势比较
参考URL: https://blog.csdn.net/ChenRui_yz/article/details/86154132
消息中间件相关知识以及各种消息中间件的比较
参考URL: https://blog.csdn.net/Future_LL/article/details/86752329
RocketMQ 如何取代kafka，成为滴滴出行的千亿级消息引擎新选择？
参考URL: https://www.jianshu.com/p/1efeb2e79926
Kafka、RabbitMQ、RocketMQ等消息中间件的介绍和对比
参考URL: https://www.jianshu.com/p/f2b6b4c439c5
技术选型：RocketMQ or Kafka
参考URL: https://blog.csdn.net/weixin_34104341/article/details/91441250
基于Kafka Connect的应用实践——打造实时数据集成平台
参考URL: https://cloud.tencent.com/developer/news/217133