分佈式系統設計理念
下面詳細闡述筆者理解的幾個分佈式系統設計理念：
1. 分佈式系統對服務器硬件要求很低
這一點主要如今以下兩個方面：
對服務器硬件可靠性不作要求，容許服務器硬件發生故障，硬件的故障由軟件來容錯。因此分佈式系統的高可靠性是由軟件來保證。
對服務器的性能不作要求，不要求使用高頻CPU、大容量內存、高性能存儲等等。由於分佈式系統的性能瓶頸在於節點間通信帶來的網絡開銷，單臺服務器硬件性能再好，也要等待網絡IO。
通常而言，互聯網公司的大型數據中心都是選用大量廉價的PC服務器而不是用幾臺高性能服務器搭建分佈式集羣，以此來下降數據中心成本。好比，Google對於數據中心的成本控制作到了極致：全部服務器一概不要機箱；主板徹底定製，只要最基本的組件，早期的定製主板連電源開關和USB接口都不要；在主板上加裝隔離帶把CPU單獨隔出來，讓冷風只吹CPU，不吹內存、硬盤等不須要降溫的組件，最大限度下降冷卻電力消耗。
2. 分佈式系統強調橫向可擴展性
橫向可擴展性（Scale Out）是指經過增長服務器數量來提高集羣總體性能。縱向可擴展性（Scale Up）是指提高每臺服務器性能進而提高集羣總體性能。縱向可擴展性的上限很是明顯，單臺服務器的性能不可能無限提高，並且跟服務器性能相比，網絡開銷纔是分佈式系統最大的瓶頸。橫向可擴展性的上限空間比較大，集羣總能很方便地增長服務器。並且分佈式系統會盡量保證橫向擴展帶來集羣總體性能的（準）線性提高。好比有10臺服務器組成的集羣，橫向擴展爲100臺一樣服務器的集羣，那麼總體分佈式系統性能會提高爲接近原來的10倍。
互聯網公司的數據中心，通常一個分佈式系統橫向擴展的上限在萬臺服務器左右。Google數據中心的基本單元，CELL，由兩萬臺左右服務器組成，每一個CELL由一套分佈式管理系統，BORG，統一管理，每一個數據中心都由多個CELL組成。
3. 分佈式系統不容許單點失效（No Single Point Failure）
單點失效是指，某個應用服務只有一份實例運行在某一臺服務器上，這臺服務器一旦掛掉，那麼這個應用服務必然也受影響而掛掉，致使整個服務不可用。例如，某網站後臺若是隻在某一臺服務器上運行一份，那這臺服務器一旦宕機，該網站服務必然受影響而不可用。再好比，若是全部數據都存在某一臺服務器上，那一旦這臺服務器壞了，全部數據都不可訪問。
由於分佈式系統的服務器都是廉價的PC服務器，硬件不能保證100%可靠，因此分佈式系統默認每臺服務器隨時均可能發生故障掛掉。同時分佈式系統必需要提供高可靠服務，不容許出現單點失效，所以分佈式系統裏運行的每一個應用服務都有多個運行實例跑在多個節點上，每一個數據點都有多個備份存在不一樣的節點上。這樣一來，多個節點同時發生故障，致使某個應用服務的全部實例都掛掉、或某個數據點的多個備份都不可讀的機率大大下降，進而有效防止單點失效。
一般狀況，不要讓服務器滿負荷運行，服務器長時間滿負荷運行的話，出故障的機率顯著升高。因此分佈式系統採用一大堆中低性能的PC服務器，儘量把負載均攤到全部服務器上，讓每臺服務器的負載都不高，保證集羣總體穩定性。
4. 分佈式系統儘量減小節點間通信開銷
如前所述，分佈式系統的總體性能瓶頸在於內部網絡開銷。目前網絡傳輸的速度還趕不上CPU讀取內存或硬盤的速度，因此減小網絡通信開銷，讓CPU儘量處理內存的數據或本地硬盤的數據，能顯著提升分佈式系統的性能。典型的例子就是Hadoop MapReduce，把計算任務分配到要處理的數據所在的節點上運行，從而避免在網絡上傳輸數據。
5. 分佈式系統應用服務最好作成無狀態的
應用服務的狀態是指運行時程序由於處理服務請求而存在內存的數據。分佈式應用服務最好是設計成無狀態。由於若是應用程序是有狀態的，那麼一旦服務器宕機就會使得應用服務程序受影響而掛掉，那存在內存的數據也就丟失了，這顯然不是高可靠的服務。把應用服務設計成無狀態的，讓程序把須要保存的數據都保存在專門的存儲上，這樣應用服務程序能夠任意重啓而不丟失數據，方便分佈式系統在服務器宕機後恢復應用服務。
好比，在設計網站後臺的時候，對於用戶登錄請求，能夠把登錄用戶的session相關信息保存在Redis或Memcache等緩存服務中，這樣每一個網站的後臺實例不保存用戶登陸狀態，這樣即便重啓網站後臺程序也不丟失用戶的登陸狀態信息；若是把用戶的session相關信息保存在網站後臺程序的內存裏，那一旦受理用戶登陸的網站後臺程序實例掛掉，必然有用戶的登陸狀態信息會丟失。
總而言之，分佈式系統是大數據時代企業級應用的首選平臺，它有良好的可擴展性，尤爲是橫向可擴展性（Scale Out），使得分佈式系統很是靈活，能應對變幻無窮的企業級需求，並且下降了企業客戶對服務器硬件的要求，真正能作到應用服務層面的彈性擴展（auto-scaling）。
緩存