可靠的、可擴充的、可維護的資料系統 ------《Designing Data-Intensive Applications》讀書筆記1

標籤：複雜度   資料中心   epp   圖片   down   修複bug   linked   手動   大量   

坦白說也是機緣巧合，在碩士生階段進入分布式系統領域學習。無論是大規模儲存或計算，其核心也是運用分布式技術利用並行性來解決資料密集型應用的需求。最近開始在啃這本《Designing Data-Intensive Applications》大部頭，作者Martin Kleppmann在分布式資料系統領域有著很深的功底，並在這本書中完整的梳理各類紛繁複雜設計背後的技術邏輯，不同架構之間的妥協與超越，很值得開發人員與架構設計者閱讀。
很可惜的是國內目前並沒有對應的中文版本，這個系列算是一個讀書感悟，同時也夾帶私貨，闡述一些自己的理解與看法，拋磚引玉，希望大家多交流學習。這本書共有12個章節，接下來我會一個章節更新一篇讀書筆記。（囧rz，感覺自己又開了一個坑）同時也希望國內的出版社可以儘快引入著作權，我也想要參與翻譯工作啊(,,? ? ?,,) ！！

1.資料密集應用

作為一個開發人員來說，目前絕大多數應用程式都是資料密集型的，而不是計算密集型的。CPU的計算能力不再成為這些應用程式的限制因素，而更加亟待解決的問題是海量的資料、資料結構之間的複雜性，應用的效能。

先看看我們經常打交道的資料系統：

• 儲存資料，以便它們或其他應用程式稍後再找到它（資料庫）
• 記住昂貴操作的結果，以加快讀取速度。（緩衝）
• 允許使用者按關鍵字搜尋資料或通過各種方式過濾資料（搜尋索引）
• 將訊息發送到另一個進程，非同步處理（流處理）
• 周期性地壓縮大量的累積資料（批處理）

而很多時候，我們所謂應用程式的絕大工作就是將這些資料系統進行組合，然後添加我們的運行邏輯，但是如何更加合理的整合這些資料系統，對我們來說仍然是一個值得學習和思考的問題。而資料系統也在慢慢變得越來越相似，不同的資料系統也在各自學習彼此的優點。如Redis這樣的緩衝系統可以支援資料落地，很多時候的應用場合我們可以替代傳統的RDBMS。而Kafka這樣的資料隊列也可以支援資料落地來儲存訊息。更加深刻的理解這些資料系統，來更好的權衡架構設計，是一門很精深的課題。

是一個典型的由多種資料系統構成的應用程式，隨著資料量和資料邏輯的複雜，就成為了一個資料密集型的應用。

2.設計資料密集型應用的三原則

• 可靠性
  具有容錯性（面對硬體或軟體故障，甚至是人為錯誤），系統仍應繼續正常工作（在期望的效能水平上執行正確的功能）。
• 可擴充性
  隨著系統的增長（在資料量、流量或複雜度），應該有合理的方法來處理這種增長。
• 可維護性
  隨著時間的推移，許多不同的人將致力改善資料系統（既保持當前的行為，並使系統適應新的環境），他們都應該能夠卓有成效地工作。

顯然，這三個原則不單單是資料密集型應用應當遵循的原則，在絕大多數軟體系統中同樣是很重要的問題，接下來我們一一梳理一下。

（1）可靠性

• 硬體故障
  硬碟崩潰，記憶體出現故障時，電網停電，有人拔了網線，幾乎硬體故障在資料中心總是不間斷的出現。
  解決方案：

  • 在軟體與硬體層面考慮冗餘，來確保硬體的故障不會演變為系統的故障。

• 人為的錯誤
  人是很不可靠，從駕駛技術的演變就可以看出來，人為的疏失會帶來巨大的災難。而且，人經常犯錯。
  解決方案：

  • 最小化錯誤機會的方式設計系統。例如，精心設計的抽象，API和管理介面可以很容易地做“正確的事情”，阻止“錯誤的事情”。

• 人們犯最多錯誤的地方和那些可能導致失敗的地方解耦。

• 全面測試，從單元測試到整個系統整合測試和手動測試。

• 允許快速和容易地從人為錯誤中恢複，以盡量減少在失敗的情況下的影響。例如，使其快速復原更改配置，逐步推出新的代碼（所以任何意想不到的錯誤隻影響一小部分使用者），並提供工具來重新計算資料（如果原來舊的計算是不正確的）。

（2）可擴充性

即使一個系統今天工作可靠，但這並不意味著它將來一定會可靠地工作。一個常見原因是負載增加：也許系統已經從10000個並發使用者發展到100000個並發使用者，或者從100萬個增加到1000萬個。

“如果系統以特定的方式增長，我們應對增長的選擇是什嗎？” “我們怎樣才能增加計算資源來處理額外的負載？”

• 描述負載
  首先，我們需要簡潔地描述系統當前的負載，負載可以用幾個數字來描述，我們稱之為負載參數。
  參數的選擇取決於系統的體繫結構，如：
• 每秒對Web伺服器的請求
• 資料庫中的讀寫比
• 聊天室中的活躍使用者數量

• 緩衝的命中率

• 描述效能
  一旦描述了系統上的負載，就可以討論負載增加時發生的情況。可以從兩方面看：
  1.增加負載參數並保持系統資源（CPU、記憶體、網路頻寬等）不變時，系統的效能如何受到影響？
  2.當增加負載時，如果希望保持效能不變，需要增加多少資源？

所以我們需要有描述效能的尺子：

• 平均回應時間：給定n值的算術平均值，全部加起來，除以n。然而這不是一個很好的指標，因為它不告訴你有多少使用者真正體驗了延遲。
• 百分比回應時間：把回應時間列表，從最快到最慢排序，那麼中間值是中間點：例如，如果平均回應時間是200毫秒，那意味著一半請求在少於200毫秒時返回，而一半請求花費的時間比那個要長。
• 高百分比的回應時間：可以看看高百分位元：95th，99th，和99.9th百分位元是常見的（簡稱P95，P99，和p999），來參考回應時間的閾值。

負載情況與效能情況是很重要的，有時系統的瓶頸是由少數極端情況引起的。作者舉了一個Twitter的例子，我覺得很好，這裡詳細分享一下這個例子：

Twitter的故事

Twitter在2012年11月16日公布的資料。
Twitter的兩個主要操作是：

• 發出Tweet
  使用者發行就緒一個Tweet給他們的訂閱者。（平均4.6k請求/秒，峰值超過1.2萬的請求/秒）。
• 擷取Tweet
  使用者可以查看他們粉絲發布Tweet。（約300K的請求/秒）。

Twitter在擴充性的挑戰主要不是由於Tweet的數量，而主要是在每個使用者都有很多訂閱者，每個使用者也有很多粉絲。執行這兩種操作大致是兩種方法：

• 1、發布一條推特，只需將新的推文插入到全球的推文集合中即可。當使用者請求他們粉絲的Tweet時，可以尋找他們所關注的所有人，並找到每個使用者的所有Tweet，並將它們合并（按時間排序）。在關聯式資料庫中，可以編寫如下查詢，例如：
  java SELECT tweets.*, users.* FROM tweets JOIN users ON tweets.sender_id = users.id JOIN follows ON follows.followee_id = users.id WHERE follows.follower_id = current_user
  如所示：
  
• 2、為每個使用者訂閱的Tweet維護一個緩衝，就像每個收件者的Twitter郵箱一樣。當使用者發布一條推文時，請尋找所有關注該使用者的人，並將新的Tweet推送到他們的緩衝中。所以讀取Tweet列表是很划算的，因為它的結果提前計算好了。

如所示的結構顯然更合適Tweet的發布，因為發布的Tweet的寫操作幾乎比讀的操作低兩個數量級，所以在這種情況下，最好是在寫時做更多的工作，而不是在讀時做更多的工作。但是方法2並不適用於有大量粉絲的帳號，假設某人有3000W粉絲，一次發布Tweet產生的寫操作可能是巨大的。所以目前在Twitter的Tweet系統中，Twitter將這兩種方法混合。大多數使用者的推文在發布時仍然會被擴充到Tweet緩衝之中，但只有少數使用者擁有大量的粉絲（即名人）。使用者可以跟蹤的任何名人的Tweet，並單獨讀取並與使用者的Tweet緩衝中進行合并。這種混合方法能夠始終如一地提供良好的效能。

（這個例子很精鍊的描述了架構設計的妥協與精妙，依據業務特點，最大化的最佳化了資料系統的效能。很佩服Twitter的工程師在架構設計上的功力。同時也很好奇如微博，是不是也是採用類似的架構進行設計。）

• 怎麼擴充
  放大（垂直縮放，移動到更強大的機器）和縮放（橫向縮放，在多台更小的機器上分配負載）之間的二選一。實際上，好的架構通常涉及到一種實用的混合方法：例如，使用幾個功能強大的機器仍然比大量的小型虛擬機器更簡單、更便宜。無節制的分布式會給系統混入複雜度，這是軟體工程中危險的地方，雖然在多台機器上分發無狀態服務相當簡單，但將有狀態資料系統從單個節點轉移到分布式安裝程式會帶來許多額外的複雜性。
  沒有這樣的東西，一個通用的，一個適合所有的應用的可伸縮的架構。（寫的真好）

（3）可維護性

這部分教導了一些構建可維護系統的方法。軟體的大部分成本不是在最初的開發中，而是在持續的維護中修複bug、保持系統運行、使其適應新業務、添加新特性。

• 可操作性
  讓操作營運團隊保持系統啟動並執行順利。

• 簡單
  讓新工程師很容易理解系統，通過儘可能地從系統中刪除儘可能多的複雜性。

• 可進化性
  讓工程師很容易在將來對系統變更，以適應需求變化時的意料之外的用例。也被稱為可擴充性、可修改性、可塑性。

（維護別人留下的爛攤子真的是很痛苦的事情，文檔，注釋真的是重中之重！！！）

可靠的、可擴充的、可維護的資料系統 ------《Designing Data-Intensive Applications》讀書筆記1