一、為什么要集群？
1.JavaEE項目，如果部署在一台Tomcat上，所有的請求，都由這一台服務器處理，存在很大風險：
A：並發處理能力有限（一般單台服務器處理的並發量為250左右，超過250，可能會出現數據丟失，鏈接不穩定的情況）。因為單服務器的性能有限制。所以單台Tomcat的最大連接數有限制，
B：容錯率低，一旦服務器故障，整個服務就無法訪問了。
eBay於 1999年6月停機22小時的事故，中斷了約230萬的拍賣，使eBay的股票下降了9.2個百分點。
C：單台服務器計算能力低，無法完成復雜的海量數據計算。
提高CPU主頻和總線帶寬是最初提供計算機性能的主要手段。但是這一手段對系統性能的提供是有限的。接着人們通過增加CPU個數和內存容量來提高性能，於是出現了向量機，對稱多處理機(SMP)等。但是當CPU的個數超過某一閾值，這些多處理機系統的可擴展性就變的極差。主要瓶頸在於CPU訪問內存的帶寬並不能隨着CPU個數的增加而有效增長。與SMP相反，集群系統的性能隨着CPU個數的增加幾乎是線性變化的。
二、什么是集群
集群是是指將多台服務器集中在一起，每台服務器都實現相同的業務，做相同的事情。但是每台服務器並不是缺一不可，存在的作用主要是緩解並發壓力和單點故障轉移問題。可以利用一些廉價的符合工業標准的硬件構造高性能的系統。實現：高擴展、高性能、低成本、高可用！
2.1伸縮性（Scalability）
在一些大的系統中，預測最終用戶的數量和行為是非常困難的，伸縮性是指系統適應不斷增長的用戶數的能力。提高這種並發會話能力的一種最直觀的方式就增加資源（CPU，內存，硬盤等），集群是解決這個問題的另一種方式，它允許一組服務器組在一起，像單個服務器一樣分擔處理一個繁重的任務，我們只需要將新的服務器加入集群中即可，對於客戶來看，服務無論從連續性還是性能上都幾乎沒有變化，好像系統在不知不覺中完成了升級
2.2高可用性（High availability）
單一服務器的解決方案並不是一個健壯方式，因為容易出現單點失效。像銀行、賬單處理這樣一些關鍵的應用程序是不能容忍哪怕是幾分鍾的死機。它們需要這樣一些服務在任何時間都可以訪問並在可預期的合理的時間周期內有響應。高可用性集群的出現是為了使集群的整體服務盡可能可用，以便考慮計算硬件和軟件的易錯性。如果高可用性集群中的主節點發生了故障，那么這段時間內將由次節點代替它。次節點通常是主節點的鏡像，所以當它代替主節點時，它可以完全接管其身份，並且因此使系統環境對於用戶是一致的。
2.3負載均衡（Load balancing）
負載均衡集群為企業需求提供了更實用的系統。如名稱所暗示的，該系統使負載可以在計算機集群中盡可能平均地分攤處理。該負載可能是需要均衡的應用程序處理負載或網絡流量負載。這樣的系統非常適合於運行同一組應用程序的大量用戶。每個節點都可以處理一部分負載，並且可以在節點之間動態分配負載，以實現平衡。
2.4高性能 (High Performance )
通常，第一種涉及為集群開發並行編程應用程序，以解決復雜的科學問題。這是並行計算的基礎，盡管它不使用專門的並行超級計算機，這種超級計算機內部由十至上萬個獨立處理器組成。但它卻使用商業系統，如通過高速連接來鏈接的一組單處理器或雙處理器 PC，並且在公共消息傳遞層上進行通信以運行並行應用程序。因此，您會常常聽說又有一種便宜的 Linux 超級計算機問世了。但它實際是一個計算機集群，其處理能力與真的超級計算機相等
三、為什么要進行分布式
傳統的項目中，我們將各個模塊放在一個系統中，系統過於龐大，開發維護困難，各個功能模塊之間的耦合度增高，無法針對單個模塊進行優化，也無法進行水平擴展。
四、什么事分布式
分布式是指將多台服務器集中在一起，每台服務器都實現總體中的不同業務，做不同的事情。並且每台服務器都缺一不可，如果某台服務器故障，則網站部分功能缺失，或導致整體無法運行。存在的主要作用是大幅度的提高效率，緩解服務器的訪問和存儲壓力。
注意：該圖中最大特點是：每個Web服務器（Tomcat）程序都負責一個網站中不同的功能，缺一不可。如果某台服務器故障，則對應的網站功能缺失，也可以導致其依賴功能甚至全部功能都不能夠使用。
五、分布式和集群的關系。
在開發中我們可以將分布式和集群分開嗎？
針對這個問題，我們可以根據分布式的介紹看出，其主要的功能是用了將我們的系統模塊化，將系統進行解耦的，方便我們的維護和開發的，但是其並不能解決我們的並發問題，也無法保證我們的系統在服務器宕機后的正常運轉。
而集群呢？其恰好彌補了分布式的缺陷，集群，就是多個服務器處理相同的業務，這在一方面可以解決或者說改善我們系統的並發問題，一方面可以解決我們服務器如果出現一定數量的宕機后，系統仍然可以正常運轉。
因此我說，分布式和集群式一堆好基友，誰也離不開誰。。。
六、事務處理
集群部署的是同一個服務，處理的數據還是同一個數據庫，需要開啟本地事務；
分布式事務需要用到事務補償機制（度娘提供）
方式一、
1、微服務-中間件-消息組件
生產者
發出帶流水號（唯一）訂單消息。調用消息組件。
消息組件
- 消息組件-消息表：id為生產者的流水號。（具備冪等性）
- 生產者發布請求，查詢消息表，判斷流水號是否存在，存在，不發送到mq；不存在：發送到mq，消息表插入記錄，消息狀態為“已發送”。
- 收到消費者反饋，處理完成請求。將消息置為“處理成功”。
- 補償機制-定時任務，不僅僅要mq自身的重試機制，還要有任務補償機制，即掃描消息表，狀態=“已發送”且發送時間>當前時間-n(n不為0)的數據進行重試，要有時間間隔。
消費者
收到mq消息，調用消息組件。
方式二、
1、MQ發送方發送遠程事務消息到MQ Server;
2、MQ Server給予響應, 表明事務消息已成功到達MQ Server.
3、MQ發送方Commit本地事務.
4、若本地事務Commit成功, 則通知MQ Server允許對應事務消息被消費; 若本地事務失敗, 則通知MQ Server對應事務消息應被丟棄.
5、若MQ發送方超時未對MQ Server作出本地事務執行狀態的反饋, 那么需要MQ Servfer向MQ發送方主動回查事務狀態, 以決定事務消息是否能被消費.
6、當得知本地事務執行成功時, MQ Server允許MQ訂閱方消費本條事務消息.
之前寫服務的時候沒有用2-pc，用的還是異步消息的事務補償機制，但沒有上面的這么復雜，首先 A->B, A→C結合一些A的本地DB操作被包裹進大的事務里，若C調用失敗觸發回滾，在捕獲C調用失敗的異常時往kafka寫入消息通知給B回滾，A不會直接調用B的接口去手動回滾因為這個動作耗時且可能失敗，而送入kafka讓B的消費者線程來消費可以保證多次重試以及日志准確記錄。
方式三、
基於事務消息的最終一致性
模型
由多個獨立的本地事務和事務消息實現最終一 致性，事務消息保證成功的情況下投遞，失敗時不投遞，超時未知的情況下check，具體的實現方式不固定，常用的策略是一個唯一業務標識和冪等操作，下圖是基於事務 MQ 的最終一致性常用模型:
優缺點
1)優點
性能好，把全局事務拆分成多個本地事務，對資源的鎖定只是一個本地事務的時間，通過在數據庫外部實現事務機制達到了最終一致性
對SOA/微服務的支持友好
2)缺點
對應用的侵入大，需要應用自身根據業務實現最終一致性邏輯，在應用系統中實現事務檢查與回滾的細節
存在中間不一致狀態
其實補償機制都是自己根據業務設計自己的，只要實現數據的一致性就行了，這幾個覺得講的不錯記一下