MySQL
关于数据库与缓存的一致性问题
简单的方案就是，更新操作时，先更新数据库，再删除缓存。 这种方案的弊端是，线程一更新了数据库还没来得及删除缓存时，线程二过来读到的缓存是旧的数据。 不能先删除缓存，再更新数据库，因为线程一删除了缓存还没来得及恒心数据库时，线程二过来发现缓存没有就读了数据库的旧数据并写入缓存，后续所有的线程都会读这个旧的数据
考虑redis做缓存时，必然就必须容忍一定的数据不一致的可能，考虑让redid做数据库我没用过
RocketMQ
关于顺序消费问题，
关于数据同步工具dts订阅MQ
源端数据，先从A修改为B，又快速的被从B修改为A，此时会产生两条修改数据的mq消息，但由于消息的无序性，导致先修改为最新值，再修改为旧值
解决方案：
1，使用顺序消息，但是有性能问题
2，更新数据使用版本号，旧版本消息不能更新数据
Dts堵塞如果大批量的操作都是修改同一张表的，其他表的修改就可能被堵塞
解决方案：
不同业务、不同数据量的Dts同步，创建不同的Dts链路。
这是一种很常见的业务隔离操作，rocketmq不同的业务使用不同的topic一样，这些都是最佳实践
如果都使用相同的topic，仅通过不同的tag过滤，则会浪费很多无用消息发送占用带宽，
Redis
一般不太会考虑redis连接池的问题，配合5，10之类的，都没有太大问题，只有在高并发的情况下，可能会因为连接池争抢，导致程序阻塞
生产上，可以配20甚至更高，以此来应对高并发情况
分布式事务
本地事务讲究ACID，但是，在生产上关于分布式事务多是关注其中的原子性，别的几个特性如果硬要处理，会极大增加系统设计的复杂性，得不偿失
如果，非要在分布式事务中考虑隔离性，那就参考本地事务关于隔离性的实现方案：加锁，对争抢的资源，加上分布式锁
针对互联网场景，往往对于时效性的关注大过一致性，所以，大多互联网关于分布式事务采用的都是最终一致性，当然，这就会带来数据短暂性的不一致，业务上也能完全容忍
关于最终一致性的解决方案，主要就是两种：回滚、重试
究竟选择哪种方案，不同的业务场景，可以做出不同的选择。比如如果是下订单同时减库存的场景，下订单后去减库存失败，可能是由于本身库存已经不足，所以这个时候，再去不断重试的扣库存依然不会成功，所以此时就应该选择回滚的方案。
又比如，发货以后通知订单状态更新，发货成功后去通知订单状态更新失败，就可以重试的去通知，知道通知成功，或者通知到一定次数仍然失败，也转为人工处理，进行人工兜底，这也是分布式事务处理的最后一步：人工兜底
无论是回滚，还是重试，都可以选择RocketMQ的延时消息，如果担心消息本身发送不成功，则可以采用本地消息事务表，发送消息失败则捕获异常，让消息落库，后续通过定时任务定时扫描此本地消息表，重试发送消息