思考：盡可能說出自己的理解，用大白話講述，而不是復制粘貼資料。
重點：分布式事務，分布式搜索，分布式緩存，分布式鎖，分布式消息隊列，分布式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.負載均衡策略：
參考資料：https://juejin.im/post/5bbb5bd96fb9a05cf371478a
Nginx
1.負載均衡。
2.反向代理？到底是什么？
反向代理方式，是指以代理服務器來接受internet上的連接請求，然后將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器；
思考 ：正向代理是通過代理服務器去發起請求，比如我們日常說的"fang牆"。。反向代理則是通過代理服務器去接受請求。
Nginx就支持反向代理。
3.CDN是什么？
CDN的全稱是Content Delivery Network，即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。CDN可以加速。
應用：玩某些游戲的時候，經常需要開加速器。就是基於CDN。
4.動靜分離
分布式服務
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慢慢的按照數據庫能處理的並發量，從消息隊列中慢慢拉取消息。在生產中，這個短暫的高峰期積壓是允許的。
常用的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.假設有千萬級/億級的海量數據，如何設計數據庫？
其他概念
1.Web Services ：可以將應用程序轉換為網絡應用程序
2.分布式系統怎么將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那么就是對計算任務進行切換，每個節點算一些，最終匯總就行了，這就是MapReduce的思想
知識圖譜：
參考資料：