我在實習和工作的過程中發現技術方案的設計這一環節是後端開發散發魅力並且深深吸引我的地方，好的技術方案/架構設計 可以讓整個系統開發的開發者開發更輕鬆 後續的維護 以及擴充更容易 遇到高併發、各種軟硬體失效人為錯誤帶來的挑戰時更可靠，總而言之，這讓我覺得像是在設計自己世界樂高，我對此很有興趣，於是找到了這本書。
資料系統基礎
這裡先給出了一個全文檢索伺服器的例子（之前《Go In Action》也拿搜尋例子做為開篇，看來文字檢索很受大家歡迎呀），，假定某個應用包含快取層（例如Memcached)與全文索引伺服器（如Elasticsearch或Solr),二者與主資料庫保持關聯，通常由應用程式碼負責快取、索引與主資料庫之間的同步，如下圖所示
在設計這個系統的時候，我們需要
- 透過快取正確地重新整理來保證客戶端們看到的效果一致；
- 系統出現區域性失效的時候 保證資料的正確性和完整性
- 系統發生降級時為客戶提供一致良好的表現。
- 負載增加時系統便於擴充
...
這本書主要圍繞系統設計的
- 可靠性
- 可擴充套件性
- 可維護性
展開
可靠性
- 硬體故障
在設計系統考慮硬體可靠性的時候 我們需要考慮到 硬碟崩潰、記憶體故障、電網停電、網線被拔掉等情況。
應對的方案大致有：1.新增硬體冗餘
（比如磁碟配置RAID，伺服器配置雙電源，熱插拔CPU，資料中心新增備用電源，發電機等）2.滾動升級（後面會介紹） - 軟體錯誤
特點時間值導致伺服器崩潰，比如2012年6月30日發生的閏秒觸發的Linux核心bug、依賴服務故障、級聯故障等。
軟體錯誤很多時候沒辦法快速解決，需要在系統設計之初認真檢查各種互動和依賴，進行全面的測試，程式隔離，提前設計好異常告警。 - 人為錯誤
經調查發現，運維人員的配置錯誤是某大型網際網路服務下線的首要原因。
所以在系統設計的時候，我們可以先假定人是不可靠的，用最小的出錯方式來設計系統、分離出最易出錯的地方、充分測試、制定出錯是快速恢復機制等。
未完待續。。。
參考
Kleppmann M. Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems[M]. " O'Reilly Media, Inc.", 2017.