訊息佇列功能介紹
字面上說的訊息佇列是資料結構中「先進先出」的一種資料結構，但是如果要求消除單點故障，保證訊息傳輸可靠性，應對大流量的衝擊，對訊息佇列的要求就很高了。現在網際網路的「微架構」模式興起，原有的大型集中式的it服務因為各種弊端，通常被拆分成細粒度的多個「微服務」，這些微服務可以在乙個區域網內，也可以跨機房部署。一方面對服務之間松耦合的要求越來越高，另一方面，服務之間的聯絡越來越緊密，分布式訊息佇列可以提供三大重要功能應用解耦、流量削峰、訊息分發，已經成為大型網際網路服務架構裡的標配的中介軟體
1.1 訊息佇列的解耦功能
複雜的應用裡會存在多個子系統，比如電商應用中有訂單系統，庫存系統，物流系統，支付系統。這個時候如果各個子系統之間的耦合度太高，整體系統的可用性就會大幅度降低。多個低錯誤率的子系統耦合在一起，得到乙個高錯誤率的整體系統。以電商應用為例，使用者建立訂單後，如果耦合呼叫庫存系統，物流系統，支付系統，任何乙個子系統出了故障或者因為公升級等原因暫時不使用，都會造成下單操作異常，影響使用者使用體驗
如圖1.1所示，當轉變成基於訊息佇列的方式後，系統的可用性就高多了，比如物流系統因為發生故障，就需要幾分鐘的時間來修復，在這幾分鐘裡，物流系統要處理的內容被快取在訊息佇列裡，使用者的下單操作可以正常完成。當物流系統恢復後，補充處理儲存在訊息佇列裡的訂單資訊即可，終端使用者感知不到物流系統發生過幾分鐘的故障
每年的雙十一，**的很多活動都在0點的時候後開啟，大部分應用系統流量會在瞬間猛增，這個時候如果沒有緩衝機制，不可能承受住短時大流量的衝擊。通過訊息佇列，把大量的請求暫存起來，分散到相對長的一段時間內處理，能大大提高系統的穩定性和使用者體驗。
舉個例子，如果訂單系統每秒最多處理一萬次下單，這個處理能力應對正常時段是綽綽有餘的，但是遇到雙十一0點時，如果沒有訊息佇列這種緩衝機制，為保證系統的穩定，只能在訂單超過一萬次後就不允許使用者下單了；如果有訊息佇列做緩衝，我們可以取消這個機制，把一秒內下的訂單分散成一段時間來處理，這時候有些使用者可能在下單後幾十秒才能收到下單成功的狀態，但是這也比不能下單的體驗要好
使用訊息佇列進行流量削峰，很多時候不是因為能力不夠，而是出於經濟性的考察；比如有的業務系統，流量高峰也不會超過一萬qps，而平時只有一千左右的qps。這種情況下我們就可以用普通效能的伺服器，然後加個訊息佇列作為高峰期的緩衝，無需花大筆資金部署能處理上萬qps的伺服器
1.3 訊息佇列的訊息分發功能
在大資料時代，資料對很多公司來說就像是金礦，公司需要依賴對資料的分析，進行使用者畫像，精準推送，流程優化等各種操作，並且對處理的實時性要求越來越高。資料是不斷產生的，各個分析團隊，演算法團隊都要依賴於這些資料來進行工作，這個時候有個可持久化的訊息佇列就非常重要。資料的產生方式只需要把各自的資料寫入乙個訊息佇列即可，資料使用方各自根據需求訂閱自己感興趣的資料，不同資料團隊所訂閱的資料可以重複也可以不重複，互不干擾，也不必和資料產生方關聯
除了上面列出的應用解耦，流量削峰，訊息分發等功能，訊息佇列還***最終一致性，方便動態擴容等功能
訊息佇列入門理解
現在假設這樣乙個場景，使用者下單成功需要給使用者發簡訊，如果沒有訊息佇列，我們會選擇同步呼叫發簡訊的介面並等待簡訊傳送成功。現在假設簡訊介面實現出現了問題或者簡訊傳送短時間內達到了上限，這個時候是選擇重試幾次還是放棄傳送呢？這裡的設計會很複雜。如果使用了訊息佇列，我們選擇將發簡訊的操作封裝成一條訊息...
單調佇列 入門
今天寫了人生中第乙個單調佇列,激動ing 先看一道單調佇列的入門題 乙個含有n項的數列 n 2000000 求出每一項前面的第m個數到它這個區間內的最小值。先寫出動規方程 f i min j合法 很明顯的,這是乙個n 2的動規,但是,我們可以注意到,數列中有些數無論如何都不會被選到.如 1 2 8 ...
C STL 佇列入門
2 queue queue 模板類的定義在標頭檔案中。與stack 模板類很相似，queue 模板類也需要兩個模板引數，乙個是元素型別，乙個容器類 型，元素型別是必要的，容器型別是可選的，預設為deque 型別。定義queue 物件的示例 如下 queueq1 queueq2 queue 的基本操作...