其他消費問題總結
1、非同步處理
比如使用者在電商**下單，下單完成後會給使用者推送簡訊或郵件，發簡訊和郵件的過程就可以非同步完成。因為下單付款是核心業務，發郵件和簡訊並不屬於核心功能，並且可能耗時較長，所以針對這種業務場景可以選擇先放到訊息佇列中，有其他服務來非同步處理。
2、應用解耦：
假設公司有幾個不同的系統，各系統在某些業務有聯動關係，比如 a 系統完成了某些操作，需要觸發 b 系統及 c 系統。如果 a 系統完成操作，主動呼叫 b 系統的介面或 c 系統的介面，可以完成功能，但是各個系統之間就產生了耦合。用訊息中介軟體就可以完成解耦，當 a 系統完成操作將資料放進訊息佇列，b 和 c 系統去訂閱訊息就可以了。這樣各系統只要約定好訊息的格式就好了。
3、流量削峰
比如秒殺活動，一下子進來好多請求，有的服務可能承受不住瞬時高併發而崩潰，所以針對這種瞬時高併發的場景，在中間加一層訊息佇列，把請求先入佇列，然後再把佇列中的請求平滑的推送給服務，或者讓服務去佇列拉取。
4、日誌處理
kafka 最開始就是專門為了處理日誌產生的。
當碰到上面的幾種情況的時候，就要考慮用訊息佇列了。如果你碰巧使用的是 rabbitmq 或者 kafka ，而且同樣也是在使用 spring cloud ，那可以考慮下用 spring cloud stream。
spring cloud stream 中的幾個重要概念：
destination binders：目標繫結器，目標指的是 kafka或者 rabbitmq，繫結器就是封裝了目標中介軟體的包。如果操作的是 kafka 就使用 kafka binder ，如果操作的是 rabbitmq 就使用 rabbitmq binder。
destination bindings：外部訊息傳遞系統和應用程式之間的橋梁，提供訊息的「生產者」和「消費者」（由目標繫結器建立）
message：一種規範化的資料結構，生產者和消費者基於這個資料結構通過外部訊息系統與目標繫結器和其他應用程式通訊。
整體架構：
說明：最底層是訊息服務，中間層是繫結層，繫結層和底層的訊息服務進行繫結，頂層是訊息生產者和訊息消費者，頂層可以向繫結層生產訊息和獲取訊息。通過定義繫結器binder作為中間層，實現了應用程式與訊息中介軟體細節之間的隔離。
詳細架構：
微服務模組：
微服務模組：乙個生產者微服務，兩個消費者微服務。
三個模組都加入如下的依賴：
編寫傳送訊息業務**：
介面imessageprovider
public
inte***ce
imessageprovider
@
enablebinding
(source
.class)/
/定義訊息的推送管道
消費訊息業務**：
@
component
@enablebinding
(sink
.class
)public
class
receivemessagelistenercontroller")
private
string
serverport;@
streamlistener
(sink
.input
)public
void
input
(message
<
string
>
message
)}
1、重複消費問題
重複消費問題,是生產和面試都是重點問題,需要保證一條資訊,如訂單支付,保證只被消費一次 這裡使用分組解決,而預設stream分組名是流水號是隨機的,沒在同乙個組存在重複消費 可以在 消費者端 配置spring.cloud.stream.bindings.input.group為同乙個組
2、訊息持久化問題
這個問題,其實分兩個端,乙個是訊息中介軟體端的持久化 , 乙個是應用層的持久化,前者需要對不用的訊息中介軟體進行配置, 我們這裡討論後者.
問題： 假如消費者掛了,而生產者生產了訊息,此時消費者再上線時無法消費生產者生產的資料。
問題產生的原因同樣是因為沒分組,所以當消費者應用重啟時會隨機生成組名,而隨機生成的組名沒有訂閱訊息消費,所以不能消費。
怎麼辦？
我們需要為訊息消費者配置組,該組訂閱生產者。在消費者掛了之後,重新啟動因為已經訂閱了生產者,就可以重新自動消費訂閱的生產者。
訊息佇列 訊息佇列
輪詢排程 一次性分發所有訊息，保證訊息平均分配，不管消費者是否能正常消費 訊息應答 保證消費端能確實消費，不丟失 公平 乙個乙個分發所有訊息,在保證分發到的執行緒確認回覆後，才分發下個訊息給下個空閒的消費者，訊息持久化 保證佇列中的訊息不丟失，包括3要素 交換器 訊息佇列 訊息都必須宣告持久化 發布...
訊息佇列 訊息佇列 kafka
kafka是乙個分布式的基於發布 訂閱模式的訊息佇列，主要用於大資料實時處理領域。要理解kafka首先要有分布式的概念，要有訊息佇列的概念。分布式系統最大的優勢就是解耦和削峰，這種情況下，a系統生成了乙個訊息，b系統非同步獲取，那麼就需要乙個存放訊息的訊息佇列 mq 相比較傳統的訊息佇列，訊息被消費...
linux訊息佇列 Linux訊息佇列
訊息佇列，unix的通訊機制之一，可以理解為是乙個存放訊息 資料 容器。將訊息寫入訊息佇列，然後再從訊息佇列中取訊息，一般來說是先進先出的順序。可以解決兩個程序的讀寫速度不同 處理資料速度不同 系統耦合等問題，而且訊息佇列裡的訊息哪怕程序崩潰了也不會消失。最簡單的訊息記憶體的使用流程 ftok函式生...