高併發高可用的架構實踐設計理念（一）

客戶端頁面快取（http header中包含expires/cache of control，last modified(304，server不返回body，客戶端可以繼續用cache，減少流量)，etag）

反向**快取

應用端的快取(memcache)

記憶體資料庫

buffer、cache機制（資料庫，中介軟體等）

雜湊、b樹、倒排、bitmap

雜湊索引適合綜合陣列的定址和鍊錶的插入特性，可以實現資料的快速訪問。

b樹索引適合於查詢為主導的場景，避免多次的io，提高查詢的效率。

倒排索引實現單詞到文件對映關係的最佳實現方式和最有效的索引結構，廣泛用在搜尋領域。

bitmap是一種非常簡潔快速的資料結構，他能同時使儲存空間和速度最優化（而不必空間換時間），適合於海量資料的計算場景。

在大規模的資料中，資料存在一定的區域性性的特徵，利用區域性性的原理將海量資料計算的問題分而治之。

mr模型是無共享的架構，資料集分布至各個節點。處理時，每個節點就近讀取本地儲存的資料處理(map)，將處理後的資料進行合併(combine)、排序(shuffle and sort)後再分發(至reduce節點)，避免了大量資料的傳輸，提高了處理效率。

平行計算（parallel computing）是指同時使用多種計算資源解決計算問題的過程，是提高計算機系統計算速度和處理能力的一種有效手段。它的基本思想是用多個處理器/程序/執行緒來協同求解同一問題，即將被求解的問題分解成若干個部分，各部分均由乙個獨立的處理機來平行計算。

和mr的區別在於，它是基於問題分解的，而不是基於資料分解。

隨著平台併發量的增大，需要擴容節點進行集群，利用負載均衡裝置進行請求的分發；負載均衡裝置通常在提供負載均衡的同時，也提供失效檢測功能；同時為了提高可用性，需要有容災備份，可以根據失效性要求的不同，進行選擇不同的備份策略。

讀寫分離是對資料庫來講的，隨著系統併發量的增大，提高資料訪問可用性的乙個重要手段就是寫資料和讀資料進行分離

平台中各個模組之間的關係盡量是低耦合的，可以通過相關的訊息元件進行互動，能非同步則非同步，分清楚資料流轉的主流程和副流程，主副是非同步的，比如記錄日誌可以是非同步操作的，增加整個系統的可用性。

當然在非同步處理中，為了確保資料得到接收或者處理，往往需要確認機制(confirm、ack)。

但是有些場景中，雖然請求已經得到處理，但是因其他原因(比如網路不穩定)，確認訊息沒有返回，那麼這種情況下需要進行請求的重發，對請求的處理設計因重發因素需要考慮冪等性。

監控也是提高整個平台可用性的乙個重要手段，多平台進行多個維度的監控；模組在執行時候是透明的，以達到執行期白盒化

拆分包括對業務的拆分和對資料庫的拆分。

系統的資源總是有限的，一段比較長的業務執行如果是一竿子執行的方式，在大量併發的操作下，這種阻塞的方式，無法有效的及時釋放資源給其他程序執行，這樣系統的吞吐量不高。

需要把業務進行邏輯的分段，採用非同步非阻塞的方式，提高系統的吞吐量。

隨著資料量和併發量的增加，讀寫分離不能滿足系統併發效能的要求，需要對資料進行切分，包括對資料進行分庫和分表。這種分庫分表的方式，需要增加對資料的路由邏輯支援。

對於系統的伸縮性而言，模組最好是無狀態的，通過增加節點就可以提高整個的吞吐量。

系統的容量是有限的，承受的併發量也是有限的，在架構設計時，一定需要考慮流量的控制，防止因意外攻擊或者瞬時併發量的衝擊導致系統崩潰。在設計時增加流控的措施，可考慮對請求進行排隊，超出預期的範圍，可以進行告警或者丟棄。

對於共享資源的訪問，為了防止衝突，需要進行併發的控制，同時有些交易需要有事務性來保證交易的一致性，所以在交易系統的設計時，需考慮原子操作和併發控制。

保證併發控制一些常用高效能手段有，樂觀鎖、latch、mutex、寫時複製、cas等；多版本的併發控制mvcc通常是保證一致性的重要手段，這個在資料庫的設計中經常會用到。

平台中業務邏輯存在不同的型別，有計算複雜型的，有消耗io型的，同時就同一種型別而言，不同的業務邏輯消耗的資源數量也是不一樣的，這就需要針對不同的邏輯採取不同的策略。

針對io型的，可以採取基於事件驅動的非同步非阻塞的方式，單執行緒方式可以減少執行緒的切換引起的開銷，或者在多執行緒的情況下採取自旋spin的方式，減少對執行緒的切換(比如oracle latch設計)；對於計算型的，充分利用多執行緒進行操作。

同一型別的呼叫方式，不同的業務進行合適的資源分配，設定不同的計算節點數量或者執行緒數量，對業務進行分流，優先執行優先級別高的業務。

系統的有些業務模組在出現錯誤時，為了減少併發下對正常請求的處理的影響，有時候需要考慮對這些異常狀態的請求進行單獨渠道的處理，甚至暫時自動禁止這些異常的業務模組。

有些請求的失敗可能是偶然的暫時的失敗(比如網路不穩定)，需要進行請求重試的考慮。

系統的資源是有限的，在使用資源時，一定要在最後釋放資源，無論是請求走的是正常路徑還是異常的路徑，以便於資源的及時**，供其他請求使用。

在設計通訊的架構時，往往需要考慮超時的控制。

高併發高可用的架構實踐 設計理念（一）