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分佈式鎖的缺陷
3.每秒上千訂單場景下的分佈式鎖高併發優化實踐！（實際就是分佈式鎖的分段加鎖方案，需要注意的是：如果某個下單請求，咔嚓加鎖，然後發現這個分段庫存裏的庫存不足了，此時咋辦？這時你得自動釋放鎖，然後立馬換下一個分段庫存，再次嘗試加鎖後嘗試處理。這個過程一定要實現。；同時還要注意對分段資源的合併問題）