简介
RocketMq是阿里巴巴集团自主研发的专业消息中间件。 产品基于高可用分布式集群技术，提供消息订阅和发布、消息轨迹查询、定时（延时）消息、资源统计、监控报警等一系列消息云服务，是企业级互联网架构的核心产品。
为分布式应用系统提供异步解耦、削峰填谷的能力，同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性
消息类型
- 事务消息：实现类似 X/Open XA 的分布事务功能，以达到事务最终一致性状态。
- 定时（延时）消息：允许消息生产者指定消息进行定时（延时）投递，最长支持 40 天。
- 大消息：支持最大 4MB 消息。
- 消息轨迹：通过消息轨迹，用户能清晰定位消息从发布者发出，经由 MQ 服务端，投递给消息订阅者的完整链路，方便定位排查问题。
- 广播消费：允许一个 Consumer ID 所标识的所有 Consumer 都会各自消费某条消息一次。
- 顺序消息：允许消息消费者按照消息发送的顺序对消息进行消费。
- 重置消费进度：根据时间重置消费进度，允许用户进行消息回溯或者丢弃堆积消息。
事务
为什么会有事务，事务的应用场景是什么？
假设有如下场景：
订单支付完成后会做如下两件事情：
- 修改订单状态（为核心系统处理）
- 通知用户积分系统 增加积分（发送至mq队列消费，不占用核心系统，做到异步解耦），此过程处理失败，不应该回滚正常订单状态
没有事务的做法
假设没有事务，我们通常的做法是在修改订单状态完成后，核心系统本地事务提交后，发送mq消息。
但是问题来了：假设发送mq的时候核心系统宕机，mq消息没有发送出去，那系统就无法处理积分，导致信息丢失
增加事务
此时RocketMq的事务机制开始登场
核心为MQ发送方来统筹发送消息、处理本地事务、检查本地事务状态。
跟没有事务的做法最主要的区别就是，预先发送Half消息，MqServer没有得到发送方的消息会去回查事务状态，从而保证事务的一致性。假设本地事务期间发生了异常，事务回滚，那么消息直接丢弃，如果在第4步发生异常，回查发现本地事务已提交，则Commit投递消息。
使用事务的消息方式，防止了消息的漏发或者不必要发的情况。
定时（延时）消息
延时消息用于指定消息发送到 MQ 服务器端后，延时一段时间才被投递到客户端进行消费（例如 3 秒后才被消费），适用于解决一些消息生产和消费有时间窗口要求的场景，或者通过消息触发延迟任务的场景，类似于延迟队列。
顺序消息
顺序消息（FIFO 消息）是 MQ 提供的一种严格按照顺序进行发布和消费的消息类型。 顺序消息指消息发布和消息消费都按顺序进行。
- 顺序发布：对于指定的一个 Topic，客户端将按照一定的先后顺序发送消息。
- 顺序消费：对于指定的一个 Topic，按照一定的先后顺序接收消息，即先发送的消息一定会先被客户端接收到。
分区顺序
对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。
适用场景
性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。
示例
【例一】用户注册需要发送发验证码，以用户 ID 作为 sharding key， 那么同一个用户发送的消息都会按照先后顺序来发布和订阅。
【例二】电商的订单创建，以订单 ID 作为 sharding key，那么同一个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息都会按照先后顺序来发布和订阅。
阿里巴巴集团内部电商系统均使用分区顺序消息，既保证业务的顺序，同时又能保证业务的高性能。
参考：
