分佈式問題分析

參考：https://github.com/CyC2018/Interview-Notebook/blob/master/notes/

業務中的分佈式：

分佈式存儲：將數據分片到多個節點上，不只能夠提升性能（可擴展性），同時也可使用多個節點對同一份數據進行備份（高可用性）

分佈式計算：將一個大的計算任務分解成小任務分配到多個節點上去執行，再彙總每一個小任務的執行結果獲得最終結果。MapReduce 是分佈式計算最好的例子。

 

分佈式事務：
指事務的操做位於不一樣的節點上，須要保證事務的 AICD 特性。

產生的緣由：

• 數據庫分庫分表；
• SOA 架構，好比一個電商網站將訂單業務和庫存業務分離出來放到不一樣的節點上。

解決辦法：

1. 兩階段提交協議（很好地解決分佈式事務問題）

2. 消息中間件（本質上是一個暫存轉發消息的一箇中間件）

處理模型：（1）點對點；（2）發佈/訂閱

 

 

 負載均衡的算法與實現：

算法有輪詢（Round Robin）、加權輪詢、最少鏈接（將請求發送給當前最少鏈接數的服務器）、加權最小鏈接、隨機算法

上面的沒有加權的適合服務器性能差很少場景

 

Zookeeper 分佈式鎖

　　Zookeeper 是一個爲分佈式應用提供一致性服務的軟件，例如配置管理、分佈式協同以及命名的中心化等，這些都是分佈式系統中很是底層並且是必不可少的基本功能，可是若是本身實現這些功能並且要達到高吞吐、低延遲同時還要保持一致性和可用性，實際上很是困難。

　　抽象模型：Zookeeper 提供了一種樹形結構級的命名空間，/app1/p_1 節點表示它的父節點爲 /app1。

監聽器：爲一個節點註冊監聽器，在節點狀態發生改變時，會給客戶端發送消息。

節點類型

• 永久節點：不會由於會話結束或者超時而消失；
• 臨時節點：若是會話結束或者超時就會消失；
• 有序節點：會在節點名的後面加一個數字後綴，而且是有序的，例如生成的有序節點爲 /lock/node-0000000000，它的下一個有序節點則爲 /lock/node-0000000001，依次類推。

分佈式鎖實現：

1. 建立一個鎖目錄 /lock。
2. 在 /lock 下建立臨時的且有序的子節點，第一個客戶端對應的子節點爲 /lock/lock-0000000000，第二個爲 /lock/lock-0000000001，以此類推。
3. 客戶端獲取 /lock 下的子節點列表，判斷本身建立的子節點是否爲當前子節點列表中序號最小的子節點，若是是則認爲得到鎖，不然監聽本身的前一個子節點，得到子節點的變動通知後重復此步驟直至得到鎖；
4. 執行業務代碼，完成後，刪除對應的子節點。

會話超時

　　若是一個已經得到鎖的會話超時了，由於建立的是臨時節點，所以該會話對應的臨時節點會被刪除，其它會話就能夠得到鎖了。能夠看到，Zookeeper 分佈式鎖不會出現數據庫分佈式鎖的死鎖問題。

羊羣效應（在這裏不存在羊羣效應）

　　在步驟二，一個節點未得到鎖，須要監聽監聽本身的前一個子節點，這是由於若是監聽全部的子節點，那麼任意一個子節點狀態改變，其它全部子節點都會收到通知（羊羣效應），而咱們只但願它的後一個子節點收到通知。

--------------------------------------------------------

分佈式 Session

　　在分佈式場景下，一個用戶的 Session 若是隻存儲在一個服務器上，那麼當負載均衡器把用戶的下一個請求轉發到另外一個服務器上，該服務器沒有用戶的 Session，就可能致使用戶須要從新進行登陸等操做。

Sticky Sessions

須要配置負載均衡器，使得一個用戶的全部請求都路由到一個服務器節點上，這樣就能夠把用戶的 Session 存放在該服務器節點中。

缺點：當服務器節點宕機時，將丟失該服務器節點上的全部 Session。

 

Session Replication

在服務器節點之間進行 Session 同步操做，這樣的話用戶能夠訪問任何一個服務器節點。

缺點：須要更好的服務器硬件條件；須要對服務器進行配置。

Persistent DataStore

將 Session 信息持久化到一個數據庫中。

缺點：有可能須要去實現存取 Session 的代碼。

 

In-Memory DataStore

可使用 Redis 和 Memcached 這種內存型數據庫對 Session 進行存儲，能夠大大提升 Session 的讀寫效率。內存型數據庫一樣能夠持久化數據到磁盤中來保證數據的安全性。