默認
打賞 發表評論 0
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
閱讀(1698) | 評論(0 收藏1 淘帖2

本文來自微信團隊工程師方樂明的技術分享,由InfoQ編輯發布,即時通訊網收錄時有修訂和改動。原文地址:mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650996535&idx=1&sn=95f32730f45cae1bce23ee796b0277c1,感謝原作者的分享。


一、引言


微信紅包業務量級的高速發展,對后臺系統架構的可用性要求越來越高。在保障微信紅包業務體驗的前提下,紅包后臺系統進行了一系列高可用方面的優化設計。

本次分享介紹了微信紅包后臺系統的高可用實踐經驗,主要包括后臺的 set 化設計、異步化設計、訂單異地存儲設計、存儲層容災設計與平行擴縮容等。聽眾可以了解到微信紅包后臺架構的設計細節,共同探討高可用設計實踐上遇到的問題與解決方案。

補充說明:本文對應的演講PPT詳見《微信紅包系統可用性設計實踐(PPT) [附件下載]》。

二、分享者


方樂明:現任微信支付應用產品系統負責人,主要從事微信紅包、微信轉賬、微信群收款等支付應用產品的系統設計、可用性提升、高性能解決方案設計等,曾連續多年負責春節微信紅包系統的性能優化與穩定性提升,取得良好的效果。

三、系列文章


❶ 系列文章目錄:


❷ 其它相關文章:


四、微信紅包介紹


微信紅包從 2014 年開始發展到現在,中間經歷了幾年時間。在這幾年的時間里,整個系統可用性產生了很大的提升。2015 年年初的時候,每天晚上九點鐘是微信紅包的業務高峰期,系統經常性地出現性能問題。到了今天,即使在節假日高峰期,系統也不會出現問題。

社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_1.jpg
▲ 紅包印象 – 產品形態(點此查看本圖出處

如上圖所示,微信紅包的業務包含包、發、搶、拆、查詢發送紅包和收紅包數量,其中最關鍵的步驟是發紅包和搶紅包。

微信紅包是微信支付的商戶,微信紅包這個商戶出售的是錢。發紅包用戶在微信紅包平臺使用微信支付購買一份錢,微信紅包將錢發放到相對應的微信群。群里的用戶搶紅包得到微信零錢。這個過程中,微信紅包和微信支付之間的關系是商家和第三方支付平臺的關系。

微信紅包和微信支付之間的交互,與普通商家與微信支付的交互一樣,需要經過六個步驟。用戶發紅包時,進入微信紅包下一筆訂單,系統記錄發紅包用戶、發紅包金額、紅包數量和要發送到的用微信群。然后微信紅包系統請求微信支付服務器進行下單,用戶使用微信支付進行支付。

支付成功后,微信支付后臺系統通知微信紅包后臺系統支付成功結果,微信紅包后臺系統收到通知后推送微信紅包消息到微信群。微信群里用戶便可搶紅包。這就是微信紅包和微信支付的關系以及交互過程。

五、微信紅包系統架構


5.1微信紅包的系統流程


社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_2.jpg
▲ 微信紅包的系統流程(點此查看本圖出處

上圖是微信紅包系統角度上的流程,業務主流程是包、發、搶、拆四個操作,每個操作包括幾個關鍵步驟。

包紅包:系統為每個紅包分配一個唯一 ID,即紅包發送訂單號,然后將發紅包用戶、紅包個數、紅包數額寫入存儲,最后去微信支付下單。

發紅包:用戶使用微信支付完成付款,微信紅包后臺系統收到微信支付系統的支付成功通知。紅包系統將紅包發送訂單狀態更新為用戶已支付,并寫入用戶發紅包記錄(用戶發紅包記錄,就是微信錢包中,查看到的用戶每一年總共發出及收到的紅包記錄)。最后微信紅包后臺系統發送微信紅包消息到微信群。

搶紅包:指微信群里的用戶收到微信紅包消息后,點開紅包消息。這個過程,微信紅包后臺系統會檢查紅包是否已被搶完,是否已過期,是否已經搶過。

拆紅包是最復雜的業務是操作,包括:

  • 1)查詢這個紅包發送訂單,判斷用戶是否可拆,然后計算本次可拆到的紅包金額;
  • 2)然后寫入一條搶紅包記錄。如果把拆紅包過程,類比為一個秒殺活動的過程,相當于扣庫存與寫入秒殺記錄的過程;
  • 3)更新庫存對應于更新紅包發送訂單,寫入秒殺記錄對應于寫入這個紅包的領取紅包記錄;
  • 4)另外,還要寫入用戶整體的紅包領取記錄;
  • 5)最后請求微信支付系統給拆到紅包用戶轉入零錢,成功后更新搶紅包的訂單狀態為已轉賬成功。

5.2微信紅包的整體架構


社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_3.jpg
▲ 微信紅包的系統架構(點此查看本圖出處

上圖所示,是微信紅包的系統架構。包括微信統一接入層,下面是微信紅包系統 API,包括發、搶、拆、查紅包詳情、查紅包用戶列表。再下面是封裝微信紅包關鍵業務的邏輯服務;最下面一層是數據存儲層,微信紅包最主要的數據是訂單數據,包括發紅包訂單和拆紅包訂單兩部分。業務邏輯和存儲服務器之間是數據接入層,它最重要的作用是封裝數據庫操作的領域邏輯,使得業務邏輯服務不需要感知對 MySQL 的連接管理、性能、容災等問題。

微信紅包數據的訪問熱度,隨著時間流逝會急劇降低,也就是數據的訪問時間段非常集中,一般紅包發出三天后,99% 的用戶不會再去點開這個紅包了。因此微信紅包系統采取按時間做冷熱數據分離,降低數據的存儲成本,同時提升了熱數據的訪問性能。

數據平臺用于對紅包數據的分析計算,比如朋友圈里的文章,統計從 某年 1 月 1 日到 2017 年 1 月一個用戶總共搶紅包的金額,在全國的排名情況,發紅包數最多的城市等。另外一個作用就是對賬,紅包的訂單和微信支付的訂單需要對賬,以保證最終資金的一致性;訂單的數據和訂單的 cache 需要做對賬,以保證數據的完整性;訂單數據和用戶的收發記錄需要對賬,以保證用戶列表完整性。

六、微信紅包系統可用性實踐


6.1系統可用性影響因素


系統的可用性影響因素可分成兩類:

  • 一類計劃外;
  • 一類計劃內。

計劃外包含很多因素,系統用到的所有東西都可能產生故障,都可能成功影響可用性的因素。從這個角度上來講,可以說故障是無法避免的,系統的運作一定會產生故障,尤其是服務器有成千上萬個的時候。計劃內的影響因素,主要有與升級相關、運維相關的操作,以及日常的備份等。這一類影響因素,通過精細地設計方案,是可以避免對可用性造成影響的。

6.2微信紅包系統可用性設計方向


基于上面兩個分析結論,可以總結出微信紅包后臺系統的可用性的設計方向。就是在不能避免意外故障的情況下,盡可能降低出現意外故障時對可用性的影響。另一方面,絕大多數計劃內的日常維護可以通過方案的設計避免影響可用性,其中平行擴容特指關于存儲層的平行擴容。

下面從降低故障影響和微信紅包系統的平行擴容兩方面進行分析。

首先是降低意外故障的影響,重點講解訂單存儲層在訂單 DB 故障的情況下如何降低對紅包系統可用性的影響。

6.3業務邏輯層 - 部署方案設計


首先是業務邏輯層的部署方案。業務邏輯層是無狀態的,微信紅包系統的業務邏輯層,部署在兩個城市,即兩地部署,每一個城市部署至少三個園區,即三個 IDC。并且每個服務需要保證三個 IDC 的部署均衡。另外,三個 IDC 總服務能力需要冗余三分之一,當一個 IDC 出現故障時,服務能力仍然足夠。從而達到 IDC 故障不會對可用性產生影響。

6.4業務邏輯層 - 異步化設計


社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_4.jpg
▲ 業務邏輯層 – 異步化(點此查看本圖出處

第二是異步化設計。如上圖所示,微信紅包的某些步驟不實時完成也不會影響用戶對紅包業務可用性的體驗。比如拆紅包,正常的業務流程很長,但關鍵步驟只有訂單相關的幾步。至于轉零錢、寫紅包記錄等操作不需要實時。用戶搶到紅包時,一般不會實時去錢包查看微信零錢,而是在微信群中點開消息查看本次搶到金額和他人搶紅包金額。所以拆紅包時只需要從 cache 查詢用戶是否拆過紅包,然后寫入拆紅包的訂單記錄,更新發紅包訂單,其他的操作都可以異步化。當然,不是每個業務都可以進行異步化設計,需要進行業務分析,判斷是否存在非關鍵步驟之外的事情可以將其異步化,并通過異步對賬保證最終一致。

社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_5.jpg
▲ 訂單存儲層 – 早期架構(點此查看本圖出處

接下來是微信紅包訂單存儲設計。上圖是 2014 年微信紅包存儲層的模型。業務邏輯層請求數據層操作時,使用訂單號 hash 路由到訂單 SERVER。訂單 SERVER 與每一組 MYSQL 數據庫連接。

微信紅包的訂單號是在發紅包時系統生成唯一標識,使用序列號服務生成唯一 ID,后面拼接三位微信紅包的訂單分庫表的標識。所以,總共可以分一百個邏輯庫,每個邏輯庫含有十張表。一百個邏輯庫均勻地分布到十組物理 DB,每組 DB 存十個邏輯庫。

這個架構的最大問題是,一組 DB 故障時,會影響其他 DB。2014-2015 年期間,微信紅包量漲得特別快,擴容速度跟不上業務增長速度。一組 DB 的性能出現瓶頸時,數據操作變慢, 拆紅包的事務操作在 MYSQL 排隊等待。由于所有十組 DB 機器與所有的訂單 SERVER 連接,導致所有的訂單 SERVER 都被拖住,從而影響紅包整體的可用性。這個架構的另一個問題是擴容不方便,后面會介紹。

為解決 DB 間的相互影響,需要將 DB 間相互隔離,訂單存儲層 SET 化。SET 化指訂單 DB 和訂單接入 SERVER 垂直 stick 一起。業務邏輯層訪問訂單時,根據訂單倒數第二、三位數字找到所屬訂單 SET,一個 SET 的請求不能路由到其他 SET。

找到對應的訂單接入服務器之后,在服務器內的多個進程中找到指定進程,讓同個紅包的所有拆請求串行化。當一組 DB 出現故障,只會影響該組 DB 對應的 SERVER。

這里有一個問題,DB 故障拖住某些訂單 SERVER,會不會也拖住更上層業務邏輯服務?業務邏輯層為什么不一起 SET 化?業務邏輯層承載了用戶維度相關的業務操作,不可以按照訂單的維度分業務邏輯,例如務邏輯層會請求用戶的頭像、昵稱等,如果繼續按照訂單分業務邏輯,會導致跨地域調用。

微信紅包系統采取的方案是,在訂單 SERVER 服務端增加快速拒絕服務的能力。SERVER 主動監控 DB 的性能情況,DB 性能下降、自身的 CPU 使用升高,或者發現其他的監控維度超標時,訂單 SERVER 直接向上層報錯,不再去訪問 DB,以此保證業務邏輯層的可用性。

一組 DB 故障不會影響整個系統的可用性。有影響的,只有十分之一,若擴成 100 組,影響便只有一百分之一。所以通過 SET 化得到的好處是,控制 DB 連接數、隔離故障影響和分流并發。

社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_6.jpg
▲ 訂單存儲層 – 故障自愈(點此查看本圖出處

完成 SET 化之后,DB 故障仍對業務有十分之一影響,那么這十分之一該怎么解決?通過對系統進行研究分析之后,發現 DB 可以做到故障自愈。

如上圖所示,所設尾號 90-99 的 SET 故障時,如果業務邏輯服務后續不再生成屬于這個 SET 的訂單,那后續的業務就可以逐漸恢復。

也就是在發生故障時,業務邏輯層發布一個版本,屏蔽故障號段的單號生成,就可以恢復業務。進一步想,除了人為發版本,有沒有方法可以讓 DB 故障時自動恢復?在 DB 故障導致業務失敗時,業務邏輯層可獲取到故障 DB 的號段,在發紅包時,將這些故障的號段,換一個可用的號段就可恢復業務。訂單號除了最后三位,前面的部分已能保證該紅包唯一性,后面的數字只代表著分庫表信息,故障時只需要將最后三位換另外一個 SET 便可自動恢復。

完成這個設計后,即使 DB 出現故障,業務的可用性也不會有影響。這里還有一點,新的發紅包請求可避免 DB 故障的影響,但那些故障之前已發出未被領取的紅包,紅包消息已發送到微信群,單號已確定,拆紅包時還是失敗。對這種情況,由于不會有增量,采用正常的主備切換解決即可。

6.5平行擴縮容設計


社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_7.jpg
▲ 平行擴縮容 – 早期方案(點此查看本圖出處

上圖是微信紅包早期的擴縮容方式。這個擴容方式,對擴容的機器數有限制。前面講到,紅包系統按紅包單號后面兩個數字分多 SET,為了使擴容后數據保持均衡,擴容只能由 10 組 DB 擴容到 20 組、50 組或者 100 組。另外,這個擴容方式,過程也比較復雜。首先,數據要先從舊數據庫同步復制到新擴容的 DB,然后部署 DB 的接入 SERVER,最后在凌晨業務低峰時停服擴容。

這個擴容方式的復雜性,根本原因是數據需要從舊 SET 遷到新 SET。如果新產生數據與舊數據沒關系,那么就可以省掉這部分的遷移動作,不需停服輸。分析發現,需要把舊數據遷出來的原因是訂單號段 00-99 已全部被用,每個物理數據庫包含了 10 個邏輯庫。如果將訂單號重新設計,預留三位空間,三位數字每一個代表獨立的物理 DB,原來 10 組 DB 分別為 000-009 號段。

這種設計,縮容時,比如要縮掉 000 這組,只需在業務邏輯服務上不生成訂單號為 000 的紅包訂單。擴容時,比如擴為 11 組,只需多生成 010 的訂單號,這個數據便自動寫入新 DB。當然,縮容需要一個前提條件,也就是冷熱分離,縮容后數據變為冷數據,可下線熱數據機器。以上就是紅包的平行擴縮容方案。

社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的_8.jpg
▲ 改進后的平行擴容(點此查看本圖出處

七、寫在最后


微信紅包系統的可用性實踐,主要包括了部署設計、SET 化設計、異步化設計、DB 故障自愈能力建設、平行擴容設計。在完成這些設計后,微信紅包系統的可用性得到了很大提升,在 近幾年的春節實現了 0 故障,在平常的運行中達到 99.99% 可用性。

(原文鏈接:點此進入

附錄1:有關微信、QQ的文章匯總


微信朋友圈千億訪問量背后的技術挑戰和實踐總結
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)
騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)
微信團隊分享:微信移動端的全文檢索多音字問題解決方案
騰訊技術分享:Android版手機QQ的緩存監控與優化實踐
微信團隊分享:iOS版微信的高性能通用key-value組件技術實踐
微信團隊分享:iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的?
騰訊技術分享:Android手Q的線程死鎖監控系統技術實踐
微信團隊原創分享:iOS版微信的內存監控系統技術實踐
讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享
iOS后臺喚醒實戰:微信收款到賬語音提醒技術總結
騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路
微信團隊分享:視頻圖像的超分辨率技術原理和應用場景
微信團隊分享:微信每日億次實時音視頻聊天背后的技術解密
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)
QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)
騰訊團隊分享:手機QQ中的人臉識別酷炫動畫效果實現詳解
騰訊團隊分享 :一次手Q聊天界面中圖片顯示bug的追蹤過程分享
微信團隊分享:微信Android版小視頻編碼填過的那些坑
微信手機端的本地數據全文檢索優化之路
企業微信客戶端中組織架構數據的同步更新方案優化實戰
微信團隊披露:微信界面卡死超級bug“15。。。。”的來龍去脈
QQ 18年:解密8億月活的QQ后臺服務接口隔離技術
月活8.89億的超級IM微信是如何進行Android端兼容測試的
以手機QQ為例探討移動端IM中的“輕應用”
一篇文章get微信開源移動端數據庫組件WCDB的一切!
微信客戶端團隊負責人技術訪談:如何著手客戶端性能監控和優化
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信團隊原創分享:Android版微信的臃腫之困與模塊化實踐之路
微信后臺團隊:微信后臺異步消息隊列的優化升級實踐分享
微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐
騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率
騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)
騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(上篇)
微信Mars:微信內部正在使用的網絡層封裝庫,即將開源
如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源
開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
微信團隊原創分享:Android版微信后臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)
Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]
微信團隊原創分享:Android版微信從300KB到30MB的技術演進
微信技術總監談架構:微信之道——大道至簡(演講全文)
微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]
如何解讀《微信技術總監談架構:微信之道——大道至簡》
微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]
微信異步化改造實踐:8億月活、單機千萬連接背后的后臺解決方案
微信朋友圈海量技術之道PPT [附件下載]
微信對網絡影響的技術試驗及分析(論文全文)
一份微信后臺技術架構的總結性筆記
架構之道:3個程序員成就微信朋友圈日均10億發布量[有視頻]
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
快速裂變:見證微信強大后臺架構從0到1的演進歷程(二)
微信團隊原創分享:Android內存泄漏監控和優化技巧總結
全面總結iOS版微信升級iOS9遇到的各種“坑”
微信團隊原創資源混淆工具:讓你的APK立減1M
微信團隊原創Android資源混淆工具:AndResGuard [有源碼]
Android版微信安裝包“減肥”實戰記錄
iOS版微信安裝包“減肥”實戰記錄
移動端IM實踐:iOS版微信界面卡頓監測方案
微信“紅包照片”背后的技術難題
移動端IM實踐:iOS版微信小視頻功能技術方案實錄
移動端IM實踐:Android版微信如何大幅提升交互性能(一)
移動端IM實踐:Android版微信如何大幅提升交互性能(二)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
移動端IM實踐:iOS版微信的多設備字體適配方案探討
信鴿團隊原創:一起走過 iOS10 上消息推送(APNS)的坑
騰訊信鴿技術分享:百億級實時消息推送的實戰經驗
IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)
IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)
騰訊TEG團隊原創:基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享
微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等
了解iOS消息推送一文就夠:史上最全iOS Push技術詳解
騰訊技術分享:微信小程序音視頻技術背后的故事
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
微信多媒體團隊梁俊斌訪談:聊一聊我所了解的音視頻技術
騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天
騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐
手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
騰訊技術分享:GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐
微信團隊分享:Kotlin漸被認可,Android版微信的技術嘗鮮之旅
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
QQ設計團隊分享:新版 QQ 8.0 語音消息改版背后的功能設計思路
>> 更多同類文章 ……

附錄2:更多架構方面的文章匯總


[1] 有關IM架構設計的文章:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
移動端IM中大規模群消息的推送如何保證效率、實時性?
現代IM系統中聊天消息的同步和存儲方案探討
IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?
IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議
IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token
WhatsApp技術實踐分享:32人工程團隊創造的技術神話
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等
IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
以微博類應用場景為例,總結海量社交系統的架構設計步驟
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
>> 更多同類文章 ……

[2] 更多其它架構設計相關文章:
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
達達O2O后臺架構演進實踐:從0到4000高并發請求背后的努力
優秀后端架構師必會知識:史上最全MySQL大表優化方案總結
小米技術分享:解密小米搶購系統千萬高并發架構的演進和實踐
一篇讀懂分布式架構下的負載均衡技術:分類、原理、算法、常見方案等
通俗易懂:如何設計能支撐百萬并發的數據庫架構?
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的下一篇:社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐

本帖已收錄至以下技術專輯

推薦方案
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特