close
（本文作者：儲曉穎，支付寶技術研發工程師）
就像一群人在證券台中商標註冊代辦所盯著股票大盤一樣，看著紅紅綠綠的各種數字曲線跳動波動然後跟著興奮緊張。
我就是做這些大盤的
所以 過來刷刷知乎緩解下情緒。
對我們這個崗位，雙十一就像高考，而我每年都要復讀，每年題目還都比去年難很多。
過完高峰來修改下：
系統沒掛！哈哈哈哈哈哈哈
白天值班很輕松再來台灣商標申請修改下：
本人一共歷經5年雙十一（是的，每一年我都參與瞭）。數據很敏感，代碼無國界，不匿名說一些技術上的感受，無傷大雅。
妄自揣測回答一個題主可能關心的問題，相信這個問題能從側面襯托出作為員工親歷雙十一的感受 純粹從技術角度，為什麼需要這麼多員工通宵達旦燈火通明的一起來支撐雙十一？為什麼不安排幾個運維同學值班就夠瞭？
第一個例子：
如果你是個程序員，你做瞭一個最簡單的B2C網站，網站的主流功能必然是面向用戶的訂單、購物車等 前臺業務 ；同時也必然會有一個 後臺 ，給你的小二（運營人員）提供運營管理功能（新增營銷活動、編輯店鋪信息、修改商品信息、查詢歷史訂單）。然後有一天你們要辦一個非常重要的促銷活動，用戶蜂擁而至，突然一個小二做瞭一個非常復雜的歷史訂單查詢（產生瞭一個嵌套好幾層的SQL），而不幸的是你的系統又沒做讀寫分離（讀寫操作在同一個DB），DB負載本來就飆升好幾倍瞭，這一下直接幹倒，多米諾效應拖垮瞭web前臺，網頁404 促銷成瞭微博上茶餘飯後的笑話。
怎麼避免這種事情？
第二個例子：
程序員應該都熟悉淘寶的tair緩存技術（雙十一能成功，它居功至偉，大量的商品信息都是緩存其中，細節不多介紹瞭）。
如果量少，怎麼玩都可以。
但是如果量大呢？
假如你有100臺機器可用於部署tair。然後你參與大促的商品一共有100W件。按照最簡單的負載均衡思想，應該把100W件商品的信息，平攤到100臺tair上，每臺緩存1W件商品詳情（我們假設一臺tair是緩存不瞭100W件全部商品的，那就必然要有所分工，即使不是按商品的粒度，也可能會按其他更粗的粒度來分工）
現在你的運營過來告訴你，根據市場行情的調查和營銷力度的把控，今年大促秒殺iPhone 6的PV可能會達到幾百萬、iPhone 4會達到....、電飯鍋的PV應該是500，電吹風是200 同時今年又是iPhone 6剛剛推出、正值風口浪尖。
如果是我，我肯定拼瞭老命、賠瞭老本也要保住iPhone 6的秒殺。至於電飯鍋，讓它自生自滅吧！
所以我可能會把90臺tair都用於iPhone等5W個重點熱門商品，10臺用於剩下的95W其他商品。
（以上台中商標申請代辦所有數字純屬YY）
第三個例子：
大傢都吐槽12306的排隊，那麼問題來瞭 如果你的代碼真的寫的很好瞭，機器真的不夠用怎麼辦？
隻能排隊啊。。。
「雙十一」對於各銀行的科技部都有怎樣的考驗？歷年都有哪些趣事發生？這裡可以看看銀行的同學們是多麼的頭疼。
銀行啊！大型機啊！都搞不定啊！
所以如何優雅的 降級 ，是阿裡這幾年技術成長的一個重點。想做優雅的排隊？對不起，首先你要異步化，否則就隻能暴力的把用戶攔在外面；想異步化？對不起，你是支付寶，你是金融系統，在異步鏈路下依然要保證強一致性（告訴用戶購買成功、錢卻等瞭1分鐘才扣這種現象要盡全力避免 經@曾祥能同學的提醒已修改）。
就算做到這些瞭，還要一個把並發編程思想發揮到極致的queue中間件，不僅能有條不紊的削峰填谷、蓄洪限流，還要能隨時接收參數調整，實時動態並發的改變閥門閾值（什麼概念？一點點的差錯、1ms的差錯，就會導致海量的訂單沒有按預期流動）
即使這些都已經做的很努力瞭~還是要不停的改進！能不降級就不降啊、能不限流就別限啊 看評論裡同學們的吐槽就知道瞭，技術上還是有很多不足的。
先就說這三個例子。雖然沒有正面回答題主的問題，但是已經很明顯的看到，現在的 監控 ，已經不僅僅是cpu、load、磁盤、端口、網絡這些運維同學的事情瞭。不僅要做到T+0的實時BI、實況轉播、ROOT-CAUSE，還要做到對所有決策的實時反饋、準備應急降級預案、事先規劃資源分配
試想第一個例子，大促開場高峰期要關閉部分後臺的復雜查詢功能（甚至是 前臺 的次要業務），小二和客服的某些服務就會暫停，用戶投訴就會上升，就要啟動事先準備好的緩和對策，等到壓力穩定，要立刻恢復被降級的服務，小二和客服立刻得到通知盡快去解決拖延已久的問題、安撫生氣的用戶。
補充：（關於降級）我們老傢有句話叫 有多少米做多大粑 。客人來的多瞭，食材不夠，這就是現狀，是前提，改變不瞭。在這種情況下還能準備好一頓開心的晚餐，把客人的總體損失降到最低，也是個技術活兒。就連納斯達克在大公司上市之前也要執行 預演 ，避免不必要的交易行為把證券系統搞掛，這也是一種降級。
補充：（提到瞭銀行就再補充一個喜聞樂見的例子）小銀行頂不住瞭怎麼辦？收銀臺引導啊、讓用戶用扛得住的銀行卡啊！銀行都挺不住怎麼辦？充值送紅包啊，讓用戶多用支付寶餘額啊！銀行的量還降下不來怎麼辦？多送點紅包啊！300不行送500啊！運營找財務撥錢來發紅包啊！決策小組親自審批啊！營銷規則要立刻發佈更新啊！這一切要在幾分鐘內完成啊！就醬紫
想要把整個雙十一玩轉，需要PD、運營、中間件、業務系統、決策小組、客服等N多個部門一起合作。因為在這麼大的數據量面前，技術上糾結的程度已經具體到電飯鍋瞭。
所以親歷雙十一是什麼感覺？
就是你看到作戰室（超大會議室）裡十幾個大屏幕上翻滾的各種業務指標、系統數據，各種紅紅綠綠的報表曲線提醒著每一秒鐘的業務健康情況、決策執行情況、降級損害程度
然後決策小組的一幫最高指揮官通過這些數據做出各種決策，有些閑庭信步、有些壯士斷腕。
運維人員和系統owner以最高效的方式執行決策並跟蹤反饋決策效果。
DBA、中間件的同學盯著自己的DB、系統在強大的壓力下隨時準備申請執行預案（還能撐一點！加油啊兒子！我靠不行扛不住瞭、首架我要執行Plan B！ ）
運營和客服的同學更不用說瞭，已經忙翻天瞭，她們可是要根據決策小組的決策不停變換工作策略！
至於我？那些屏幕上的數字還在動，是準的，夠用，我才能安心的過來寫知乎啊~
針對評論的一些補充：
看瞭評論裡的吐槽都指向收藏夾啊？暫時得到的反饋是收藏夾大促未做降級，肯定還是量太大沒有穩住。
可惜的是這一塊的業務監控做的很弱（之前都重點覆蓋購物車等業務瞭 ），目前沒有什麼有用的指標，大促之後我得到原因再過來反饋。
另外很多熱愛coding的同學都在尋求技術答案，我知識面有限，難以全部回答準確，qcon上支付寶架構師胡喜的支付寶彈性計算架構應該能夠幫助同行們瞭解一下支付寶技術上的努力，淘寶的就更多瞭，很多早就開源的優秀解決方案。技術問題我就不一一解答瞭，可以私信留言，我去幫你翻翻資料盡量回復。
評論好多 我知道有很多朋友覺得阿裡這種 人為創造春運 的行為不好，明明可以把交易分攤到更久的時間段裡慢慢買的，為何要人為的創造這樣一個 節日 來折騰員工、折騰用戶、折騰快遞小哥。這個問題好大，我隻是一個碼農我隻能回答一個碼農的觀點：
大傢覺得春運不好，本質還是運力不足、經濟發展不平衡，這些才是痛點的源頭啊。可是互聯網、電子商務、IT技術，這些可以不痛啊。我聽過這樣一句話：
在很多科技領域，我們趕超歐美日本等發達國傢還有很長的路要走，人傢比我們提早瞭幾百年。但是計算機，我們的起步隻落後幾十年，尤其是軟件，落後的更短，而且軟件的資源成本、硬成本較低，它的關鍵是人才。
支付寶從最初的一個小工具，到趕超VISA、支付能力甩它幾條街，我們並沒有消耗浪費很多的社會資源，我們一年又一年的性能優化項目反而是在降低資源消耗。這個 人造節日 ，鍛煉出瞭一批又一批的高素質軟件人才，無論他們去向哪裡，都會成為編程好手、架構棟梁，促進整個IT業的發展，改變我們依賴洋大人、天天學SSH、天天捧著Google的論文尊為聖經的現狀。
起碼對程序猿，這是好事兒，不是嗎？
文章糾錯
微信公眾號搜索" 驅動之傢 "加關註，每日最新的手機、電腦、汽車、智能硬件信息可以讓你一手全掌握。推薦關註！【微信掃描下圖可直接關註】
閱讀更多：阿裡巴巴 天貓
AUGI SPORTS｜重機車靴｜重機車靴推薦｜重機專用車靴｜重機防摔鞋｜重機防摔鞋推薦｜重機防摔鞋
AUGI SPORTS｜augisports｜racing boots｜urban boots｜motorcycle boots
文章標籤
全站熱搜
留言列表
