producer 5.消息在落地broker落地之普通消息Broker根据producer请求的RequestCode.SEND_MESSAGE选择对应的处理器SendMessageProcessor 根据请求消息内容构建消息内部结构MessageExtBrokerInner 调DefaultMessageStore加消息写入commitlog
producer 6.消息在落地broker落地之事务消息1. 消息落地commitLog针对事物消息的处理，消息的第20位开始的八位记录是的消息在逻辑队列中的queueoffset，
但是针对事物消息为preparedType和rollbackType的存储的是事物状态表的索引偏移量
2. 分发事物消息： [url=] [/url]
分发消息位置信息到ConsumeQueue: 事物状态为preparedType和rollbackType的消息不会将请求分发到ConsumeQueue中去，即不处理，所以不会被消息 更新transactionstable table：如果是prepared消息记，通过TransactionStateService服务将消息加到存储事务状态的表格tranStateTable的文件中；
如果是commitType和rollbackType消息， 修改事物状态表格tranStateTable中的消息状态。 记录Transaction Redo Log日志： 记录了 commitLogOffset, msgSize,preapredTransactionOffset, storeTimestamp。[url=][/url]
3. 事物状态表 事物状态表是有MapedFileQueue将多个文件组成一个连续的队列，它的存储单元是定长为24个字节的数据， tranStateTableOffset可以认为是事物状态消息的个数，索引偏移量， 它的值是 tranStateTable.getMaxOffset()/ TSStoreUnitSize
3. 事物回查
[url=][/url]
定时回查线程会定时扫描（默认每分钟）每个存储事务状态的表格文件，遍历存储事务状态的表格记录如果是已经提交或者回滚的消息调过过，如果是prepared状态的如果消息小于事务回查至少间隔时间（默认是一分钟）跳出终止遍历调transactionCheckExecuter.gotocheck方法向producer回查事物状态， 根据group随机选择一台producer 查询消息，根据commitLogOffset和msgSize到commitlog查找消息 向Producder发起请求,请求code类型为CHECK_TRANSACTION_STATE，producer的DefaultMQProducerImpl.checkTransactionState()方法
来处理broker定时回调的请求，这里构建一个Runnable任务异步执行producer注册的回调接口，处理回调，在调endTransactionOneway向broker
发送请求更新事物消息的最终状态无Prepared消息，且遍历完，则终止扫描这个文件的定时任务[url=][/url]
4. 事物消息的load&recover
TransactionStateService.load ()事物状态服务加载， 加载只是建立文件映射 redoLog队列恢复，加载本地redoLog文件 tranStateTable事物状态表， 加载本地tranStateTable文件
recover:
[url=][/url]
正常恢复： 利用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消息，添加到事物状态表文件中[url=][/url]
这个事物状态表transstable的作用是定期（1分钟）将状态为prepared事物回查producer端redolog这个队列其实标记消费到哪了，
事物状态的恢复根本上是有commitlog来做的 |
