Stream 分組消費與持久化
建立了一個module cloud-stream-rabbitmq-consumer8803，作為消息接收子產品（參考8802）
這一塊是根據建立的這個進行的示範：
現在就是這樣的架構：
比如在如下場景中，訂單系統我們做叢集部署，都會從RabbitMQ中擷取訂單資訊，那如果一個訂單同時被兩個服務擷取到，那麼就會造成資料錯誤，我們得避免這種情況，這時我們就可以使用Stream中的消息分組來解決。
注意在Stream中處于同一個group中的多個消費者是競争關系，就能夠保證消息隻會被其中一個應用消費一次。
不同組是可以全面消費的（重複消費），同一組内會發送競争關系，隻有其中一個可以消費。
目前遇到的問題：
目前是8802/8803同時都收到消息了，存在重複消費問題。
分組：
原理：
微服務應用放置在同一個group中，就能夠保證消息隻會被其中一個應用消費一次。
不同的組是可以消費的，同一個組内會發生競争關系，隻有其中一個可以消費。
把8802/8803都變成不同組，group兩個不同
修改8802/8803的yml配置檔案
結論：還是重複消費。
分布式微服務應用為了實作高可用和負載均衡，實際上都會部署多個執行個體，本次啟動了兩個消費微服務8802/8803
多數情況下，生産者發送消息給某一個具體的微服務時隻希望被消費一次，按照上面我們啟動兩個應用的例子，雖然他們同屬一個應用。
但是這個消費出現了被重複消費兩次的情況，為了解決這個問題，在spring cloud Stream中提供了消費組的概念。
怎麼實作這一消費組：
8802/8803實作了輪詢分組，每一次隻有一個消費者
8801子產品發送的消息隻能被8802或者8803其中一個接受到，這樣避免了重複消費。
8802/8803都變成相同組，group兩個相同。
怎麼設定？
在8802和8803消費者上面設定一樣的分組group
結論：
這樣8802和8803消費者上面分别收到了一個消息，這樣就避免了重複消費的問題。
同一個組會競争資源，輪詢。不同組會重複消費。
持久化
關于自定義分組
**場景：**停止8802/8803并且去除掉8802的分組group:atguiguA
注意：8803的分組沒有去掉。
結果：
如果8802去掉分組，而8803不去掉，當8802/8803都關閉服務，8801這時候發送消息，8802再啟動的時候不會重新獲得未曾獲得的消息并消費，而8803重新開機後會獲得8801之前發送的消息并消費。
是以group分組屬性在消息重複消費和消息持久化消費 避免消息丢失是非常重要的屬性
就是預設的分組不會保留未曾獲得的消息，自定義的分組會保留。