分佈式服務接口請求的順序性如何保證?

本博客轉自git項目advancejava
面試題剖析
首先,一般來說,個人建議是,你們從業務邏輯上設計的這個系統最好是不需要這種順序性的保證,因爲一旦引入順序性保障,比如使用分佈式鎖,會導致系統複雜度上升,而且會帶來效率低下,熱點數據壓力過大等問題。

下面我給個我們用過的方案吧,簡單來說,首先你得用 dubbo 的一致性 hash 負載均衡策略,將比如某一個訂單 id 對應的請求都給分發到某個機器上去,接着就是在那個機器上因爲可能還是多線程併發執行的,你可能得立即將某個訂單 id 對應的請求扔一個內存隊列裏去,強制排隊,這樣來確保他們的順序性。
在這裏插入圖片描述

但是這樣引發的後續問題就很多,比如說要是某個訂單對應的請求特別多,造成某臺機器成熱點怎麼辦?解決這些問題又要開啓後續一連串的複雜技術方案…曾經這類問題弄的我們頭疼不已,所以,還是建議什麼呢?

最好是比如說剛纔那種,一個訂單的插入和刪除操作,能不能合併成一個操作,就是一個刪除,或者是什麼,避免這種問題的產生。

發佈了107 篇原創文章 · 獲贊 15 · 訪問量 3萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章