名称：后写的队列跑到了前面-真
问题描述：多队列 分别执行 update 和select ，逻辑上是 先update 但是实际过程中出现先select 问题
原因分析：队列存在排队问题，多站点多队列分布式部署过程中 可能出现 A机器的队列排队3 B队列排队30 ，A执行 select B执行update 这样 A排队后发现 B还没执行 就返回了异常。
解决方案：业务上通过控制逻辑解决、技术上可参考redis原子性但需要兼容业务不可死锁
名称：后面的事件跑到了前面执行-假
问题描述：post 拿到结果后 update ，再另一个队列里监听post里的事件 select数，最后发现 先select后 update ,post用时1000ms 但是 队列监听的 在第650ms就监听到了
原因分析：第一版需求里post是拿到request就返回了response，但是业务调整后 中间逻辑原因、第二：可能是post网络消耗事件确实比事件要慢导致出现 300ms的延迟
解决方案：post之前就update ,保证监听对列里select能拿到值
名称：数据库主从延迟
问题描述：复杂的业务逻辑、漫长的产品线 post一个方法 方法内通过异步事件去update数据 ，post后通过idselect值，这时候拿不到值。
原因分析：超过100W-1000W数据量的mysql数据库 中频频出现超过20个事件的主从库延迟 虽然有监听到警报但是如果触发延迟则程序报错
解决方案：1：post同步方法改为异步，post只负责接收数据 ，通过监听事件 来接受结果。2：在广播消息之前确认数据已经同步到数据库且消耗了对应的时间。过程中可能会主动睡眠具体时间用来消耗主从延迟问题。3：数据库sql大规模排查 禁止使用 通过 不加索引的where 执行update 语句情况 大量改为通过主键 update解决数据库压力