## 隊列  為了更好的學習，分享知識，我在segmentfault上建立了一個技術圈子：[php隊列](https://segmentfault.com/g/1570000010691466) * * * * * ### php-resque分析 [PHP的輕量消息隊列php-resque使用說明](https://avnpc.com/pages/run-background-task-by-php-resque) 1. 允許處理多個隊列工作，用逗號分隔，*標示處理所有隊列 2. 允許定義工作進程是否使用阻塞的模式（默認為false，表示阻塞），和阻塞時間間隔（默認為5秒，不能為0） 3. 允許開啟多個工作進程（子進程的形式）來工作，默認是啟動一個工作進程 4. 每個工作進程通過死循環來實現“常駐進程”，“守護進程”的效果 5. 工作進程是怎么獲取隊列和執行工作的呢，實際上工作進程也會開辟子進程（死循環開辟），“執行隊列工作”在其子進程中完成，獲取隊列在自身進程中完成，在分析這里面之前先來了解下這個： > 工作進程通過lpop和blpop兩種方式來彈出左邊的一條工作隊列（隊列任務），之所以會以兩種方式來從隊列中彈出一條工作信息是有意義的，下面來分析： 先來看獲取隊列時使用到的兩個方法： 1. [blpop](http://doc.redisfans.com/list/blpop.html)的第二個參數會使用到阻塞的時間間隔，也就是以阻塞的方式獲取隊列 2. [lpop](http://doc.redisfans.com/list/lpop.html)雖然沒有使用到，但是在工作進程中使用usleep阻塞了 > 總結：不管blocking為true還是為false，不阻塞還是阻塞，其實都會阻塞的，這是在沒有新隊列時，在有隊列時都不會阻塞（唯一的阻塞大概就是lpop時redis的并發處理阻塞吧，猜測，還在了解redis）這是為了最大化隊列工作的效率 上面總結是事實，那具體代碼中是怎么做到的呢，下面揭秘： 1. 獲取工作時，如果發現blocking為true即非阻塞時，則采用blpop查詢，blpop的特點是如果沒有數據，則阻塞，有數據則與lpop無異。否則blocking為false即阻塞時，則采用lpop查詢，沒有阻塞。 2. 接下來如果有隊列則往下執行，如果，沒有隊列，并且blocking為false即阻塞時那就使用usleep阻塞。 關鍵的部分我們大概分析完了，現在有幾個問題？ 1. 獲取隊列是在工作進程中進行的，而“執行隊列工作”是在工作進程的子進程完成的，也就是說做到了沒有讓隊列工作執行阻塞工作進程，一般也我們也假設隊列工作的執行是最耗時的部分，比如發短信，和發郵件，而獲取隊列，雖然可能是redis的并發阻塞，但是redis是內存是數據庫，所以還是很快的，那么是不是有可能造成工作進程開辟很多子進程呢，并且隊列工作的執行很耗時，那么造成大量的子進程在運行，會不會將服務器拖垮呢？因為這個子進程的數量沒有得到控制。 2. 為什么我們獲取隊列工作時每次只獲取一條呢，為什么不獲取多條呢，下面分析獲取多條與單條的優缺點比較： ## 獲取多條： * 好處： 1. 減少數據庫的查詢次數，下面再循環執行工作就可以 2. 減少開銷，用最少的進程完成工作，減少進程的開辟數量，提升性能 * 壞處： 1. 獲取多條數據的時間相對慢 2. 怎么加鎖呢，不管是悲觀還是樂觀鎖，增加維護的成本 3. 一個工作進程中循環執行多次隊列任務（有可能多個不同的工作隊列），內存得不到及時的釋放，這樣會消耗更多的性能和時間（隊列工作的執行時相互阻塞的），即使將每個隊列工作都放在子進程中，那也更得不償失，嵌套開辟子進程過多，性能更沒保證。 ## 獲取單條： * 好處： 1. 獲取單條快，加鎖容易 2. 每次執行一個隊列工作，管理容易，維護方便 3. 每次執行一個隊列工作，符合隊列的快進快出原則，盡早執行完，盡早釋放，有更好的性能 * 壞處： 1. 消費執行相同數量的隊列工作需要操作數據庫的次數增多，影響性能 2. 消費執行相同數量的隊列工作需要開辟維護的進程的數增多，影響性能 3. 每個工作進程通過死循環來實現“常駐進程”，“守護進程”的，這樣長時間工作有沒有性能問題呢，比如內存釋放等，如果再MVC框架中還會有更大的性能開銷呢，如果不用在MVC框架中，但是我們的工作業務邏輯很重，很依賴框架啊，這個么辦法解決呢？ 4. redis會不會導致數據丟失呢？每次好像沒有考慮隊列工作的執行結果啊，彈出后如果執行沒有成功，這個問題怎么解決？ #### 先來看第一個問題 > 如果第一個問題php-resque沒有好的辦法解決，或者它沒有想到這個問題，沒有考慮過這個問題，那我們只能盼望隊列工作的執行相對于取隊列來說消耗很短的時間了，我們把取隊列需要消耗t時間，消費執行隊列工作需要消耗t2時間，我們只能盼望t2相對于t慢不了太多，也就是說我們t2要很快才行，t2-1越大意味著我們越擔心會出問題，如果越小則說明系統越穩定，越健康。（可是我們怎么能夠賭上這一把呢，怎么能夠期待它呢，這很不靠譜好吧！） ### 解決問題1： [pcntl_wait](http://php.net/manual/zh/function.pcntl-wait.php) wait函數掛起當前進程的執行直到一個子進程退出或接收到一個信號要求中斷當前進程或調用一個信號處理函數。 如果一個子進程在調用此函數時已經退出（俗稱僵尸進程），此函數立刻返回。子進程使用的所有系統資源將 被釋放。關于wait在您系統上工作的詳細規范請查看您系統的wait（2）手冊。 這樣的話就不用擔心這個問題了，在子進程為完成前，會把父進程阻塞住，也就不會出問題了。這跟用不用子進程其實是一樣的，但是這樣的好處是更靈活。 #### 用生活中的例子來說明隊列的使用場景，并做分析與對比。 隊列要效率就要多進程，就像生活中的例子，公交站很多人，每個人要想快點回家，只有來更多的公交車才行，但這里要注意一點，馬路要寬，要同時容納或者同時能走兩輛車才行，如果馬路只能同時有一輛車走那就沒意義了。 這也就是多進程不會阻塞的意義。 但是還有一個問題，即使執行隊列是多進程不阻塞，但是獲取隊列缺失阻塞的，總不能并發給用戶發多次通知短信吧，所以阻塞還是有的，只不過這里的阻塞時間很短很短，這就沒問題。而執行隊列如果阻塞，那不敢想象，就像馬路一次只能走一輛車（假設馬路的承重有限），來再多車都沒有意義。 看一個典型容易出錯的問題：隊列工作阻塞和這個例子類似嗎？ 如果我們用循環，不用子進程就相當于生活中，多輛公交車來站臺載人，其實這就說錯了不嚴謹，因為多輛公交車可以“并行”啊，就算馬路只能很窄只能容納一輛車通行，第二輛車也可以跟在后面啊，所以這并不叫阻塞好吧！其實這就很尷尬了，既不能并行，后面的車只能跟在前面的車的屁股后面，也不算是程序里面的串行的意義，這種情況真是尷尬，它沒有體現并行的效率，但也不是串行的低效率，既不是真正意義上的并行，也不是真正意義上的串行，反正程序里面是不會有這樣的情況的。程序里面只有絕對的并行和絕對的串行，現實生活中簡直是被玩壞了。 所以在此嚴謹的定義下: * 串行：馬路很窄只能有一輛公交車，且馬路的承重是一輛車的重量，兩輛車會會把馬路壓塌的所以每輛車上路時都會檢查馬路上有沒有車，必須保證任何時候馬路上最多只能有一輛車。 * 并行：馬路很寬，承重不止一輛車，能同時在上面跑很多車(跟在屁股后面那種形式已經被我們干掉了，不用考慮了，不允許這樣的情況)，或者有很多條馬路，每個人從站臺開始，決定上哪一輛，走哪條路。 說了這么多其實是要先指出“把隊列工作，并行，串行，多進程，對應到現實生活中的例子時”容易犯的一個尷尬錯誤。 指出這個問題后，以后我們說的每種情況都不會在去糾結這個問題了，永遠不會再包含種情況了，并行就是同時發多輛車可以絕對并行與程序代碼并行意義一致，串行就是發一輛車與程序串行意義一致，意味著我們默認聲明了不包含這種情況了！請知曉，別說沒警告你哦。 現在我們問題就會明朗很多了，多進程就是同時發多輛車，單進程就是發一輛車，可以看出我們還有一個問題沒有解決，那就是別人怎么上車啊，上車有阻塞嗎？ 用lpop的話其實是有阻塞的，這個阻塞是必要的，這就相當于是，公交站有一個叉裝的通道，只有一個入口，叉裝通道通道每個車里面去，這個唯一的入口每次只能通行一個人，兩個人是擠不過去的。 其實還有一個比如更恰當，假設這些公交車會來搶人的，并且乘車的人都是按先來后到順序排隊的，這些公交車就按照這個順序搶排在前面先來的人，但是這么多人搶，總不能把一個人扯死五馬分尸吧，所以lpop內部應該是阻塞的。 也就是說上車是阻塞的，有沒有辦法實現上車不阻塞呢？ 還真有！**取模。** 在thinkPHP社區看到的使用定時任務system方式“多進程”，這其實不算多進程，這還是串行阻塞的方式的，每個隊列工作只能前一個執行完畢，后面一個才能執行，這是串行阻塞。 但是他那里面有一個思想還可以，就是巧妙的用了樂觀鎖(id%count=i)，保證每個進程（他說的進程，其實不是多進程），不會相互取到對方的隊列信息，并且是每次取多條隊列，這個思想還是可以的。 [隊列應用場景，自己實現隊列【附視頻和代碼】 - ThinkPHP框架](http://www.thinkphp.cn/topic/14728.html) ~~~ 本次公開課講的隊列，不是一種數據結構，而是一個業務邏輯的處理方法。 作為一個WEB開發人員，想象一下這樣的場景：你的網站平均一個用戶有一百多個好友，他們要給友好群發消息。假設每發送一條消息的相關操作，需要耗時0.1秒，發送一百多條，就需要十幾秒。肯定不能讓用戶點了“發送”按鈕之后在那等著發消息吧。這些耗時的操作，我們都是在后臺運行，甚至是在專門的隊列程序服務器上運行，而不能讓這些耗時的操作影響用戶體驗。 同樣的場景還有很多，比如郵件隊列，任務隊列，Feed隊列等等。 怎么處理這些隊列呢，本次課講講解一個低成本，易操作，易部署的方法：數據庫+輪詢程序，還會涉及到一些小技巧，比如，如何用多進程快速執行隊列，如何監測隊列等等 ~~~ 雖然他這個是假多進程，但是我們可以利用這個思想，用真多進程實現出來。 不過這個是MySQL的，如果是redis可能不太好實現吧，并且這樣有一個問題，那就是不好維護，如果突然需要增加進程或者減少進程，不可貿然的改變進程數量，否則會亂，會出問題的，這涉及到隊列重新分配的問題，所以必須要關閉所有進程，等所有進程執行完畢后才能操作，管理，這就很麻煩了，也就是說管理很不方便，維護麻煩。 這個問題留著慢慢討論，其實redis的lpop的阻塞效率應該很高了，我們將阻塞最厲害的部分，隊列工作的執行部分并行掉了，這個地方阻塞其實沒多大問題的哈。 還是想將這個問題分析完，上面那個“隊列分流”問題管理麻煩到底是哪里麻煩呢，id%count=i這里count是確定了的，也以為著所有的id都被分配好了，不論未知的id是否有被加進來，它都已經被早早的安排好的。只能唯一的被管理count的這個進程管理，如果這個管理"count"的是一個腳本，i是它開辟的子進程，那么則這個腳本只能有一個啟動一次，否則會出問題，出什么問題呢，并發的問題，將導致你可能會受到多條提示短信，這是我們不愿看到的。 如果突然要增加進程或者減少呢，需要重新分配“隊列分流”就可能造成問題，那怎么解決這個問題呢，兩個辦法，一是控制源頭，暫停所有隊列的寫入，讓隊列全部執行完，此時關閉守護進程，調整參數，重新啟動，一般不采取這鐘方案，這會導致這段時間內的隊列無法使用，丟失，不能使用隊列。第二種方式可平滑變動，無需停掉隊列服務，即軟關閉守護進程（直接殺死進程可能會出問題），這就需要在代碼中增加鉤子提前做好控制了，工作進程都關閉后再關閉守護進程，調整參數，重新啟動，這樣就能平滑的過渡了。基本沒有什么影響，只是會在關閉工作進程到重新啟動這個期間隊列服務有一點的演示而已。 樂觀鎖雖然好，但確實在有些時候確實會給管理維護帶來麻煩。 [什么是一致性Hash算法？](https://www.toutiao.com/a6533182504579367431/?tt_from=weixin&utm_campaign=client_share&timestamp=1521306221&app=news_article_lite&utm_source=weixin&iid=25315997380&utm_medium=toutiao_android&wxshare_count=1) > 主要體現在服務器數量變動的時候，所有緩存的位置都要發生改變！（求模，機器數量發生變化了就得重排，之前全部失效，效率太低了。） * * * * * ### 分析完php-resque后再來分析think-queue **這個還沒看完，但大概分析了一下，感覺結構還是比php-resque弱很多，但是自定義功能加強了（可能僅適于MySQL吧），下面總結幾點：** 1. 不支持多進程，沒有要求支持ext-pcntl擴展 2. 守護進程也是靠死循環做的，支持阻塞延時 3. 單進程本來就是阻塞的，每次循環都會sleep阻塞 4. 每次獲取一條隊列信息，采取開啟事務，加悲觀鎖，取一條，立即改變狀態，然后提交事務，釋放鎖的方式 5. 支持添加延遲任務到隊列 6. 隊列任務有超時時間，機制是每次一個隊列執行完畢后就sleep，沒有php-resque的智能機制 7. 支持任務執行失敗的捕獲 8. 支持重新發布(超時/失敗)任務 **隊列中兩個重要的東西:** **多進程：** php-resque依靠PHP的ext-pcntl擴展做的 **常駐/守護進程：** php-resque和think-queue都是用死循環（thinkPHP論壇那個帖子用的是crontab定時器） （啟動腳本時，SSH->bash 關閉窗口后就關閉進程了，這個用nohup常駐就行了） 最后記錄：2016-8-16 12:13:07 * * * * * ### 擴展 **什么放隊列，什么不放隊列，有什么原則？** 本來立即要做，但是當前做太耗時，不適應網頁這種快速處理，快速響應的場景，并且可以允許適當的延后執行(那些當前必須做的事就在本次就做了，做的過程中客戶端處于等待的狀態，做完后再響應)，即使隊列執行失敗也不會影響到程序邏輯，對程序整體不會產生錯誤，這樣的事可以放到隊列。比如下單發短信。 只要滿足這個原則的都可以當隊列，反之就不適合當隊列，要考慮其它方法了。 有一類事情，需要定時去檢查，去做的不適合放隊列。這個適合定時任務。 比如關閉超時訂單，這個需要掃訂單表，將超時訂單找出來處理。 記住這些情況可以結合隊列使用，兩者可以一起使用，已經說了只要滿足隊列的使用原則就可以使用它。 實際上隊列也是一個定時程序。 還有一種算是任務類的，比如給全站所有用戶推送消息。 隊列程序，一般最好一個隊列程序監控某一類或者某幾類任務，比如一個程序專門監控短信任務，只負責發短信。 那么上面的說的給所有用戶發信息的任務算是一個比較耗時長時間執行的任務了，這個可以讓一個隊列程序專門監控這類任務的任務隊列。 一個隊列程序又可以多進程并行處理隊列任務，這樣就能加快處理速度。 update：2016-12-6 14:19:46 * * * * * **有兩種觀點：** 1. 隊列處理程序為了性能有時候沒必要完全引入整個MVC 2. 如果不引入MVC的話，那就相對獨立了，系統配置什么的，環境，自動加載，數據模型等，這就很不方便了。 當然如果框架系統考慮到了隊列，CLI那么提供一種CLI模式運行環境，那也是極好的。 另外需要注意的一個問題就是，假設a程序是處理程序，那么現在每個幾秒鐘去運行一次a還是運行a，在里面死循環比較好。**（這個和php的運行模式和生命周期有關，例子是Laravel和Swoole，下面有探討。）** 如果每隔幾秒去運行a，那就相當于另外的程序去主動調用a了（命令行/自動任務等），那么就要注意不能重復調用a，不能多個其他程序都去調用了a，這可以做一個文件鎖來保證a同一時間內只能被調用一次，也就是不允許并發執行。死循環的話，一個腳本太長時間執行，擔心影響性能，出現內存泄露，并且死循環不能是“死的”，需要提供可以控制的能力，可以停止執行，這可以用文件鎖/配置/信號處理之類的來做到。不能強行的對處理程序做“熱插拔”，否則如果再處理重要任務時異常中斷就可能會出現意外。 還要有監控的能力，知道程序是否執行了，最后的執行時間，執行日志等。 所以兩種方法各有優點和缺點，如果取其中間，調用&程序內循環，增加調用間隔，循環增加限制（可以是執行時間，也可以是循環次數），超過自動退出。 記住任何時候，最好的就是最合適的。 [隊列的思考 · php筆記 · 看云](http://www.hmoore.net/xiak/php-node/504497) > 可以在控制器方法中啟動隊列監聽，這樣整個生命周期就只有一次框架環境實例了，但是配置文件的更改，任務的修改可能得不到更新，因為已經引入內存中了，所以當配置或任務文件更改后需重新重啟監聽。 * * * * * ### 擴展 - [原創 | 消息中間件的工作原理和RabbitMQ入門](https://mp.weixin.qq.com/s/r8k1TN46Pk61qTjZ8ljsEQ) - [think-queue隊列這個怎么用呢](http://www.thinkphp.cn/topic/42388.html) - [thinkphp-queue 筆記](https://github.com/coolseven/notes/blob/master/thinkphp-queue/README.md) - [php調用外部exe程序-CSDN論壇](http://bbs.csdn.net/topics/390270857) - [PHP調用外部程序的方法](http://blog.csdn.net/whatday/article/details/54880851) - [PHP在linux上執行外部命令](http://www.cnblogs.com/wumingcong/p/5899046.html) - [消息隊列 云消息 訂閱管理監控 分布式應用-阿里云](https://www.aliyun.com/product/ons) - [1分鐘實現“延遲消息”功能 - 架構師之路 | 十條](http://www.10tiao.com/html/249/201703/2651959961/1.html) > 這里把我想到的幾個問題全部說出來了，“后知后覺”的問題，和重復執行的問題，還是做架構的人牛逼，哈哈。 - [深入理解php底層：php生命周期](http://blog.csdn.net/hguisu/article/details/7377520) - [Python3之多進程](http://www.toutiao.com/a6439858194382962945/?tt_from=weixin&utm_campaign=client_share&app=news_article&utm_source=weixin&iid=11683717705&utm_medium=toutiao_android&wxshare_count=1) - [進程與線程的一個簡單解釋 - 阮一峰的網絡日志](http://www.ruanyifeng.com/blog/2013/04/processes_and_threads.html) - [Linux 守護進程的啟動方法 - 阮一峰的網絡日志](http://www.ruanyifeng.com/blog/2016/02/linux-daemon.html) - [極客漫畫：不要使用 SIGKILL 的原因（看哭了）](http://www.toutiao.com/a6454826726273843726/?tt_from=weixin&app=news_article&iid=12619555732&wxshare_count=1) - [關于PHP連接處理中set_time_limit()、connection_status()和ignore_user_abort()深入解析 - 很多時候，你缺少的不是知識而是熱情 - CSDN博客](http://blog.csdn.net/jiao_fuyou/article/details/17138057) ~~~ php種也是一樣，默認`ignore_user_abort(false)`也沒有給代碼處理后續工作的機會，但是`register_shutdown_function()`可以做一些收尾工作（比如日志保存之類的，不過也不能優雅的控制代碼中進程回收問題）。 ~~~ - [【rabbitMQ 用法】 - Hongyang - CSDN博客](http://blog.csdn.net/lmj623565791/article/category/2386657) - [「服務器」RabbitMQ入門教程——簡介及工作原理](https://www.toutiao.com/a6512994463378309645/?tt_from=weixin&utm_campaign=client_share&timestamp=1516444347&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1) - [計算機底層知識拾遺（四）理解文件系統 - zdy0_2004的專欄 - CSDN博客](http://blog.csdn.net/zdy0_2004/article/details/44259313) [Q新聞丨Go 語言排行飆升至前十；GitHub 已切換到 Kubernetes；陸奇最新內部演講：如何成為一個優秀的工程師？](http://mp.weixin.qq.com/s/pboTbWevEWoN2FJEQgtcKA) ~~~ 默默維護 30 年，glibc 創始人兼維護者辭職 GNU C library (glibc) 項目原作者兼維護者 Roland McGrath 宣布辭職和退出該項目，原因與家庭或其它問題無關，而是因為 30 年了該放手了。1980 年代，Roland 當時還是一名十多歲的青少年，他在為自由軟件基金會工作期間開發了最早的 C 函數庫。 他在郵件列表上表示，他過去幾個月故意保持沉默，不回應任何郵件，看看這個項目還需不需要他這位維護者，結果證明 glibc 項目沒有他仍然能繼續前進，因此他決定辭職和不再直接參與 glibc。今年夏天將迎來 glibc 誕生三十周年的紀念。Roland 對所有幫助和參與 glibc 項目的人表示感謝，稱有許多人對項目做出的貢獻比他更大。 ~~~ [在WordPress中使用wp-cron插件來設置定時任務](http://www.jb51.net/article/76183.htm) [PHP實現執行定時任務的幾種思路詳解 - Web烤貓 - SegmentFault](https://segmentfault.com/a/1190000002955509) [基于Laravel Task-Scheduler定時發送郵件小程序 - 來生做個漫畫家 - SegmentFault](https://segmentfault.com/a/1190000005057786) [Laravel 5.2 文檔 服務 —— 任務調度 – Laravel學院](http://laravelacademy.org/post/3267.html) [詳解PHP實現定時任務的五種方法_php技巧_腳本之家](http://www.thinkphp.cn/topic/42571.html) > 定時運行任務對于一個網站來說，是一個比較重要的任務，比如定時發布文檔，定時清理垃圾信息等，現在的網站大多數都是采用PHP動態語言開發的，而對于PHP的實現決定了它沒有Java和.Net這種AppServer的概念，而http協議是一個無狀態的協議，PHP只能被用戶觸發，被調用，調用后會自動退出內存，沒有常駐內存。 [PHP 實現定時任務的幾種方法 - ThinkPHP框架](http://www.thinkphp.cn/topic/42571.html) [PHP實現定時任務的幾種方式-PHPChina開發者社區-權威的PHP中文社區](http://www.phpchina.com/portal.php?mod=view&aid=41051) [php 定時任務_百度搜索](https://www.baidu.com/s?wd=php+%E5%AE%9A%E6%97%B6%E4%BB%BB%E5%8A%A1&ie=utf-8&rsv_cq=php+%E5%8D%95%E4%BE%8B&rsv_dl=0_right_recommends_20807&euri=5c209d60170a7167991896a99f87be1f) * * * * * ### 思考、求證、求問 進程通信，事件回調，事件通知，計算機內部難道就是個“死循環”實現的嗎，只不過是優化的“死循環”而已，本質還是“死循環”，如果這樣，那么真正意義上的【實時】其實根本就不存在了啊，看來這些東西需要了解計算機的原理，系統底層，內核才能真正理解，窺見程序的魅力啊。（注意這里的引號，真正的死循環是不可控的，也就是BUG） 參考：[究竟能不能用死循環？或者其實我們就活在一個死循環的世界中？](https://segmentfault.com/q/1010000009586182) > 死循環不如說元循環和其他循環一樣有始有終，只不過其他循環是元循環的一段，走過就沒了，死循環走過了回到了原點。 ***** #### 什么是實時？ 實時是指兩個對象，發送者，響應者，發送者發出消息后，響應者立即/同時得到信息，這就是實時。可以說事件發生時間與消息接收時間是同一時刻（兩個事件同時發生）。 那么計算機的實時是怎么樣的呢？ 我們知道時間刻度是可以無限細分的，也就是不存在絕對的，只有相對的。 而理論上電路的通斷，處理是需要時間的，只不過很短。（可以想象你按下燈泡開關，到亮燈的例子，你認為燈泡通電和你按下開關是不是同時的） 所以真正的實時，從技術上來說，計算機應該無法做到。 軟件無法實現實時，軟件的實時反饋其實本質也是來自于硬件的，比如硬盤磁頭已經準備好了，網卡收發數據完畢了等等。 **任何事物都不能脫離它所存在的環境而存在。** 但是大多時候，我們可以認為它是實時的，至少對我們感覺上來說是實時的。 因為我們的大腦是需要反應時間的，即使簡單的膝跳反應，神經反應也是需要時間的，比如如果人的反應在100ms左右，那么只要在100ms左右的反應，我們人都可以認為是實時的，因為再快的話，人的大腦也捕捉不到，就沒有意義了。所以是否真正的實時，對我們來說并不需要糾結，繼續鉆牛角尖糾結沒有意義。 所以很多東西都是相對的，要結合人去看待其它事物，以人為本。  > 生活中也有同步/同時的例子，比如電機內部齒輪上的那個皮帶（套在兩個齒輪上），叫做同步帶，顯然，一個齒輪轉動時通過同步帶來帶動另一個齒輪轉動，兩個齒輪是同時，同步轉動的。 >[danger] **同步帶 是現在我唯一能找到的，可以證明兩個事件是同時發生（并行）的案列。** （你還知道哪些其它生動的例子，期待你的留言！） [用世界上最強的電子顯微鏡看原子 簡直大開眼界](https://www.365yg.com/a6554838150886195726) [0.999…=1嗎？無窮小量的數學史_嗶哩嗶哩 (゜-゜)つロ 干杯~-bilibili](https://www.bilibili.com/video/av43969456) * * * * * [你手機CPU到底如何工作的！科普手機內部CPU工作原理！ - 今日頭條](http://www.365yg.com/item/6456519526136676878/) [你知道CPU是如何工作的？ - 今日頭條](http://www.365yg.com/item/6414455349574631937/) CPU就是一個死循環，里面有一個時鐘，按照一個固定頻率通斷電路（每隔一段時間做某件事），這個頻率就是CPU的主頻，單位為赫茲。所以本質其實就是一個死循環。 * * * * * [你必須理解的計算機核心概念](https://mp.weixin.qq.com/s/XmHhlZzpYbJWW_m5NMPqEw) [一文告訴你什么是實時操作系統？就連Windows也不是實時操作系統](http://www.toutiao.com/a6434715971818651906/) [深入實時 Linux](http://www.toutiao.com/a6445229605447975182/) [怎么去證明兩個是事件是在同一時刻發生的？](https://segmentfault.com/q/1010000009908203) [普朗克時間_百度百科](https://baike.baidu.com/item/普朗克時間/2429708?fr=aladdin) [普朗克長度和普朗克時間的存在是否意味這個宇宙可能是虛擬的？ - 知乎](https://www.zhihu.com/question/29294919) [同時性_互動百科](http://www.baike.com/wiki/同時性) 任何東西都是相對的，世界上的任何事情都是相對的，沒有絕對的，你覺得一秒鐘過得有多快，樹懶的一秒鐘又有多慢，哈哈哈哈。 [Facebook“發明”了新的時間單位：1秒=705600000 Flicks](https://www.toutiao.com/a6514077852609020423/?tt_from=weixin&utm_campaign=client_share&timestamp=1516906187&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1) ~~~ Q：怎么證明兩個事件是同時發生的，或者說，時間的最小刻度是多少？ A：普朗克時間，是指時間量子間的最小間隔，即普朗克時間，為 1E－43秒（即10^-43s)。沒有比這更短的時間存在。普朗克時間=普朗克長度/光速。（注：1普朗克時=0.0000000000000000000000000000000000000000001秒） （理論上存在，實際上卻無法證明，那就只有出一個標準了，這個標準若要所有人信服，就必須是當前人類認知的極限 —— 量子） ----------- Q：關燈后，燈光到哪里去了？ A：光是電子/原子躍遷時釋放能量時產生的光子，關燈以后，光子被屋子里的環境所吸收了，如果你小時候玩過會發夜光的玩具你就明白了，小時候我們把夜光玩具放在燈光下照，然后關燈后就可以在躲在被窩里面樂呵了。 ---------- Q：光速是不是宇宙中最快的？ A：是，也不是。在人類已知的宇宙中，光速是最快的，不過量子學打破了這一理論，還有超光速和快子的存在，其速度遠大于光速，不過由于無法實驗證明它，所以無法確定，畢竟這超出了宇宙的因果關系，而宇宙也是我們認知的一撇而已。 ~~~ http://www.ruanyifeng.com/blog/2020/10/weekly-issue-130.html > 德國科學家發現迄今為止最短的時間：光穿過一個氫分子耗時為10-21秒。 * * * * * **php的運行模式和生命周期** [Laravel的核心概念 - SegmentFault](https://segmentfault.com/p/1210000007162144) [為什么Swoole可以加速php - daryl的技術天地 - SegmentFault](https://segmentfault.com/a/1190000009486485) * * * * * [關于PHP協程與阻塞的思考](http://mp.weixin.qq.com/s/WxcP_ghWyY3kWoPi_8dC8w) * * * * * [linux kill php進程，對PHP的生命周期產生怎樣的影響？](https://segmentfault.com/q/1010000005030126) 題主如果是想控制php的死循環，不想用命令行，也不想用信號，那么通過“配置”也是可以做到的，配置可以是文件，可以數據庫存儲的值，相當于開關： 開始時間 = 當前時間 生命周期時間 = 300 ~~~php while(ture) { if task.lock 不存在 退出 else 執行業務邏輯 } ~~~ 題外話：其實這種循環是可控的，不是真正的死循環，就算是真正的死循環可能也是有作用的（如事件循環），如果無法控制的死循環，意外造成的死循環，那才是真正的BUG，所以以前學校老師說：“不要寫出死循環代碼，那是最嚴重的BUG，會消耗完機器內存”，那句話其實不嚴謹！ * * * * * [為什么Socket被翻譯為“套接字”？ - 簡書](http://www.jianshu.com/p/2515266051ea) > 服務器就像一個大插排，包含很多插座，客戶端就是像一個插頭，每一個線程代表一條電線，客戶端將電線的插頭插到服務器插排上對應的插座上，就可以開始通信了。 [Http Server ： 一個差生的逆襲](http://mp.weixin.qq.com/s/WO2GuaUCtvUFWIupgpWcbg) [互聯網為什么要提供套接字？-痞子高的回答-悟空問答](https://www.wukong.com/answer/6486678019279683854/?iid=12619555732&app=news_article&share_ansid=6486678019279683854&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share) * * * * * **圖靈是完備的，函數是一等公民。** [什么是圖靈完備？ - 知乎](https://www.zhihu.com/question/20115374) [2017 年你應該學習一下下函數式編程 - 知乎專欄](https://zhuanlan.zhihu.com/p/26608727) * * * * * **記錄** 隊列說到底關鍵的就是要消費任務，而任務一定是存在某個地方被消費者取出來消費執行的，如果想要提高處理大量任務的速度，就必須增加消費的工人數量。 那么問題就來了： 1. 任務儲存在哪里效率高？ 2. 如何解決多工人進程取任務時出現重復取出了，造成任務被重復執行了，也就是并發問題？ ~~~ 1. 取出一條任務 2. 執行任務 3. 標記該任務被處理 如何避免消費工人的并發問題 ~~~ 其實問題就出在取任務的地方，拿MySQL來說，如果用鎖的話，那么就變成串行了，多個工人就完全沒有意義了。 如果不用鎖的話，可以 id / n 取整的方式處理任務（n為工人數量），這樣可以解決并發問題，但是需要保證任務id的連續性和唯一性，并且當工人數量變動時，需要關閉系統，再重啟隊列系統，否則中途改變工人數量會導致任務分配混亂 **（因為在任何時候，一個正在運行的系統是動態的，有任務當前正在執行，而系統無法知道是哪些任務，所以在貿然一個正在運行的動態的系統中做任何操作都是危險的）。** 如果用redis來做是不是能完美解決這個問題呢，也就是取任務的問題呢，redis是怎么取的呢？ 待分析…… 2017-8-18 00:31:55 * * * * * ### 隊列總結 **隊列主要的難點問題：** 1. 消息存要高效 2. 怎么監聽到有新的消息來了？（事實上并不能監聽到新消息來了，沒有那么智能，只能用蠢辦法，死循環，好吧我不說“死循環了”，就說循環，或者是無限循環，可控的循環吧） 3. 怎么安全高效的取消息（安全：多工人，也就是多進程取消息時不會出現重復取消息，不然如果是轉賬的消息，如果出現重復執行的話，多次轉賬，那就完蛋了，還有執行完畢后，消息應該標記為已處理，并且任務處理失敗的話，要記錄日志和狀態等詳細信息，以便于加到重試隊列或者有其它作用；高效：取消息效率必須要高，不能出現select那種掃表，如果循環掃表的話那就很悲催） 4. 怎么管理，常駐工人進程（怎么啟動維護后臺常駐程序，怎么有效的管理多工人進程，比如工人數量的增減同時還要保證服務正確，不會錯亂） 5. 怎么高效的讓工人根據消息內容找到任務執行者，并讓它執行。（一般任務執行者和工人是部署在同一個服務器的，任務執行者因為可能需要DB操作，或者其它操作，所以最好是保證和我們框架是一樣的環境，怎么讓它在框架的cli環境下執行，并且要高效，因為如果和web訪問模式一樣每次訪問都要走一遍框架的初始化流程，那效率就太低了，所以要改變這種模式，讓框架環境只初始化一次，讓任務執行者在里面執行就可以了。） **通過對隊列的分析，我們看到要做好隊列服務，至少5個有以上的難點需要思考和解決的。** [聊架構：使用Redis隊列解決商品數據大批量上傳問題](http://www.toutiao.com/a6399982285475938561/?tt_from=weixin&utm_campaign=client_share&app=news_article&utm_source=weixin&iid=12619555732&utm_medium=toutiao_android&wxshare_count=1) [Apache Kafka：下一代分布式消息系統](http://www.infoq.com/cn/articles/apache-kafka) * * * * * [Raft 為什么是更易理解的分布式一致性算法 - mindwind - 博客園](http://www.cnblogs.com/mindwind/p/5231986.html) [raft算法與paxos算法相比有什么優勢，使用場景有什么差異？ - 知乎](https://www.zhihu.com/question/36648084) [春晚搶微信紅包如何實現 - 騰訊云分布式消息隊列CMQ架構](http://www.toutiao.com/a6333075051169399041/?tt_from=weixin&utm_campaign=client_share&app=news_article&utm_source=weixin&iid=12619555732&utm_medium=toutiao_android&wxshare_count=1) * * * * * last update：2017-9-11 15:12:49 * * * * * **Redis為隊列存取而生** Redis實現隊列重要的一點解決了存和取的問題，存很快，取彈出隊列（`blpop: 客戶端阻塞直到隊列有值輸出`），注意是**阻塞彈出隊列的，即阻塞取消息的**，這意味著多工人進程也沒事，多工人時不會出現重復取消息，不會出現并發問題，是安全的，這就方便多了，要是用mysql存消息，為了防止并發問題，保證不會出現重復取消息，那處理起來就麻煩多了，需要開啟事務用鎖，每次limit 1，掃表，多進程間的鎖等待，真是不敢想象的恐怖，超級超級的低效率。所以Redis真爽，一下子就解決了隊列中最頭痛的問題，簡直是為隊列消息存取而生的。 [Redis 實現隊列 · php筆記 · 看云](http://www.hmoore.net/xiak/php-node/399425) last update：2017-9-9 18:43:02 * * * * * [從Timer類源碼分析，猜想今日頭條的取消推薦文章的技術實現](https://www.toutiao.com/i6488636316970910222/?tt_from=weixin&utm_campaign=client_share&app=news_article&utm_source=weixin&iid=12619555732&utm_medium=toutiao_android&wxshare_count=1) > 你那個死循環合不合適啊 * * * * * **沒錯就是“死循環”（無限循環）** [張大胖的socket - 碼農翻身](http://mp.weixin.qq.com/s/XmWVy2ARauSBoehygs4Zvw)  * * * * * [到底什么時候該使用MQ？](http://mp.weixin.qq.com/s/LqViglTO_h8UJqi3aD6P6w) [MQ，互聯網架構解耦神器](http://mp.weixin.qq.com/s/2PFd4xQ9F9S_9g23WtyFGw) * * * * * [redis 隊列應用實例](https://segmentfault.com/q/1010000011410596) ~~~ 1 : 你說的有點忽悠人，其實就是死循環，或者說是無限循環，可控的循環吧。有消息就一直循環不等待，無消息就控制一下循環的頻率，睡眠5秒鐘繼續循環。 阻塞是redis客戶端取消息的原子操作，這個是redis保證的，這樣就不會出現多進程重復消費消息的問題了。不過你要理解最終在redis中是原子操作的，也就是串行的。 至于消費失敗的情況，可以做一個記錄，記錄失敗的消息，再根據情況，比如重試機制。 php有一個來源的隊列庫。以上就是從那里分析來的。 當然還有更好的商用隊列產品，這個就不細說了。 ~~~ [消息隊列應用場景 - 13070113 - 博客園](http://www.cnblogs.com/stopfalling/p/5375492.html) > 按照以上約定，用戶的響應時間相當于是注冊信息寫入數據庫的時間，也就是50毫秒。**注冊郵件，發送短信寫入消息隊列后，直接返回，<span style="color:red;">因為寫入消息隊列的速度很快，基本可以忽略</span>**，因此用戶的響應時間可能是50毫秒。因此架構改變后，系統的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。 [消息隊列使用的四種場景 - CSDN博客](https://blog.csdn.net/ntotl/article/details/72765713)（原文） * * * * * [重磅資料！Github上的PHP資源匯總大全 - 資訊/編程 - 極思維](http://www.topthink.com/topic/8309.html) **隊列** ——處理事件和任務隊列的庫 [Pheanstalk](https://github.com/pda/pheanstalk):?一個Beanstalkd客戶端庫 [PHP?AMQP](https://github.com/videlalvaro/php-amqplib):?一個純PHP?AMQP庫 [Thumper](https://github.com/videlalvaro/Thumper):?一個RabbitMQ模式庫 [Bernard](https://github.com/bernardphp/bernard):?一個多后端的抽象庫 [php-amqplib/php-amqplib: The most widely used PHP client for RabbitMQ](https://github.com/php-amqplib/php-amqplib) [php-amqplib/Thumper: PHP Library that implements several messaging patterns for RabbitMQ](https://github.com/php-amqplib/Thumper) [pda/pheanstalk: PHP client for beanstalkd queue](https://github.com/pda/pheanstalk) [beanstalkd首頁、文檔和下載 - 輕量級消息隊列 - 開源中國社區](http://www.oschina.net/p/beanstalkd) [kr/beanstalkd: Beanstalk is a simple, fast work queue.](https://github.com/kr/beanstalkd) * * * * * [為什么使用mq？-淮安二傻子的回答-悟空問答](https://www.wukong.com/answer/6481088357995643150/?iid=12619555732&app=news_article&share_ansid=6480998431820087566&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share) * * * * * >[danger] MQ其實也是一種異步編程模型的實現方式，它解耦了相互獨立的業務模型。 * * * * * [2.7 消息隊列 - 51CTO.COM](http://book.51cto.com/art/201412/462303.htm) 消息隊列對電商平臺特別是大型電商平臺來說是不可或缺的部分，電商平臺中的眾多操作，如郵件發送、短信發送、商品屬性更改后需要通知各類促銷模塊，以及執行時間較長的insert/update/delete等，這些操作如果在小型站點中使用同步方式處理姑且可以容忍，但在大型平臺中，由于用戶量、訪問量特別大，使用同步處理會造成站點的堵塞，用戶可能需要等待很長時間，有的甚至會直接超時。但如果只是簡單將操作都改成js異步觸發，同樣不是很好的解決辦法，用戶需要發出js請求并等待返回，大量異步js請求同樣會造成系統的壓力猛增，直至堵塞，所以將這些費時但又不需要立刻完成的請求放入一個隊列中，然后由隊列來執行這些任務，在將任務放入隊列后，用戶不需要等待任務的執行，而是繼續進行下面的操作，這樣極大提高了用戶體驗。 * * * * * 分布式、鎖、一致性、調度、隊列、延時、Broker、task、worker、…… ***** [消息隊列 - 如何實現php的異步任務隊列 - SegmentFault 思否](https://segmentfault.com/q/1010000000186204) [請教PHP+Redis實現任務隊列的思路 - SegmentFault 思否](https://segmentfault.com/q/1010000007207389) ```php // 堵塞等待隊列中第一個和$uuid匹配的(到我了) while($uuid != $redis->lGet($tsk_name, 0)){ if((time()-$time_start)> $time_out) { break; // 超時跳出(某些原因隊列異常了, 可能永遠取不到) } usleep(10); // sleep 10ms, 再次嘗試 } ``` >[tip] 阻塞獲取就沒問題（沒有數據會阻塞著不返回，當有數據了就馬上返回），如果沒有這點的話，那和傳統那樣一直循環查詢有什么區別，那樣性能太低了，就沒什么意義了。 ***** ### 開源項目 [resque/php-resque: An implementation of Resque in PHP.](https://github.com/resque/php-resque) >[tip] Package chrisboulton/php-resque is abandoned, you should avoid using it. Use resque/php-resque instead. [一個簡單的定時任務 · Thinkphp5.1學習筆記 · 看云](http://www.hmoore.net/hideblue/thinkphpnotebook/853526) > 邏輯代碼中，請不要使用exit、die、sleep語句 [定時任務調度系統 opencron](https://www.toutiao.com/a6622156995799548419/) [Quartz使用總結 - 路邊飛 - 博客園](https://www.cnblogs.com/drift-ice/p/3817269.html) > Quartz就是來干這樣的事,你給它一個觸發條件的定義,它負責到了時間點,觸發相應的Job起來干活。 [pheanstalk/pheanstalk: PHP client for beanstalkd queue](https://github.com/pheanstalk/pheanstalk) [beanstalkd/beanstalkd: Beanstalk is a simple, fast work queue.](https://github.com/beanstalkd/beanstalkd) [有贊延遲隊列設計](https://tech.youzan.com/queuing_delay/) [mysql - PHP定時通知、按時發布怎么做？ - SegmentFault 思否](https://segmentfault.com/q/1010000009508176?_ea=4975839) [chenlinzhong/php-delayqueue: 基于redis實現高可用，易拓展，接入方便的延遲隊列](https://github.com/chenlinzhong/php-delayqueue) [Kafka中的時間輪算法](https://mp.weixin.qq.com/s/DDfPQgxDQz814BYB-LfzdA) > 我覺得可以寫多個輪子，一個放一分鐘內要執行的任務，每秒檢查一次，一個放一個小時內要執行的任務，每個分鐘檢查一次，以此類推，一百年的任務也只要 60+24+365+100，內存完全沒問題。不過我好奇的是怎么寫這個定時檢測的代碼…… 1 作者 > 起一個定時器去掃就行了 [PHP: Queue - Manual](http://php.net/manual/zh/class.ds-queue.php) [resque/resque: Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later.](https://github.com/resque/resque) [chrisboulton/php-resque: PHP port of resque (Workers and Queueing)](https://github.com/chrisboulton/php-resque) [tangshuang/php-cron: 實現PHP Cron，也就是PHP定時任務，通過本地文件記錄schedules，然后通過fsockopen實現非阻塞式的后臺訪問對應的url來實現定時任務，通過sleep實現定時，如果錯過任務，則通過用戶訪問來執行該任務（還未完善）](https://github.com/tangshuang/php-cron) [lisijie/webcron: 定時任務管理器](https://github.com/lisijie/webcron) [kcloze/queueSwoole: 基于swoole的微型框架，適合于高并發場景下的搶購／秒殺業務場景](https://github.com/kcloze/queueSwoole) [yunwuxin/think-cron: 計劃任務 for thinkphp5](https://github.com/yunwuxin/think-cron) [notes/README.md at master · coolseven/notes](https://github.com/coolseven/notes/blob/master/thinkphp-queue/README.md) [huyanping/php_crontab: A crontab written in PHP based on pcntl and react/event-loop](https://github.com/huyanping/php_crontab) [mawenpei/swoole-crontab: 基于swool實現的crontab,兼容linux的crontab格式,并且支持秒級](https://github.com/mawenpei/swoole-crontab) [xuxueli/xxl-job: A lightweight distributed task scheduling framework.（分布式任務調度平臺XXL-JOB）](https://github.com/xuxueli/xxl-job) [kohkimakimoto/workerphp: A PHP micro job scheduler framework like cron.](https://github.com/kohkimakimoto/workerphp) [jobbyphp/jobby: Manage all your cron jobs without modifying crontab. Handles locking, logging, error emails, and more.](https://github.com/jobbyphp/jobby) [george518/PPGo_Job: 定時任務管理-支持多臺服務器](https://github.com/george518/PPGo_Job) [Automattic/kue: Kue is a priority job queue backed by redis, built for node.js.](https://github.com/Automattic/kue) [symfony/process: The Process component executes commands in sub-processes.](https://github.com/symfony/process) [php + Laravel 實現部署自動化](http://mp.weixin.qq.com/s/qZGVdNtCJOycR_sye9az6w) [qq8044023/taskPHP: taskPHP基于原生態php開發的定時計劃任務框架,利用多進程實現任務的分配和運行,利用原生態php內存共享實現進程間通信,支持linux和windows。有較好的伸縮性、擴展性、健壯穩定性而被多家公司使用，同時也希望開源愛好者一起貢獻。](https://github.com/qq8044023/taskPHP) [top-think/think-worker: ThinkPHP5 Workerman extend](https://github.com/top-think/think-worker) [justlive1/earth-frost: 分布式任務調度框架](https://gitee.com/justlive1/earth-frost?from=20180429) [SegmentFault/SimpleFork: 一個最精簡的php多進程控制庫](https://github.com/SegmentFault/SimpleFork) [從0到1優雅的實現PHP多進程管理 - 掘金](https://juejin.im/post/5a1ff1396fb9a0451704fb42) [\[Node\]\[Agenda\]Node Agenda 中文文檔 定時任務調度系統\[基礎篇\] - CSDN博客](https://blog.csdn.net/github_36749622/article/details/76595489) [Redis 還能做實時訂閱推送功能？原諒我無知...--文末送書](https://mp.weixin.qq.com/s/ECvC9-sMv94ce4Hw3HSZhA) [實戰：消息中間件，解耦、異步、削峰，到底該如何使用](https://mp.weixin.qq.com/s/jswWojRQkXgHraEZeIntlg) [分布式調度框架Quartz衍生出的三種任務類型，你用過幾個？](https://mp.weixin.qq.com/s/j7iA0nPCK94HFUpgekRTJg) [究竟什么時候該使用MQ？](https://mp.weixin.qq.com/s/_kXoRBAotb4GXoDTqTObYQ) [Sprint Boot如何基于Redis發布訂閱實現異步消息系統的同步調用？](https://mp.weixin.qq.com/s/7C1noGWEUFNArhrGzVUFDA) [為了kafka概念掃盲,寫了萬字長文(我看完吐了)](https://mp.weixin.qq.com/s/M8V77F4Fc4bhOm_LP5YjCQ) [一般電商應用的訂單隊列架構思想](https://mp.weixin.qq.com/s/ZTrBQwKjdoK_OMackUX1Qw) [「ThinkPHP開發者周刊」第39期——消息隊列](http://www.hmoore.net/thinkphp/weekly/1173591) [淺談redission以及Redis分布式鎖探索入門](https://mp.weixin.qq.com/s/noIpTGWeRFBqK1pPltDtVA) [網易云音樂的消息隊列改造之路](https://mp.weixin.qq.com/s/Q48LvBZaoBRP5Y5NIG7upA) [同樣是消息隊列，為什么Kafka這么快？](https://mp.weixin.qq.com/s/5pPjUOfAH6IN7cXMgMvoKw) [從這個角度，我終于理解為什么需要Kafka這樣的東西了!](https://mp.weixin.qq.com/s/ghFDVMCacgYuTcG5klxTiw) [Python 源碼分析：queue 隊列模塊](https://mp.weixin.qq.com/s/_TxlIF037dlTphYae2GcWw) [經典得不能再經典的分布式服務和消息隊列面試題](https://mp.weixin.qq.com/s/OUt077Y4INNn_Q-3cjWxOA) [Java并發編程之阻塞隊列](https://mp.weixin.qq.com/s/6XXpPykDtFfnAgnEXrZLKA) > 消息被消費的順序性不能依賴于隊列系統，最好在業務里面解決掉 > 隊列的brck和任務調度器對業務系統來說都屬于第三方，不能依賴于它 [關于消息隊列的思考](https://mp.weixin.qq.com/s/g5Qq_gasJbDFVfOYkZaPcg) > Message Broker 可能不可靠，但是任務消費的狀態記錄必須可靠，這才是實現最終一致性的保證。 [五分鐘入門消息中間件](https://mp.weixin.qq.com/s/AQDmjICPmwbR_t9ayOsdkw) [1分鐘實現“延遲消息”功能](https://mp.weixin.qq.com/s/eDMV25YqCPYjxQG-dvqSqQ) [世上最全的RabbitMQ-總結](https://mp.weixin.qq.com/s/0cX6o3QVygxhOTK4uxWFPw) [如何快速實現“延時消息”？](https://mp.weixin.qq.com/s/9qt3JEvjv1wka57GBTng9g) [定時和延時問題在業務場景中的常見處理](https://mp.weixin.qq.com/s/2hvuI4z1HXZ6EFqKTkTGiA) [我所知道的數據結構之隊列](https://mp.weixin.qq.com/s/0p4oovNTtUsqV9SvUQHuyA) [非常強悍的 RabbitMQ 總結，寫得真好！](https://mp.weixin.qq.com/s/Xx2A9-EGHgQtLg8MyCiB-Q) [RabbitMQ 七戰 Kafka，五勝二負，差異立現！](https://mp.weixin.qq.com/s/c_o5HIsQKVQmC6aiCtU8bg) * * * * * ### 相關課程 [PHP消息隊列實現及應用-慕課網](https://www.imooc.com/learn/852) [Beanstalkd-帶你玩轉消息隊列-慕課網](https://www.imooc.com/learn/912) [php+mysql 模擬隊列發送郵件-慕課網](https://www.imooc.com/learn/721) [Redis課程簡介，Redis的Lua腳本編程教程-慕課網](https://www.imooc.com/learn/1039) [redis計數器與數量控制](http://www.imooc.com/learn/1067) [開源消息隊列QMQ的設計與實現理念](https://mp.weixin.qq.com/s/Jz8OXPHnC3Cs22vPubZ9pQ) [MQ消息隊列應用場景比較介紹](https://mp.weixin.qq.com/s/pq9wCA-IL2SWixoJikeSxw) [Kafka基本原理](https://mp.weixin.qq.com/s/t_NGK7WY6FygCdWoayUHZQ) [【消息隊列 MQ 專欄】消息隊列之 RabbitMQ —— 集群原理與搭建篇](https://mp.weixin.qq.com/s/lvXwN-KejP2KrRLEOh-Q8w) [【消息隊列 MQ 專欄】RabbitMQ](https://mp.weixin.qq.com/s/F2XTL9QFO0P4zNDExMx6Cg) [【系統架構】聊聊開源消息中間件的架構和原理](https://mp.weixin.qq.com/s/NwjYJde9_TC4PXMPpYw1Gw) [網站架構之消息隊列(MQ)簡述](http://toutiao.com/group/6552863131087929864/?iid=31395168747&app=news_article_lite&timestamp=1525748634&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share) > 請求 治標不治本 [消息隊列背后的設計思想](https://mp.weixin.qq.com/s/k8sA6XPrp80JiNbuwKaVfg) [面試官：給我一個避免消息重復消費的解決方案？](https://mp.weixin.qq.com/s/xW8vjzmrGZ-yNYdPsiACsQ) ***** [阿里云免費套餐-企業版](https://free.aliyun.com/?open_id=928e888d-52df-40e3-ac87-a1360365866d-37062509&open_cid=910)（試用隊列） * * * * * last update：2018-2-6 15:08:27