提高系統運行效率，從應用程序通信做起。當前流行的互聯網平台由多個分布式應用程序串連，它們就像流水線一樣處理數據，產能的高低受制於流水線的運轉速度。以前人們使用掃描數據庫的方式來交互，即承擔流水線職責是數據庫，顯然數據庫應該承擔的是倉庫職責。每個生產環節都不停的跑到倉庫去詢問，有沒有它要加工的產品，倉庫的壓力可想而知，生產效率可想而知。沒有工廠會這樣運行，但你的項目就這樣干過。
我們需要在各應用程序間建立有效的通信機制來承擔流水線的職責，去掉輪詢將會有效降低數據庫的壓力。輪詢帶來的弊端有：
1. 硬件資源投入隨着用戶的增加成比例上升。工廠要生產更多的商品，廠長就得增加更多的倉庫來服務，否則倉庫會由於壓力太大而崩潰。但由於流水線本身的運轉速度不夠，投入產出比太低。
2. 穩定性不足，可靠性不夠。訂單多的時候倉庫忙不過來，沒訂單的時候倉庫也沒閑着，盡管這時候倉庫里沒貨也有很多人來問。同時，為了防止不同流水線拿錯商品，倉庫還要做好登記，標明哪個商品在哪條流水線生產。受制於此，產能極易受到波動，一點小小的沖擊可能造成災難性的后果。
3. 結構復雜，維護困難，難以滿足靈活多變的業務需求。某天市場部門收到新產品的訂單，需要培訓新的生產工人，倉庫也需要為此做出改變，並增加更多的倉庫，牽一發動全身，難以按時交貨。好不容易頂住壓力完成交貨，卻由於質量不高客戶怨聲載道。新產品市場反應不好，不再有訂單需要生產，剛投入的資源需要全部收回。笨重的生產流程難以適應市場需求，我們需要靈活、高效、可靠的生產線。
如何能拋棄輪詢的機制，讓信息高效傳遞呢? 數據量大，實時性要求高是互聯網系統的重要特點，技術團隊需要有所創新和改變，敢於直面用戶需求。
如果各應用程序依靠輪詢數據庫來傳遞消息，模塊A做完后將數據寫入數據庫，模塊B通過輪詢數據庫來確定模塊A已經完成，它看起來就像這樣：
我們想要的結果是下圖這樣, 但數據庫不能做到。因為數據庫顧名思義就是保存數據的地方，消息通信不是它的職責。
有沒有可能讓信息主動傳遞呢？如果不用數據庫呢？如果使用消息呢？YES，它就是我們想要的。
如此調整之后將有效降低數據庫的負載，結構優雅高效，提高了穩定性，降低無謂的資源消耗。調整后各組件職責更為明確，做組件擅長的事情。數據庫負責持久化數據、Redis負責緩存熱數據、MQ負責在應用程序間傳遞消息。
流水線上一環節生產的半成品直接交給下一環節再加工，提高了工人效率，解放了倉庫保管員，市場部不再抱怨生產部了，這才是真正的流水線。