常用消息队列框架与技术选型

又是一年双11季,土豪们买买买,程序员看看热闹,聊聊技术 。海量的订单、支付请求以及库存更新等任务 , 离不开分布式架构(SOFAStack)、分布式数据库(OceanBase)、分布式缓存(TAIr)、数据处理(Flink)等一系列框架的支持 。而消息队列作为连接这些组件的重要纽带,可以实现各组件之间的异步通信和解耦 。本文接下来就聊聊消息队列那些事儿~
消息队列给我们带来什么?消息中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削峰等问题,实现高性能 , 高可用,可伸缩和最终一致性的系统架构 。
  • 应用解耦
在分布式系统中,服务之间可能会有依赖关系,如果直接进行服务调用,会增加服务之间的耦合度 。使用消息队列可以将服务之间的通信转化为消息的发送和接收,降低服务之间的耦合度 。
常用消息队列框架与技术选型

文章插图
降低系统耦合性(源于网络)
  • 流量削峰/数据缓冲
在高并发场景下,瞬间的请求量可能会超出系统的承受能力 , 导致系统瘫痪 。使用消息队列可以实现流量削峰,将请求放入消息队列中 , 由消费者服务异步消费请求 , 有效降低瞬间的请求量,保护系统稳定性 。
常用消息队列框架与技术选型

文章插图
削峰/限流(源于网络)
  • 异步处理:
在分布式系统中,不同服务之间的调用可能会因为网络延迟或者服务负载高等原因导致调用时间较长 。使用消息队列可以实现异步处理 , 将请求放入消息队列中,由消费者服务异步消费请求,提高系统的并发性和吞吐量 。
常用消息队列框架与技术选型

文章插图
异步提高性能(源于网络)
常用的消息队列框架?目前在市面上比较主流的消息队列中间件主要有 , Kafka、ActiveMQ、RabbitMQ、RocketMQ 等这几种 。
常用消息队列框架与技术选型

文章插图
RocketMQ和Kafka 都是高吞吐量、高可用的分布式消息队列系统,相较于早期较活跃的ActiveMQ 和RabbitMQ 还是有着明显优势的,特别是在双11这样的场景,吞吐量的重要性是不言而喻的 。
接下来从多个维度重点对RocketMQ与Kafka对比:
数据可靠性
  • RocketMQ:支持异步实时刷盘、同步刷盘、同步复制、异步复制 。“同步刷盘”,可以提高单机的可靠性,避免数据丢失 。
  • kafka:使用异步刷盘方式,异步复制/同步复制 。采用的是异步刷盘的方式 , 可能会存在一定的数据丢失风险 。不过,Kafka也提供了一些可靠性保障的机制,例如副本机制和ISR机制等,可以在一定程度上保证数据的可靠性 。
在同步复制方面,RocketMQ可以利用IO组的commit机制,批量传输数据,因此性能上可能比Kafka要更好一些 。而Kafka的同步复制是以partition为单位进行的,一个Kafka实例上可能有多个partition,这可能会影响性能 。
单机支持的队列数
  • kafka单机若超过超过一定数量的partition/队列 , CPU load会发生明显飙高,partition越多,CPU load越高,发消息的响应时间变长 。
  • RocketMQ单机支持最高5万个队列,CPU load不会发生明显变化 。
队列多有什么好处呢?
单机可以创建更多个topic, 因为每个topic都是有一组队列组成 。
消费者的集群规模和队列数成正比,队列越多,消费类集群可以越大 。
消息投递的实时性
  • kafka只支持pull模式,实时性取决于pull时间间隔(0.8以后版本支持长轮询)
  • rocketmq有pull(长轮询)、push两种模式 (虽然这个push模式是假push) , push模式延迟肯定是比pull模式延迟低 。
push模式是基于pull模式的 , 本地有个定时线程去pull broker的消息,缓存到本地,然后push到消费线程 。
消费失败重试