rocketmq总结

2017-12-30 11:42:06来源:oschina作者:xiaomin0322人点击

分享
rocketmq总结 博客分类: MQ

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”就会导致泄露一次信号量

http://www.cnblogs.com/tommyli/p/5081846.html

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台