[toc] ## :-: **隊列 的 概念** 1、是隊列結構的中間件 2、消息放入后<span style="color:red;">不需要立即處理</span> 3、由訂閱者/消費者按順序處理 ## :-: **隊列 原理**  - 也是解耦的原理：業務系統和隊列處理系統沒有關系 - 一個寫（業務系統），一個讀（隊列管理系統）。 - <span style="color:red;">寫的只管</span>往隊列里<span style="color:blue;">寫</span>，別的不用操心，讀的能不能讀完和寫的也沒有關系 - 同樣，<span style="color:red;">讀的只管</span>從隊列里往外<span style="color:blue;">讀</span>，來活兒就干，沒活兒歇著 ## :-: **應用場景** - 冗余：<span style="color:red;">持久化的存儲在隊列中</span>，后續由訂單處理程序獲取，處理完成之后，在把這條記錄進行刪除 - 解耦：是解這2套系統（業務和隊列處理），我們平常做的都是一套系統的。入隊和出隊的系統沒有直接的關系，<span style="color:red;">其中一套蹦了，另一套系統不會受影響</span>，因為中間隔了個隊列 - 流量削鋒：秒殺和搶購。流量劇增，<span style="color:red;">配合緩存使用消息隊列</span>（就是限制下，如 只允許10個，隊列里存10個之后就不存了，在來就提示秒殺結束） - 異步通信：<span style="color:red;">因為消息本身就可使入隊的系統</span>直接返回，所以說實現了程序的異步操作 - 場景擴展性：如 現在只有訂單系統和財務系統，后續我想加個配貨系統，<span style="color:red;">直接讓配貨系統訂閱這個隊列就可以 </span> - 排序保證：有些場景下，如 銀行數據的<span style="color:red;">處理順序是很重要</span>的，因為隊列本身就可以做成單線程，單進單出的這種系統 ## :-: **實現介質** 1、使用mysql：可靠性高，易實現，速度慢 2、使用redis：速度快，單條大消息包時效率低 3、使用更專業的第三方類庫：專業性強，可靠，學習成本高。 請參考我這篇博客http://blog.csdn.net/qq\_33862644/article/details/79386484 ## :-: **消息觸發機制** 1、死循環方式讀取：易實現，故障時無法及時回復（<span style="color:red;">適用于秒殺這種短時間的</span>） 2、定時任務：壓力均分，有處理上限（無論你隊列前的系統，峰值多么不穩定，<span style="color:red;">隊列后的系統依然會定時執行</span>） >[warning]定時時間是個關鍵：不要上一個還定時任務沒執行完，下一個定時任務就啟動了 示例：訂單系統，下單后將訂單信息寫入隊列后，立刻返回下單成功。配貨系統每隔幾分鐘<span style="color:red;">定時讀取隊列</span>，對訂單進行匯總處理 3、守護進程：類似于php-fpm和cgi，需要shell基礎（用這個進程來檢測，隊列中是否有內容，有內容的話，啟動出隊系統進行處理） ## :-: **使用mysql實現解耦的示例** - 為什么要解耦：如果架構在一起。訂單系統壓力大，而物流信息是不需要立刻返回的。訂單崩了，物流也就蹦了，所以要解耦   - 表的設計  - 訂單系統寫入隊列的代碼  - 配貨系統讀取隊列的代碼  執行定時任務crontab -e  >[warning] 這日志要自己新建  1、通過瀏覽器訪問order.php添加訂單 2、去數據庫看結果，在shell中的日志中看結果(沒有執行成功，可能是這sh文件需要放在某個特點目錄吧，等復習完 在跑) ## :-: **使用redis進行流量削鋒的示例**  - 思路： 1、秒殺程序請求寫入redis???? 2、檢查redis已存放數據的長度，超出上限直接丟棄（返回秒殺結束） 3、死循環處理存入redis的數據并入庫 - 表的設計：  - 秒殺代碼  - 入庫代碼  瀏覽器直接訪問user.php 在shell中使用php -f savetodb.php 去數據庫查看