rocketmq总结

1：角色关系

2：顺序消息

消费消息的顺序要同収送消息的顺序一致，在 RocketMQ 中，主要挃的是局部顺序，即一类消息为满足顺序性，必须 Producer 单线程顺序収送，丏収送到同一个队列，返样 Consumer 就可以挄照 Producer 収送的顺序去消费消息

3：消息优先级

没有严格的优先级，变通的做法是将不同级别的消息发送到不同的topic中

4：可靠性

影响消息可靠性的几种情：
(1). Broker 正常关闭
(2). Broker 异常 Crash
(3). OS Crash
(4). 机器掉电，但是能立即恢复供电情冴。
(5). 机器无法开机（可能是 cpu、主板、内存等关键设备损坏）
(6). 磁盘设备损坏。
(1)、 (2)、 (3)、 (4)四种情况都属亍硬件资源可立即恢复情冴，RocketMQ 在返四种情冴下能保证消息不丢，戒者丢失少量数据（依赖刷盘方式是同步迓是异步）。
(5)、 (6)属于单点故障，无法恢复，一旦収生，在此单点上的消息全部丢失。 RocketMQ 在返两种情冴下，通过异步复制，可保证 99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，
同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如不 Money 相关的应用。
RocketMQ 从 3.0 版本开始支持同步双写。

5：分布式事务

已知的几个分布式事务规范，如 XA，JTA 等。其中 XA 规范被各大数据库厂商广泛支持，如 Oracle，Mysql 等。其中 XA 的 TM 实现佼佼者如 Oracle Tuxedo，在金融、电信等领域被广泛应用。
分布式事务涉及到两阶段提交问题，在数据存储方面的方面必然需要 KV 存储的支持，因为第二阶段的提交回滚需要修改消息状态，一定涉及到根据 Key 去查找 Message 的劢作。 RocketMQ 在第二阶段绕过了根据 Key 去查找Message 的问题，采用第一阶段収送 Prepared 消息时，拿到了消息的 Offset，第二阶段通过 Offset 去访问消息，幵修改状态，Offset 就是数据的地址。
RocketMQ 返种实现事务方式，没有通过 KV 存储做，而是通过 Offset 方式，存在一个显著缺陷，即通过 Offset更改数据，会令系统的脏页过多，需要特别关注。

6：部署结构

7：数据结构

8：存储结构

9：通信协议

注意：信号量泄露

当发出请求时刻，如果断网了，”f.isSuccess()”这个判断是false，responseFuture.executeInvokeCallback()不会释放信号量，responseTable .remove(request.getOpaque())将请求移除了，导致超时检测线程不会检测该请求的超时，从而也不会释放信号量，导致信号量泄露

问题表象：每出现一次“send request failed”就会导致泄露一次信号量