分佈式系統

1、分佈式技術概念

1.負載均衡：

Nginx：高性能、高併發的web服務器；功能包括負載均衡、反向代理、靜態內容緩存、訪問控制；工做在應用層
LVS： Linux virtual server，基於集羣技術和Linux操做系統實現一個高性能、高可用的服務器；工做在網絡層

2.webserver：

Java：Tomcat，Apache，Jboss
Python：gunicorn、uwsgi、twisted、webpy、tornado

3.service：　　
SOA、微服務、spring boot，django

4.容器：

docker，kubernetes

5.cache：

memcache、redis等

6.協調中心：

zookeeper、etcd等
zookeeper使用了Paxos協議Paxos是強一致性，高可用的去中心化分佈式。zookeeper的使用場景很是普遍，以後細講。

7.rpc框架：

grpc、dubbo、brpc
dubbo是阿里開源的Java語言開發的高性能RPC框架，在阿里系的諸多架構中，都使用了dubbo + spring boot

8.消息隊列：

kafka、rabbitMQ、rocketMQ、QSP
消息隊列的應用場景：異步處理、應用解耦、流量削鋒和消息通信

9.實時數據平臺：

storm、akka

10.離線數據平臺：

hadoop、spark
PS: apark、akka、kafka都是scala語言寫的，看到這個語言仍是很牛逼的

11.dbproxy：

cobar也是阿里開源的，在阿里系中使用也很是普遍，是關係型數據庫的sharding + replica 代理

12.db：

mysql、oracle、MongoDB、HBase

13.搜索：

elasticsearch、solr

14.日誌：

rsyslog、elk、flume

 2、分佈式常見問題

1.分佈式事務

 1.1 分佈式事務基礎

    事務的 特性：ACID:原子性、一致性、隔離性、持久性。

   1）CAP定理 

     C:一致性

     A：可用性

　 P：分區容錯性,容忍網絡中斷。

   2）BASE理論 解決了CAP中沒有網絡延遲，用軟狀態和最終一致性，保證了延遲後的一致性。

      BA:基本可用

　  S:軟狀態

      E:最終一致性

 1.2 分佈式事務解決方案 

  DTP事務模型

  DTP角色：

  AP:節點

  RM:資源管理器。數據庫

  TM:事務管理器

  1. 2PC方案：基於XA協議的兩階段提交方案

   1)提交請求階段

   2)提交執行階段

   存在問題：

1. 執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。
2. 協調者發生故障。參與者會一直阻塞下去，須要額外的備機進行容錯。

  2. 3PC:經過超時機制解決阻塞的問題。

   1)詢問階段

   2)準備階段

   3)提交階段

   存在問題：3PC的出現就是經過增長複雜度（性能也所以下降）來解決或優化2PC中的一部分問題。

 3. TCC方案 Try:嘗試執行業務，Confirm:確認執行業務，Cancel:取消執行業務。事務補償。

    第一階段：主業務服務分別調用全部從業務服務的 try 操做，並在活動管理器中記錄全部從業務服務。當全部從業務服務 try 成功或者某個從業務服務 try 失敗時，進入第二階段。

   第二階段：活動管理器根據第一階段從業務服務的 try 結果來執行 confirm 或 cancel 操做。若是第一階段全部從業務服務都 try 成功，則協做者調用全部從業務服務的 confirm 操        做，不然，調用全部從業務服務的 cancel 操做。

   在第二階段中，confirm 和 cancel 一樣存在失敗狀況，因此須要對這兩種狀況作 異常處理 以保證數據一致性。

   Confirm 失敗：則回滾全部 confirm 操做並執行 cancel 操做。

   Cancel 失敗：從業務服務須要提供自動 cancel 機制，以保證 cancel 成功。

    優勢：TCC是對二階段的一個改進，try階段經過預留資源的方式避免了同步阻塞資源的狀況。

    缺點： 缺點仍是比較明顯的，業務侵入性太強，須要大量開發工做進行業務改造，給業務升級、運維都帶來困難；在一些場景中，一些業務流程可能用TCC不太好定義及處理。

 4. 基於消息的最終一致性方案

   

2.接口冪等性

 1）對於每一個請求必須有一個惟一的標識。

 2）每次處理完請求以後，必須有一個記錄標識這個請求處理過了。

 3）每次接收請求須要進行判斷以前是否處理過的邏輯處理。

  例：用redis用orderId做爲惟一鍵。

3.分佈式鎖

  1)數據庫：實現排他鎖

  2)redis分佈式鎖，redisson

  3)zk分佈式鎖，curator

  性能：redis > zk > 數據庫

  可靠性： zk > redis > 數據庫。

4.分佈式session

  4.1

 1)tomcat + redis

 2)spring session + redis

 4.2解決session一致性方案

  1)session粘滯：配置簡單，單點故障問題。

    基於nginx的ip_hash策略來作負載均衡。原理：根據ip作hash計算，同一個ip的請求始終會定位到同一臺tomcat。

  2)session複製：不會丟失session，內存消耗大。

   服務器session複製。原理：tomcat服務器建立session後，會經過組播方式把session發送到組播地址中的其餘服務器上。

  3)session共享(redis)：不會丟失session，適合大集羣，系列化和反系列化消耗CPU性能。

 5.分佈式雪崩

 1）熔斷

 2）隔離

 3）限流