現在使用者對商品下單，我們的系統有三個步驟要做：
1.減商品的庫存。
2.如果使用者有紅包，扣掉使用者的可用紅包。
3.建立乙個訂單。
情況1：交易系統中扣庫存成功，扣紅包成功，但是此時由於某種原因（如超時）導致建立訂單失敗。
問：如何解決資料一致性（c）問題？
答：1.一次建立失敗，為提高系統的可用性，我們應該進行操作的重試（如：3次）。2
2.如果還是失敗，那可能就是系統問題了，此時我們可以進行補償，把扣掉的庫存加回去，把扣掉的紅包加回去。操作失敗的時候一定要持久化我們的運算元據。
3.分布式事物原理是什麼？所謂的分布式事物可以看成是乙個長事物，本地事物就是短事物，這裡就是將乙個長事物化作三個短事物。
問：上面回答中的重試應該在哪一環節重試？如何保證冪等性？
答：1.在資料訪問層重試行嗎？沒問題。因為訂單號在建立訂單之前就已經生成了。所以在資料訪問層重試不會造成重複下單的問題。
2.在交易系統的業務邏輯層重試行嗎？不行。如果所有流程都沒問題，訂單已經入庫，在交易業務邏輯層呼叫返回超時。此時，返給上游的結果失敗。但實際的業務已經完成。現在如果進行重試，業務邏輯層會重新建立乙個訂單號，假設重試成功，那麼系統中就會有兩個訂單。造成了重複下單。如何解決呢? 使用者進入系統前伺服器返給使用者乙個標識token，後端將該唯一標識和訂單號繫結放到本地快取中，重試的時候如果快取中有訂單號，那麼我們取出這個訂單號進行重試。重試成功將值刪掉。如果還是失敗，將失敗的資訊持久化一下，便於後續的檢查以及補償。
3.閘道器層重試也會有相同的問題。
問：如果呼叫扣紅包很多次都沒成功，怎麼辦？
答：服務熔斷保護系統避免雪崩。單個的服務不可用，不要影響到其它可用服務。
分布式 分布式場景下面試題
redis相比memcached有哪些優勢 執行緒模型 redis 基於 reactor 模式開發了自己的網路事件處理器 這個處理器被稱為檔案事件處理器 file event handler 雖然檔案事件處理器以單執行緒方式執行，但通過使用 i o 多路復用程式來監聽多個套接字，檔案事件處理器既實現...
核心金融場景分布式事務
分布式事務是分布式系統架構設計中的乙個技術難點，特別是在這幾年越來越火的微服務架構中，服務拆分所帶來的跨服務資料一致性問題亟待解決，本文將圍繞分布式事務產生背景和螞蟻金服的分布式事務解決方案 sofa dtx 向大家進行介紹。1.1 資料庫的水平拆分 通常業務系統的資料庫起初是單庫，但隨著業務資料規...
分布式 分布式鎖
本質是利用redis的setnx 方法的特性來加鎖，setnx 即key不存在則設定key，否則直接返回false，要求在分布式系統中使用同乙個redis服務，以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題，因為可能在鎖過期之後該執行緒尚未執行完...