RabbitMQ VS Kafka

RabbitMQ VS Kafka

PPTMQ.pptx

比较内容KafkaRabbitMQ 定位设计定位系统间的数据流管道，实时数据处理用于实时的，对可靠性要求较高的消息传递上　例如：常规的消息系统、网站活例如：订单，交易，充值，流计
性跟踪，监控数据基础对比成熟度成熟:日志领域成熟成熟所属社区／公司 ApacheMozilla Public License社区活跃度 高 高API完备性 高 高文档完备性 高 高开发语言ScalaErlang支持协议仅支持自定义协议支持AMQP、MQTT、STOMP协议客户端语言C/C++、Python、Go、 Java、
Erlang、NET、Ruby、Node.JS、PHP ..Java、C、C++、Python、PHP、Perl默认监控端口无15672默认数据端口90925672　持久化方式磁盘文件(顺序追加磁盘,内存只是缓存思路,不是持久化思路,因为内存和磁盘会出现同一条数据, LSM的机制)内存+磁盘文件(数据分配比如50%内存,50%磁盘)网络开销相对较小(堆攒batch,相对小,不会频繁走network) 但是batch同时带来带宽大相对较大
(就理解成一条条的刷,这里的优化只是channel级别的优化)内存消耗相对较小 (内存只是缓存)相对较大 (内存在放数据)cpu消耗CPU消耗大(压缩,分发,异步,同步复制,都需要消耗cpu)相对小部署方式单机／集群(至少3台)单机／集群(至少3台)是否支持事务性消息支持支持集群管理zookeeper　选主方式从ISR中自动选举一个leader 最早加入集群的broker为主可用性非常高:分布式、主从高 :主从,数据量大的时候可能产生性能瓶颈是否支持topic优先级不支持支持是否支持消息全局有序不支持支持是否支持多个生产者一个topic支持多个生产者不支持元数据管理通过zookeeper进行管理支持消息数据持久元数据管理通过zookeeper进行管理支持消息数据持久
可靠性比较是否支持多个消费者一个topic支持多个消费者(一个消费者可消费多个分区，一个分区可被多个消费组消费，但同一消费组内仅能有一个消费者同时消费1个分区)根据模式匹配主从切换自动切换:
N个副本，允许N-1个失效：
master失效以后自动从ISR中选一个为主.自动切换:
最早加入的slave会成为master.
新加入的slave回去同步之前master的数据,
但如果一直不能同步,可能会出现部分数据丢失.数据可靠性　　很好:
支持producer的单条发送、同步刷盘、异步复制好:
producer同步、异步ack，支持队列数据持久化，镜像模式中支持主从同步消息写入性能/吞吐量非常好一般百万级/s
单机10w+/s
集群: 取决于规模单机: 2w/s
集群: 4w/s性能的稳定性partition分区过多时性能不稳定，性能会明显下降消息堆积时，性能不稳定、明显下降下降。消息堆积不影响性能的稳定性　单机支持的队列数单机支持的队列数单机超过64个队列,Load会发生明显的飚高现象,队列越多,load越高,发送消息响应时长变长依赖于可用内存有多大支持消息回溯，因为消息持久化，消息被消费后会记录offset和timstamp不支持，消息确认被消费后，会被删除　　　是否支持消息追踪不支持消息追踪支持消息追踪　broker 端的维护消息被消费的记录：一个消息被分发到 consumer 后 broker 就马上进行标记或者等待 customer 的通知后进行标记。这 样也可以在消息在消费后立马就删除以减少空间占用。
但是这样会不会有什么问题呢？如果一条消息发送出去之后就立即被标记为消费
过的，一旦 consumer 处理消息时失败了（比如程序崩溃）消息就丢失了使用Trace实现，Trace是Rabbitmq用于记录每一次发送的消息，方便使用Rabbitmq的开发者调试、排错。可通过插件形式提供可视化界面。Trace启动后会自动创建系统Exchange：amq.rabbitmq.trace  ,每个队列会自动绑定该Exchange，绑定后发送到队列的消息都会记录到Trace日志堆积能力非常好一般
消息存储在log中，每个分区由一个或多个segment log文件 生产者、消费者正常时，性能表现稳定；
消费者不消费时，消息堆积,可能会出现性能不稳定复制备份消息先写入leader的log，
followers从leader中pull数据.
pull到数据后先ack 到leader，然后写入log中。普通模式下不复制；ISR中维护与leader同步的列表，落后太多的follwer会被删除掉.镜像模式下:
消息写先到master，然后写到slave上。
加入集群之前的已经到达的message不会被复制到新的slave上。功能对比消息投递的实时性具体由consumer轮询间隔时间决定　顺序消费支持支持　但是一台Broker宕机后，可能会产生消息乱序　定时消息不支持可能支持(死信队列)　可以由其他计算框架配合支持RabbitMQ的死信队列详解 - 简书消息查询默认不支持,可以开发一些工具支持默认不支持,可以开发一些工具支持消息失败重试不支持不支持消息重新消费支持,修改offset 、timestamp、不支持发送端的负载均衡采用zookeeper对集群中的broker，consumer进行管理，可以注册topic到zookeeper上，通过zookeeper的协调机制，producer保存对应的topic的broker信息，可以随机或者轮询发送到broker上，producer可以基于语义指定分片，消息发送到broker的某个分片上。需要单独的loadbalancer支持消息并行度消费并行度和分区数一致.可以一次性抓取多条消息消费消费方式consumer pull consumer pull /push 批量发送支持;默认缓存、压缩、然后批量不支持运维消息清理策略指定文件保存时间，过期删除consumer ack 以后，
消息将被标记 为删除(当内存少于40%，触发gc，将进行merge然后删除。)系统维护scala开发，维护成本高erlang开发，维护成本低部署依赖zookeeperErlang环境管理后台功能官方不提供。
第三方开源工具可供使用。官方提供 rabbitMQ- ui 界面权限管理支持 (身份认证/权限控制)
1.身份认证:client 与服务器的连接进行身份认证，brokers和zookeeper之间的连接进行Authentication（producer 和 consumer）、其他 brokers、tools与 brokers 之间连接的认证。
2. 权限控制:(生产/消费/group)数据权限支持
角色绑定自定义virtual hosts来控制数据的读写
Admin | Monitoring | Policymaker
Management | Impersonator 管理后台功能/监控Kafak Web Console:

producer
Brokers
leader/follower: ISR.HW
Topic、Partition:logSize
Consumer Groups/Consumer: Offset、Lag等信息
 
Connections、
Channels、
Virtual Host
Exchanges、
BindingKey
Queues生产和消费流里图、消息预览Binding:
 exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。broker 列表稳定Connection:
publisher／consumer和broker之间的TCP连接。断开连接的 *** 作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。Kafka Monitor: JMX/LOG/ConsumerQueue:
消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。Kafka集群状态：
1.Topic、Consumer Group列表；
2.图形化展示topic和consumer之间
的关系：
3.图形化展示consumer的Offset、Lag等信息Exchange:
message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。Kafka Manager
Preferred leader:
Brokers Spead:使用率
Brokers Skew: 是否倾斜
Brokers Leader Skew:partition是否倾斜
Lag:消息是否堆积产生延迟Channel:
如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel作为轻量级的Connection极大减少了 *** 作系统建立TCP connection的开销。优点/缺点1.监控集群的状态（topics，brokers，副本
分布，分区分布）；
2.产生分区分配（Generate partition
assignments）
3.基于集群的当前
状态：重新分配分区Virtual host:
出于多租户和安全因素设计的，提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。扩容数据迁移+扩容支持 ,脚本支持erlang 语言难度较大。集群不支持动态扩展时效性延迟在 ms 级以内 ms 级吞吐量10w级1w级　producer端提供缓存、压缩支持多种客户端语言：支持amqp协议。提供顺序消费能力多种消费方式提供多种客户端语言使用RAM模式时，性能很好 生态完善，在大数据处理方面有很多配
套设施管理界面较丰富，在互联网公司也有较大规模的应用；　数据安全性 有保障,宣称0丢失.　　　　开启安全机制也会比较消耗性能　消费集群数目受到分区数目限制erlang 语言难度较大。集群不支持动态扩展单机topic多时，性能会明显消息堆积是，性能明显下降　支持支持事务会影响有延迟支持支持事务会影响有延迟