1.【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？（因为现在消息中间件很多的调用都是异步的，如果保证这些消息的一致性，就需要涉及到可靠消息服务了）
相关于挂接了一套中间系统来实时控制消息的状态，从而保证整体的一致性。
另外，文章提到的一个主题就是这套核心思想的落地中如果保证99.99%的高可用（涉及到了高可用的保障机制：基于KV存储的队列支持的高可用降级方案）：可靠消息最终一致性方案的高可用保障生产实践
总结该保障机制特点
（1）自行封装MQ客户端组件与故障感知
（2）基于kv存储中队列的降级方案
注意用redis的几个坑：
第一个，任何kv存储的集合类数据结构，建议不要往里面写入数据量过大，否则会导致大value的情况发生，引发严重的后果。因此绝不能在redis里搞一个key，就拼命往这个数据结构中一直写入消息，这是肯定不行的。
第二个，绝对不能往少数key对应的数据结构中持续写入数据，那样会导致热key的产生，也就是某几个key特别热。
大家要知道，一般kv集群，都是根据key来hash分配到各个机器上的，你要是老写少数几个key，会导致kv集群中的某台机器访问过高，负载过大。
（3）下游服务消费MQ的降级感知
（4）故障的自动恢复
（5）更多的业务细节（比如消息是否要保证顺序性等问题需要在实际落地中考虑）
主要讲到了Redisson实现Redis分布式锁的底层原理
（1）加锁机制
（2）锁互斥机制
（3）watch dog自动延期机制
（4）可重入加锁机制
（5）锁释放机制
（6）此种方案Redis分布式锁的缺陷（文章提到的缺陷的部分解决方案，有点像哨兵的投票选举以及kafka的ISR机制）
3.每秒上千订单场景下的分布式锁高并发优化实践！（实际就是分布式锁的分段加锁方案，需要注意的是：如果某个下单请求，咔嚓加锁，然后发现这个分段库存里的库存不足了，此时咋办？这时你得自动释放锁，然后立马换下一个分段库存，再次尝试加锁后尝试处理。这个过程一定要实现。；同时还要注意对分段资源的合并问题）