分佈式系統掌握要點

時間 2019-11-10

標籤分佈式系統掌握要點欄目系統架構简体版

原文原文鏈接

1. 從集中式到分佈式

2. 分佈式Session

　　服務通常分爲有狀態和無狀態，而分佈式sessoion就是針對有狀態的服務。java

　　分佈式Session的幾種實現方式

基於數據庫的Session共享
基於resin/tomcat web容器自己的session複製機制
基於oscache/Redis/memcached 進行 session 共享。
基於cookie 進行session共享

2.1 Session複製

　　Session Replication 方式管理 (即session複製)
　　簡介：將一臺機器上的Session數據廣播複製到集羣中其他機器上
　　使用場景：機器較少，網絡流量較小
　　優勢：實現簡單、配置較少、當網絡中有機器Down掉時不影響用戶訪問
　　缺點：廣播式複製到其他機器有必定廷時，帶來必定網絡開銷node

2.2 Session綁定

　　Session Sticky 方式管理
　　簡介：即粘性Session、當用戶訪問集羣中某臺機器後，強制指定後續全部請求均落到此機器上
　　使用場景：機器數適中、對穩定性要求不是很是苛刻
　　優勢：實現簡單、配置方便、沒有額外網絡開銷
　　缺點：網絡中有機器Down掉時、用戶Session會丟失、容易形成單點故障git

2.3 Session服務器（靠譜）

　緩存集中式管理
　　簡介：將Session存入分佈式緩存集羣中的某臺機器上，當用戶訪問不一樣節點時先從緩存中拿Session信息
　　使用場景：集羣中機器數多、網絡環境複雜
　　優勢：可靠性好
　　缺點：實現複雜、穩定性依賴於緩存的穩定性、Session信息放入緩存時要有合理的策略寫入github

目前生產中使用到的

基於tomcat配置實現的MemCache緩存管理session實現(麻煩)
基於OsCache和shiro組播的方式實現(網絡影響)
基於spring-session+redis實現的(最適合)

3. 分佈式緩存

3.1 Redis

3.2 一致性hash

4. 數據庫

4.1 讀寫分離

　　MySql主從配置，讀寫分離並引入中間件，開源的MyCat，阿里的DRDS都是不錯的選擇。web

　　若是是對高可用要求比較高，可是又沒有相應的技術保障，建議使用阿里雲的RDS或者Redis相關數據庫，省事省力又省錢。redis

4.1.1 主從熱備

4.2 分庫

4.3 分表

5. 一致性

5.1 分佈式事務

5.1.1 CAP

　　Consistency(一致性), 數據一致更新，全部數據變更都是同步的
　　Availability(可用性), 好的響應性能
　　Partition tolerance(分區容錯性) 可靠性算法

　　定理：任何分佈式系統只可同時知足二點，無法三者兼顧。
　　忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。spring

關係數據庫的ACID模型擁有高一致性 + 可用性很難進行分區：
Atomicity原子性：一個事務中全部操做都必須所有完成，要麼所有不完成。
　　Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。
　　Isolation隔離層. 事務將假定只有它本身在操做數據庫，彼此不知曉。
　　Durability. 一旦事務完成，就不能返回。
　　跨數據庫事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務能夠支持2PC。由於2PC是反模式，儘可能不要使用2PC，使用BASE來回避。數據庫

5.1.2 BASE

　　BASE模型反ACID模型，徹底不一樣ACID模型，犧牲高一致性，得到可用性或可靠性：編程

　　Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分數據庫)
　　Soft state軟狀態狀態能夠有一段時間不一樣步，異步。
　　Eventually consistent最終一致，最終數據是一致的就能夠了，而不是時時高一致。

　　BASE思想的主要實現有
　　1.按功能劃分數據庫
　　2.sharding碎片

　　BASE思想主要強調基本的可用性，若是你須要High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE思想的方案在性能上仍是有潛力可挖的。

5.1.3 2PC/3PC

2PC

Two Phase Commitment Protocol

兩階段提交協議

實現分佈式事務的關鍵就是兩階段提交協議。在此協議中，一個或多個資源管理器的活動均由一個稱爲事務協調器的單獨軟件組件來控制。此協議中的五個步驟以下：

　　• 應用程序調用事務協調器中的提交方法。

　　• 事務協調器將聯絡事務中涉及的每一個資源管理器，並通知它們準備提交事務（這是第一階段的開始）。

　　• 爲了以確定的方式響應準備階段，資源管理器必須將本身置於如下狀態：確保能在被要求提交事務時提交事務，或在被要求回滾事務時回滾事務。大多數資源管理器會將包含其計劃更改的日記文件（或等效文件）寫入持久存儲區中。若是資源管理器沒法準備事務，它會以一個否認響應來回應事務協調器。

　　• 事務協調器收集來自資源管理器的全部響應。

　　• 在第二階段，事務協調器將事務的結果通知給每一個資源管理器。若是任一資源管理器作出否認響應，則事務協調器會將一個回滾命令發送給事務中涉及的全部資源管理器。若是資源管理器都作出確定響應，則事務協調器會指示全部的資源管理器提交事務。一旦通知資源管理器提交，此後的事務就不能失敗了。經過以確定的方式響應第一階段，每一個資源管理器均已確保，若是之後通知它提交事務，則事務不會失敗。

3PC

Three Phase Commitment Protocol

In computer networking and databases, the three-phase commit protocol (3PC) is a distributed algorithm which lets all nodes in a distributed system agree to commit a transaction. Unlike the two-phase commit protocol (2PC) however, 3PC is non-blocking. Specifically, 3PC places an upper bound on the amount of time required before a transaction either commits oraborts. This property ensures that if a given transaction is attempting to commit via 3PC and holds some resource locks, it will release the locks after the timeout.

3PC was originally described by Dale Skeen and Michael Stonebraker in their paper, 「A Formal Model of Crash Recovery in a Distributed System」[1]. In that work, they modeled 2PC as a system of non-deterministic finite state automata and proved that it is not resilient to a random single site failure. The basic observation is that in 2PC, while one site is in the 「prepared to commit」 state, the other may be in either the 「commit」 or the 「abort」 state. From this analysis, they developed 3PC to avoid such states and it is thus resilient to such failures.

5.1.4 Paxos

　　Paxos 算法解決的問題是一個分佈式系統如何就某個值（決議）達成一致。一個典型的場景是，在一個分佈式數據庫系統中，若是各節點的初始狀態一致，每一個節點都執行相同的操做序列，那麼他們最後能獲得一個一致的狀態。爲保證每一個節點執行相同的命令序列，須要在每一條指令上執行一個「一致性算法」以保證每一個節點看到的指令一致。一個通用的一致性算法能夠應用在許多場景中，是分佈式計算中的重要問題。所以從20世紀80年代起對於一致性算法的研究就沒有中止過。節點通訊存在兩種模型：共享內存（Shared memory）和消息傳遞（Messages passing）。Paxos 算法就是一種基於消息傳遞模型的一致性算法。

5.2 分佈式鎖

5.2.1 Redisson

redisson是redis官網推薦的java語言實現分佈式鎖的項目。固然，redisson遠不止分佈式鎖，還包括其餘一些分佈式結構。詳情請移步：https://github.com/mrniko/redisson/wiki

　　redisson支持4種連接redis的方式：

　　Cluster(集羣)

　　Sentinel servers(哨兵)

　　Master/Slave servers(主從)

　　Single server(單機)

6. 負載均衡

DNS負載均衡，通常域名註冊商的dns服務器不支持，但博主用的阿里雲解析已經支持
四層負載均衡(F五、LVS)，工做在TCP協議下
七層負載均衡(Nginx、haproxy)，工做在Http協議下

6.1 硬件 F5

F5 負載均衡器

數據流量過大的網絡中，單一設備沒法承擔，因而就再回了一臺設備用來分擔網絡的流量，F5負載均衡器就是實現合理的分配網絡中的業務流量，使之不至於出現一臺設備過忙，一臺不能發揮做用。使倆臺設備合理的分擔網絡流量的負擔。F5是負載均衡產品的一個品牌，其地位相似於諾基亞在手機品牌中的位置。除了F5之外，Radware、Array、A10、Cisco、深信服等都是負載均衡的牌子，但因爲F5在這類產品中影響最大，因此常常說F5負載均衡。

6.2 軟件 LVS

　　在分析服務器集羣實現虛擬網絡服務的相關技術上，LVS集羣中實現的三種IP負載均衡技術VS/NAT、VS/TUN、VS/DR的工做原理.

6.2 負載均衡策略

負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：1、負載均衡算法，2、對網絡系統情況的檢測方式和能力。

一、rr 輪詢調度算法。顧名思義，輪詢分發請求。

優勢：實現簡單

缺點：不考慮每臺服務器的處理能力

二、wrr 加權調度算法。咱們給每一個服務器設置權值weight，負載均衡調度器根據權值調度服務器，服務器被調用的次數跟權值成正比。

優勢：考慮了服務器處理能力的不一樣

三、sh 原地址散列：提取用戶IP，根據散列函數得出一個key，再根據靜態映射表，查處對應的value，即目標服務器IP。過目標機器超負荷，則返回空。

四、dh 目標地址散列：同上，只是如今提取的是目標地址的IP來作哈希。

優勢：以上兩種算法的都能實現同一個用戶訪問同一個服務器。

五、lc 最少鏈接。優先把請求轉發給鏈接數少的服務器。

優勢：使得集羣中各個服務器的負載更加均勻。

六、wlc 加權最少鏈接。在lc的基礎上，爲每臺服務器加上權值。算法爲：（活動鏈接數*256+非活動鏈接數）÷權重，計算出來的值小的服務器優先被選擇。

優勢：能夠根據服務器的能力分配請求。

七、sed 最短時間望延遲。其實sed跟wlc相似，區別是不考慮非活動鏈接數。算法爲：（活動鏈接數+1)*256÷權重，一樣計算出來的值小的服務器優先被選擇。

八、nq 永不排隊。改進的sed算法。咱們想一下什麼狀況下才能「永不排隊」，那就是服務器的鏈接數爲0的時候，那麼假若有服務器鏈接數爲0，均衡器直接把請求轉發給它，無需通過sed的計算。

九、LBLC 基於局部性的最少鏈接。均衡器根據請求的目的IP地址，找出該IP地址最近被使用的服務器，把請求轉發之，若該服務器超載，最採用最少鏈接數算法。

十、LBLCR 帶複製的基於局部性的最少鏈接。均衡器根據請求的目的IP地址，找出該IP地址最近使用的「服務器組」，注意，並非具體某個服務器，而後採用最少鏈接數從該組中挑出具體的某臺服務器出來，把請求轉發之。若該服務器超載，那麼根據最少鏈接數算法，在集羣的非本服務器組的服務器中，找出一臺服務器出來，加入本服務器組，而後把請求轉發之。

7. 消息隊列

　　「消息隊列」是在消息的傳輸過程當中保存消息的容器。

　　MQ全稱爲Message Queue, 消息隊列（MQ）是一種應用程序對應用程序的通訊方法。應用程序經過讀寫出入隊列的消息（針對應用程序的數據）來通訊，而無需專用鏈接來連接它們。消息傳遞指的是程序之間經過在消息中發送數據進行通訊，而不是經過直接調用彼此來通訊，直接調用一般是用於諸如遠程過程調用的技術。排隊指的是應用程序經過隊列來通訊。隊列的使用除去了接收和發送應用程序同時執行的要求。其中較爲成熟的MQ產品有IBM WEBSPHERE MQ等等。

　　消息隊列的主要特色是異步處理，主要目的是減小請求響應時間和解耦。因此主要的使用場景就是將比較耗時並且不須要即時（同步）返回結果的操做做爲消息放入消息隊列。同時因爲使用了消息隊列，只要保證消息格式不變，消息的發送方和接收方並不須要彼此聯繫，也不須要受對方的影響，即解耦和。

7.1 RabbitMQ

　　RabbitMQ是一個在AMQP基礎上完成的，可複用的企業消息系統。他遵循Mozilla Public License開源協議。

7.2 ZeroMQ

　　ZMQ (如下 ZeroMQ 簡稱 ZMQ)是一個簡單好用的傳輸層，像框架同樣的一個 socket library，他使得 Socket 編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ 的明確目標是「成爲標準網絡協議棧的一部分，以後進入 Linux 內核」。如今還未看到它們的成功。可是，它無疑是極具前景的、而且是人們更加須要的「傳統」BSD 套接字之上的一層封裝。ZMQ 讓編寫高性能網絡應用程序極爲簡單和有趣。

7.3 ActiveMQ

　　ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現，儘管JMS規範出臺已是好久的事情了，可是JMS在當今的J2EE應用中間仍然扮演着特殊的地位。

7.4 Kafka

　　Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它能夠處理消費者規模的網站中的全部動做流數據。這種動做（網頁瀏覽，搜索和其餘用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素。這些數據一般是因爲吞吐量的要求而經過處理日誌和日誌聚合來解決。對於像Hadoop的同樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是經過Hadoop的並行加載機制來統一線上和離線的消息處理，也是爲了經過集羣來提供實時的消費。

8. 服務化

8.1 服務註冊於發現 Zookeeper

　　ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是 Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。

　　ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

　　ZooKeeper包含一個簡單的原語集，提供Java和C的接口。

　　ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口，代碼在zookeeper-3.4.3\src\recipes。其中分佈鎖和隊列有Java和C兩個版本，選舉只有Java版本。

8.2 架構

8.2.1 微服務

　　微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其餘技術是否能很好的實施微服務，而紅帽說API應該是重點。

　　微服務能夠在「本身的程序」中運行，並經過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務能夠在本身的程序中運行。經過這一點咱們就能夠將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務均可以被內部獨立進程所限制。若是其中任何一個服務須要增長某種功能，那麼就必須縮小進程範圍。在微服務架構中，只須要在特定的某種服務中增長所需功能，而不影響總體進程。

8.2.1.1 Spring Boot

　　Spring Boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員再也不須要定義樣板化的配置。用個人話來理解，就是spring boot其實不是什麼新的框架，它默認配置了不少框架的使用方式，就像maven整合了全部的jar包，spring boot整合了全部的框架（不知道這樣比喻是否合適）。

　　Spring Boot能夠輕鬆建立能夠「運行」的獨立的，生產級的基於Spring的應用程序。咱們對Spring平臺和第三方圖書館有一個見解，因此你能夠從最開始的時候開始。大多數Spring Boot應用程序須要不多的Spring配置。

　　特徵：

建立獨立的Spring應用程序
直接嵌入Tomcat，Jetty或Undertow（不須要部署WAR文件）
提供有意思的「啓動」POM來簡化您的Maven配置
儘量自動配置彈簧
提供生產就緒功能，如指標，運行情況檢查和外部化配置
絕對沒有代碼生成，也不須要XML配置

8.2.1.2 Dubbo

　　是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分包含:

遠程通信: 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。
集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持
自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

8.2.2 RPC

　　RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，爲通訊程序之間攜帶信息數據。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。RPC採用客戶機、服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，而後等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息的到達爲止。當一個調用信息到達，服務器得到進程參數，計算結果，發送答覆信息，而後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，得到進程結果，而後調用執行繼續進行。有多種RPC模式和執行。最初由Sun公司提出。IETF ONC憲章從新修訂了Sun版本，使得ONC RPC協議成爲IETF標準協議。如今使用最廣泛的模式和執行是開放式軟件基礎的分佈式計算環境（DCE）。

8.2.3 SOA

　　面向服務的架構(Service-Oriented Architecture)
　　是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）經過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。