CAP是由我們園子裡的楊曉東大神開發出來的一套分布式事務的決絕方案，是.Net Core Community中的第一個千星項目（目前已經1656 Star），具有輕量級、易使用、高性能等特點。
https://github.com/dotnetcore/CAP
本部落客要針對易用性這一點，展開叙述，一起看看CAP如何結合EF Core和RabbitMQ帶領小白輕松走入分布式消息隊列的世界。
首先，你需要搭建一套RabbitMQ系統，搭建過程在此不再叙述，如果大家覺得麻煩，可以用我搭好的。
HostName: coderayu.cn UserName:guest Password:guest (僅僅可用作實驗，資料丢失不負責)
建立Asp.Net Core 項目，并引入Nuget包
你可以運作以下下指令在你的項目中安裝 CAP。
如果你的消息隊列使用的是 Kafka 的話，你可以：
如果你的消息隊列使用的是 RabbitMQ 的話，你可以：
CAP 提供了 Sql Server, MySql, PostgreSQL 的擴充作為資料庫存儲：
因為我采用的是EF Core，是以首先要建立一個DbContext上下文，代碼如下：
首先需要在ConfigureServices函數中進行相關服務的注入，對應的操作和功能解釋如下：
最後還要再Congiure中啟用CAP中間件
再程式包管理控制台中依此輸入以下指令行
如果成成功執行，那麼打開資料庫，就可以看到用來存儲CAP發送和接收資料的表格了。
表格中每列的含義如下：
我們直接在ValuesController的基礎上進行改造。
在 Controller 中注入 <code>ICapPublisher</code> 然後使用 <code>ICapPublisher</code> 進行消息發送
發送消息
訂閱消息
啟動程式後，首先看到CAP啟動成功
緊随其後，消費者也就是我們的訂閱方法在RabbitMQ伺服器上注冊成功。
發送消息，發送成功，如下
發送後，立即在控制台看到了訂閱方法輸出的結果。
在訂閱方法中，如果抛出異常，那麼CAP就會認為該條消息處理失敗，會自動進行重試，重試次數在前方已經進行了配置。
我們把訂閱方法做一個改動，列印接收的資訊到控制台中，并抛出異常
可以看到，立即進行了三次重試
可是在前面，我們設定的失敗重試次數是5次，為什麼這裡隻重試三次嗎？是不是要叫曉東過來改BUG了呢
？當然不是。
觀察發現，CAP重試的前三次是立即進行的，而後面的重試，是每隔一段時間進行的，當在分布式通訊的過程中，可能出現了問題确實不會立即修複解決，可能過了一定時間，系統就自動恢複了，如網絡抖動。
發送成功了五條消息，成功接收處理了三條，兩條處理失敗，處理失敗的任務，我們可以直接在面闆中進行重新消費，可謂非常友善。
同時，處理失敗的消息，點選消息的編号後，可以檢視到消息的内容和異常原因。
CAP如此強大，讓消息隊列這種高大上産品操作So Easy，學會了CAP,也可以吹牛說，我也懂分布式任務處理啦
。
感謝曉東開發出如此強大的項目，同時感謝.Net Core Community。
參考 CAP Github wiki
https://github.com/dotnetcore/CAP/wiki
本部落格Demo代碼
https://github.com/liuzhenyulive/CAP.Demo