分布式、中間件和消息隊列、集群

From今日頭條：

https://www.wukong.com/answer/6534675344568353032/?iid=28070358035&app=news_article&share_ansid=6534675344568353032&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share

https://www.wukong.com/question/6506283491167043844/?app=news_article&share_ansid=6533256199767326979&iid=28070358035&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=topic_android&utm_campaign=client_share

一、分布式

相對以前單一系統，所有功能、服務都部署在一台服務器上，一掛全掛！

分布式采用了把系統提供的服務分布在不同的服務器上的策略，這樣的架構就叫做分布式架構！

【一個業務被拆成多個子業務，部署在多台服務器上，這個就叫做分布式】

　　　　　　　　　　　　    【分布式架構圖】

實例：

我有一個系統A，提供一個很簡單的接口，根據員工編號查詢員工姓名和他的考勤記錄。

我拆開兩個系統：人員管理系統B和考勤系統C，分別部署在兩台服務器上。

這個需求，需要調用一下系統B，再調用一下系統C，最后得到需要的結果。

這個就是分布式。

分布式架構優勢：

1，單個服務宕機不影響別的服務正常運行！

2，單個節點所有的負載分布均衡到了多台服務器上！

3，各服務之間相互透明，實現解耦！

注意：

分布之后問題來了，以前的單一系統，所有服務都在同一個機器，在同一個內存里面，直接調用即可；

但現在分布在不同的jvm中，怎么調用呢？或者說數據怎么傳輸？ --消息中間件應運而生！

二 、中間件

中間件：將具體業務和底層邏輯解耦的軟件

目前應用較多消息隊列有ActiveMQ，RabbitMQ，Kafka，RocketMQ，ons，它們又可以被稱作是消息中間件。

消息中間件解決的就是分布式系統之間消息傳遞的問題。

1，生產者和消費者之間通過某種方式（點對點或者訂閱）實現"綁定"！

2，生產者生產數據，並發送到消息中間件，消息中間件進行落庫處理！

3，訂閱了消息的消費者通過監聽器監聽消息中間件，如果有屬於自己的消息，進行消費！

注：整個過程中間會有數據一致性問題，怎么解決呢？

【1】保證生產消息到消息中間件的時候進行返回值確認保證這一步的數據一致

【2】在消息到消費者的時候保證返回正確結果即可，如果中間出現異常可進行重試，或者發郵件等

         到此，分布式系統的數據傳遞通過消息中間件解決了！

但分布式還有如session、日志處理、單點登錄等各服務器需要相同數據的問題，可通過接到同一個redis緩存進行處理！

分布式服務的配置文件可以通過統一的文件配置中心統一處理！

添加服務注冊和發現，還有服務宕機的監控處理！

例子：

我要開一家炸雞店（業務端），需要雞肉，有很多養雞場（底層），我需要一個一個比較價錢，然后找一家性價比高的養雞場合作（適配不同底層邏輯）。可能一段時間后，我需要重新選一家養雞場合作，進貨方式、交易方式等要重新制定（重新適配）。

這一套事情太復雜了，於是我找到了一個專門整合養雞場的第三方代理（中間件），跟他談好價格和質量后（統一接口），以后我就只需要給代理錢，然后拿肉就行。具體這個第三方代理怎么操作，我不用管。

三、消息隊列

消息隊列可以看做內存中的隊列，有人往里放消息，有人從里取消息。

1、Producer：消息生產者

2、Broker：消息處理中心，負責消息存儲、確認、重試等

3、Consumer：消息消費者

消息隊列的特點是：異步、解耦、可靠性（消息隊列一般會把接收到的消息持久化到本地硬盤上）

例子：

我是做網上商城的，有一個短信系統，當客戶下了一個訂單之后，通知客戶你下單成功。

當訂單量比較小的時候，只需要調用發送短信的接口就可以了。

但是如果訂單量大了之后呢，並且短信發送晚個一兩分鍾也沒有什么問題，那么就可以使用消息中間件：把待發送的短信發送到消息隊列里面，短信系統從消息隊列中取出短信進行發送就可以了。

而且還有一個好處：如果短信系統掛掉了，短信消息保存在消息中間件里面不會丟失，等短信系統恢復了之后，繼續短信發送即可。

四、分布式和集群

集群：同一個業務，部署在多台服務器上，這個就叫做集群。

單機模式的系統：單機模式是說一個服務器就部署一個應用，一個應用上包含很多功能，當用戶規模小，請求數不多，那么這個單機模式可以支撐業務，但是如果訪問量特別大，你會發現一個服務器無法支撐大的訪問量，於是為了解決這個高並發的問題，就產生了集群的概念，就是用好多服務器，每個服務器上部署相同的應用。這個就能支撐高並發請求了。

集群里面，每一台服務器實現的功能沒有差別。

比如我有一個系統A，提供一個很簡單的接口，根據員工編號查詢員工姓名和他的考勤記錄。

當有一個系統調用這個接口的時候，我部署一台服務器就夠用了。

當有一百個系統調用這個接口的時候，我就部署十台服務器，前面掛一個負載均衡。

這就是集群部署，當一台服務器掛了以后，不影響功能使用。

                                                      【集群部署】

 

分布式：一個業務被拆成多個子業務，部署在多台服務器上

分布說明應用是分散在不同的服務器上的，當集群無法滿足業務需求時，業務耦合度高，需要降低各功能模塊的耦合度，因此就對一個大系統進行拆分成小系統，單獨部署，易於維護，這就產生了分布式。

 

分布式里面，每一台服務器實現的功能是有差別的，分布式每台服務器功能加起來，才是完整的業務。

還是這個業務場景，我有一個系統A，提供一個很簡單的接口，根據員工編號查詢員工姓名和他的考勤記錄。

我拆開兩個系統：人員管理系統B和考勤系統C，分別部署在兩台服務器上。這個就是分布式。

好處是什么呢？

如果有系統D也需要使用人員信息，傳統的方式系統A和D都要有人員信息管理功能，意味着兩個系統各自維護人員信息，那新入職一個員工，可能要在系統A和D里面都維護；如果是有EFGHI系統都需要人員信息呢？

而分布式解決了這個問題，人員信息單獨拎出來是一個系統，維護人員信息，同時對外提供查詢服務。

分布式主要是應用在大型網站系統，比如天貓，淘寶等，集群一般配合分布式使用。

分布式+集群

很多時候要結合起來一起用。

還是這個業務場景，我有一個系統A，提供一個很簡單的接口，根據員工編號查詢員工姓名和他的考勤記錄。

我拆開兩個系統：人員管理系統B和考勤系統C。

那么系統B部署在十台服務器上，系統C部署在十台服務器上；前面分別掛負載均衡；這樣保證了每個子業務功能的高可用。