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
4. 事物回查
定时回查线程会定时扫描(默认每分钟)每个存储事务状态的表格文件,遍历存储事务状态的表格记录
如果是已经提交或者回滚的消息调过过,
如果是prepared状态的如果消息小于事务回查至少间隔时间(默认是一分钟)跳出终止遍历
调transactionCheckExecuter.gotocheck方法向producer回查事物状态,
根据group随机选择一台producer
查询消息,根据commitLogOffset和msgSize到commitlog查找消息
向Producder发起请求,请求code类型为CHECK_TRANSACTION_STATE,producer的DefaultMQProducerImpl.checkTransactionState()方法来处理broker定时回调的请求,这里构建一个Runnable任务异步执行producer注册的回调接口,处理回调,在调endTransactionOneway向broker发送请求更新事物消息的最终状态
无Prepared消息,且遍历完,则终止扫描这个文件的定时任务
5. 事物消息的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来做的