淺談大規模高並發服務的伸縮問題

• 2019 年 10 月 9 日
• 筆記

什麼是大規模高並發？

大規模高並發是兩個詞，前者表示有大量的流量訪問，後者表示競爭狀態下並發可能會遇到的一致性和可用性問題。

有什麼問題？

如果只是大規模的流量，我們可以簡單的進行負載均衡和針對架構層面的優化就能解決，這一塊和業務並無直接聯繫。

但是高並發就不一樣了，就算只有不太多的流量，只要存在並發競爭關係，必然會牽扯到狀態的一致性和業務流程的拆分優化。

最重要的是狀態，由於狀態需要被維護，因此針對狀態的伸縮擴展一直以來很容易跟技術發生混淆，我們必須要明確的一點就是，如果狀態競爭在業務層面沒有得到有效的解決，在技術層面目前也是無法得到有效的解決的。

可以想像，無狀態的服務很容易得到拓展，只需要增加處理節點，均勻的負載流量，路由到指定的節點處理即可。

所以關鍵在於業務要如何拆分？狀態要如何維護？這是下面將要講到的。

如何解決？

大規模低並發

這種是最容易解決的，只需要增加處理節點即可，因為不需要牽扯到狀態的維護，因此也無須擔心會發生副作用。

一般來講，HTTP請求將會被均勻的路由給不同的節點進行處理，我們可以做到無限拓展，只需要在適當的條件下進行伸縮即可。

因為不存在狀態的維護，因此和業務關係不大，只需要在技術層面進行優化。

大規模高並發

有時間的可以讀一下我之前寫的這篇文章（https://www.cnblogs.com/xingxueliao/p/11561263.html）

我這裡所提到的並發，可能跟很多人的理解有所不同，並發這個詞實際上指的是邏輯上的，什麼是邏輯上的？那就是和底層細節隔離開，我們只需要在腦海中存在這麼一個概念。

無論我們使用多執行緒，多進程，還是在不同主機上面運行的程式，在不同的時間進行並行處理，高並發在本文的重點側重於對狀態的變更所導致的一致性問題和可用性問題。

就像java的並發包裡面，更多的是一些工具用於維護狀態，為了使狀態在並發條件下預期可控制，所以我也使用並發一詞來表達這種競爭場景。

看起來似乎是矛盾的，一致性和可用性是兩個極端，我們只能在這兩個點之間進行選擇，平衡兩點對應業務的影響。

如果我們想要高可用，那麼業務流程可能就會更複雜，因為時間關係，我們只能選擇最終一致，那麼必然就存在中間狀態和流程。

如果我們想要強一致，那麼只需要簡單的按照順序處理完整個業務流程即可，但是可用性就無法發揮到最佳的程度。

在產品初期，為了快速的實現原型設想，又要保證結果是可預期的，可靠的，直接使用支援ACID的資料庫是最方便省事的。

過渡到產品後期，取決於業務數據的維度和聚合主體，狀態隔離分區和業務流程優化是必不可少的。

簡而言之，高可用帶來了更大的複雜性，而強一致又會導致可用性不足。

在上面的連接中我也簡略的講了一些“解決辦法”，倒不如說是思考方式。