場景
業務場景：下單時扣減庫存，由于比較簡單，商品和庫存都放到了一個背景關系中  學習多個背景關系之間的互動，協作，訂單背景關系生成訂單時，扣減商品背景關系中的庫存第一個方法
第一個方法的技術選型，Redis，WebApiClient，EF CORE, Polly, ExceptionLess，雪花演算法 把商品的庫存放到redis中，在redis中驗證庫存，redis中扣減庫存,生成訂單后使用WebApiClient呼叫商品背景關系中扣減庫存的介面 問題： 1，在redis中驗證庫存，扣減庫存時，需要加上Look，多執行緒時，獲取redis中的庫存時不加鎖獲取的庫存可能不正確 2，確保WebApiClient呼叫介面能成功，使用polly 如果掉介面例外，失敗時，重試，重試程序中記錄例外，和重試的次數，并發出通知， 3，性能不強，EF core 需要持久化訂單的資料，使用WebApiClient呼叫商品背景關系中的介面有網路開銷 4，WebApiClient請求例外，失敗時，Polly會進行重試，出現多次呼叫的問題，商品背景關系介面必須做冪等 5，如何保證不超賣，執行扣減庫存修改陳述句是帶上庫存必須大于0的條件第二個方法
第二個方法的技術選型，Redis，CAP，Rabbitmq，EF CORE, Polly,ExceptionLess，雪花演算法 把商品的庫存放到redis中，在redis中驗證庫存，redis中扣減庫存,生成訂單時開啟事務，使用CAP來發送訊息到EventBus，商品背景關系訂閱，扣減庫存 問題： 1，如果保證訊息不丟，使用CAP,CAP是基于本地訊息表的方式來實作的組件，發送訊息和消費訊息都已本地事務的方式記錄了發送和消費的情況，如果失敗 會進行重試，重試一定的次數，可以人工干預解決問題，也可以做補償事件， 2，訂閱訊息時可能出現例外，CAP會進行重試，同一訊息會出現多次消費的問題，商品背景關系介面必須做冪等 3，CAP在發送，消費訊息時都會已本地事務的方式，寫入一條資訊到資料庫表中，進行了2次IO的交付第三個方法
第三個方法的技術選型，Redis，Rabbitmq，CAP，EF CORE, Polly,ExceptionLess，雪花演算法 之前看過一句話，讀多寫少用快取，寫多讀少用佇列，我們可能使用佇列來提高我們的處理能力，佇列可以堆積訊息，所以要使用訊息佇列
使用CommandService來發送Command，DomainEventService來發送事件，CAP具有EventBus的功能，但是多了2次IO的互動，使用自己簡單封裝Rabbitmq來寫CommandService
事件會改變我們系統的狀態，代表已經發生過的事實，比較重要，為了確保安全選擇了CAP
當前端呼叫我們介面時在Controller中使用CommandService發送command到EventBus，commandHandler訂閱訊息，在redis中驗證庫存，redis中扣減庫存,生成訂單時開啟事務
使用DomainEventService來發送訊息到EventBus，商品背景關系訂閱，扣減庫存
問題：
1，CommandService的實作，參考Rabbitmq官網的demo以及檔案，參考CAP原始碼
2，使用佇列后，沒有獲取到回傳值，通過記錄日志，查看訊息的消費情況
3，大大增強了框架的復雜性，查錯比較復雜
4，Rabbitmq沒有使用集群，web也沒有使用集群，資料沒有集群，目前對于集群的學習比較淺
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/59644.html
標籤：.NET Core