hello 各位同學們，大家好，我是姚半仙，慕課網Java架構師成長直通車課程架構師講師團成員之一。快來搬個小闆凳坐好，聽老師講故事,這個故事就是當年阿裡新零售業務中為何在商品釋出階段引入了削峰政策，故事的開頭是這樣的：
這是什麼意思呢？有一天，營運總監找到我，開口就說:"爸爸，我有個事求你啊"(不好意思，前面是我歪歪的)。營運總監找到我說：“本座喚你來做個新需求，一鍵釋出所有商品到新店”。我就弱弱的問，所有商品是多少個啊？營運總監發話了，其實吧，也沒有那麼多，大概小幾十萬吧。話音剛落，這個總監就使出了一擊必殺的大招，這個大招的名字就叫一鍵開店。
它有什麼功能啊？就是瞬間打出五萬以上的QPS，秒殺所有商品的服務。這個一鍵開店的技能是一個需要持續施法的技能。它一旦開始吟唱 ，大概會在十秒鐘不到的時間打出小幾十萬的商品，那對應到商品服務的叢集來說，大概就是每秒五萬家的QPS。以當時我們的服務叢集機器數量是遠遠承載不夠的，那營運總監這一招厲害啊，估計還沒有吟唱完，這個所有商品服務全部都團滅了。
咱不光說商品服務要團滅啊，一個商品釋出，它調用的遠遠不止商品服務這一個服務，它還會調用後續的訂單服務，庫存服務，總之，很多下遊微服都會受到這個影響。眼看服務血崩就要發生了，那麼接下來我們怎麼辦呢？那就是必須要引入消息元件來做流量削峰。
所謂兵來将擋，水來土淹，一物降一物。那這個東西就是完克營運總監技能的法寶啊。我們看看消息元件的技能說明都有哪些啊？第一個是平滑輸出。我們采用用戶端主動拉取的方式，它并不是主動的往裡嘴裡硬塞東西，而是用戶端根據自己的處理能力主動去拉取，有多大學事就幹多大的事。第二個特點是不怕Timeout,咱如果在短時間内像剛才的商品釋出一樣，十秒鐘内釋出五十萬個商品，如果你接口響應逾時了，那你還要設定很多的容錯政策來補償，保證最終一緻性，那你這個業務場景就被API逾時給限制住了，而消息元件需要擔心這個問題嗎？完全不用擔心啊， 你的所有請求都被存放在消息組建這裡了，什麼時候有資源，那什麼時候就會有用戶端來主動拉取去做，完全沒有基于API調用的逾時煩惱。那最重要的當然還是依靠消息組建的高吞吐量特性，你五十萬個請求，如果全部落在我們的業務伺服器上，這個造成的傷害很大，但是如果你落在中間件消息組建的叢集上你這個真的就是毛毛雨了，要不怎麼說能擔當中間件的大任呢。咱但凡提到中間件，一般來說，吞吐量都是相當優秀的。那我們有了消息元件這件神裝的加持，看看如何來抵擋營運總監的淫威啊？
總監這時又開始吟唱起了一鍵開店的技能，那抵達了商品中心，接下來我們就寄出了消息，組建這件神裝啊。商品中心把一鍵開店所對應的所有商品，一股腦的發送給了消息中間件，那商品釋出消息抵達到消息中間件以後呢，我們每一個下遊應用都會去監聽這個消息隊列。比如我們的商品服務監聽到這個消息開始釋出淘系商品，那銷售單服務釋出一些銷售計劃等等， 庫存服務呢，就是去初始化庫存，釋出每日庫存所有的下遊服務全部井然有序的運作着。營運總監這一個大招砸下來啊，就被咱的消息元件完美化解了，對我們的服務沒有造成任何一點傷害，此刻我心中不由燃起了對從事技術工作的這種優越感，對營運總監、産品經理這些技術小白啊，隻有他們想不到的問題， 沒有技術人員解決不了的問題，程式員的超能力他們不懂。
言歸正傳，本篇文章就和大家分享到這，有機會我将帶大家探秘Stream Binder作用機制。