第一章：分布式系統介紹
定義：分布式系統是一組分布在網絡上通過消息傳遞進行協作的計算機組成系統。
分布式系統的意義
- 升級單機處理能力的性價比越來越低
- 單機處理器能力存在瓶頸
- 處於穩定性和可用性考慮
阿姆達爾定律：s(P)=1/((1-p)+p/N)
其中P指的是程序中可並行的部分的程序在單核上執行的時間的占比，N表示處理器的個數（核心數）。S(N)是指程序在N個處理器相對單個處理器的提升速度比。
單進程多線程和多進程的區別
線程是屬於進程的，一個進程內的多個線程共享進程的內存空間；而多個進程之間的內存空間是相對獨立的，因此多個進程間通過內存共享、交換數據的方式與多個線程間的方式就有所不同。多進程相對於單進程多線程的方式來說，資源控制更容易實現，此外多進程中單個進程出現問題不會造成整體不可用。
分布式系統的難點
- 缺乏全局時鍾
- 面對故障的獨立性。在分布式系統，整個系統的一部分有問題而其它部分正常是經常出現的情況，我們稱之為故障的獨立性。
- 單點故障。在整個分布式系統中，如果某個角色或者功能只有單台機器在支撐，那個這個節點稱為單點，發生的故障稱為單點故障。在分布式系統中要盡量避免出現單點。如果不能把單機實現變為集群實現，那么一般還有兩種選擇：
- 給這個單點做好備份，能夠在出現問題是進行恢復，並且盡量做到自動恢復，降低恢復所需要使用的時間。
- 降低單點故障的影響范圍。
4.事務的挑戰。
第二章：大型網站及架構的演進過程
1.從一個單機交易網站說起
所有的功能模塊和數據在單台服務器上，通過各個模塊之間通過JVM內部的方法調用來進行交互，而應用和數據庫之間是通過JDBC進行訪問的。
2.單機負載告警，數據庫與應用分離
隨着訪問量的增加，服務器負載持續升高，考慮將應用服務器和數據庫服務器分離。
3.應用服務器負載告警，如何讓應用服務器走向集群
應用服務器壓力變大時，根據對應用服務器的監測結果，可以考慮將服務器從一台變為兩台，增加服務器后急需解決如下連個問題：
- 用戶對於應用服務器的選擇問題，可以通過在應用服務器前增加負載均衡設備來解決。
- Session問題。
3.1引入負載均衡設備
引入負載均衡設備后的架構
3.2解決應用服務器的Session問題
HTTP協議本生是無狀態協議，需要基於HTTP協議支持回話(Session State)狀態機制。具體的實現方式為：在回話開始時，分配一個唯一的回話標識(SessionID)，通過Cookie把這個標識告訴瀏覽器，以后每次請求的時候，瀏覽器會帶上這個會話標識告訴服務器請求數據那個會話。在Web服務器上，各個會話有獨立的存儲，保存不同的回話信息。如果遇到禁用Cookie的情況，一般的做法就是把這個回話標識放到URL的參數中。
如上圖所示，如果第一次網站請求在左邊的服務器，那么Session保存在左邊的服務器上，如果不做處理，就不能保證每次請求都落在同一台服務器上，這就是Session問題。
Session Stickey
保證同一個回話的請求都落在同意Web服務器上，稱為Session Stickey。
這種方案可以讓同樣的Session請求每次都發送到同一個服務器進行處理，非常利於對Session進行服務器端本地緩存。不過帶來以下問題：
- 如果服務器宕機或者重啟，那個這台服務器上的回話數據會丟失。
- 回話是應用層信息，那么負載均衡要將同一個回話請求都保存到同一個Web服務器上的話，就需要進行應用層負載均衡，這個開銷比第四層的交換要大。
- 負載均衡器會變為一個有狀態節點，要將會話到具體Web服務器的映射保存。和無狀態的幾點相比，內存消耗更大，容災方面會更麻煩。
Session Replication
Session Replication在Web 服務器之間增加了會話數據同步機制，通過保證不同Web服務之間的Session數據的一致，來解決Session問題。一般的應用容器都支持Session Replication。和Session Replication相比，它對負載均衡設備沒有要求，但是其本生也存在一些缺點。
- 同步Session數據造成了網絡帶寬的開銷。
- 每台服務器都要保存保存所有的Session數據，如果整個集群的Session數很多，每台機器用戶保存Session的數據占據內存嚴重。
Session 集中存儲
該方案的問題：
- 讀寫Session數據引入了網絡操作，這相對於本地數據讀取來說，問題就在於存在時延和不穩定性。
- 如果集中的Session服務器或者集群有問題，會對應用產生嚴重影響。
Cookie Based
該方案通過Cookie來傳遞Session數據，將Session數據存放在Cookie中，然后在Web服務器上從Cookie中生成對應的Session數據。相對於Session 集中存儲，這個方案不會依賴一個外部存儲系統，也就不存在從外部系統獲取、寫入Session數據的網絡時延。
該方案存在的不足：
- Cookie長度的限制。
- 安全性。
- 帶寬消耗。
- 性能影響。每次Http請求和響應都帶有Session數據，對於Web服務器來說，在同樣的處理情況下，響應的結果會減少，支持的並發數就越多。
4.數據庫讀壓力變大，讀寫分離
采用數據庫作為讀庫
讀寫分離導致的問題：
- 數據復制問題。
- 數據源選擇問題
數據庫系統一般都提供了數據復制功能，但是對於數據復制還需要考慮數據復制的時延問題。數據復制延遲會帶來數據短期不一致問題。於此同時，對於寫操作主要走主庫，事務中的讀也要走主庫，也要考慮到備庫相對於主庫的延遲。
搜索引擎其實是一個讀庫
搜索引擎要工作，首要的一點是需要根據被搜索的數據來構建索引。
搜索集群的使用方式和讀庫的使用方式是一樣的。可以從兩個維度對搜索系統構建索引的方式進行划分：一種是按照全量/增量划分，另一種是按照實時/非實時划分。搜索引擎的技術解決了站內搜索時某些場景下的讀的問題，提供更好的查詢效率。
加速數據讀取的利器-緩存
數據緩存
大型系統中的數據緩存主要用於分擔數據庫的讀的壓力。一般在緩存中存放的是“熱”數據而不是全部數據。應用訪問緩存，如果緩存不存在，則從數據讀出數據后放入緩存。
使用緩存來加速數據的讀取情況，一個很關鍵的指標是緩存命中率，因此緩存命中率較低，意味着還有不少的請求回到數據庫中。同時數據的分布於更新策略也要結合具體的場景來考慮。在分布上，要考慮的問題是需要避免局部熱點，並且緩存服務器擴展或者縮容要盡量平滑。而在緩存的更新上，后有定時失效、數據變更時失效和數據變更時更新等策略。
5. 引入分布式存儲系統
分布式存儲系統起到存儲的作用，也就是提供讀寫支持。相對於讀寫分離中“讀”源，分布式存儲系統更多是直接替代主庫。分布式存儲系統通過集群提供了一個高容量、高並發訪問、數據冗余容災的支持。
6. 讀寫分離后數據庫又遇到瓶頸
專庫專用，數據垂直拆分
垂直拆分的意思就是把數據庫中不同的業務數據拆分到不同的數據庫中。
不同業務的數據從原來的一個數據庫中拆分到多個數據庫中，就需要考慮如何處理原來單機中跨業務的事務。一種辦法是使用分布式事務，其性能明顯要低於單機事務；另一種辦法就是去掉事務或者不去追求強事務支持。對數據庫進行垂直拆分之后，解決了把所有業務數據放在一個數據庫的壓力問題。並且也可以根據不同的業務特點進行優化。
垂直拆分后的單機遇到瓶頸，數據庫水平拆分
數據庫的水平拆分就是把同一個表中的數據拆分到兩個數據庫中。產生數據水平拆分的原因是某個業務的數據表的數據量或者更新量達到了單個數據庫的瓶頸，這是就可以把這個表拆分到兩個或者多個數據庫中。數據庫水平拆分會給業務帶來一些影響:首先，要解決SQL路由的問題；其次主鍵的處理也會變得不同；最后由於同一個業務數據被拆分到了不同的數據庫中，因此一些數據查詢需要從兩個數據庫中讀取數據，如果數據量較大需要分頁就會比較難以處理。
7. 數據庫問題解決之后，應用面對的挑戰
拆分應用
隨着業務的發展，應用的功能越來越多，應用也會越來越大，這是需要把應用拆開，從一個應用變為兩個甚至多個應用。
走服務化的路
業務之間的訪問不僅是單機內部的方法調用了，還引入了遠程的服務調用；其次共享的代碼不再是散落在不同的應用中了，這些實現被放在各個服務中心。
