本文章轉自如下地址： http://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651814363&idx=1&sn=187b38d35456f89a1030b24f8c4388c3&scene=23&srcid=0424R2Pm5qshQXpvTO ...
本文章轉自如下地址：
http://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651814363&idx=1&sn=187b38d35456f89a1030b24f8c4388c3&scene=23&srcid=0424R2Pm5qshQXpvTOz5hAXF#rd
本文普及一下傳說中的互聯網架構三板斧，以便有些場沒趕上滴，有些會沒參加滴，聽完沒有來得及消化滴，也能get到技能（學習也是棒棒的）！ 有人問了為啥是三板斧，是[三]，不是[四]，這也是習慣的力量！比如為啥是煎餅果子讓西喬姐苦惱了一樣。可多層包裹的煎餅可無限擴展的單元化豆腐Ps：關於[三]的流行參考，百度可得 宅男有三好；Dota、基友、破電腦。蘿莉有三好；柔體、輕音、易推倒。屌絲有三廢；在嗎、忙不、早點睡。女神有三寶；幹嘛、呵呵、去洗澡。
“ 與傳統意義上的紅包相比，近兩年火起來的互聯網“紅包”，似乎才是如今春節的一大重頭戲。春晚直播期間討論春晚的微博達到5191萬條，網友互動量達到1.15億，網友搶微博紅包的總次數超過8億次。看得見的數據背後，隱藏的是什麼看不見的技術呢？”
按照各家公佈的數據，除夕全天微信用戶紅包總發送量達到10.1億次，搖一搖互動量達到110億次，紅包峰值發送量為8.1億次/分鐘。而支付寶的紅包收發總量達到2.4億次，參與人數達到6.83億人次，紅包總金額40億元，峰值為8.83億次/分鐘。春晚直播期間討論春晚的微博達到5191萬條，網友互動量達到1.15億，網友搶微博紅包的總次數超過8億次。”
--以上數據引用自InfoQ[解密微博紅包：架構、防刷、監控和資源調度]。本文會以一些公開的內容聊聊萬變不離其中的所謂絕招，為了吸引要求，素材主要參考淘寶大秒系統和各家紅包系統的情況。第一板斧第一板斧：活下來 [Stability]俗話說身體是革命的本錢，首先要活著。大凡架構還沒有捨身成仁的死法，都是好死不如賴活著。關於如何活著，其實是有模式可循的，活著這事在技術界也有一個蠻好聽的名字--穩定性（花名 Stability）。穩定性實踐筆者印象比較深的有2篇內容，一是由淘寶小邪在2011年分享的[淘寶穩定性實踐]。
該材料經牆內搜索百度查詢，基本沒有別的存檔了，唯有百度文庫碩果僅存，地址就不貼了。這個slide主要講了4招：容量規劃、集群容災、依賴降級、運行監控。
就容災可以區分為同機房內、同城異機房、異地機房幾個層次考慮。
上圖機房1種C系統故障切換機房2的情況。保護自己是很重要的，如下圖所示，C掛了，則A調用C超時，如何保障A不被拖累呢？
阿淘也給出解法，就是stable switch。如下圖所示：
隨著淘寶、天貓的業務發展，本著更優雅運維的思路，阿淘在穩定性方面的建設肯定有更多精細化，更好、更優雅的做法，但是其本質原則：活著勝過一切！多個備份、無縫切換、超限限流、斷尾求生又稱優雅降級等是指導同類互聯網應用的常見招數。另外，特別安利一下服務治理，隨著微服務興起，大有不微不能出來見人的姿勢。但服務治理是在服務管理中一塊重要內容，亘古彌新。如果有上千應用，服務介面不計其數。做一次功能升級，我得知道誰調用了我，我調用了誰；做性能和容量改進，我得知道那條鏈路是瓶頸；做鏈路優化，我得通過工具來看那些強依賴可以調整為弱依賴等等。
第二篇高大上的ppt是來自國外的一個ppt。
http://www.slideshare.net/jboner/scalability-availability-stability-patterns
作者把可用性和穩定性，做了一些區分。可用性偏大局，比如FO，MM模式等。而穩定性強調單區域應用中的手段比如開關，降級等。
第二板斧：簡單可擴展（scalability）
啥叫可擴展，就是可以不斷加資源以達成更大容量，支撐更高的併發、迎接更多用戶。這裡的資源可以是應用伺服器，也可以是資料庫伺服器，或者是緩存伺服器。[可擴展Web架構探討]這個材料中也有對可擴展有所定義。這裡也提及scalability是系統適應不斷增長用戶數量的能力。特別提及擴展容易（所有組件都應當簡單擴展）、無共用架構（shared arch）。
、
負載均衡是的作用有幾個，一是接入接入保護、失效檢測；二是提供在用戶和伺服器之間做中介，讓增減伺服器對用戶不可見；三是通過負載均衡演算法讓流量相對均衡的分佈。負載均衡有硬體設備也有純軟體比如LVS，負載均衡對於頁面請求以及rpc調用都能較均衡的分配，是一個重要的考量因素。（關於負載均衡的具體內容，此文不贅述）有一個很古老的文檔，叫LiveJournal's Backend - A history of scaling 敘述了網站的發展歷程。
一臺server有啥壞處，自不必說了。然後…
某一天發展到5台了，3個web server；2台db。使用mysql replication來做複製。隨著用戶數的增加，用戶需要cluster
後來因為性能的原因，需要使用cache，包括Mogile Storage等。詳情可參見
一個網站的發展後來成了很多架構文章的標配。上更多webserver、上更多dbserver、讀寫分離、分庫分表、上搜索引擎等等。架構之道在合適的時間做合適的決定(tradeoff),運用之道，存乎一心。第三板斧第三板斧：攔河大壩、去併發
由於營銷活動（創造營銷節點、擴大影響力的需要），總有很多產品策劃、運營樂此不疲的玩著一個game---在足夠集中的時間內比如秒級處理足夠多的用戶請求，讓世界為此狂歡，同時也是彰顯技術實力的一次大考。
小米賣著搶號的手機、天貓發明瞭雙11光棍節、微信和支付寶連續2年做著新春紅包。營銷活動的時候要使用前2板斧，保證可用性和簡單可擴展性，同時還要祭出第三板絕殺—攔河大壩、緩存為王、去熱點資源的併發。
為啥要攔？很簡單，用戶很熱情（感性），但系統必須得理性！就3個蘋果手機，憑啥讓幾十萬人都涌入櫃臺！在大秒系統一文中許同學就娓娓道來(省得少畫個圖)……
對大流量系統的數據做分層校驗也是最重要的設計原則，所謂分層校驗就是對大量的請求做成“漏斗”式設計，如上圖所示：在不同層次儘可能把無效的請求過濾，“漏斗”的最末端才是有效的請求，要達到這個效果必須對數據做分層的校驗，下麵是一些原則：
1先做數據的動靜分離
2將90%的數據緩存在客戶端瀏覽器
3將動態請求的讀數據Cache在Web端
4對讀數據不做強一致性校驗
5對寫數據進行基於時間的合理分片
6對寫請求做限流保護
7對寫數據進行強一致性校驗
將90%的數據緩存在客戶端瀏覽器，將動態請求的讀數據cache在web端，還是不夠的。在大秒的過程中，存在極端情況，就是請求超過單key所在server的QPS能力。數據訪問熱點，比如Detail中對某些熱點商品的訪問度非常高，即使是Tair緩存這種Cache本身也有瓶頸問題，一旦請求量達到單機極限也會存在熱點保護問題。有時看起來好像很容易解決，比如說做好限流就行，但你想想一旦某個熱點觸發了一臺機器的限流閥值，那麼這台機器Cache的數據都將無效，進而間接導致Cache被擊穿，請求落地應用層資料庫出現雪崩現象。這類問題需要與具體Cache產品結合才能有比較好的解決方案，這裡提供一個通用的解決思路，就是在Cache的client端做本地Localcache，當發現熱點數據時直接Cache在client里，而不要請求到Cache的Server。數據更新熱點，更新問題除了前面介紹的熱點隔離和排隊處理之外，還有些場景，如對商品的lastmodifytime欄位更新會非常頻繁，在某些場景下這些多條SQL是可以合併的，一定時間內只執行最後一條SQL就行了，可以減少對資料庫的update操作。另外熱點商品的自動遷移，理論上也可以在數據路由層來完成，利用前面介紹的熱點實時發現自動將熱點從普通庫里遷移出來放到單獨的熱點庫中。心得體會請允許筆者總結一下高併發方案的解決之道。
使用緩存，能越前端緩存的放在前端，這樣調用鏈路最短。這裡的緩存不僅僅是redis、或者memcached，而是local或者climatchent優先的思路，去除對併發資源的依賴。比如[揭秘微信搖一搖背後的技術細節]一文中提到：按一般的系統實現，用戶看到的紅包在系統中是資料庫中的數據記錄，搶紅包就是找出可用的紅包記錄，將該記錄標識為match屬於某個用戶。在這種實現里，資料庫是系統的瓶頸和主要成本開銷。我們在這一過程完全不使用資料庫，可以達到幾個數量級的性能提升，同時可靠性有了更好的保障。
1支付系統將所有需要下發的紅包生成紅包票據文件；
2將紅包票據文件拆分後放到每一個接入服務實例中；
3接收到客戶端發起搖一搖請求後，接入服務里的搖一搖邏輯拿出一個紅包票據，在本地生成一個跟用戶綁定的加密票據，下發給客戶端；
4客戶端拿加密票據到後臺拆紅包，match後臺的紅包簡化服務通過本地計算即可驗證紅包，完成搶紅包過程。
分拆熱點
上文提到，在極端情況下大秒使用了二級緩存，通過拆分key來達到避免超過cache server請求能力的問題。在facebook有一招，就是通過多個key_index（key:xxx#N） ,來獲取熱點key的數據，其實質也是把key分散。對於非高一致性要求的高併發讀還是蠻有效的。
如圖
則解決之道是：
• Hot keys are published to all web-servers
• Each web-server picks an alias for gets– get key:xxx => get key:xxx#N
• Each web-server deletes all aliases
微博團隊披露：服務端本地緩存，使用nginx本身緩存和伺服器的L0緩存，來提升模塊的響應速度，做到了90%以上核心介面的響應時間在50ms以內，減少了進程等待時間，提升了伺服器的處理速度。
解決併發有1種基本辦法: 分拆！而分拆有兩種拆法，
1拆資源一是把資源（resource）拆了，著名的比如ConcurrentHashMap，拆成了16個桶，併發能力大大提高。
2拆基礎數據在紅包應用中，如果還依賴一個共同的基礎數據，也可以把這個基礎數據拆成多個cell。
預處理[互動1808億次，16倍的超越！談支付寶紅包的高併發挑戰]一文中如此說：“在這次春晚活動中，涉及到大量的資源，包括圖片、拜年視頻等。圖片和視頻都比較大，十幾b到幾百kb不等。當在高峰期時，如果瞬間有海量的請求到CDN上，這麼大的請求帶寬根本扛不住。我們當時預估了大約有幾T的帶寬需求。為了能有效地扛住瞬間峰值對CDN的壓力，我們對資源進行了有效的管理和控制。首先在客戶端預埋了幾個預設資源，萬一真不行了，這幾個資源可以用。其次儘量提前打開入口，當用戶瀏覽過後，就將資源下載到本地。再次瀏覽時不再需要遠程訪問CDN。最後，做了應急預案，高峰期一旦發現流量告警，緊急從視頻切換到圖片，降低帶寬壓力，確保不出現帶寬不夠而發生限流導致的黑屏等體驗不好的問題。最後的結果可以用完美來形容，由於預熱充分，帶寬雖然很高，但沒達到我們的告警值，應急預案也沒有使用。”
微信團隊也提到：
“在除夕，用戶通過搖一搖參與活動，可以搖到紅包或其他活動頁，這些頁面需要用到很多圖片、視頻或 H5 頁面等資源。在活動期間，參與用戶多，對資源的請求量很大，如果都通過實時線上訪問，伺服器的網路帶寬會面臨巨大壓力，基本無法支撐；另外，資源的尺寸比較大，下載到手機需要較長時間，用戶體驗也會很差。因此，我們採用預先下載的方式，在活動開始前幾天把資源推送給客戶端，客戶端在需要使用時直接從本地載入。”
非同步化江湖傳說中有一句話，叫能非同步的儘量非同步。做活動的時候，資源多寶貴啊，對C端無感但可以容忍的，就讓它慢慢做，而此種一般放入到隊列當中。
杭州的蘑菇街七公又名小白，是一個熱情的朋友。他提及交易服務依賴過多的解決之道。服務依賴過多，會帶來管理複雜性增加和穩定性風險增大的問題。試想如果我們強依賴10個服務，9個都執行成功了，最後一個執行失敗了，那麼是不是前面9個都要回滾掉？這個成本還是非常高的。所以在拆分大的流程為多個小的本地事務的前提下，對於非實時、非強一致性的關聯業務寫入，在本地事務執行成功後，我們選擇發消息通知、關聯事務非同步化執行的方案。（看看下圖，那些可以非同步化？）
使用隊列
攔、攔、攔；之後緩存抗；緩存扛不住的併發分拆；但是還有一個問題，就是極端熱點資源在db里，如果併發高還是會出問題。大秒一文中有較好的處理方案，就是排隊。Web伺服器排隊，在db層還做了一個patch排隊，真心是業務是最好的老師，不得已何必祭大招！
應用層做排隊。按照商品維度設置隊列順序執行，這樣能減少同一臺機器對資料庫同一行記錄操作的併發度，同時也能控制單個商品占用資料庫連接的數量，防止熱點商品占用太多資料庫連接。關於詳情，可以閱讀大秒一文。
總結總結一下，互聯網架構三板斧：
-
活下來(Stability)
-
簡單可擴展（Scalability）
-
攔河大壩/去併發
在第三板斧中又有分層攔截、多級緩存、數據近端、分拆鎖、預處理、非同步化及隊列等pattern。學習原則：靈活運用，不盡信經驗。
寫這麼個長篇，我也是醉醉的了，權當為那些沒時間學習、沒仔細學習的朋友盡心了。引用引用內容 from：《互動1808億次，16倍的超越！談支付寶紅包的高併發挑戰》- QCon公眾號《10億紅包從天而降，揭秘微信搖一搖背後的技術細節》 - InfoQ網站《淘寶大秒系統設計詳解》- CSDN《解密微博紅包：架構、防刷、監控和資源調度》 - InfoQ網站
http://www.slideshare.net/jboner/scalability-availability-stability-patterns
LiveJournal's Backend - A history of scaling
