RocketMQ基本和高级特性在电商平台实践
单体项目走向微服务，进而演变成业务中台，中间件微服务也渐渐从同步转向异步。
电商业务对MQ的核心诉求：
一致性：X kafka/RabbitMQ
高性能：X ActiveMQ/IBMMQ
可扩展：X ActiveMQ/IBMMQ
RocketMQ的架构-领域模型
topic：一对多
consumer queue：分配负载，横向扩展
producer：生成者
consumer：消费者
Group:客户端分组
broker:消息代理
NameServer：CAP无状态服务发现
RocketMQ架构:存储核心
对于消息队列而言，存储子系统是重中之重，它是基于统一的commitLog，以顺序写的方式来完成消息物理数据的可靠存储。在commitLog物理数据落盘之后，它会异步去分发consumer queue来满足消息的快速读取。一个topic可以通过数据分片可以把流量分散在不同的Broker上面去，这样就具备了一个无限扩展的能力。RocketMQ基于CommitLog还分发出一个持久化的Hash索引，它为RocketMQ提供了低成本的面向业务组件的查询能力，达到消息的可观测性。通过消息的VID查询每条消息的轨迹详情，包括生产者、生产时间、消息被哪些消费者消费、消费时间、消费次数等。另外RocketMQ消费进度的管理是基于log加offset的管理，这个可以提供RocketMQ的可用性，当消息消费完成之后，业务逻辑出现了问题，依然有回滚的机会，可以将消息进行回放到过去重新消费。
高级特性:事务消息
定义：分布式一致性，生产者和消费者对同一个业务状态达到最终一致
原理：两阶段提交+补偿机制+重试
顺序消息
定义:顺序一致性，保证同一业务的消息满足FIFO，同一订单的状态信息，同一商品的变更消息。
原理：消息key作为分区键，生产者同key写入同ConsumeQueue(分区)；消费者锁定ConsumeQueue，顺序读取。
定时消息
定义：生产者发送消息，在指定的时间(秒级)后对消费者可见
原理：时间轮索引
SQL过滤
定义:消息包含自定义属性，消费者可以用SQL按照属性过滤目标消息
原理:写时计算+布隆过滤
原文作者：二进制跳动；如有侵权，请联系管理员删除。
