MQ的核心问题在于三点:
消息发送 消息存储 消息消费
1.对于消息的发送,尤其是Meta数据(Topic路由信息)的同步性
自研设计了NameServer,摒弃了业界常用的ZooKeeper作为注册中心
让Topic信息无须在集群之间保持强一致性,追求最终一致性,保证了CAP中的AP
2.对于消息的存储,将消息存储文件设计为了文件组的概念,组内单个文件大小固定,加上内存映射
加上顺序写,提升了消息写性能
3.消息消费不保证正好一次,而是由消费者保证幂等性
对应的常见问题解决方案
1.整体架构
如同常见中间价,订阅发布,消息发送,消息存储,消息消费,路由发现
2.顺序消息
消费的顺序和存储到队列的顺序一致,内部的实现是局部顺序(队列内有序)
3.消息过滤
支持消息过滤
从Broker端来说,Broker只将消费者感兴趣的消息发送给消息消费者
从消息消费端来说,也可以自定义过滤,但是缺点很多,无用的消息会从Broker传到消费端
4.消息存储
虽然没有走远吗,但是盲猜是PageCache+堆外文件做到的
5.消息高可用性
常见的影响高可用的情况如下:
(1).Broker正常关机
(2).Broker异常Crash
(3).OS Crash
(4).机器断电
(5).机器无法开机
对于上述的情况,同步刷盘的情况下,我们可以保证除了5都不会有问题
对于异步的刷盘,都无法保证2-5,而且5一旦出现,可能就是消息全部丢失
如果开启了异步复制,则可以保证只丢部分消息
最后MQ则在后续的版本中引入多副本机制,满足可靠性极高的场景
6.消息到达
消息支持pull模式
7.消息只消费一次
因为利用的ACK消息来确保消息至少被消费一次
但是因为ACK的不稳定性,导致可能被消费多次
8.回溯消息
支持回溯已经消费的消息
9.消息堆积
和消息存储类似,但是不是永久的存储在消息服务器端,而是提供了过期机制,默认保留3天
10.定时消息
Rocket不支持任意进度的定时消息,只支持特定的延迟级别
11.消息重试机制
在消息消费的时候,,如果发生了异常,消息中间件需要支持消息的重新投送