点击我的GIT

RocketMQ原理解析-Producer

producer 

producer 1.启动流程

Producer如何感知要发送消息的broker即brokerAddrTable中的值是怎么获得的,
1.      发送消息的时候指定会指定topic,如果producer集合中没有会根据指定topic到namesrv获取topic发布信息TopicPublishInfo,并放入本地集合
2.      定时从namesrv更新topic路由信息,

Producer与broker间的心跳

Producer定时发送心跳将producer信息(其实就是procduer的group)定时发送到, brokerAddrTable集合中列出的broker上去
Producer发送消息只发送到master的broker机器,在通过broker的主从复制机制拷贝到broker的slave上去

producer 2.如何发送消息

Producer轮询某topic下的所有队列的方式来实现发送方的负载均衡

 

 

1)  Topic下的所有队列如何理解:

比如broker1, broker2, borker3三台broker机器都配置了Topic_A

Broker1 的队列为queue0 , queue1

Broker2 的队列为queue0, queue2, queue3,

Broker3 的队列为queue0

当然一般情况下的broker的配置都是一样的

以上当broker启动的时候注册到namesrv的Topic_A队列为共6个分别为:

broker1_queue0, broker1_queue1,

broker2_queue0, broker2_queue1, broker2_queue2,

broker3_queue0,

2)  Producer如何实现轮询队列:

Producer从namesrv获取的到Topic_A路由信息TopicPublishInfo

           --List<MessageQueue>messageQueueList  //Topic_A的所有的队列

           --AtomicIntegersendWhichQueue        //自增整型

           方法selectOneMessageQueue方法用来选择一个发送队列

                    (++sendWitchQueue)% messageQueueList.size为队列集合的下标

                    每次获取queue都会通过sendWhichQueue加一来实现对所有queue的轮询

                            如果入参lastBrokerName不为空,代表上次选择的queue发送失败,这次选择应该避开同一个queue

3)  Producer发消息系统重试:

发送失败后,重试几次retryTimesWhenSendFailed = 2

发送消息超时sendMsgTimeout = 3000

Producer通过selectOneMessageQueue方法获取一个MessagQueue对象

           --topic            //Topic_A

           --brokerName           //代表发送消息到达的broker

           --queueId              //代表发送消息的在指定broker上指定topic下的队列编号

向指定broker的指定topic的指定queue发送消息

                   发送失败(1)重试次数不到两次(2)发送此条消息花费时间还没有到3000(毫秒), 换个队列继续发送。 

 producer发送普通消息

producer 3.如何发送顺序消息

Rocketmq能够保证消息严格顺序,但是Rocketmq需要producer保证顺序消息按顺序发送到同一个queue中,比如购买流程(1)下单(2)支付(3)支付成功,
这三个消息需要根据特定规则将这个三个消息按顺序发送到一个queue 如何实现把顺序消息发送到同一个queue: 一般消息是通过轮询所有队列发送的,顺序消息可以根据业务比如说订单号orderId相同的消息发送到同一个队列, 或者同一用户userId发送到同一队列等等 messageQueueList [orderId%messageQueueList.size()] messageQueueList [userId%messageQueueList.size()]

 

 

producer 4.如何发布分布式事务消息

先引入官方文档图:

  

分布式事物是基于二阶段提交的

1)      一阶段,向broker发送一条prepared的消息,返回消息的offset即消息地址commitLog中消息偏移量。Prepared状态消息不被消费
发送消息ok,执行本地事物分支, 本地事物方法需要实现rocketmq的回调接口

2) LocalTransactionExecuter,
处理本地事物逻辑返回处理的事物状态LocalTransactionState 3) 二阶段,处理完本地事物中业务得到事物状态, 根据offset查找到commitLog中的prepared消息,设置消息状态commitType或者rollbackType,
让后将信息添加到commitLog中, 其实二阶段生成了两条消息

事物消息发送

 

producer 5.消息在落地broker落地之普通消息

Broker根据producer请求的RequestCode.SEND_MESSAGE选择对应的处理器SendMessageProcessor

         根据请求消息内容构建消息内部结构MessageExtBrokerInner

         调DefaultMessageStore加消息写入commitlog

 

producer 6.消息在落地broker落地之事务消息

1. 消息落地

commitLog针对事物消息的处理,消息的第20位开始的八位记录是的消息在逻辑队列中的queueoffset,
但是针对事物消息为preparedType和rollbackType的存储的是事物状态表的索引偏移量

2. 分发事物消息:   

  分发消息位置信息到ConsumeQueue: 事物状态为preparedType和rollbackType的消息不会将请求分发到ConsumeQueue中去,即不处理,所以不会被消息
  更新transactionstable table:如果是prepared消息记,通过TransactionStateService服务将消息加到存储事务状态的表格tranStateTable的文件中;
如果是commitType和rollbackType消息, 修改事物状态表格tranStateTable中的消息状态。 记录Transaction Redo Log日志: 记录了 commitLogOffset, msgSize,preapredTransactionOffset, storeTimestamp。

3. 事物状态表

         事物状态表是有MapedFileQueue将多个文件组成一个连续的队列,它的存储单元是定长为24个字节的数据,

         tranStateTableOffset可以认为是事物状态消息的个数,索引偏移量, 它的值是 tranStateTable.getMaxOffset()/ TSStoreUnitSize     

 

 

3. 事物回查

定时回查线程会定时扫描(默认每分钟)每个存储事务状态的表格文件,遍历存储事务状态的表格记录

如果是已经提交或者回滚的消息调过过,

如果是prepared状态的如果消息小于事务回查至少间隔时间(默认是一分钟)跳出终止遍历

调transactionCheckExecuter.gotocheck方法向producer回查事物状态,

         根据group随机选择一台producer

         查询消息,根据commitLogOffset和msgSize到commitlog查找消息

         向Producder发起请求,请求code类型为CHECK_TRANSACTION_STATE,producer的DefaultMQProducerImpl.checkTransactionState()方法
来处理broker定时回调的请求,这里构建一个Runnable任务异步执行producer注册的回调接口,处理回调,在调endTransactionOneway向broker
发送请求更新事物消息的最终状态 无Prepared消息,且遍历完,则终止扫描这个文件的定时任务

 

4. 事物消息的load&recover

TransactionStateService.load ()事物状态服务加载, 加载只是建立文件映射
 redoLog队列恢复,加载本地redoLog文件
 tranStateTable事物状态表, 加载本地tranStateTable文件

 recover:

正常恢复:

         利用tranRedoLog文件的recover

         利用tranStateTable文件重建事物状态表

异常恢复:

         先按照正常流程恢复TranRedo Log

         commitLog异常恢复,commitLog根据checkpoint时间点重新生成 redolog,重新分发消息DispatchRequest,

分发消息到位置信息到ConsumeQueue

                  更新Transaction State Table

                   记录TransactionRedo Log

         删除事物状态表tranStateTable

通过RedoLog全量恢复StateTable

         重头扫描RedoLog, 过滤出所有prepared状态的消息, 将commit或者rollback的消息对应的prepared消息删除

         重建StateTable,  将上面过滤出的prepared消息,添加到事物状态表文件中
这个事物状态表transstable的作用是定期(1分钟)将状态为prepared事物回查producer端redolog这个队列其实标记消费到哪了, 
事物状态的恢复根本上是有commitlog来做的

 

 

 

 

posted @ 2016-11-08 10:19  _1900  阅读(...)  评论(...编辑  收藏