web集羣和分佈式服務以及消息補償機制幾種方案

1、爲何要集羣？
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、什麼是集羣
集羣是是指將多臺服務器集中在一塊兒，每臺服務器都實現相同的業務，作相同的事情。可是每臺服務器並非缺一不可，存在的做用主要是緩解併發壓力和單點故障轉移問題。能夠利用一些廉價的符合工業標準的硬件構造高性能的系統。實現：高擴展、高性能、低成本、高可用！

 

圖片.png

2.1伸縮性（Scalability）
在一些大的系統中，預測最終用戶的數量和行爲是很是困難的，伸縮性是指系統適應不斷增加的用戶數的能力。提升這種併發會話能力的一種最直觀的方式就增長資源（CPU，內存，硬盤等），集羣是解決這個問題的另外一種方式，它容許一組服務器組在一塊兒，像單個服務器同樣分擔處理一個繁重的任務，咱們只須要將新的服務器加入集羣中便可，對於客戶來看，服務不管從連續性仍是性能上都幾乎沒有變化，好像系統在不知不覺中完成了升級

2.2高可用性（High availability）
單一服務器的解決方案並非一個健壯方式，由於容易出現單點失效。像銀行、帳單處理這樣一些關鍵的應用程序是不能容忍哪怕是幾分鐘的死機。它們須要這樣一些服務在任什麼時候間均可以訪問並在可預期的合理的時間週期內有響應。高可用性集羣的出現是爲了使集羣的總體服務儘量可用，以便考慮計算硬件和軟件的易錯性。若是高可用性集羣中的主節點發生了故障，那麼這段時間內將由次節點代替它。次節點一般是主節點的鏡像，因此當它代替主節點時，它能夠徹底接管其身份，而且所以使系統環境對於用戶是一致的。

2.3負載均衡（Load balancing）
負載均衡集羣爲企業需求提供了更實用的系統。如名稱所暗示的，該系統使負載能夠在計算機集羣中儘量平均地分攤處理。該負載多是須要均衡的應用程序處理負載或網絡流量負載。這樣的系統很是適合於運行同一組應用程序的大量用戶。每一個節點均可以處理一部分負載，而且能夠在節點之間動態分配負載，以實現平衡。

2.4高性能 (High Performance )
一般，第一種涉及爲集羣開發並行編程應用程序，以解決複雜的科學問題。這是並行計算的基礎，儘管它不使用專門的並行超級計算機，這種超級計算機內部由十至上萬個獨立處理器組成。但它卻使用商業系統，如經過高速鏈接來連接的一組單處理器或雙處理器 PC，而且在公共消息傳遞層上進行通訊以運行並行應用程序。所以，您會經常據說又有一種便宜的 Linux 超級計算機問世了。但它實際是一個計算機集羣，其處理能力與真的超級計算機相等
3、爲何要進行分佈式
傳統的項目中，咱們將各個模塊放在一個系統中，系統過於龐大，開發維護困難，各個功能模塊之間的耦合度增高，沒法針對單個模塊進行優化，也沒法進行水平擴展。

 

圖片.png

4、什麼事分佈式
分佈式是指將多臺服務器集中在一塊兒，每臺服務器都實現整體中的不一樣業務，作不一樣的事情。而且每臺服務器都缺一不可，若是某臺服務器故障，則網站部分功能缺失，或致使總體沒法運行。存在的主要做用是大幅度的提升效率，緩解服務器的訪問和存儲壓力。

 

 

注意：該圖中最大特色是：每一個Web服務器（Tomcat）程序都負責一個網站中不一樣的功能，缺一不可。若是某臺服務器故障，則對應的網站功能缺失，也能夠致使其依賴功能甚至所有功能都不可以使用。

5、分佈式和集羣的關係。
在開發中咱們能夠將分佈式和集羣分開嗎？
針對這個問題，咱們能夠根據分佈式的介紹看出，其主要的功能是用了將咱們的系統模塊化，將系統進行解耦的，方便咱們的維護和開發的，可是其並不能解決咱們的併發問題，也沒法保證咱們的系統在服務器宕機後的正常運轉。
而集羣呢？其剛好彌補了分佈式的缺陷，集羣，就是多個服務器處理相同的業務，這在一方面能夠解決或者說改善咱們系統的併發問題，一方面能夠解決咱們服務器若是出現必定數量的宕機後，系統仍然能夠正常運轉。
所以我說，分佈式和集羣式一堆好基友，誰也離不開誰。。。

6、事務處理

集羣部署的是同一個服務，處理的數據仍是同一個數據庫，須要開啓本地事務；

分佈式事務須要用到事務補償機制（度娘提供）

方式1、

一、微服務-中間件-消息組件

生產者

    發出帶流水號（惟一）訂單消息。調用消息組件。

消息組件

• 消息組件-消息表：id爲生產者的流水號。（具有冪等性）
• 生產者發佈請求，查詢消息表，判斷流水號是否存在，存在，不發送到mq；不存在：發送到mq，消息表插入記錄，消息狀態爲「已發送」。
• 收到消費者反饋，處理完成請求。將消息置爲「處理成功」。
• 補償機制-定時任務，不只僅要mq自身的重試機制，還要有任務補償機制，即掃描消息表，狀態=「已發送」且發送時間>當前時間-n(n不爲0)的數據進行重試，要有時間間隔。

消費者

    收到mq消息，調用消息組件。

 

方式2、

一、MQ發送方發送遠程事務消息到MQ Server;
二、MQ Server給予響應, 代表事務消息已成功到達MQ Server.
三、MQ發送方Commit本地事務.
四、若本地事務Commit成功, 則通知MQ Server容許對應事務消息被消費; 若本地事務失敗, 則通知MQ Server對應事務消息應被丟棄.
五、若MQ發送方超時未對MQ Server做出本地事務執行狀態的反饋, 那麼須要MQ Servfer向MQ發送方主動回查事務狀態, 以決定事務消息是否能被消費.
六、當得知本地事務執行成功時, MQ Server容許MQ訂閱方消費本條事務消息.

以前寫服務的時候沒有用2-pc，用的仍是異步消息的事務補償機制，但沒有上面的這麼複雜，首先 A->B, A→C結合一些A的本地DB操做被包裹進大的事務裏，若C調用失敗觸發回滾，在捕獲C調用失敗的異常時往kafka寫入消息通知給B回滾，A不會直接調用B的接口去手動回滾由於這個動做耗時且可能失敗，而送入kafka讓B的消費者線程來消費能夠保證屢次重試以及日誌準確記錄。

方式3、

基於事務消息的最終一致性
模型

 

由多個獨立的本地事務和事務消息實現最終一 致性，事務消息保證成功的狀況下投遞，失敗時不投遞，超時未知的狀況下check，具體的實現方式不固定，經常使用的策略是一個惟一業務標識和冪等操做，下圖是基於事務 MQ 的最終一致性經常使用模型:

優缺點
1)優勢
　　性能好，把全局事務拆分紅多個本地事務，對資源的鎖定只是一個本地事務的時間，經過在數據庫外部實現事務機制達到了最終一致性
　　對SOA/微服務的支持友好
2)缺點
　　對應用的侵入大，須要應用自身根據業務實現最終一致性邏輯，在應用系統中實現事務檢查與回滾的細節
　　存在中間不一致狀態

其實補償機制都是本身根據業務設計本身的，只要實現數據的一致性就好了，這幾個以爲講的不錯記一下