分散式系統概念

分散式系統是由一系列分散自治元件通過網際網路並行併發協作，從而組成的一個coherent軟體系統。

它具備資源共享，並行併發，可靠容錯，透明開放等特性。

分散式概念
(1)三元組：分散式系統說白了，就是很多機器組成的叢集，靠彼此之間的網路通訊，擔當的角色可能不同，共同完成同一個事情的系統。
1、節點 -- 系統中按照協議完成計算工作的一個邏輯實體，可能是執行某些工作的程序或機器
2、網路 -- 系統的資料傳輸通道，用來彼此通訊。通訊是具有方向性的。
3、儲存 -- 系統中持久化資料的資料庫或者檔案儲存。
(2)狀態特性
各個節點的狀態可以是“無狀態”或者“有狀態的”.
一般認為，節點是偏計算和通訊的模組，一般是無狀態的。這類應用一般不會儲存自己的中間狀態資訊，比如Nginx，一般情況下是轉發請求而已，不會儲存中間資訊。另一種“有狀態”的，如MySQL等資料庫，狀態和資料全部持久化到磁碟等介質。“無狀態”的節點一般我們認為是可隨意重啟的，因為重啟後只需要立刻工作就好。“有狀態”的則不同，需要先讀取持久化的資料，才能開始服務。所以，“無狀態”的節點一般是可以隨意擴充套件的，“有狀態”的節點需要一些控制協議來保證擴充套件。
(3)系統異常
異常，可認為是節點因為某種原因不能工作，此為節點異常。還有因為網路原因，臨時、永久不能被其他節點所訪問，此為網路異常。在分散式系統中，要有對異常的處理，保證叢集的正常工作。

分散式基礎理論：CAP，BASE，Paxos，事務

1.CAP理論:一致性（Consistency），可用性（Availability），分割槽容忍性（Partition tolerance）

1.Consistency一致性，Eric Brewer（CAP理論提出者）用一個服務要麼被執行，要麼不被執行來定義(原文：A service that is consistent operates fully or not at all)。請注意，這裡的一致性是有別於資料庫ACID屬性中的C，資料庫層面的C指的是資料的操作不能破壞資料之間的完整性約束，如外來鍵約束。在分散式環境中，可以把C簡單理解為多節點看到的是資料單一或者同一副本。
2.Availability可用性，意味著服務是可用的。可用性又可以細分為寫可用和讀可用。在分散式環境中，往往指的是系統在確定時間內可返回讀寫操作結果，也即讀寫均可用。
3.Partition tolerance分割槽容忍性，除了整個網路故障外（如光纖被掘斷），其它故障（如丟包、亂序、抖動、甚至是網路分割槽節點 crash ）都不能導致整個系統無法正確響應。

2.BASE理論:基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）

eBay的架構師Dan Pritchett，在ACM上發表文章提出。BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。
1.基本可用（Basically Available）是指分散式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。
電商大促時，為了應對訪問量激增，部分使用者可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
2.軟狀態（ Soft State）軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式儲存中一般一份資料至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的非同步複製也是一種體現。 
3.最終一致性（ Eventual Consistency）是指系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

3.Paxos:分散式一致性演算法

提議者Proposer、接受者Acceptor、提案Proposal的proposal_id
總體說來，paxos就是通過兩個階段確定一個決議：
Phase1：確定誰的編號proposal_id最高，只有編號最高者才有權利提交proposal；
Phase2：編號最高者提交proposal，如果沒有其他節點提出更高編號的proposal，則該提案會被順利通過；否則，整個過程就會重來。
你編號高，我比你更高，反覆如此，演算法永遠無法結束，這叫活鎖。活鎖便是Paxos無法解決的硬傷.

4.事務

分散式事務，常見兩個處理辦法就是兩段式提交和補償。
1.兩段式提交:
a. 協調員伺服器傳送一條投票請求訊息給所有參與這次事務的參與者伺服器。
b. 當一個參與者收到一條投票請求，它會向協調員傳送一條響應請求訊息:YES/NO。如果參與者投票NO，意味著參與者不參與這次事務，等價於ABORT決定，事務終止。
c. 協調員收集所有參與者的投票都是YES，則COMMIT，並把COMMIT訊息傳送給所有參與者。否則ABORT，協調員會把ABORT訊息發給那些投票為YES的那些參與者
2.補償
先處理業務，然後定時或者回調裡，檢查狀態是不是一致的，如果不一致採用某個策略，強制狀態到某個結束狀態。
思路：事務拆分，大的業務流程，轉化成幾個小的業務流程，加入中間狀態，考慮最終一致性。
複雜的業務互動過程中，不建議使用強一致性的分散式事務。解決分散式事務的最好辦法就是不考慮分散式事務。就像剛說的問題一樣，把分散式的事務過程拆解成多箇中間狀態，中間狀態的東西不允許使用者直接操作，等狀態都一致成功，或者檢測到不一致的時候全部失敗掉。就解耦了這個強一致性的過程。

分散式系統與單節點的不同

 1.網路傳輸

在unix/linux/mac(類Unix)環境下，兩個機器通訊（socket），傳輸資料是read()/write()系統呼叫，把一段記憶體緩衝區發出去。傳送資料需要走核心->網絡卡->鏈路->對端網絡卡->核心，路徑太長只能是非同步操作。write()把資料寫入核心緩衝區之後就返回到應用層了，具體後面何時傳送、怎麼傳送、TCP怎麼做滑動視窗、流控都是tcp/ip協議棧核心的事情了。
所以在應用層，能確認對方受到了訊息只能是對方應用返回資料，邏輯確認了這次傳送才認為是成功的。
這就卻別與單系統程式設計，大部分系統呼叫、庫呼叫只要返回了就說明已經確認完成了。

 2.不可控的狀態

在單系統程式設計中，我們對系統狀態是非常可控的。比如函式呼叫、邏輯運算，要麼成功，要麼失敗，因為這些操作被框在一個機器內部，cpu/匯流排/記憶體都是可以快速得到反饋的。開發者可以針對這兩個狀態很明確的做出程式上的判斷和後續的操作。
而在分散式的網路環境下，這就變得微妙了。比如一次rpc、http呼叫，可能成功、失敗，還有可能是“超時”，這就比前者的狀態多了一個不可控因素，導致後面的程式碼不是很容易做出判斷。試想一下，用A用支付寶向B轉了一大筆錢，當他按下“確認”後，介面上有個圈在轉啊轉，然後顯示請求超時了，然後A就抓狂了，不知道到底錢轉沒轉過去，開始確認自己的賬戶、確認B的賬戶、打電話找客服等等。
所以分散式環境下，我們的其實要時時刻刻考慮面對這種不可控的“第三狀態”設計開發，這也是挑戰之一。

 3.視”異常“為”正常“

單系統下，程序/機器的異常概率十分小。即使出現了問題，可以通過人工干預重啟、遷移等手段恢復。
但在分散式環境下，機器上千臺，每幾分鐘都可能出現宕機、宕機、網路斷網等異常，出現的概率很大。所以，這種環境下，程序core掉、機器掛掉都是需要我們在程式設計中認為隨時可能出現的，這樣才能使我們整個系統健壯起來，所以”容錯“是基本需求。
異常可以分為如下幾類：
節點錯誤：一般是由於應用導致，一些coredump和系統錯誤觸發，一般重新服務後可恢復。
硬體錯誤：由於磁碟或者記憶體等硬體裝置導致某節點不能服務，需要人工干預恢復。 
網路錯誤：由於點對點的網路抖動，暫時的訪問錯誤，一般拓撲穩定後或流量減小可以恢復。
網路分化：網路中路由器、交換機錯誤導致網路不可達，但是網路兩邊都正常，這類錯誤比較難恢復，並且需要在開發時特別處理。【這種情況也會比較前面的問題較難處理】

分散式系統設計策略

 1.重試機制

一般情況下，寫一段網路互動的程式碼，發起rpc或者http，都會遇到請求超時而失敗情況。可能是網路抖動(暫時的網路變更導致包不可達，比如拓撲變更)或者對端掛掉。這時一般處理邏輯是將請求包在一個重試迴圈塊裡，如下：
int retry = 3;  
while(!request() && retry--)  
  sched_yield();   // or usleep(100)  
此種模式可以防止網路暫時的抖動，一般停頓時間很短，並重試多次後，請求成功！但不能防止對端長時間不能連線(網路問題或程序問題)

 2.心跳機制

心跳顧名思義，就是以固定的頻率向其他節點彙報當前節點狀態的方式。收到心跳，一般可以認為一個節點和現在的網路拓撲是良好的。當然，心跳彙報時，一般也會攜帶一些附加的狀態、元資料資訊，以便管理。但心跳不是萬能的，收到心跳可以確認ok，但是收不到心跳卻不能確認節點不存在或者掛掉了，因為可能是網路原因倒是鏈路不通但是節點依舊在工作。
所以切記，”心跳“只能告訴你正常的狀態是ok，它不能發現節點是否真的死亡，有可能還在繼續服務。(後面會介紹一種可靠的方式 -- Lease機制)

 3.副本

副本指的是針對一份資料的多份冗餘拷貝，在不同的節點上持久化同一份資料，當某一個節點的資料丟失時，可以從副本上獲取資料。資料副本是分散式系統解決資料丟失異常的僅有的唯一途徑。當然對多份副本的寫入會帶來一致性和可用性的問題，比如規定副本數為3，同步寫3份，會帶來3次IO的效能問題。還是同步寫1份，然後非同步寫2份，會帶來一致性問題，比如後面2份未寫成功其他模組就去讀了(下個小結會詳細討論如果在副本一致性中間做取捨)。

 4.中心化/無中心化

系統模型這方面，無非就是兩種：
中心節點，例如mysql的MSS單主雙從、MongDB Master、HDFS NameNode、MapReduce JobTracker等，有1個或幾個節點充當整個系統的核心元資料及節點管理工作，其他節點都和中心節點互動。這種方式的好處顯而易見，資料和管理高度統一集中在一個地方，容易聚合，就像領導者一樣，其他人都服從就好。簡單可行。
但是缺點是模組高度集中，容易形成效能瓶頸，並且如果出現異常，就像群龍無首一樣。
無中心化的設計，例如cassandra、zookeeper，系統中不存在一個領導者，節點彼此通訊並且彼此合作完成任務。好處在於如果出現異常，不會影響整體系統，區域性不可用。缺點是比較協議複雜，而且需要各個節點間同步資訊。

大型網站架構演化

(1)初始階段：獨立伺服器
應用伺服器、檔案服務、資料庫服務所有資源在同一臺伺服器
(2)起步階段：應用與資料分離，不同特性伺服器承擔不同服務角色。
應用伺服器，檔案伺服器和資料庫伺服器對硬體資源要求各不相同，分離承擔不同角色服務
(3)提升階段：使用快取技術和資料庫讀寫分離
網站訪問遵循二八定律，快取熱點資料，提升網站訪問速度，降低資料服務訪問壓力
(4)進化階段1：應用伺服器叢集：實現負載均衡
叢集是解決高併發，海量資料問題的常用手段，引入負載均衡伺服器實現系統訪問請求的分發，實現系統的可伸縮性
(5)進化階段2：分散式資料庫，實現讀寫分離
使用者達到一定規模，快取仍不能解決資料庫服務瓶頸問題，搭建資料庫主從架構，實現讀寫分離
(6)進化階段3：面對複雜網路環境，使用反向代理和CDN加速網站響應，提升快取能力，加快使用者訪問速度
反向代理：部署在網站中心機房；CDN(內容分發網路)：部署在網路提供商機房

分散式系統優化

1. I/O優化

增加快取，減少磁碟的訪問次數。
優化磁碟的管理系統，設計最優的磁碟方式策略，以及磁碟的定址策略，這是在底層作業系統層面考慮的。
設計合理的磁碟儲存資料塊，以及訪問這些資料庫的策略，這是在應用層面考慮的。例如，我們可以給存放的資料設計索引，通過定址索引來加快和減少磁碟的訪問量，還可以採用非同步和非阻塞的方式加快磁碟的訪問速度。
應用合理的RAID策略提升磁碟I/O。

2. Web前端調優

減少網路互動的次數（多次請求合併）
減少網路傳輸資料量的大小(壓縮)
儘量減少編碼（儘量提前將字元轉化為位元組，或者減少從字元到位元組的轉化過程。）
使用瀏覽器快取
減少Cookie傳輸
合理佈局頁面
使用頁面壓縮
延遲載入頁面
CSS在最上面，JS在最下面
CDN
反向代理
頁面靜態化
異地部署

3.服務降級（自動優雅降級）

拒絕服務和關閉服務

4.冪等性設計

有些服務天然具有冪等性，比如講使用者性別設定為男性，不管設定多少次，結果都一樣。但是對轉賬交易等操作，問題就會比較複雜，需要通過交易編號等資訊進行服務呼叫有效性校驗，只有有效的操作才能繼續執行。
（注：冪等性是系統的介面對外一種承諾(而不是實現), 承諾只要呼叫介面成功, 外部多次呼叫對系統的影響是一致的. 宣告為冪等的介面會認為外部呼叫失敗是常態, 並且失敗之後必然會有重試.）

5.失效轉移

若資料伺服器叢集中任何一臺伺服器宕機，那麼應用程式針對這臺伺服器的所有讀寫操作都需要重新路由到其他伺服器，保證資料訪問不會失敗，這個過程叫失效轉移。
失效轉移包括：失效確認（心跳檢測和應用程式訪問失敗報告）、訪問轉移、資料恢復。
失效轉移保證當一個數據副本不可訪問時，可以快速切換訪問資料的其他副本，保證系統可用。

6.效能優化

根據網站分層架構,效能優化可分為：web前端效能優化、應用伺服器效能優化、儲存伺服器效能優化。
1. web前端效能優化
瀏覽器訪問優化：減少http請求;使用瀏覽器快取;啟用壓縮;css放在頁面最上面、javaScript放在頁面最下面;減少Cookie傳輸
CDN加速
反向代理
2. 應用伺服器效能優化
分散式快取（Redis等）
非同步操作（訊息佇列）
使用叢集（負載均衡）
程式碼優化
3. 儲存效能優化
機械硬碟vs固態硬碟
B+樹 vs LSM樹
RAID vs HDFS

7. 程式碼優化

多執行緒（Q:怎麼確保執行緒安全？無鎖機制有哪些？）
資源複用（單例模式，連線池，執行緒池）
資料結構
垃圾回收

8. 負載均衡

HTTP重定向負載均衡
當用戶發來請求的時候，Web伺服器通過修改HTTP響應頭中的Location標記來返回一個新的url，然後瀏覽器再繼續請求這個新url，實際上就是頁面重定向。通過重定向，來達到“負載均衡”的目標。例如，我們在下載PHP原始碼包的時候，點選下載連結時，為了解決不同國家和地域下載速度的問題，它會返回一個離我們近的下載地址。重定向的HTTP返回碼是302。
優點：比較簡單。
缺點：瀏覽器需要兩次請求伺服器才能完成一次訪問，效能較差。重定向服務自身的處理能力有可能成為瓶頸，整個叢集的伸縮性國模有限；使用HTTP302響應碼重定向，有可能使搜尋引擎判斷為SEO作弊，降低搜尋排名。

DNS域名解析負載均衡
DNS（Domain Name System）負責域名解析的服務，域名url實際上是伺服器的別名，實際對映是一個IP地址，解析過程，就是DNS完成域名到IP的對映。而一個域名是可以配置成對應多個IP的。因此，DNS也就可以作為負載均衡服務。
事實上，大型網站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組伺服器並不是實際提供Web服務的物理伺服器，而是同樣提供負載均衡服務的內部伺服器，這組內部負載均衡伺服器再進行負載均衡，將請求分發到真是的Web伺服器上。
優點：將負載均衡的工作轉交給DNS，省掉了網站管理維護負載均衡伺服器的麻煩，同時許多DNS還支援基於地理位置的域名解析，即會將域名解析成舉例使用者地理最近的一個伺服器地址，這樣可以加快使用者訪問速度，改善效能。
缺點：不能自由定義規則，而且變更被對映的IP或者機器故障時很麻煩，還存在DNS生效延遲的問題。而且DNS負載均衡的控制權在域名服務商那裡，網站無法對其做更多改善和更強大的管理。

反向代理負載均衡
反向代理服務可以快取資源以改善網站效能。實際上，在部署位置上，反向代理伺服器處於Web伺服器前面（這樣才可能快取Web相應，加速訪問），這個位置也正好是負載均衡伺服器的位置，所以大多數反向代理伺服器同時提供負載均衡的功能，管理一組Web伺服器，將請求根據負載均衡演算法轉發到不同的Web伺服器上。Web伺服器處理完成的響應也需要通過反向代理伺服器返回給使用者。由於web伺服器不直接對外提供訪問，因此Web伺服器不需要使用外部ip地址，而反向代理伺服器則需要配置雙網絡卡和內部外部兩套IP地址。
優點：和反向代理伺服器功能整合在一起，部署簡單。
缺點：反向代理伺服器是所有請求和響應的中轉站，其效能可能會成為瓶頸。

LVS-NAT:修改IP地址
LVS-TUN: 一個IP報文封裝在另一個IP報文的技術。
LVS-DR:將資料幀的MAC地址改為選出伺服器的MAC地址，再將修改後的資料幀在與伺服器組的區域網上傳送。

9.快取

快取就是將資料存放在距離計算最近的位置以加快處理速度。快取是改善軟體效能的第一手段，現在CPU越來越快的一個重要因素就是使用了更多的快取，在複雜的軟體設計中，快取幾乎無處不在。大型網站架構設計在很多方面都使用了快取設計。
CDN: 內容分發網路，部署在距離終端使用者最近的網路服務商，使用者的網路請求總是先到達他的網路服務商哪裡，在這裡快取網站的一些靜態資源（較少變化的資料），可以就近以最快速度返回給使用者，如視訊網站和入口網站會將使用者訪問量大的熱點內容快取在CDN中。
反向代理：反向代理屬於網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的資料中心時，最先訪問到的就是反向代理伺服器，這裡快取網站的靜態資源，無需將請求繼續轉發給應用伺服器就能返回給使用者。
本地快取：在應用伺服器本地快取著熱點資料，應用程式可以在本機記憶體中直接訪問資料，而無需訪問資料庫。
分散式快取：大型網站的資料量非常龐大，即使只快取一小部分，需要的記憶體空間也不是單機能承受的，所以除了本地快取，還需要分散式快取，將資料快取在一個專門的分散式快取叢集中，應用程式通過網路通訊訪問快取資料。
使用快取有兩個前提條件，一是資料訪問熱點不均衡，某些資料會被更頻繁的訪問，這些資料應該放在快取中；二是資料在某個時間段內有效，不會很快過期，否則快取的資料就會因已經失效而產生髒讀，影響結果的正確性。網站應用中，快取處理可以加快資料訪問速度，還可以減輕後端應用和資料儲存的負載壓力，這一點對網站資料庫架構至關重要，網站資料庫幾乎都是按照有快取的前提進行負載能力設計的。

10. 負載均衡演算法

輪詢 Round Robin
加強輪詢 Weight Round Robin
隨機 Random
加強隨機 Weight Random
最少連線 Least Connections
加強最少連線
源地址雜湊 Hash

其他演算法
最快演算法(Fastest)：傳遞連線給那些響應最快的伺服器。當其中某個伺服器發生第二到第7 層的故障，BIG-IP 就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
觀察演算法(Observed)：連線數目和響應時間以這兩項的最佳平衡為依據為新的請求選擇伺服器。當其中某個伺服器發生第二到第7 層的故障，BIG-IP就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
預測演算法(Predictive)：BIG-IP利用收集到的伺服器當前的效能指標，進行預測分析，選擇一臺伺服器在下一個時間片內，其效能將達到最佳的伺服器相應使用者的請求。(被BIG-IP 進行檢測)
動態效能分配演算法(Dynamic Ratio-APM):BIG-IP 收集到的應用程式和應用伺服器的各項效能引數，動態調整流量分配。
動態伺服器補充演算法(Dynamic Server Act.):當主伺服器群中因故障導致數量減少時，動態地將備份伺服器補充至主伺服器群。
服務質量演算法(QoS):按不同的優先順序對資料流進行分配。
服務型別演算法(ToS): 按不同的服務型別(在Type of Field中標識)負載均衡對資料流進行分配。
規則模式演算法：針對不同的資料流設定導向規則，使用者可自行

11. 擴充套件性和伸縮性的區別

擴充套件性：指對現有系統影響最小的情況下，系統功能可持續擴充套件或替身的能力。表現在系統基礎設施穩定不需要經常變更，應用之間較少依賴和耦合，對需求變更可以敏捷響應。它是系統架構設計層面的開閉原則（對擴充套件開放，對修改關閉），架構設計考慮未來功能擴充套件，當系統增加新功能時，不需要對現有系統的結構和程式碼進行修改。
衡量網站架構擴充套件性好壞的主要標準就是在網站增加新的業務產品時，是否可以實現對現有產品透明無影響，不需要任何改動或者很少改動既有業務功能就可以上線新產品。不同產品之間是否很少耦合，一個產品改動對其他產品無影響，其他產品和功能不需要受牽連進行改動。
伸縮性：所謂網站的伸縮性指是不需要改變網站的軟硬體設計，僅僅通過改變部署的伺服器數量就可以擴大或者縮小網站的服務處理能力。
指系統能夠增加（減少）自身資源規模的方式增強（減少）自己計算處理事務的能力。如果這種增減是成比例的，就被稱作線性伸縮性。在網站架構中，通常指利用叢集的方式增加伺服器數量、提高系統的整體事務吞吐能力。
衡量架構伸縮性的主要標準就是可以用多臺伺服器構建叢集，是否容易向叢集中新增新的伺服器。加入新的伺服器後是否可以提供和原來服務無差別的服務、叢集中的可容納的總的伺服器數量是否有限制。

12.分散式快取的一致性hash

具體演算法過程：先構造一個長度為2^32的整數環（這個環被稱作一致性Hash環）根據節點名稱的Hash值（其分佈範圍為[0,2^32 - 1]）將快取伺服器階段設定在這個Hash環上。然後根據需要快取的資料的Key值計算得到Hash值（其分佈範圍也同樣為[0,2^32 - 1]），然後在Hash環上順時針查詢舉例這個KEY的hash值最近的快取伺服器節點，完成KEY到伺服器的Hash對映查詢。
優化策略：將每臺物理伺服器虛擬為一組虛擬快取伺服器，將虛擬伺服器的Hash值放置在Hash環上，key在換上先找到虛擬伺服器節點，再得到物理伺服器的資訊。
一臺物理伺服器設定多少個虛擬伺服器節點合適呢？經驗值：150。
一致性hash演算法提出了在動態變化的Cache環境中，判定雜湊演算法好壞的四個定義：
1、平衡性(Balance)：平衡性是指雜湊的結果能夠儘可能分佈到所有的緩衝中去，這樣可以使得所有的緩衝空間都得到利用。很多雜湊演算法都能夠滿足這一條件。
2、單調性(Monotonicity)：單調性是指如果已經有一些內容通過雜湊分派到了相應的緩衝中，又有新的緩衝加入到系統中。雜湊的結果應能夠保證原有已分配的內容可以被對映到原有的或者新的緩衝中去。 
3、分散性(Spread)：(即不一致)在分散式環境中，終端有可能看不到所有的緩衝，而是隻能看到其中的一部分。當終端希望通過雜湊過程將內容對映到緩衝上時，由於不同終端所見的緩衝範圍有可能不同，從而導致雜湊的結果不一致，最終的結果是相同的內容被不同的終端對映到不同的緩衝區中。這種情況顯然是應該避免的，因為它導致相同內容被儲存到不同緩衝中去，降低了系統儲存的效率。
4、負載(Load)：負載問題實際上是從另一個角度看待分散性問題。既然不同的終端可能將相同的內容對映到不同的緩衝區中，那麼對於一個特定的緩衝區而言，也可能被不同的使用者對映為不同 的內容。與分散性一樣，這種情況也是應當避免的，因此好的雜湊演算法應能夠儘量降低緩衝的負荷。

13. 網路安全

1. XSS攻擊
跨站點指令碼攻擊(Cross Site Script)，指黑客通過篡改網頁，注入惡意的HTML指令碼，在使用者瀏覽網頁時，控制使用者瀏覽器進行惡意操作的一種攻擊方式。
防範手段：消毒（XSS攻擊者一般都是通過在請求中嵌入惡意指令碼大道攻擊的目的，這些指令碼是一般使用者輸入中不使用的，如果進行過濾和消毒處理，即對某些html危險字元轉移，如“>”轉譯為“& gt;”）;HttpOnly(防止XSS攻擊者竊取Cookie).
2. 注入攻擊：SQL注入和OS注入
SQL防範：預編譯語句PreparedStatement; ORM；避免密碼明文存放；處理好相應的異常。
3. CSRF（Cross Site Request Forgery，跨站點請求偽造）。聽起來與XSS有點相似，事實上兩者區別很大，XSS利用的是站內的信任使用者，而CSRF則是通過偽裝來自受信任使用者的請求來利用受信任的網站。
防範：httpOnly;增加token;通過Referer識別。
4. 檔案上傳漏洞
5. DDos攻擊

14. 加密技術

摘要加密：MD5, SHA
對稱加密：DES演算法，RC演算法， AES
非對稱加密：RSA
非對稱加密技術通常用在資訊保安傳輸，數字簽名等場合。
HTTPS傳輸中瀏覽器使用的數字證書實質上是經過權威機構認證的非對稱加密的公鑰。

15. 流控（流量控制）

流量丟棄
通過單機記憶體佇列來進行有限的等待，直接丟棄使用者請求的處理方式顯得簡單而粗暴，並且如果是I/O密集型應用（包括網路I/O和磁碟I/O），瓶頸一般不再CPU和記憶體。因此，適當的等待，既能夠替身使用者體驗，又能夠提高資源利用率。
通過分散式訊息佇列來將使用者的請求非同步化。

16.序列化

序列化技術：
Serializable，序列化是將物件狀態轉換為可保持或傳輸的形式的過程。 序列化的補集是反序列化，後者將流轉換為物件。 這兩個過程一起保證資料易於儲存和傳輸。
實現分散式的時候，需要將一個物件從Server分發給client。通過網路TCP，建立Socket，傳輸一個物件，就需要將物件轉換成一段位元組流，即物件的序列化。同時，也要求可以從這段位元組流，創建出對應的物件出來。
---
java Serializable儲存的檔案內容：
當前類描述   
當前類屬性描述 
超類描述
超類屬性描述(如果超類還有超類，則依次遞迴)
超類屬性值描述
子類屬性值描述
---
序列化框架
（1）Java Serializable
java序列化主要是為了跨平臺，實現物件的一致性，可在不同的平臺上，保持自己原有的屬性和方法不變
Serializable方法： writeObject()  readObject()
缺點：
1.無法跨語言。這應該是java序列化最致命的問題了。由於java序列化是java內部私有的協議，其他語言不支援，導致別的語言無法反序列化，這嚴重阻礙了它的應用。
2.序列後的碼流太大。java序列化的大小是二進位制編碼的5倍多！
3.序列化效能太低。java序列化的效能只有二進位制編碼的6.17倍，可見java序列化效能實在太差了。
（2）Kryo是一個快速高效的Java序列化框架，旨在提供快速、高效和易用的API。無論檔案、資料庫或網路資料Kryo都可以隨時完成序列化。Kryo還可以執行自動深拷貝（克隆）、淺拷貝（克隆）。這是物件到物件的直接拷貝，非物件->位元組->物件的拷貝。
（3）Protobuf是google開源的專案，全稱 Google Protocol Buffers.特點：
1.結構化資料儲存格式（xml,json等）
2.高效能編解碼技術
3.語言和平臺無關，擴充套件性好
4.支援java,C++,Python三種語言。
（4）Thrift源於faceBook，2007年facebook將Thrift做為一個開源專案交給了apache基金會。特點：
1.Thrift支援多種語言（C++,C#,Cocoa,Erlag,Haskell,java,Ocami,Perl,PHP,Python,Ruby,和SmallTalk）
2.Thrift適用了組建大型資料交換及儲存工具，對於大型系統中的內部資料傳輸，相對於Json和xml在效能上和傳輸大小上都有明顯的優勢。
3.Thrift支援三種比較典型的編碼方式。（通用二進位制編碼，壓縮二進位制編碼，優化的可選欄位壓縮編解碼）
（5）Hessian
Hessian 是由 caucho 提供的一個基於 binary-RPC 實現的遠端通訊 library