kafka与rocketmq

kafka与Rocketmq的区别

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化。

2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，

但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，

为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

数据可靠性

  • RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication
  • Kafka使用异步刷盘方式，异步Replication

总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。

同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。

另外Kafka的Replication以topic为单位，支持主机宕机，备机自动切换，但是这里有个问题，由于是异步Replication，那么切换后会有数据丢失，同时Leader如果重启后，会与已经存在的Leader产生数据冲突。开源版本的RocketMQ不支持Master宕机，Slave自动切换为Master，阿里云版本的RocketMQ支持自动切换特性。

性能对比

  • Kafka单机写入TPS约在百万条/秒，消息大小10个字节
  • RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节

总结：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。

RocketMQ为什么没有这么做？

  1. Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题
  2. Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错
  3. Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。
  4. 缓存的功能完全可以由上层业务完成。

单机支持的队列数

  • Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
  • RocketMQ单机支持最高5万个队列，Load不会发生明显变化

队列多有什么好处？

  1. 单机可以创建更多Topic，因为每个Topic都是由一批队列组成
  2. Consumer的集群规模和队列数成正比，队列越多，Consumer集群可以越大

消息投递实时性

  • Kafka使用短轮询方式，实时性取决于轮询间隔时间
  • RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。

消费失败重试

  • Kafka消费失败不支持重试
  • RocketMQ消费失败支持定时重试，每次重试间隔时间顺延

总结：例如充值类应用，当前时刻调用运营商网关，充值失败，可能是对方压力过多，稍后在调用就会成功，如支付宝到银行扣款也是类似需求。

这里的重试需要可靠的重试，即失败重试的消息不因为Consumer宕机导致丢失。

严格的消息顺序

  • Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序
  • RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序

Mysql Binlog分发需要严格的消息顺序

定时消息

  • Kafka不支持定时消息
  • RocketMQ支持两类定时消息
    • 开源版本RocketMQ仅支持定时Level
    • 阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间

分布式事务消息

  • Kafka不支持分布式事务消息
  • 阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息

消息查询

  • Kafka不支持消息查询
  • RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）

总结：消息查询对于定位消息丢失问题非常有帮助，例如某个订单处理失败，是消息没收到还是收到处理出错了。

消息回溯

  • Kafka理论上可以按照Offset来回溯消息
  • RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息

总结：典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。

消费并行度

  • Kafka的消费并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行消费（每台机器只能开启一个线程），或者一台机器消费（10个线程并行消费）。即消费并行度和分区数一致。

  • RocketMQ消费并行度分两种情况

    • 顺序消费方式并行度同Kafka完全一致
    • 乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。

消息轨迹

  • Kafka不支持消息轨迹
  • 阿里云ONS支持消息轨迹

开发语言友好性

  • Kafka采用Scala编写
  • RocketMQ采用Java语言编写

Broker端消息过滤

  • Kafka不支持Broker端的消息过滤
  • RocketMQ支持两种Broker端消息过滤方式
    • 根据Message Tag来过滤，相当于子topic概念
    • 向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。

消息堆积能力

理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也可以支持亿级的消息堆积能力，我们认为这个堆积能力已经完全可以满足业务需求。

成熟度

  • Kafka在日志领域比较成熟
  • RocketMQ在阿里集团内部有大量的应用在使用，每天都产生海量的消息，并且顺利支持了多次天猫双十一海量消息考验，是数据削峰填谷的利器。

技术选型：RocketMQ or Kafka

当业务需要系统间调用解耦时，MQ 是一个很好的方案，目前选择最多的当属Kafka和阿里的RocketMQ, 两种中间件都可以使用，都是备选方案，摆在面前，怎么选择？

  1. 方法论-评估和选择备选方案的方法

按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。

  1. RocketMQ 和 Kafka 到底有什么区别？

（1） 适用场景

Kafka适合日志处理；

RocketMQ适合业务处理。

结论：平手，根据具体业务定夺。

（2） 性能

Kafka单机写入 TPS 号称在百万条/秒；

RocketMQ 大约在10万条/秒。

结论：追求性能的话，Kafka单机性能更高。

（3） 可靠性

RocketMQ支持异步/同步刷盘;异步/同步Replication；

Kafka使用异步刷盘方式，异步Replication。

结论：RocketMQ所支持的同步方式提升了数据的可靠性。

（4） 实时性

均支持pull长轮询，RocketMQ消息实时性更好

结论：RocketMQ 胜出。

（5） 支持的队列数

Kafka单机超过64个队列/分区，消息发送性能降低严重；

RocketMQ 单机支持最高5万个队列，性能稳定

结论：长远来看，RocketMQ 胜出，这也是适合业务处理的原因之一

（6） 消息顺序性

Kafka 某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序；

RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，

发送消息会失败，但是不会乱序；

结论：RocketMQ 胜出

（7）消费失败重试机制

Kafka消费失败不支持重试

RocketMQ消费失败支持定时重试，每次重试间隔时间顺延。

（8）定时/延时消息

Kafka不支持定时消息；

RocketMQ支持定时消息

（9）分布式事务消息

Kafka不支持分布式事务消息；

阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息

（10）消息查询机制

Kafka不支持消息查询

RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息

（11）消息回溯

Kafka理论上可以按照Offset来回溯消息

RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息

  1. 为什么阿里会自研RocketMQ？

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

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

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

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

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

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

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

  1. 其他

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

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

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

更多的性能对比可以参考阿里中间件团队的报告。

Kafka理论概述和应用场景

1.Kafka概述

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。

简单地说，Kafka就相比是一个邮箱，生产者是发送邮件的人，消费者是接收邮件的人，Kafka就是用来存东西的，只不过它提供了一些处理邮件的机制。

                            

2.Kafka相关名词分析

  • Broker：Kafka节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群
  • Topic：一类消息，消息存放的目录即主题，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发
  • massage： Kafka中最基本的传递对象。
  • Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列
  • Segment：partition物理上由多个segment组成，每个Segment存着message信息
  • Producer : 生产者，生产message发送到topic
  • Consumer : 消费者，订阅topic并消费message, consumer作为一个线程来消费
  • Consumer Group：消费者组，一个Consumer Group包含多个consumer
  • Offset：偏移量，理解为消息partition中的索引即可

下面做进一步说明：

    broker即kafka程序，kafka程序运行于zookeeper之上，zookeeper是一个分布式的，分布式应用程序的协调服务，其提供的功能包括：配置维护、域名服务、分布式同步、组服务等。在此处，zookeeper协调kafka节点的配置、同步操作等。

    topic即主题，kafka中发布消息、订阅消息的对象是topic。我们可以为每类数据创建一个topic。一个topic中的消息数据按照多个partition组织，分区是kafka消息队列组织的最小单位(并不是物理上的最小单位)，一个分区可以看作是一个FIFO（ First Input First Output的缩写，先进先出队列）的队列。如下图：

                      

例如，在上图中，一个topic被分成了3个分区（即partition0~2），用户发布message时，可以指定message所处topic的partition，如果没有指定，则随机分布到该topic的partition。发布的消息（其实是逻辑日志）将在partition尾部插入。

  segment是partition的物理存储单元，kafka收到message后，会向对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被保存到磁盘，只有被保存到磁盘上的消息consumer才能消费，segment达到一定的大小后将不会再往该segment写数据，kafka会创建新的segment。其实，每个partition相当于分配到多个大小相等segment数据文件中。但每个segment消息数量不一定相等，这种特性方便无用的segment快速被删除，segment文件生命周期由服务端配置参数决定。如下图：

                              

  consumer和consumer group，一个consumer group包含多个consumer,用户可以指定consumer的group。各个consumer可以组成一个group，partition中的每个message只能被一个group中的一个consumer消费，如果一个message想要被多个consumer消费的话，那么这些consumer必须在不同的group。kafka不支持一个partition中的message同时由两个或两个以上的consumer thread来处理，即便是来自不同的consumer group的也不行。kafka为了保证吞吐量，只允许一个consumer去访问一个partition。如果觉得效率不高，可以加partition的数量来横向扩展，再加新的consumer去消费，充分发挥了横向的扩展性，吞吐量极高。这也就形成了分布式消费的概念。如下图：

                                                    

上图中有两个服务器的kafka群集，它们有四个分区（P0-P3），其中有两个group。group A有两个消费者，group B有四个消费者。P0如果被C1消费后，则C2不能再消费，但是group B的C3或者其它的一个可以消费P0。

3.Kafka的优势

  • 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
  • 可扩展性：kafka集群支持热扩展
  • 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
  • 容错性：允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）
  • 高并发：支持数千个客户端同时读写

4.Kafka应用场景

  • 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer
  • 消息系统：解耦生产者和消费者、缓存消息等
  • 用户活动跟踪：kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后消费者通过订阅这些topic来做实时的监控分析，亦可保存到数据库
  • 运营指标：kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告
  • 流式处理：比如spark streaming和storm；

RocketMQ —— 优点及基础理论

更深入的了解RocketMQ一些优点，以及队列的基础知识。

设计优点

优点描述
支持分布式 原生支持分布式,ActiveMQ原生存在单点
严格的消息顺序 保证严格的消息顺序，ActiveMQ无法保证
海量消息低延迟 RocketMQ支持亿级消息堆积能力，并可以保证亿级消息写入时达到低延迟
消息拉取模式 1. PUSH：消费者端设置Listener
2. PULL：应用可主动从Broker获取消息，主动拉取会存在消费记录位置问题（如果不记录位置，会出现重复消费）
分布式协调 Metaq1.x/2.x版本，分布式协调采用Zookeeper，RocketMQ通过自己实现NameServer达到分布式协调，更轻量，由于自主实现，更贴近框架，性能更好
其它 消费重试机制、高效订阅者水平扩展功能、API（多语言）、分布式事务机制等！

[Producer / Consumer] GROUP

RocketMQ中有一个“组”机制，此机制很重要，如下图：
在这里插入图片描述
通过组机制(Group)，RocketMQ可以天然支持分布式。
如下所示：
在这里插入图片描述
如上图所示，某个Topic有9条消息，Consumer Group有三个实例（3个进程或3台机器），9条消息就会均摊到每个实例上（3条/个）!

【RocketMQ只有一个模式 ———— 发布订阅模式！】

RocketMQ 集群部署模式

 描述
单Master模式 单点，Broker重启或宕机，队列就失效了，生产一定要避免单点，所以不考虑
多Master模式 由于是复数Master，当某台Broker宕机，新到消息是不会受影响，但由于没有Slave，会出现只有将宕机Master重启之后，才可以消费掉宕机Master上的消息，如果生产消息队列较少，并且对时间要求不严苛，可以考虑。
多Master多Slave(异步复制) 高可用模式！ 采用异步复制方式，主备之间短暂延迟。Master宕机可以在Slave消费，但是Master宕机，会导致少量消息丢失。常用投产解决方案之一
多Master多Slave(同步双写) 和异步复制方式的区别在于，采用的是同步方式。在Master/Slave都写成功后向应用返回成功，无论是数据还是服务都不存在单点，可靠性强！不过同步性能比异步较低！

参考:https://www.cnblogs.com/xuwc/p/14018568.html

posted @ 2022-01-05 00:23  Vincent-yuan  阅读(295)  评论(0)  编辑  收藏  举报