當系統**現「生產「和「消費「的速度或穩定性等因素不一致的時候，就需要訊息佇列，作為抽象層，彌合雙方的差異。
舉個例子：業務系統觸發簡訊傳送申請，但簡訊傳送模組速度跟不上，需要將來不及處理的訊息暫存一下，緩衝壓力。
再舉個例子：調遠端系統下訂單成本較高，且因為網路等因素，不穩定，攢一批一起傳送。
再舉個例子，互動模組5：00到24：00和電商系統聯通，和內部erp斷開。1：00到4：00和erp聯通，和電商系統斷開。
再舉個例子，服務員點菜快，廚師做菜慢。
再舉個例子，到銀行辦事的人多，提供服務的視窗少。
乖乖排隊吧。
使用了訊息佇列，生產者一方，把訊息往佇列裡一扔，就可以立馬返回，響應使用者了。無需等待處理結果。
處理結果可以讓使用者稍後自己來取，如醫院取化驗單。也可以讓生產者訂閱（如：留下手機號碼或讓生產者實現listener介面、加入監聽佇列），有結果了通知。獲得約定將結果放在某處，無需通知。
考慮電商系統下訂單，傳送資料給生產系統的情況。
電商系統和生產系統之間的網路有可能掉線，生產系統可能會因維護等原因暫停服務。
如果不使用訊息佇列，電商系統資料發布出去，顧客無法下單，影響業務開展。
兩個系統間不應該如此緊密耦合。應該通過訊息佇列解耦。同時讓系統更健壯、穩定。
訊息佇列中的資料需要在多個系統間共享資料才能發揮價值。
所以必須提供分布式通訊機制、協同機制。
單系統內部，為了更好的效能、為了避免單點故障，多為集群環境。
集群環境中，應用執行在多台伺服器的多個jvm中；資料也儲存在各種型別的資料庫或非資料庫的多個節點上。
為了滿足多節點協作需要，需要提供分布式的解決方案。
需進行良好的併發控制。確保「執行緒安全「。
不要出現乙個訂單被出貨兩次。不要出現顧客a下的單，發貨發給了顧客b等情況。
需定義簡單的，語義明確的，業務無關的，恰當穩妥的統一的訪問方式。
控制好單點故障，確保資料安全。
可便捷擴容。
成熟的訊息佇列中介軟體產品太多了，族繁不及備載。
成熟產品經過驗證，介面規範，可擴充套件性強。
結合事業環境因素、組織過程遺產、實施運維考慮、技術路線考慮、開發人員情況等原因綜合考慮，基於redis自己做乙個是最可行的選擇。
如何做呢？
請聽下回分解。
基於Redis實現分布式鎖
分布式鎖的基本功能 1.同一時刻只能存在乙個鎖 2.需要解決意外死鎖問題，也就是鎖能超時自動釋放 3.支援主動釋放鎖 分布式鎖解決什麼問題 多程序併發執行任務時，需要保證任務的有序性或者唯一性 準備 redis版本 2.6 redis是主從 sentinel模式 為了高可用 原理 redis2.6之...
基於Redis實現分布式鎖
之前專案中使用redis鎖實現秒殺等一些併發業務，在這裡整理一下基於redis實現分布式鎖的簡單入門例項，記錄一下，便於以後檢視 學習。springboot整合redisson分布式鎖 1 簡介 在分布式系統中存在併發場景，為了解決這一問題，基於redis鎖一定程度可以解決這一問題，但是也有缺點，如...
基於redis實現分布式鎖
實現方式 具備條件 確保鎖可用，必須要滿足一下幾個條件 1 互斥性，任意時刻只有乙個使用者能持有鎖 2 不會產生死鎖，假設某個使用者在持有鎖的期間由於服務崩潰或者其他原因沒有主動釋放鎖，也能保證後續其他使用者可以加鎖 3 加鎖和解鎖必須是同一使用者，b使用者無法解除a使用者加的鎖 實現 1 引入je...