本地消息表简介
本地消息表是分布式事务的一种实现方式，解决了分布式场景下数据最终一致性问题，是分布式事务相对简单可靠的解决方案，有一定的数据延迟性
例：如在支付场景中，当用户支付完订单后，
- 订单服务会向本地消息表插入一条消息，消息内容为订单支付成功
- 订单服务会向支付服务发送一条消息，消息内容为订单支付成功
- 订单支付的业务逻辑和本地消息表的写入，生成订单相关业务逻辑和数据，订单的异步MQ任务投递是在同一个事务中，其属性是原子的
- 订单的异步MQ任务会被需要的服务消费，消费后的结果会更新本地消息表的状态
- 本地消息表会定时扫描，将状态为未处理的消息重新投递到MQ中
- 其他服务在需要查询订单状态时，会先查询本地消息表，若状态为已处理，则直接返回结果，否则向订单服务查询
- 并且需要一个定时扫描程序定期扫描本地消息表，检查检索没有正确投递，或者下游服务没有正确应答的消息，将其重新投递到MQ中
- 需要注意的是重新投递的MQ任务也可能会投递、消费失败，则需要在本地消息表中记录重试次数，超过最大重试次数则需要人工处理，注意在所有下游服务拉去MQ时的消息记录和日志需要完整，并且记录下每次消费的结果（正确或异常），方便后续分析和处理
问题
- MQ服务，和其他服务在交互环节中会有数据不一致，延迟，消息丢失，服务挂机的情况发生，有服务宕机，消息丢失，进程消费异常等情况是会经常发生出现的，如何解决该问题
- 需要通过生成全局消息表traceId的方式完善该问题的逻辑，全局消息表是全局唯一，并且幂等，如果有消息丢失进程挂起，假死等情况需要将全局的本地消息表记录中的mq数据重复投递，
- 在其他分布式服务中需要幂等该进程的traceId的幂等消费，多次投递多次消费的结果是一致的
- 本地消息表是和业务逻辑相对耦合的，如果业务逻辑发生变化，需要同步修改本地消息表的处理逻辑，否则会导致数据不一致的问题，所以该实现方式对业务侵入性较强，不适合处理通用性较强的场景，所以使用时需要注意代码的后期维护几率和成本，如果后期维护成本较高，并且业务逻辑频繁变更，建议使用其他分布式事务实现方式
mWIQfsLgpzBTgXicCYiGArdh