問：站點與服務，服務與服務上下游之間，一般如何通訊？
答：有兩種常見的方式
一種是「直接呼叫」，通過rpc框架，上游直接呼叫下游。
在某些業務場景之下（具體哪些業務場景，見《到底什麼時候該使用mq？》），可以採用「mq推送」，上游將訊息發給mq，mq將訊息推送給下游。
問：為什麼會有流量衝擊？
答：不管採用「直接呼叫」還是「mq推送」，都有乙個缺點，下游訊息接收方無法控制到達自己的流量，如果呼叫方不限速，很有可能把下游壓垮。
舉個栗子，秒殺業務：
上游發起下單操作
下游完成秒殺業務邏輯（庫存檢查，庫存凍結，餘額檢查，餘額凍結，訂單生成，餘額扣減，庫存扣減，生成流水，餘額解凍，庫存解凍）
上游下單業務簡單，每秒發起了10000個請求，下游秒殺業務複雜，每秒只能處理2000個請求，很有可能上游不限速的下單，導致下游系統被壓垮，引發雪崩。
為了避免雪崩，常見的優化方案有兩種：
1）業務上游佇列緩衝，限速傳送
2）業務下游佇列緩衝，限速執行
不管哪種方案，都會引入業務的複雜性，有「緩衝流量」需求的系統都需要加入類似的機制（具體怎麼保證訊息可達，見《訊息匯流排能否實現訊息必達？》），正所謂「通用痛點統一解決」，需要乙個通用的機制解決這個問題。
問：如何緩衝流量？
答：明明中間有了mq，並且mq有訊息落地的機制，為何不能利用mq來做緩衝呢？顯然是可以的。
問：mq怎麼改能緩衝流量？
答：由mq-server推模式，公升級為mq-client拉模式。
mq-client根據自己的處理能力，每隔一定時間，或者每次拉取若干條訊息，實施流控，達到保護自身的效果。並且這是mq提供的通用功能，無需上下游修改**。
問：如果上游傳送流量過大，mq提供拉模式確實可以起到下游自我保護的作用，會不會導致訊息在mq中堆積？
答：下游mq-client拉取訊息，訊息接收方能夠批量獲取訊息，需要下游訊息接收方進行優化，方能夠提公升整體吞吐量，例如：批量寫。
結論1）mq-client提供拉模式，定時或者批量拉取，可以起到削平流量，下游自我保護的作用（mq需要做的）
2）要想提公升整體吞吐量，需要下游優化，例如批量處理等方式（訊息接收方需要做的）
MQ如何快速實現流量削峰填谷
問 站點與服務，服務與服務上下游之間，一般如何通訊？答 有兩種常見的方式 一種是 直接呼叫 通過rpc框架，上游直接呼叫下游。在某些業務場景之下 具體哪些業務場景，見 到底什麼時候該使用mq？可以採用 mq推送 上游將訊息發給mq，mq將訊息推送給下游。問 為什麼會有流量衝擊？答 不管採用 直接呼叫...
MQ如何實現訊息延時
很多時候，業務有 在一段時間之後，完成乙個工作任務 的需求。例如 滴滴打車訂單完成後，如果使用者一直不評價，48小時後會將自動評價為5星。一般來說怎麼實現這類 48小時後自動評價為5星 需求呢？常見方案 啟動乙個cron定時任務，每小時跑一次，將完成時間超過48小時的訂單取出，置為5星，並把評價狀態...
前端如何快速實現構建
1.entry webpack 查詢依賴的入口檔案配置，入口檔案既可以乙個也可以是多個。單頁面應用入口配置 通常做法配置 index.js 單頁面應用入口檔案，vendor.js 第三方依賴庫，polyfill.js 特性填充庫，匯出配置 module.exports 多頁面應用入口配置 和單頁面應...