本文來(lái)自微信團(tuán)隊(duì)工程師方樂(lè)明的技術(shù)分享，由InfoQ編輯發(fā)布，下文有修訂和改動(dòng)。
一、引言
微信紅包業(yè)務(wù)量級(jí)的高速發(fā)展，對(duì)后臺(tái)系統(tǒng)架構(gòu)的可用性要求越來(lái)越高。在保障微信紅包業(yè)務(wù)體驗(yàn)的前提下，紅包后臺(tái)系統(tǒng)進(jìn)行了一系列高可用方面的優(yōu)化設(shè)計(jì)。
本次分享介紹了微信紅包后臺(tái)系統(tǒng)的高可用實(shí)踐經(jīng)驗(yàn)，主要包括后臺(tái)的 set 化設(shè)計(jì)、異步化設(shè)計(jì)、訂單異地存儲(chǔ)設(shè)計(jì)、存儲(chǔ)層容災(zāi)設(shè)計(jì)與平行擴(kuò)縮容等。聽(tīng)眾可以了解到微信紅包后臺(tái)架構(gòu)的設(shè)計(jì)細(xì)節(jié)，共同探討高可用設(shè)計(jì)實(shí)踐上遇到的問(wèn)題與解決方案。
補(bǔ)充說(shuō)明：本文對(duì)應(yīng)的演講PPT詳見(jiàn)《微信紅包系統(tǒng)可用性設(shè)計(jì)實(shí)踐(PPT) [附件下載]》。
技術(shù)交流：
二、分享者
方樂(lè)明：現(xiàn)任微信支付應(yīng)用產(chǎn)品系統(tǒng)負(fù)責(zé)人，主要從事微信紅包、微信轉(zhuǎn)賬、微信群收款等支付應(yīng)用產(chǎn)品的系統(tǒng)設(shè)計(jì)、可用性提升、高性能解決方案設(shè)計(jì)等，曾連續(xù)多年負(fù)責(zé)春節(jié)微信紅包系統(tǒng)的性能優(yōu)化與穩(wěn)定性提升，取得良好的效果。
三、系列文章
系列文章目錄：
四、微信紅包介紹
微信紅包從 2014 年開(kāi)始發(fā)展到現(xiàn)在，中間經(jīng)歷了幾年時(shí)間。在這幾年的時(shí)間里，整個(gè)系統(tǒng)可用性產(chǎn)生了很大的提升。2015 年年初的時(shí)候，每天晚上九點(diǎn)鐘是微信紅包的業(yè)務(wù)高峰期，系統(tǒng)經(jīng)常性地出現(xiàn)性能問(wèn)題。到了今天，即使在節(jié)假日高峰期，系統(tǒng)也不會(huì)出現(xiàn)問(wèn)題。
▲ 紅包印象 – 產(chǎn)品形態(tài)（點(diǎn)此查看本圖出處）
如上圖所示，微信紅包的業(yè)務(wù)包含包、發(fā)、搶、拆、查詢發(fā)送紅包和收紅包數(shù)量，其中最關(guān)鍵的步驟是發(fā)紅包和搶紅包。
微信紅包是微信支付的商戶，微信紅包這個(gè)商戶出售的是錢(qián)。發(fā)紅包用戶在微信紅包平臺(tái)使用微信支付購(gòu)買(mǎi)一份錢(qián)，微信紅包將錢(qián)發(fā)放到相對(duì)應(yīng)的微信群。群里的用戶搶紅包得到微信零錢(qián)。這個(gè)過(guò)程中，微信紅包和微信支付之間的關(guān)系是商家和第三方支付平臺(tái)的關(guān)系。
微信紅包和微信支付之間的交互，與普通商家與微信支付的交互一樣，需要經(jīng)過(guò)六個(gè)步驟。用戶發(fā)紅包時(shí)，進(jìn)入微信紅包下一筆訂單，系統(tǒng)記錄發(fā)紅包用戶、發(fā)紅包金額、紅包數(shù)量和要發(fā)送到的用微信群。然后微信紅包系統(tǒng)請(qǐng)求微信支付服務(wù)器進(jìn)行下單，用戶使用微信支付進(jìn)行支付。
支付成功后，微信支付后臺(tái)系統(tǒng)通知微信紅包后臺(tái)系統(tǒng)支付成功結(jié)果，微信紅包后臺(tái)系統(tǒng)收到通知后推送微信紅包消息到微信群。微信群里用戶便可搶紅包。這就是微信紅包和微信支付的關(guān)系以及交互過(guò)程。
五、微信紅包系統(tǒng)架構(gòu)
5.1 微信紅包的系統(tǒng)流程
▲ 微信紅包的系統(tǒng)流程（點(diǎn)此查看本圖出處）
上圖是微信紅包系統(tǒng)角度上的流程，業(yè)務(wù)主流程是包、發(fā)、搶、拆四個(gè)操作，每個(gè)操作包括幾個(gè)關(guān)鍵步驟。
包紅包：系統(tǒng)為每個(gè)紅包分配一個(gè)唯一 ID，即紅包發(fā)送訂單號(hào)，然后將發(fā)紅包用戶、紅包個(gè)數(shù)、紅包數(shù)額寫(xiě)入存儲(chǔ)，最后去微信支付下單。
發(fā)紅包：用戶使用微信支付完成付款，微信紅包后臺(tái)系統(tǒng)收到微信支付系統(tǒng)的支付成功通知。紅包系統(tǒng)將紅包發(fā)送訂單狀態(tài)更新為用戶已支付，并寫(xiě)入用戶發(fā)紅包記錄（用戶發(fā)紅包記錄，就是微信錢(qián)包中，查看到的用戶每一年總共發(fā)出及收到的紅包記錄）。最后微信紅包后臺(tái)系統(tǒng)發(fā)送微信紅包消息到微信群。
搶紅包：指微信群里的用戶收到微信紅包消息后，點(diǎn)開(kāi)紅包消息。這個(gè)過(guò)程，微信紅包后臺(tái)系統(tǒng)會(huì)檢查紅包是否已被搶完，是否已過(guò)期，是否已經(jīng)搶過(guò)。
拆紅包是最復(fù)雜的業(yè)務(wù)是操作，包括：
- 1）查詢這個(gè)紅包發(fā)送訂單，判斷用戶是否可拆，然后計(jì)算本次可拆到的紅包金額；
- 2）然后寫(xiě)入一條搶紅包記錄。如果把拆紅包過(guò)程，類(lèi)比為一個(gè)秒殺活動(dòng)的過(guò)程，相當(dāng)于扣庫(kù)存與寫(xiě)入秒殺記錄的過(guò)程；
- 3）更新庫(kù)存對(duì)應(yīng)于更新紅包發(fā)送訂單，寫(xiě)入秒殺記錄對(duì)應(yīng)于寫(xiě)入這個(gè)紅包的領(lǐng)取紅包記錄；
- 4）另外，還要寫(xiě)入用戶整體的紅包領(lǐng)取記錄；
- 5）最后請(qǐng)求微信支付系統(tǒng)給拆到紅包用戶轉(zhuǎn)入零錢(qián)，成功后更新?lián)尲t包的訂單狀態(tài)為已轉(zhuǎn)賬成功。
5.2 微信紅包的整體架構(gòu)
▲ 微信紅包的系統(tǒng)架構(gòu)（點(diǎn)此查看本圖出處）
上圖所示，是微信紅包的系統(tǒng)架構(gòu)。包括微信統(tǒng)一接入層，下面是微信紅包系統(tǒng) API，包括發(fā)、搶、拆、查紅包詳情、查紅包用戶列表。再下面是封裝微信紅包關(guān)鍵業(yè)務(wù)的邏輯服務(wù)；最下面一層是數(shù)據(jù)存儲(chǔ)層，微信紅包最主要的數(shù)據(jù)是訂單數(shù)據(jù)，包括發(fā)紅包訂單和拆紅包訂單兩部分。業(yè)務(wù)邏輯和存儲(chǔ)服務(wù)器之間是數(shù)據(jù)接入層，它最重要的作用是封裝數(shù)據(jù)庫(kù)操作的領(lǐng)域邏輯，使得業(yè)務(wù)邏輯服務(wù)不需要感知對(duì) MySQL 的連接管理、性能、容災(zāi)等問(wèn)題。
微信紅包數(shù)據(jù)的訪問(wèn)熱度，隨著時(shí)間流逝會(huì)急劇降低，也就是數(shù)據(jù)的訪問(wèn)時(shí)間段非常集中，一般紅包發(fā)出三天后，99% 的用戶不會(huì)再去點(diǎn)開(kāi)這個(gè)紅包了。因此微信紅包系統(tǒng)采取按時(shí)間做冷熱數(shù)據(jù)分離，降低數(shù)據(jù)的存儲(chǔ)成本，同時(shí)提升了熱數(shù)據(jù)的訪問(wèn)性能。
數(shù)據(jù)平臺(tái)用于對(duì)紅包數(shù)據(jù)的分析計(jì)算，比如朋友圈里的文章，統(tǒng)計(jì)從 某年 1 月 1 日到 2017 年 1 月一個(gè)用戶總共搶紅包的金額，在全國(guó)的排名情況，發(fā)紅包數(shù)最多的城市等。另外一個(gè)作用就是對(duì)賬，紅包的訂單和微信支付的訂單需要對(duì)賬，以保證最終資金的一致性；訂單的數(shù)據(jù)和訂單的 cache 需要做對(duì)賬，以保證數(shù)據(jù)的完整性；訂單數(shù)據(jù)和用戶的收發(fā)記錄需要對(duì)賬，以保證用戶列表完整性。
六、微信紅包系統(tǒng)可用性實(shí)踐
6.1系統(tǒng)可用性影響因素
系統(tǒng)的可用性影響因素可分成兩類(lèi)：
- 一類(lèi)計(jì)劃外；
- 一類(lèi)計(jì)劃內(nèi)。
計(jì)劃外包含很多因素，系統(tǒng)用到的所有東西都可能產(chǎn)生故障，都可能成功影響可用性的因素。從這個(gè)角度上來(lái)講，可以說(shuō)故障是無(wú)法避免的，系統(tǒng)的運(yùn)作一定會(huì)產(chǎn)生故障，尤其是服務(wù)器有成千上萬(wàn)個(gè)的時(shí)候。計(jì)劃內(nèi)的影響因素，主要有與升級(jí)相關(guān)、運(yùn)維相關(guān)的操作，以及日常的備份等。這一類(lèi)影響因素，通過(guò)精細(xì)地設(shè)計(jì)方案，是可以避免對(duì)可用性造成影響的。
6.2微信紅包系統(tǒng)可用性設(shè)計(jì)方向
基于上面兩個(gè)分析結(jié)論，可以總結(jié)出微信紅包后臺(tái)系統(tǒng)的可用性的設(shè)計(jì)方向。就是在不能避免意外故障的情況下，盡可能降低出現(xiàn)意外故障時(shí)對(duì)可用性的影響。另一方面，絕大多數(shù)計(jì)劃內(nèi)的日常維護(hù)可以通過(guò)方案的設(shè)計(jì)避免影響可用性，其中平行擴(kuò)容特指關(guān)于存儲(chǔ)層的平行擴(kuò)容。
下面從降低故障影響和微信紅包系統(tǒng)的平行擴(kuò)容兩方面進(jìn)行分析。
首先是降低意外故障的影響，重點(diǎn)講解訂單存儲(chǔ)層在訂單 DB 故障的情況下如何降低對(duì)紅包系統(tǒng)可用性的影響。
6.3業(yè)務(wù)邏輯層 - 部署方案設(shè)計(jì)
首先是業(yè)務(wù)邏輯層的部署方案。業(yè)務(wù)邏輯層是無(wú)狀態(tài)的，微信紅包系統(tǒng)的業(yè)務(wù)邏輯層，部署在兩個(gè)城市，即兩地部署，每一個(gè)城市部署至少三個(gè)園區(qū)，即三個(gè) IDC。并且每個(gè)服務(wù)需要保證三個(gè) IDC 的部署均衡。另外，三個(gè) IDC 總服務(wù)能力需要冗余三分之一，當(dāng)一個(gè) IDC 出現(xiàn)故障時(shí)，服務(wù)能力仍然足夠。從而達(dá)到 IDC 故障不會(huì)對(duì)可用性產(chǎn)生影響。
6.4業(yè)務(wù)邏輯層 - 異步化設(shè)計(jì)
▲ 業(yè)務(wù)邏輯層 – 異步化（點(diǎn)此查看本圖出處）
第二是異步化設(shè)計(jì)。如上圖所示，微信紅包的某些步驟不實(shí)時(shí)完成也不會(huì)影響用戶對(duì)紅包業(yè)務(wù)可用性的體驗(yàn)。比如拆紅包，正常的業(yè)務(wù)流程很長(zhǎng)，但關(guān)鍵步驟只有訂單相關(guān)的幾步。至于轉(zhuǎn)零錢(qián)、寫(xiě)紅包記錄等操作不需要實(shí)時(shí)。用戶搶到紅包時(shí)，一般不會(huì)實(shí)時(shí)去錢(qián)包查看微信零錢(qián)，而是在微信群中點(diǎn)開(kāi)消息查看本次搶到金額和他人搶紅包金額。所以拆紅包時(shí)只需要從 cache 查詢用戶是否拆過(guò)紅包，然后寫(xiě)入拆紅包的訂單記錄，更新發(fā)紅包訂單，其他的操作都可以異步化。當(dāng)然，不是每個(gè)業(yè)務(wù)都可以進(jìn)行異步化設(shè)計(jì)，需要進(jìn)行業(yè)務(wù)分析，判斷是否存在非關(guān)鍵步驟之外的事情可以將其異步化，并通過(guò)異步對(duì)賬保證最終一致。
▲ 訂單存儲(chǔ)層 – 早期架構(gòu)（點(diǎn)此查看本圖出處）
接下來(lái)是微信紅包訂單存儲(chǔ)設(shè)計(jì)。上圖是 2014 年微信紅包存儲(chǔ)層的模型。業(yè)務(wù)邏輯層請(qǐng)求數(shù)據(jù)層操作時(shí)，使用訂單號(hào) hash 路由到訂單 SERVER。訂單 SERVER 與每一組 MYSQL 數(shù)據(jù)庫(kù)連接。
微信紅包的訂單號(hào)是在發(fā)紅包時(shí)系統(tǒng)生成唯一標(biāo)識(shí)，使用序列號(hào)服務(wù)生成唯一 ID，后面拼接三位微信紅包的訂單分庫(kù)表的標(biāo)識(shí)。所以，總共可以分一百個(gè)邏輯庫(kù)，每個(gè)邏輯庫(kù)含有十張表。一百個(gè)邏輯庫(kù)均勻地分布到十組物理 DB，每組 DB 存十個(gè)邏輯庫(kù)。
這個(gè)架構(gòu)的最大問(wèn)題是，一組 DB 故障時(shí)，會(huì)影響其他 DB。2014-2015 年期間，微信紅包量漲得特別快，擴(kuò)容速度跟不上業(yè)務(wù)增長(zhǎng)速度。一組 DB 的性能出現(xiàn)瓶頸時(shí)，數(shù)據(jù)操作變慢, 拆紅包的事務(wù)操作在 MYSQL 排隊(duì)等待。由于所有十組 DB 機(jī)器與所有的訂單 SERVER 連接，導(dǎo)致所有的訂單 SERVER 都被拖住，從而影響紅包整體的可用性。這個(gè)架構(gòu)的另一個(gè)問(wèn)題是擴(kuò)容不方便，后面會(huì)介紹。
為解決 DB 間的相互影響，需要將 DB 間相互隔離，訂單存儲(chǔ)層 SET 化。SET 化指訂單 DB 和訂單接入 SERVER 垂直 stick 一起。業(yè)務(wù)邏輯層訪問(wèn)訂單時(shí)，根據(jù)訂單倒數(shù)第二、三位數(shù)字找到所屬訂單 SET，一個(gè) SET 的請(qǐng)求不能路由到其他 SET。
找到對(duì)應(yīng)的訂單接入服務(wù)器之后，在服務(wù)器內(nèi)的多個(gè)進(jìn)程中找到指定進(jìn)程，讓同個(gè)紅包的所有拆請(qǐng)求串行化。當(dāng)一組 DB 出現(xiàn)故障，只會(huì)影響該組 DB 對(duì)應(yīng)的 SERVER。
這里有一個(gè)問(wèn)題，DB 故障拖住某些訂單 SERVER，會(huì)不會(huì)也拖住更上層業(yè)務(wù)邏輯服務(wù)？業(yè)務(wù)邏輯層為什么不一起 SET 化？業(yè)務(wù)邏輯層承載了用戶維度相關(guān)的業(yè)務(wù)操作，不可以按照訂單的維度分業(yè)務(wù)邏輯，例如務(wù)邏輯層會(huì)請(qǐng)求用戶的頭像、昵稱(chēng)等，如果繼續(xù)按照訂單分業(yè)務(wù)邏輯，會(huì)導(dǎo)致跨地域調(diào)用。
微信紅包系統(tǒng)采取的方案是，在訂單 SERVER 服務(wù)端增加快速拒絕服務(wù)的能力。SERVER 主動(dòng)監(jiān)控 DB 的性能情況，DB 性能下降、自身的 CPU 使用升高，或者發(fā)現(xiàn)其他的監(jiān)控維度超標(biāo)時(shí)，訂單 SERVER 直接向上層報(bào)錯(cuò)，不再去訪問(wèn) DB，以此保證業(yè)務(wù)邏輯層的可用性。
一組 DB 故障不會(huì)影響整個(gè)系統(tǒng)的可用性。有影響的，只有十分之一，若擴(kuò)成 100 組，影響便只有一百分之一。所以通過(guò) SET 化得到的好處是，控制 DB 連接數(shù)、隔離故障影響和分流并發(fā)。
▲ 訂單存儲(chǔ)層 – 故障自愈（點(diǎn)此查看本圖出處）
完成 SET 化之后，DB 故障仍對(duì)業(yè)務(wù)有十分之一影響，那么這十分之一該怎么解決？通過(guò)對(duì)系統(tǒng)進(jìn)行研究分析之后，發(fā)現(xiàn) DB 可以做到故障自愈。
如上圖所示，所設(shè)尾號(hào) 90-99 的 SET 故障時(shí)，如果業(yè)務(wù)邏輯服務(wù)后續(xù)不再生成屬于這個(gè) SET 的訂單，那后續(xù)的業(yè)務(wù)就可以逐漸恢復(fù)。
也就是在發(fā)生故障時(shí)，業(yè)務(wù)邏輯層發(fā)布一個(gè)版本，屏蔽故障號(hào)段的單號(hào)生成，就可以恢復(fù)業(yè)務(wù)。進(jìn)一步想，除了人為發(fā)版本，有沒(méi)有方法可以讓 DB 故障時(shí)自動(dòng)恢復(fù)？在 DB 故障導(dǎo)致業(yè)務(wù)失敗時(shí)，業(yè)務(wù)邏輯層可獲取到故障 DB 的號(hào)段，在發(fā)紅包時(shí)，將這些故障的號(hào)段，換一個(gè)可用的號(hào)段就可恢復(fù)業(yè)務(wù)。訂單號(hào)除了最后三位，前面的部分已能保證該紅包唯一性，后面的數(shù)字只代表著分庫(kù)表信息，故障時(shí)只需要將最后三位換另外一個(gè) SET 便可自動(dòng)恢復(fù)。
完成這個(gè)設(shè)計(jì)后，即使 DB 出現(xiàn)故障，業(yè)務(wù)的可用性也不會(huì)有影響。這里還有一點(diǎn)，新的發(fā)紅包請(qǐng)求可避免 DB 故障的影響，但那些故障之前已發(fā)出未被領(lǐng)取的紅包，紅包消息已發(fā)送到微信群，單號(hào)已確定，拆紅包時(shí)還是失敗。對(duì)這種情況，由于不會(huì)有增量，采用正常的主備切換解決即可。
6.5平行擴(kuò)縮容設(shè)計(jì)
▲ 平行擴(kuò)縮容 – 早期方案（點(diǎn)此查看本圖出處）
上圖是微信紅包早期的擴(kuò)縮容方式。這個(gè)擴(kuò)容方式，對(duì)擴(kuò)容的機(jī)器數(shù)有限制。前面講到，紅包系統(tǒng)按紅包單號(hào)后面兩個(gè)數(shù)字分多 SET，為了使擴(kuò)容后數(shù)據(jù)保持均衡，擴(kuò)容只能由 10 組 DB 擴(kuò)容到 20 組、50 組或者 100 組。另外，這個(gè)擴(kuò)容方式，過(guò)程也比較復(fù)雜。首先，數(shù)據(jù)要先從舊數(shù)據(jù)庫(kù)同步復(fù)制到新擴(kuò)容的 DB，然后部署 DB 的接入 SERVER，最后在凌晨業(yè)務(wù)低峰時(shí)停服擴(kuò)容。
這個(gè)擴(kuò)容方式的復(fù)雜性，根本原因是數(shù)據(jù)需要從舊 SET 遷到新 SET。如果新產(chǎn)生數(shù)據(jù)與舊數(shù)據(jù)沒(méi)關(guān)系，那么就可以省掉這部分的遷移動(dòng)作，不需停服輸。分析發(fā)現(xiàn)，需要把舊數(shù)據(jù)遷出來(lái)的原因是訂單號(hào)段 00-99 已全部被用，每個(gè)物理數(shù)據(jù)庫(kù)包含了 10 個(gè)邏輯庫(kù)。如果將訂單號(hào)重新設(shè)計(jì)，預(yù)留三位空間，三位數(shù)字每一個(gè)代表獨(dú)立的物理 DB，原來(lái) 10 組 DB 分別為 000-009 號(hào)段。
這種設(shè)計(jì)，縮容時(shí)，比如要縮掉 000 這組，只需在業(yè)務(wù)邏輯服務(wù)上不生成訂單號(hào)為 000 的紅包訂單。擴(kuò)容時(shí)，比如擴(kuò)為 11 組，只需多生成 010 的訂單號(hào)，這個(gè)數(shù)據(jù)便自動(dòng)寫(xiě)入新 DB。當(dāng)然，縮容需要一個(gè)前提條件，也就是冷熱分離，縮容后數(shù)據(jù)變?yōu)槔鋽?shù)據(jù)，可下線熱數(shù)據(jù)機(jī)器。以上就是紅包的平行擴(kuò)縮容方案。
▲ 改進(jìn)后的平行擴(kuò)容（點(diǎn)此查看本圖出處）
七、寫(xiě)在最后
微信紅包系統(tǒng)的可用性實(shí)踐，主要包括了部署設(shè)計(jì)、SET 化設(shè)計(jì)、異步化設(shè)計(jì)、DB 故障自愈能力建設(shè)、平行擴(kuò)容設(shè)計(jì)。在完成這些設(shè)計(jì)后，微信紅包系統(tǒng)的可用性得到了很大提升，在 近幾年的春節(jié)實(shí)現(xiàn)了 0 故障，在平常的運(yùn)行中達(dá)到 99.99% 可用性。
（原文鏈接：點(diǎn)此進(jìn)入）
八、更多鵝廠技術(shù)文章匯總
《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》
《IM全文檢索技術(shù)專(zhuān)題(二)：微信移動(dòng)端的全文檢索多音字問(wèn)題解決方案》
《騰訊技術(shù)分享：Android版手機(jī)QQ的緩存監(jiān)控與優(yōu)化實(shí)踐》
《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》
《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》
《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實(shí)踐》
《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》
《iOS后臺(tái)喚醒實(shí)戰(zhàn)：微信收款到賬語(yǔ)音提醒技術(shù)總結(jié)》
《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》
《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場(chǎng)景》
《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》
《騰訊信鴿技術(shù)分享：百億級(jí)實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》
《騰訊技術(shù)分享：GIF動(dòng)圖技術(shù)詳解及手機(jī)QQ動(dòng)態(tài)表情壓縮技術(shù)實(shí)踐》
《微信團(tuán)隊(duì)分享：Kotlin漸被認(rèn)可，Android版微信的技術(shù)嘗鮮之旅》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》
《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》
《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對(duì)2020年春節(jié)紅包的技術(shù)實(shí)踐》
《社交軟件紅包技術(shù)解密(十一)：解密微信紅包隨機(jī)算法(含代碼實(shí)現(xiàn))》
《社交軟件紅包技術(shù)解密(十三)：微信團(tuán)隊(duì)首次揭秘微信紅包算法，為何你搶到的是0.01元》
（本文已同步發(fā)布于：http://www.52im.net/thread-2564-1-1.html）