架構學習筆記系列二

阿里架構

2017 阿里技術精選 中，一文《如何高效排查系統故障？一分錢引發的系統設計 “踩坑” 案例》講解到， 理財年化收益率對賬一分錢不平的問題，開發人員發現，在資料庫記錄中的收益轉結記錄中存在兩筆轉結收益，每日應該是一筆轉結收益。

UserID	TX ID	收益	建立時間	修改時間
使用者 A	TX ID A	0.03	8:00:23	8:00:29
使用者 A	TX ID B	0.03	8:00:29	8:00:29

開發人員發現這兩筆結算時間擠在一起，懷疑很可能是出現了併發問題。繼續跟蹤第一筆 “TX ID A” 記錄，開發確認線上日誌存在超時情況，失敗原因是資料庫連線數打滿，執行緒等待提交。

原有的系統設計思路：
1. 分散式鎖有效時間5s；
2. sql操作發生錯誤，最多重試8次；
3. 分散式鎖下的sql操作失敗，重試操作會被攔截；
4. sql操作沒有設定事務超時時間，或者超時時間過長

由此推斷過程還原:
1. 分散式鎖下的sql操作，因資料庫連線數打滿，導致執行緒請求等待，返回操作失敗；則sql操作重試8次
2. 在分散式鎖失效之前，所有的sql操作重試都被攔截；
3. 分散式鎖5s後失效，然後重新發起冪等操作，這時5s已過，之前的8次重試沒有執行完，資料庫連線有空閒執行緒，這時會成功寫入“TX ID A”記錄，同時外圍的冪等操作，會插入“TX ID B”記錄；導致收益轉結兩次

過程抽象化：
1. 上層業務系統有重試機制；
2. 業務請求存在一定時間之後提交成功的情況；
3. 下游系統缺乏其他有效的冪等操作

解決方案：
1. 調整上游的重試時間， 且分散式鎖有效期的時長大於前者；
2. 冪等操作的可靠性，比如，設定表索引的唯一性，發起每個使用者每日轉結該TX ID是唯一的。

其中增加冪等控制是值得推薦的。

我聯想到：
如果通過一個TX ID（冪等操作）， 如果已有TX ID A，再來一個同樣的 TX ID A，這個時候是狀態更新的話，這會引出覆蓋問題，狀態覆蓋的先後順序問題，或者狀態是否可逆問題？除非記錄是無狀態或者就是操作快照，則不會存在這個問題。

《純乾貨 | 從淘寶到雲端的高可用架構演進》

高可用的演進主要考察點：

1. 快取設計 shell 在快取設計上，最簡單且高可用的部署模型：雙機房。對快取來說有兩種經典部署模式： 1. 共享叢集部署。也就是說在IDC裡，我的應用是分機房部署的，cache也是分機房部署的，對於應用來說，cache在邏輯上是一個叢集，IDC1和IDC2各寫一半cache。好處是，當一個IDC掛掉後，有一半cache是可以命中的，不會直接死掉。緩減伺服器穿透壓力。另外，減少了儲存成本 2. 獨立部署。也就是說IDC1和IDC2的cache是一樣的，IDC掛掉一個，cache照樣命中，承擔副本的作用。相對於共享叢集部署，其缺點是：成本高，以及當一個IDC的某些cache失效時，另一個IDC的對應cache也要擦除，這樣才能保證資料一致性 shell 作者認為，一些東西都是可以被快取的。我們再設計一個系統時，如果對資料一致性非常高，則會傾向於不用快取，直接用資料庫扛這個流量。 但是作者又舉例說了一個問題：Mysql儲存引擎InnoDB的Buffer Pool冷啟動問題。異地多活面臨一個問題，當建立一個新單元去承擔這個機房的流量，流量切過來50%，這個單元會掛掉，因為mysql服務是冷的，快取是空的，直接穿透整個資料儲存。所以必須引入流控。 同時現在業界有很多叫API閘道器(gateway)或者CDN，他們在邊緣節點也做了一層短暫的cache，可能只cache50或者100ms，如果收到網路攻擊，這層短暫的cache命中率是非常高的，後端服務可能只有幾百個QPS，這個是防禦網路攻擊很好的手段。

2. 限流降級

   限流降級印象特別深刻的是有關Netflix的“防故障”基礎設施：隨機殺節點、延時響應和中斷機房，這個是在正式環境做的，只能膜拜。
   
   對於限流降級的思考，最關鍵的地方在於，當發生故障後，你的服務是否會受到影響、同時需要多久時間進行服務恢復。
   降級服務通常的做法是服務回滾，但是有些服務啟動的時間過長，這個過程對使用者是有損的。如果有開關控制，則我可以線上上出現問題時，直接通過服務配置開關，把線上服務直接切到老服務上，所以開關降級的做法直接借鑑。
   

3. 容災設計

   容災設計的發生在於：server掛掉，比如：新引入的依賴、或者github上的package。 
   思路：如何降級、如何解決
   特別關注點：
       1. 是否有資料遷移，以及一致性的保證
       2. 服務釋出順序是否有依賴
       3. 是否需要停機
       4. 如何回滾
       5. 是否需要掛公告通知外部使用者
   

4. 面向彈性的設計

   針對不同雲服務的不同容災策略，有個大原則：切  切  切，切流量。 第二個是購買虛擬機器、負載均衡或者RDS時，一定要選擇多可能去的服務，這樣主備切流量，保證服務不受影響。
   

5. 面向跨區域/

   首先弄清楚兩個概念，異地多活和跨區域。面向跨區域要解決的問題是，跨區域資料一致性問題、跨城市之間的資料傳輸耗時問題。