場景
業務場景：下單時扣減庫存，由於比較簡單，商品和庫存都放到了一個上下文中  學習多個上下文之間的交互，協作，訂單上下文生成訂單時，扣減商品上下文中的庫存
第一個方法
第一個方法的技術選型，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也沒有使用集群，數據沒有集群，目前對於集群的學習比較淺
