默認
打賞 發表評論 1
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
閱讀(2369) | 評論(1 收藏1 淘帖2

本文來自微信團隊工程師方樂明的技術分享,由InfoQ編輯發布,即時通訊網收錄時有修訂和改動。原文地址:infoq.cn/article/2017hongbao-weixin,感謝原作者的分享。


一、引言


每年節假日,微信紅包的收發數量都會暴漲,尤以除夕為最。如此大規模、高峰值的業務需要,背后需要怎樣的技術支撐?百億級別的紅包規模,如何保證并發性能與資金安全?

本文將為讀者介紹微信百億級別紅包背后的高并發設計實踐,內容包括微信紅包系統的技術難點、解決高并發問題通常使用的方案,以及微信紅包系統的所采用高并發解決方案

二、分享者


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

三、系列文章


❶ 系列文章目錄:


❷ 其它相關文章:


四、微信紅包的兩大業務特點


微信紅包(尤其是發在微信群里的紅包,即群紅包),業務形態上很類似網上的普通商品“秒殺”活動。

就像下面這樣:

  • 1)用戶在微信群里發一個紅包,等同于是普通商品“秒殺”活動的商品上架;
  • 2)微信群里的所有用戶搶紅包的動作,等同于“秒殺”活動中的查詢庫存;
  • 3)用戶搶到紅包后拆紅包的動作,則對應“秒殺”活動中用戶的“秒殺”動作。

不過除了上面的相同點之外,微信紅包在業務形態上與普通商品“秒殺”活動相比,還具備自身的特點。

首先:微信紅包業務比普通商品“秒殺”有更海量的并發要求。

微信紅包用戶在微信群里發一個紅包,等同于在網上發布一次商品“秒殺”活動。假設同一時間有 10 萬個群里的用戶同時在發紅包,那就相當于同一時間有 10 萬個“秒殺”活動發布出去。10 萬個微信群里的用戶同時搶紅包,將產生海量的并發請求。

其次:微信紅包業務要求更嚴格的安全級別。

微信紅包業務本質上是資金交易。微信紅包是微信支付的一個商戶,提供資金流轉服務。

用戶發紅包時,相當于在微信紅包這個商戶上使用微信支付購買一筆“錢”,并且收貨地址是微信群。當用戶支付成功后,紅包“發貨”到微信群里,群里的用戶拆開紅包后,微信紅包提供了將“錢”轉入折紅包用戶微信零錢的服務。

資金交易業務比普通商品“秒殺”活動有更高的安全級別要求。普通的商品“秒殺”商品由商戶提供,庫存是商戶預設的,“秒殺”時可以允許存在“超賣”(即實際被搶的商品數量比計劃的庫存多)、“少賣”(即實際被搶的商戶數量比計劃的庫存少)的情況。但是對于微信紅包,用戶發 100 元的紅包絕對不可以被拆出 101 元;用戶發 100 元只被領取 99 元時,剩下的 1 元在 24 小時過期后要精確地退還給發紅包用戶,不能多也不能少。

以上是微信紅包業務模型上的兩大特點。

五、 微信紅包系統的技術難點


在介紹微信紅包系統的技術難點之前,先介紹下簡單的、典型的商品“秒殺”系統的架構設計,如下圖所示。

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的_1.jpg

該系統由接入層、邏輯服務層、存儲層與緩存構成:

  • 1)Proxy 處理請求接入;
  • 2)Server 承載主要的業務邏輯;
  • 3)Cache 用于緩存庫存數量;
  • 4)DB 則用于數據持久化。

一個“秒殺”活動,對應 DB 中的一條庫存記錄。當用戶進行商品“秒殺”時,系統的主要邏輯在于 DB 中庫存的操作上。

一般來說,對 DB 的操作流程有以下三步:

  • 1)鎖庫存;
  • 2)插入“秒殺”記錄;
  • 3)更新庫存。

其中,鎖庫存是為了避免并發請求時出現“超賣”情況。同時要求這三步操作需要在一個事務中完成(所謂的事務,是指作為單個邏輯工作單元執行的一系列操作,要么完全地執行,要么完全地不執行)。

“秒殺”系統的設計難點就在這個事務操作上。商品庫存在 DB 中記為一行,大量用戶同時“秒殺”同一商品時,第一個到達 DB 的請求鎖住了這行庫存記錄。在第一個事務完成提交之前這個鎖一直被第一個請求占用,后面的所有請求需要排隊等待。同時參與“秒殺”的用戶越多,并發進 DB 的請求越多,請求排隊越嚴重。因此,并發請求搶鎖,是典型的商品“秒殺”系統的設計難點

微信紅包業務相比普通商品“秒殺”活動,具有海量并發、高安全級別要求的特點。

在微信紅包系統的設計上,除了并發請求搶鎖之外,還有以下兩個突出難點:

  • 首先,事務級操作量級大:
    上文介紹微信紅包業務特點時提到,普遍情況下同時會有數以萬計的微信群在發紅包。這個業務特點映射到微信紅包系統設計上,就是有數以萬計的“并發請求搶鎖”同時在進行。這使得 DB 的壓力比普通單個商品“庫存”被鎖要大很多倍;
  • 其次,事務性要求嚴格:
    微信紅包系統本質上是一個資金交易系統,相比普通商品“秒殺”系統有更高的事務級別要求。

六、解決高并發問題通常使用的方案


普通商品“秒殺”活動系統,解決高并發問題的方案,大體有以下幾種。

6.1方案一:使用內存操作替代實時的 DB 事務操作


如圖 2 所示,將“實時扣庫存”的行為上移到內存 Cache 中操作,內存 Cache 操作成功直接給 Server 返回成功,然后異步落 DB 持久化。

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的_2.jpg

這個方案的優點是用內存操作替代磁盤操作,提高了并發性能。

但是缺點也很明顯,在內存操作成功但 DB 持久化失敗,或者內存 Cache 故障的情況下,DB 持久化會丟數據,不適合微信紅包這種資金交易系統。

6.2方案二:使用樂觀鎖替代悲觀鎖


所謂悲觀鎖,是關系數據庫管理系統里的一種并發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作對某行數據應用了鎖,那只有當這個事務把鎖釋放,其他事務才能夠執行與該鎖沖突的操作。對應于上文分析中的“并發請求搶鎖”行為。

所謂樂觀鎖,它假設多用戶并發的事務在處理時不會彼此互相影響,各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前,每個事務會先檢查在該事務讀取數據后,有沒有其他事務又修改了該數據。如果其他事務有更新的話,正在提交的事務會進行回滾。

商品“秒殺”系統中,樂觀鎖的具體應用方法,是在 DB 的“庫存”記錄中維護一個版本號。在更新“庫存”的操作進行前,先去 DB 獲取當前版本號。在更新庫存的事務提交時,檢查該版本號是否已被其他事務修改。如果版本沒被修改,則提交事務,且版本號加 1;如果版本號已經被其他事務修改,則回滾事務,并給上層報錯。

這個方案解決了“并發請求搶鎖”的問題,可以提高 DB 的并發處理能力。

但是如果應用于微信紅包系統,則會存在下面三個問題:

  • 1)如果拆紅包采用樂觀鎖:那么在并發搶到相同版本號的拆紅包請求中,只有一個能拆紅包成功,其他的請求將事務回滾并返回失敗,給用戶報錯,用戶體驗完全不可接受;
  • 2)如果采用樂觀鎖:將會導致第一時間同時拆紅包的用戶有一部分直接返回失敗,反而那些“手慢”的用戶,有可能因為并發減小后拆紅包成功,這會帶來用戶體驗上的負面影響;
  • 3)如果采用樂觀鎖的方式:會帶來大數量的無效更新請求、事務回滾,給 DB 造成不必要的額外壓力。

基于以上原因,微信紅包系統不能采用樂觀鎖的方式解決并發搶鎖問題。

七、微信紅包系統的高并發解決方案


綜合上面的分析,微信紅包系統針對相應的技術難點,采用了下面幾個方案,解決高并發問題。

7.1系統垂直 SET 化,分而治之


微信紅包用戶發一個紅包時,微信紅包系統生成一個 ID 作為這個紅包的唯一標識。接下來這個紅包的所有發紅包、搶紅包、拆紅包、查詢紅包詳情等操作,都根據這個 ID 關聯。

紅包系統根據這個紅包 ID,按一定的規則(如按 ID 尾號取模等),垂直上下切分。切分后,一個垂直鏈條上的邏輯 Server 服務器、DB 統稱為一個 SET。

各個 SET 之間相互獨立,互相解耦。并且同一個紅包 ID 的所有請求,包括發紅包、搶紅包、拆紅包、查詳情詳情等,垂直 stick 到同一個 SET 內處理,高度內聚。通過這樣的方式,系統將所有紅包請求這個巨大的洪流分散為多股小流,互不影響,分而治之,如下圖所示。

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的_3.jpg

這個方案解決了同時存在海量事務級操作的問題,將海量化為小量。

7.2邏輯 Server 層將請求排隊,解決 DB 并發問題


紅包系統是資金交易系統,DB 操作的事務性無法避免,所以會存在“并發搶鎖”問題。但是如果到達 DB 的事務操作(也即拆紅包行為)不是并發的,而是串行的,就不會存在“并發搶鎖”的問題了。

按這個思路,為了使拆紅包的事務操作串行地進入 DB,只需要將請求在 Server 層以 FIFO(先進先出)的方式排隊,就可以達到這個效果。從而問題就集中到 Server 的 FIFO 隊列設計上。

微信紅包系統設計了分布式的、輕巧的、靈活的 FIFO 隊列方案。其具體實現如下:

首先,將同一個紅包 ID 的所有請求 stick 到同一臺 Server。

上面 SET 化方案已經介紹,同個紅包 ID 的所有請求,按紅包 ID stick 到同個 SET 中。不過在同個 SET 中,會存在多臺 Server 服務器同時連接同一臺 DB(基于容災、性能考慮,需要多臺 Server 互備、均衡壓力)。

為了使同一個紅包 ID 的所有請求,stick 到同一臺 Server 服務器上,在 SET 化的設計之外,微信紅包系統添加了一層基于紅包 ID hash 值的分流,如下圖所示。

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的_4.jpg

其次,設計單機請求排隊方案。

將 stick 到同一臺 Server 上的所有請求在被接收進程接收后,按紅包 ID 進行排隊。然后串行地進入 worker 進程(執行業務邏輯)進行處理,從而達到排隊的效果,如下圖所示。

社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的_5.jpg

最后,增加 memcached 控制并發。

為了防止 Server 中的請求隊列過載導致隊列被降級,從而所有請求擁進 DB,系統增加了與 Server 服務器同機部署的 memcached,用于控制拆同一個紅包的請求并發數。

具體來說,利用 memcached 的 CAS 原子累增操作,控制同時進入 DB 執行拆紅包事務的請求數,超過預先設定數值則直接拒絕服務。用于 DB 負載升高時的降級體驗。

通過以上三個措施,系統有效地控制了 DB 的“并發搶鎖”情況。

7.3雙維度庫表設計,保障系統性能穩定


紅包系統的分庫表規則,初期是根據紅包 ID 的 hash 值分為多庫多表。隨著紅包數據量逐漸增大,單表數據量也逐漸增加。而 DB 的性能與單表數據量有一定相關性。當單表數據量達到一定程度時,DB 性能會有大幅度下降,影響系統性能穩定性。采用冷熱分離,將歷史冷數據與當前熱數據分開存儲,可以解決這個問題。

處理微信紅包數據的冷熱分離時,系統在以紅包 ID 維度分庫表的基礎上,增加了以循環天分表的維度,形成了雙維度分庫表的特色。

具體來說,就是分庫表規則像 db_xx.t_y_dd 設計,其中,xx/y 是紅包 ID 的 hash 值后三位,dd 的取值范圍在 01~31,代表一個月天數最多 31 天。

通過這種雙維度分庫表方式,解決了 DB 單表數據量膨脹導致性能下降的問題,保障了系統性能的穩定性。同時,在熱冷分離的問題上,又使得數據搬遷變得簡單而優雅。

綜上所述:微信紅包系統在解決高并發問題上的設計,主要采用了 SET 化分治、請求排隊、雙維度分庫表等方案,使得單組 DB 的并發性能提升了 8 倍左右,取得了很好的效果。

八、本文小結


微信紅包系統是一個高并發的資金交易系統,最大的技術挑戰是保障并發性能與資金安全。

這種全新的技術挑戰,傳統的“秒殺”系統設計方案已不能完全解決。在分析了業界“秒殺”系統解決方案的基礎上,微信紅包采用了 SET 化、請求排隊串行化、雙維度分庫表等設計,形成了獨特的高并發、資金安全系統解決方案,并在平時節假日、春節紅包雨實踐中充分證明了可行性,取得了顯著的效果。以2017 雞年除夕夜為例,微信紅包收發峰值達到 76 萬每秒,收發微信紅包 142 億個,微信紅包系統的表現穩定,實現了除夕夜系統零故障。

(原文鏈接:點此進入

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


[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] 有關QQ、微信的技術故事:
技術往事:微信估值已超5千億,雷軍曾有機會收編張小龍及其Foxmail
QQ和微信兇猛成長的背后:騰訊網絡基礎架構的這些年
閑話即時通訊:騰訊的成長史本質就是一部QQ成長史
2017微信數據報告:日活躍用戶達9億、日發消息380億條
騰訊開發微信花了多少錢?技術難度真這么大?難在哪?
技術往事:創業初期的騰訊——16年前的冬天,誰動了馬化騰的代碼
技術往事:史上最全QQ圖標變遷過程,追尋IM巨人的演進歷史
技術往事:“QQ群”和“微信紅包”是怎么來的?
開發往事:深度講述2010到2015,微信一路風雨的背后
開發往事:微信千年不變的那張閃屏圖片的由來
開發往事:記錄微信3.0版背后的故事(距微信1.0發布9個月時)
一個微信實習生自述:我眼中的微信開發團隊
首次揭秘:QQ實時視頻聊天背后的神秘組織
為什么說即時通訊社交APP創業就是一個坑?
微信七年回顧:歷經多少質疑和差評,才配擁有今天的強大
前創始團隊成員分享:盤點微信的前世今生——微信成功的必然和偶然
即時通訊創業必讀:解密微信的產品定位、創新思維、設計法則等
QQ的成功,遠沒有你想象的那么順利和輕松
QQ現狀深度剖析:你還認為QQ已經被微信打敗了嗎?
[技術腦洞] 如果把14億中國人拉到一個微信群里技術上能實現嗎?
QQ和微信止步不前,意味著即時通訊社交應用創業的第2春已來?
那些年微信開發過的雞肋功能,及其帶給我們的思考
讀懂微信:從1.0到7.0版本,一個主流IM社交工具的進化史
同為IM社交產品中的王者,QQ與微信到底有什么區別
還原真實的騰訊:從最不被看好,到即時通訊巨頭的草根創業史
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大表優化方案總結
小米技術分享:解密小米搶購系統千萬高并發架構的演進和實踐
一篇讀懂分布式架構下的負載均衡技術:分類、原理、算法、常見方案等
通俗易懂:如何設計能支撐百萬并發的數據庫架構?
>> 更多同類文章 ……

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

上一篇:社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節下一篇:社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的

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

推薦方案
評論 1
,一般公司怎么用呢?
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特