分佈式系統的簡單理解

 思考：儘量說出本身的理解，用大白話講述，而不是複製粘貼資料。

重點：分佈式事務，分佈式搜索，分佈式緩存，分佈式鎖，分佈式消息隊列，分佈式session，分庫分表

 

集羣、分佈式

1.集羣：同一個業務，部署在多個服務器上(不一樣的服務器運行一樣的代碼，幹同一件事)

2.分佈式：一個業務分拆多個子業務，部署在不一樣的服務器上(不一樣的服務器，運行不一樣的代碼，爲了同一個目的)

3.當今是個分佈式、集羣、雲計算等名詞滿天飛的時代。形成這種局面的一個重要因素就是，單一機器的處理能力已經不能知足咱們的需求，不得不採用由多臺機器組成的服務集羣。服務集羣對外提供服務的過程當中，能夠分解處理壓力，在必定程度上打破性能瓶頸，並提升服務的可用性（不會由於一臺機器宕機而形成服務不可用）。

4.架構師的技術升級要點：用兩個字來描述：集羣，用三個字：分佈式，再用多點的文字：把海量的流量和數據合理分攤到數量合適的機器上。

 想明白這點，後面就能知道該學哪些了，好比流量分攤時得負載均衡，存儲海量數據時得靠數據庫集羣，或分庫分表，爲了防止單點失效，得設計冗餘系統，系統間通信時得用消息中間件，不能讓每次請求都走後臺，因此能夠搭建緩存，單個緩存容易失效，因此能夠搭建分佈式緩存，爲了監控性能，因此得上一些監控措施，好比監控JVM，監控數據等的，爲了等看日誌，因此得上一些日誌組件。等等。

參考資料：https://blog.csdn.net/qq_24047659/article/details/86731850

5.Partition(分區)和Replication(副本)是解決分佈式系統問題的一記組合拳，不少具體的問題均可以用這個思路去解決。但這並非銀彈，每每是爲了解決一個問題，會引入更多的問題，好比爲了可用性與可靠性保證，引用了冗餘（複製集）。有了冗餘，各個副本間的一致性問題就變得很頭疼，一致性在系統的角度和用戶的角度又有不一樣的等級劃分。若是要保證強一致性，那麼會影響可用性與性能，在一些應用（好比電商、搜索）是難以接受的。若是是最終一致性，那麼就須要處理數據衝突的狀況。CAP、FLP這些理論告訴咱們，在分佈式系統中，沒有最佳的選擇，都是須要權衡，作出最合適的選擇。

分佈式一致性

1.CAP理論：一個分佈式系統不可能同時知足一致性（C：Consistency）、可用性（A：Availability）和分區容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時知足其中兩項。
 C：數據一致性(consistency) ， 全部節點擁有數據的最新版本。其中，一致性又分爲強一致性、弱一致性、最終一致性。
 A：可用性(availability) ，數據具有高可用性
 P：分區容錯性(partition-tolerance)，容忍網絡出現分區，分區之間網絡不可達。

2.分佈式一致性。數據的一致性模型能夠分紅如下 3 類：

• 強一致性：數據更新成功後，任意時刻全部副本中的數據都是一致的，通常採用同步的方式實現。
• 弱一致性：數據更新成功後，系統不承諾當即能夠讀到最新寫入的值，也不承諾具體多久以後能夠讀到。
• 最終一致性：弱一致性的一種形式，數據更新成功後，系統不承諾當即能夠返回最新寫入的值，可是保證最終會返回上一次更新操做的值。
   

分佈式事務

1. 分佈式事務：2PC。3PC。

2.BASE理論。

3.概念：分佈式事務是指會涉及到操做多個分佈式節點(服務器)上的多個數據庫的事務。若是想讓分佈式部署的多臺機器中的數據保持一致性，那麼就要保證在全部節點的數據寫操做，要不所有都執行，要麼所有的都不執行。
4.分佈式事務和分佈式一致性的關係：爲了知足分佈式一致性，多節點上的數據庫操做要保證分佈式事務。
5.分佈式事務的例子：好比，進行一次下單操做，在A節點的庫存模塊對應的庫存表會減小一個庫存，而在B節點的訂單模塊中的訂單表會增長一條訂單，這個就必須保證一致性。要知足分佈式事務，要麼所有都成功，要麼所有都不成功。

6.分佈式事務解決方案：補償機制TCC。XA。消息隊列MQ。

事務補償機制: 在事務鏈中的任何一個正向事務操做, 都必須存在一個徹底符合回滾規則的可逆事務.

7.冪等性: 簡單的說, 業務操做支持重試, 屢次發起操做，不會產生不利影響. 常見的實現方式: 爲消息額外增長惟一ID.

 

參考資料：

http://www.cnblogs.com/xingzc/p/5745587.html

https://cloud.tencent.com/developer/article/1117449

高併發高可用

1.海量數據的解決方案：

  使用緩存； 頁面靜態化技術；數據庫優化；分離數據庫中活躍的數據；批量讀取和延遲修改；讀寫分離；使用NoSQL和Hadoop等技術；分佈式部署數據庫；應用服務和數據服務分離；使用搜索引擎搜索數據庫中的數據；進行業務的拆分；

2.高併發狀況下的解決方案：

  應用程序和靜態資源文件進行分離；頁面緩存；集羣與分佈式；反向代理；CDN；

3.高併發場景下的限流策略： 信號量;計數器(限制請求數量);滑動窗口;漏桶算法;令牌桶算法;分佈式限流。

參考資料： https://cloud.tencent.com/developer/article/1181346

負載均衡

1.負載均衡：將流量或者請求均衡地分派到各個服務器。避免某個服務器壓力過大。

2.負載均衡分爲硬件負載均衡和軟件負載均衡。

硬件負載均衡：主要經過在服務器節點之間安裝專門用於負載均衡的設備，好比F5。

軟件負載均衡：在服務器上安裝一些具備均衡負載功能或模塊的軟件來完成請求分發工做。

3.負載均衡策略：

參考資料：http://www.javashuo.com/article/p-kpbtvqdc-dv.html

 

Nginx

1.負載均衡。

2.反向代理？究竟是什麼？

反向代理方式，是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個反向代理服務器；

思考 ：正向代理是經過代理服務器去發起請求，好比咱們平常說的"fang牆"。。反向代理則是經過代理服務器去接受請求。

Nginx就支持反向代理。

3.CDN是什麼？

CDN的全稱是Content Delivery Network，即內容分發網絡。其基本思路是儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。CDN能夠加速。

 應用：玩某些遊戲的時候，常常須要開加速器。就是基於CDN。

4.動靜分離

動靜分離是讓動態網站裏的動態網頁根據必定規則把不變的資源和常常變的資源區分開來，動靜資源作好了拆分之後，咱們就能夠根據靜態資源的特色將其作緩存操做，這就是網站靜態化處理的核心思路。

5.Nginx的缺陷，那麼就是不支持HTTPS。

分佈式服務

1.RPC：遠程過程調用，也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，因爲不在一個內存空間，不能直接調用，須要經過網絡來表達調用的語義和傳達調用的數據。用Socket比較麻煩。

對於大多數rpc框架通用，實現的幾個技術點：

•  服務提供者發佈服務：服務接口定義，數據結構，服務提供者信息等；
•  客戶端遠程調用：一般是使用jdk的代碼代理攔截；
• 底層通訊：如今應該更可能是使用netty吧，固然也有走支持http的；
•  序列化：關注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；

經常使用的rpc框架：  dubbo、Thrift、Hadoop的Avro-RPC、Hessian、gRPC 

2.Soa ： 面向服務的架構。SOA 是一種軟件架構模式，用於構建大型的企業應用程序，這些應用程序一般要求集成多種服務，而每種服務使用不一樣的平臺和編程語言來構建，並經過通用的通訊機制進行交互。

分佈式鎖

1.zookeeper，能夠進行分佈式服務協調，作爲dubbo的服務註冊中心。zookeeper還能夠作分佈式鎖，也能夠幫kafka存儲元數據( topic，partition信息等）更新。

2.分佈式系統的不一樣節點上須要分佈式鎖，那麼咱們須要瞭解分佈式鎖到底應該有哪些特色:

• 互斥性:和咱們本地鎖同樣互斥性是最基本，可是分佈式鎖須要保證在不一樣節點的不一樣線程的互斥。

• 可重入性:同一個節點上的同一個線程若是獲取了鎖以後那麼也能夠再次獲取這個鎖。

• 鎖超時:和本地鎖同樣支持鎖超時，防止死鎖。

• 高效，高可用:加鎖和解鎖須要高效，同時也須要保證高可用防止分佈式鎖失效，能夠增長降級。

• 支持阻塞和非阻塞:和ReentrantLock同樣支持lock和trylock以及tryLock(long timeOut)。

• 支持公平鎖和非公平鎖(可選):公平鎖的意思是按照請求加鎖的順序得到鎖，非公平鎖就相反是無序的。這個通常來講實現的比較少。

常見的分佈式鎖有：zookeeper

 

分佈式消息隊列

1.消息隊列，屬於生產者-消費者模式。

消息隊列作爲中間件模式的的優勢：解耦、異步、削峯。

解耦：將消息寫入消息隊列，須要消息的系統本身從消息隊列中訂閱，從而系統A不須要作任何修改。

異步：將消息寫入消息隊列，非必要的業務邏輯以異步的方式運行，加快響應速度
削峯：系統A慢慢的按照數據庫能處理的併發量，從消息隊列中慢慢拉取消息。在生產中，這個短暫的高峯期積壓是容許的。
經常使用的MQ有ActiveMQ,RabbitMQ,RocketMQ,Kafka。

2.kafka，能夠作爲消息隊列。優勢是分佈式隊列，吞吐量高。

 

搜索引擎

1.elasticsearch 是一個實時分佈式搜索和分析引擎，能夠應用在任何實時檢索的場景中。

分佈式session

1.首先是爲何會有這樣的概念出現？

先考慮這樣一個問題，如今個人應用須要部署在3臺機器上。是否是出現這樣一種狀況，我第一次登錄，請求去了機器1，而後再機器1上建立了一個session；可是我第二次訪問時，請求被路由到機器2了，可是機器2上並無個人session信息，因此得從新登陸。固然這種能夠經過nginx的IP HASH負載策略來解決。對於同一個IP請求都會去同一個機器。

可是業務發展的愈來愈大，拆分的愈來愈多，機器數不斷增長；很顯然那種方案就不行了。那麼這個時候就須要考慮是否是應該將session信息放在一個獨立的機器上，因此分佈式session要解決的問題其實就是分佈式環境下的session共享的問題。

 

分佈式數據庫

1.假設有千萬級/億級的海量數據，如何設計數據庫？

分庫分表，主從架構，讀寫分離

2.分庫分表，什麼時候分？怎麼分？

將庫拆分，將表拆分，原來是放在同一個系統裏面的，拆分後放到不一樣的系統或者不一樣的模塊裏面。

分庫分表包括水平拆分，垂直拆分。

水平分庫/表 ：每個庫/表的結構和字段都同樣，可是存儲的數據不同。

垂直分庫/表 ：每個庫/表的結構和字段都不同，存儲的數據不同。

http://www.javashuo.com/article/p-rdqirvgq-bh.html

3.數據庫中間件，好比sharding-jdbc、mycat。

mycat有些大坑，不建議使用。

其餘概念

1.Web Services  ：能夠將應用程序轉換爲網絡應用程序

2.分佈式系統怎麼將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那麼就是對計算任務進行切換，每一個節點算一些，最終彙總就好了，這就是MapReduce的思想

 知識圖譜：

參考資料：

業務中使用分佈式的場景

Java分佈式應用如何入門以及有哪些資料？