中小
分享到：qq空間
人人網豆瓣網
開心網更多
0講師：jeri
核心功能&目標
搖：搖的流暢
快：搶的要快
爽：拆的爽
穩：能分享出去
系統難點：
1.中國運營商網路環境複雜，覆蓋面廣，春節期間網路吃緊，容易出現網路故障
2.在尖峰搖時如何避免服務雪崩
3.在服務資源有限時，如何提供柔性服務
4.如何構造有損服務
5.如何構造set模型
6.如何解決併發搶
7.如何實現實現資料一致性
系統整體架構圖
跨區域網路解決方案
跨區域網路問題，在物理實施上，也需要有備份繞行的能力，這個可以在系統的底層框架中實現，當指定專線出現故障時，快速切換網路，恢復服務
如何構建有損服務
比如，春晚搖一搖，我們的核心點是搖/拆/分享，那系統的資源優先需要保證這些服務的響應，任何關聯系統出現異常的時候馬上進行系統降級，防止引起系統雪崩。
系統降級可以分為兩個方面，一是把核心功能呼叫鏈路簡化，減少依賴，通過輔助輕量化的服務實現，確保最短關鍵路徑的可行，比方說在接入層置入搖紅包邏輯，將每秒千萬級請求轉化為每秒萬級的紅包請求，再傳到紅包服務的後端邏輯，降低雪崩的可能性。
柔性服務.打造好的產品體驗
柔性可用是在有損服務價值觀支援下的方法，重點在於實際上會結合使用者使用場景，根據資源消耗，調整產品策略，設計幾個級別不同的使用者體驗場景，保證盡可能成功返回關鍵資料，並正常接受請求，絕不輕易倒下。
比如，紅包的核心功能拆，拆完需要記錄使用者頭像暱稱，轉帳資金劃轉，同時輸出同個訂單下其它拆記錄，拆過程這些操作都可能失敗，但是核心操作獲取紅包是成功的，此時，我們至少可以告訴使用者搶到金額，不至於讓使用者焦急等待，不斷重試，未完成的操作(頭像補全與資金轉帳)，可以通非同步補嘗方式重試。這樣解決了使用者的問題，也緩解了系統壓力。
如果構造set模型
set模組就像乙個貨櫃，把各模組標準化，模組化，規模化，它為海量服務運營，特別是裝置管理、網路架構，提供了巨集觀運營支撐框架，從而極大提高了海量服務運營效率。
如何解決併發搶
群裡紅包的規則是金額隨機搶，在乙個大**乙個紅包出去，搶併發請求量高，在同乙個資源上操作，需要增加鎖操作，避免乙個搶總數超過傳送紅包總數，眾所周所，mysql的加鎖操作，很多搶在乙個鎖上等，效能損耗大，吞吐量下降，對於海量服務的操作，是不能滿足要求。
在set模組的基礎上，我們把發/搶的資源請求都會落到同乙個資源set，在最外層，cache紅包的狀態，如果紅包已經被搶完了，即刻返回，如果紅包未接完，對於乙個紅包進去搶環節還有限流，這是第一級保護，通過一致性hash演算法，一乙個單到dao層都會路由到同乙個機器的同乙個程序，dao到mysql在現乙個連線上完成搶操作，把併發搶修改成序列化，mysql可以無鎖等待，效能明顯提公升。
如何實現資料一致性
談到分布式系統，先回顧cap理論
c：consistency資料一致更新，所有變動都是同步的
a：高可用，好的響應效能
p: 分割槽容忍，可靠性
在我們的系統設計中，同樣碰到這個問題，無法同時滿足三個因子，移動網際網路系統，高可用性是必要要求，資料分割槽也是分布式系統的條件，所以，我們設計系統時，只能盡量保證資料一致性，只要一定時間視窗內，完成資料一致，讓使用者滿意。
n：資料副本份數紅包有三份
r: 一次需讀取的副本紅包一次從乙個副本可以全部讀取需要資料
w: 一次寫入資料2份實時寫，一分非同步化
r(1) + w(2) <=n從公式算出，我們的資料模型也是弱一致性
使用者資料是非同步更新，更新失敗，通過訊息中心，非同步重試，根據db資源負載設定呼叫方的呼叫閥值，除了實時重試，我們還有準實時資料核對，保證資料最終一致性。
微信紅包的設計實現
拆紅包高併發讀 併發寫網路流量峰值 對賬降級 故障恢復 拆紅包有預拆包和實時拆包2種策略 預拆包的策略在發紅包時將金額m的紅包拆分成n份，將分配好的結果放入記憶體佇列或者cache，通過incr操作在使用者搶紅包時分配預算好的紅包slot，預算的策略可以避免對共享資源的操作，減少了鎖競爭，服務本身是...
微信搶紅包架構設計
實時性 為什麼明明搶到紅包，點開後發現沒有？答 2014年的紅包一點開就知道金額，分兩次操作，先搶到金額，然後再轉賬。2015年的紅包的拆和搶是分離的，需要點兩次，因此會出現搶到紅包了，但點開後告知紅包已經被領完的狀況。進入到第乙個頁面不代表搶到，只表示當時紅包還有。分配 紅包裡的金額怎麼算？為什麼...
微信紅包池以及庫存設計思考
庫存設計 乙個商品主表 100條庫存記錄，每各庫存記錄49個庫存 額外一條保障庫存記錄有100個庫存100個 一共101條庫存記錄 共5000庫存 如何實現下單功能 1 如何實現減庫存 2 如何確保快速獲取到庫存個數大於0的庫存記錄並實現減庫存 3 如何保障5000庫存均被消費 寫請求直接到庫 讀請...