默認
打賞 發表評論 3
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
閱讀(3853) | 評論(3 收藏1 淘帖2 1

本文來自微信團隊工程師張文瑞的技術分享,由InfoQ編輯發布,即時通訊網收錄時有修訂和改動。原文地址:infoq.cn/article/1-billion-bonus-from-the-clouds,感謝原作者的分享。


一、引言


與傳統意義上的紅包相比,手機端的紅包似乎更符合現在年輕一代的習慣。這其中,以春節發紅包最為流行。以微信為例,除夕全天微信用戶紅包總發送量可以達到百億個,紅包峰值收發量為比百萬個/秒。

本文將由微信團隊工程師張文瑞分享微信春節搖一搖紅包技術背后的方方面面,希望能給同行們帶來啟發。

二、分享者



社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節_zhangwenrui.jpg
張文瑞:微信高級工程師,微信接入系統負責人。一直從事后臺系統設計開發,早期涉足傳統行業軟件,后投身互聯網。作為微信最早的后臺開發之一,見證了微信從零開始到逐漸發展壯大的過程。
王鵬程:微信支付商戶系統開發組組長,專家工程師。2008 年加入騰訊,6 年的電商經驗,做過 c2c、b2b2c、b2c 及 erp,2 年第三方支付開發經驗。

張文瑞還分享了微信其它方面的技術文章,您也可能感興趣:


三、系列文章


❶ 系列文章目錄:


❷ 其它相關文章:


四、搖一搖紅包系統組成


紅包系統由三部分組成:

  • 1)信息流;
  • 2)業務流;
  • 3)資金流。

這三部分在組織架構上由不同的后臺團隊完成:

  • 1)信息流——微信后臺;
  • 2)業務流——微信支付后臺;
  • 3)資金流——財付通后臺。

在平時,紅包系統主要處理個人會話中以消息形式發出的紅包,其中:

  • 1)信息流主要包括用戶操作背后的請求通信和紅包消息在不同用戶和群中的流轉;
  • 2)業務流是用戶請求引發的包紅包、搶紅包和拆紅包等的業務邏輯;
  • 3)資金流則是紅包背后的資金轉賬和入賬等流程。

微信紅包系統在春節除夕活動時和平時的實現不大一樣。在除夕活動時,除了個人紅包外,紅包系統還要處理由后臺通過搖一搖集中下發的大量企業紅包。這里邊信息流的實現變化較大。

接下來簡單介紹一下 2016 年除夕活動時的紅包系統架構。

社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節_1.jpg

如上圖所示,搖一搖紅包系統架構包括三個方面:

  • 1)資源預下載;
  • 2)搖紅包;
  • 3)拆紅包。

資源預下載:
在除夕,用戶通過搖一搖參與活動,可以搖到紅包或其他活動頁,這些頁面需要用到很多圖片、視頻或 H5 頁面等資源。在活動期間,參與用戶多,對資源的請求量很大,如果都通過實時在線訪問,服務器的網絡帶寬會面臨巨大壓力,基本無法支撐;另外,資源的尺寸比較大,下載到手機需要較長時間,用戶體驗也會很差。因此,我們采用預先下載的方式,在活動開始前幾天把資源推送給客戶端,客戶端在需要使用時直接從本地加載。

搖 / 拆紅包:
除夕的搖一搖子系統是專門為活動定制的,按時間軸進行各項活動,這里邊最重要、同時也是請求量最大的是搖紅包。從需求上看,系統需要完成兩個事:用戶可以通過搖一搖搶到紅包,紅包金額可以入到用戶的支付賬戶。在除夕,系統需要在很短時間內將幾十億個紅包發放下去,對性能和可用性要求很高。考慮到涉及資金的業務邏輯比較復雜,還有很多數據庫事務處理,耗時會比較長,于是我們將搶紅包(信息流)和紅包的賬務邏輯(業務流和資金流)異步化。將前一部分處理流程盡可能設計得輕量,讓用戶可以很快搶到紅包,然后再異步完成剩下的賬務邏輯。

那么,搶紅包階段是怎樣做到既輕量又可靠呢?

1)零 RPC 調用:

在微信后臺系統中,一般情況下客戶端發起的請求都是通過接入服務轉發給具體的業務服務處理的,會產生 RPC 調用。但對于搖一搖請求,我們將搖一搖邏輯直接嵌入接入服務中,接入服務可以直接處理搖一搖請求,派發紅包。

2)零數據庫存儲:

按一般的系統實現,用戶看到的紅包在系統中是數據庫中的數據記錄,搶紅包就是找出可用的紅包記錄,將該記錄標識為屬于某個用戶。在這種實現里,數據庫是系統的瓶頸和主要成本開銷。我們在這一過程完全不使用數據庫,可以達到幾個數量級的性能提升,同時可靠性有了更好的保障。

  • 1)支付系統將所有需要下發的紅包生成紅包票據文件 ;
  • 2)將紅包票據文件拆分后放到每一個接入服務實例中;
  • 3)接收到客戶端發起搖一搖請求后,接入服務里的搖一搖邏輯拿出一個紅包票據,在本地生成一個跟用戶綁定的加密票據,下發給客戶端;
  • 4)客戶端拿加密票據到后臺拆紅包,后臺的紅包簡化服務通過本地計算即可驗證紅包,完成搶紅包過程。

3)異步化:

用戶搶到紅包后不會同步進行后續的賬務處理,請求會被放入紅包異步隊列,再通過異步隊列轉給微信支付后臺,由微信支付后臺完成后續業務邏輯。

五、大規模集群中保證數據一致性


事實上網絡分裂很難從根本上避免,我們在設計系統時都是假設網絡分裂一定會出現,基于此思考應該采用什么方案保障系統在網絡分裂時能正常運作。

我們的方案是在每個數據中心都建設三個獨立的數據園區,可以做到在任意一個數據園區出現網絡分裂等故障,甚至徹底變成園區孤島后,另外兩個數據園區可以無損承接整個數據中心的請求。

三園區容災的關鍵就是數據一致性:我們需要做到在分裂出去的那個數據園區的數據在其他園區有個強一致的副本,這樣請求落到其他兩個園區后,可以無損完成服務。

此外在故障園區恢復后,數據在所有園區還能自動保持強一致。

微信后臺實現了基于 Quorum 算法,對數據有強一致性保證的存儲系統——KvSvr(這一存儲系統,詳見:《快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)》、《快速裂變:見證微信強大后臺架構從0到1的演進歷程(二))。

此外還有可以提供三園區強一致保證的可靠異步隊列,這次就應用在這個紅包系統中。前邊提到的部署在接入服務的紅包文件實際上也是可以實現三園區容災的,我們在每臺接入服務部署的紅包文件都會在其他數據園區有個備份。在某個數據園區故障時,我們可以在其他數據園區發放故障園區的紅包。

通常活動紅包總量非常大,活動形式也更豐富,我們會在以下方面做優化。

1)服務性能:

為提升各個服務模塊的處理性能,我們通過壓測和 Profiler 分析,發現了不少性能瓶頸點,做了大量優化。

2)業務支撐能力:

支持更加復雜的業務場景,并在客戶端和服務器都加入了很多可以后期靈活調整的預埋能力,以更好地服務產品運營。

3)可用性:

不斷提升系統可用性是我們一直努力的目標,以下 5 點很好地提高了系統的可用性。

[3.1] 系統容量評估與配額

對系統的容量需要有個準確的評估與驗證,并結合業務設計合理的配額方案和降級方案,盡可能保障系統不會過載。例如,我們評估并驗證完系統每秒最大拆紅包量后,就可以在處理用戶搖一搖請求時,限制系統每秒最大發放紅包配額,這就間接保證了拆紅包量不會超出處理能力。

[3.2] 過載保護

服務如果出現過載了,必須有能力自保,不被壓垮,并且不擴散到系統其他的服務。我們在后臺的服務框架層面具備通用的過載保護能力:服務如果處理不過來,就按請求的優先級盡快丟掉超出處理能力的請求,保證服務的有效輸出;上游調用端在部分服務實例過載時,能自動做負載均衡調整,將請求調整到負載較低的服務實例中;上游調用端發現大部分服務實例都出現過載,也可以主動丟掉部分請求,減輕后端服務器的負擔。

[3.3] 減少關鍵路徑

減少核心用戶體驗所涉及的步驟和模塊,集中力量保證關鍵路徑的可用性,從而在整體上提高可用性。我們把活動紅包的信息流和業務流進行異步化,就是基于這個考慮。跟用戶核心體驗相關的搶紅包操作,在信息流中的接入服務、紅包簡化邏輯服務和紅包異步隊列(入隊)這三個服務模塊參與下即可完成。這三個服務模塊是可以比較容易用較低成本就做到高可用的,可以較好地規避業務流和資金流中幾十甚至上百個服務模塊可能出現的風險。

[3.4] 監控指標

我們需要對系統的真實負載情況有準確及時的了解,就必須要有一套高效、可靠的監控系統,同時還要有一套有效的監控指標,監控指標不是越多越好,太多了反而會影響判斷,必須要有能準確反映問題的幾個核心指標。在我們系統里,這些核心指標一般在基礎框架集成,根據經驗來看,其中一個很有用的指標是服務的最終系統失敗。

我們把服務的失敗分為兩類:邏輯失敗和系統失敗。系統失敗一般是服務暫時不可用導致,是可通過重試來自動解決的,如果請求重試若干次仍然為系統失敗,就產生最終系統失敗。通過最終系統失敗通常可以快速定位到異常的服務,及時進行處置。

[3.5] 人工介入

我們在紅包系統內預置了很多配置開關,當自動運作的過載保護無法發揮預期作用時,可以通過人工介入,使用這些保底的手動開關迅速降低負載、恢復服務。

六、技術創新


實際上,類似的這種活動用到的技術都是現成的,并不復雜。但為什么大家會覺得很難實現呢?

主要是因為規模:用戶和請求的并發規模越大,就越難在系統的成本和可用性上達到平衡,也就是說越難實現一個低運營成本、高服務可用性的系統。

在傳統的應對這種有很大規模用戶參與的活動的實現方案里,一般會采用在客戶端過濾請求,以某種概率(基于時間或互動次數)發到服務器進行處理,這樣服務器的壓力可以大幅降低。

我們認為還可以做得更好,在這種活動的技術方案上可以有所突破——在保持低成本的前提下,全量處理用戶的每次交互。這就大大降低了客戶端的實現風險(因為客戶端的更新和覆蓋周期相對較長)。此外,服務器有了對用戶交互有了全面的控制能力和靈活調整的能力。

這些能力對活動的運營是非常可貴的。可以讓我們在活動過程中,各種復雜用戶場景下,都能做到精細的調整,給了產品運營很大的靈活性,以保證活動效果和用戶體驗。看看下面兩個例子。

我們可以精確控制和調整每次用戶交互出現什么結果,曝光哪個贊助商;
活動過程中,有個很難預估的因素——參與人數。說不準參與的用戶少了(或互動次數少了),導致紅包很久都發不完?或者參與的用戶多了(或互動次數多了),導致需要加快發放速度,更快速發完紅包?

于是我們對這個技術方案做了全面的思考和設計,最終實現了現在這個系統,可以用很低的成本實現極高的性能和可用性,在除夕活動中得到了成功的應用。

七、服務降級方案


我們曾經對搖一搖 / 朋友圈紅包照片在 2016.1.26 的預熱活動和 2016.2.7 的正式活動都做了詳細的復盤。包括活動過程中各項業務數據是否符合預期,各個模塊的表現是否符合預期等,并分析各種不符合預期表現的成因和解決措施。

在紅包系統的信息流、業務流和資金流都有很多保障用戶核心體驗的降級方案。舉幾個信息流的降級方案的例子。

a) 如果某一個數據園區出現網絡分裂等故障,完全不可用了,部署在那里的紅包怎么發下去?

紅包文件雖然在園區間有冗余存儲,但基于性能和可用性考慮,我們并不打算在各園區間維護強一致的紅包發放記錄,做到記錄級的“斷點續發”,而是將紅包文件按時段進行切分,降級為只做文件級的“斷點續發”。在某個園區不可用時,使用降級方案后,故障園區當前發放時段的紅包文件不會接著發放,僅保證下一時段的紅包能通過其他園區正常發出去。

b)活動過程中,如果用戶的交互量超過服務的處理能力了怎么辦?

正如前面所述,我們很難準確估計參與用戶量及互動次數。就本次活動而言,在系統設計之初,我們評估有 2000 萬次 / 秒的峰值請求,并在系統最終實現和部署時預留了一定的余量,提供了評估值 2.5 倍(也就是 5000 萬次 / 秒峰值請求)的系統處理能力,除夕當晚服務器處理請求峰值達到 2500 萬次 / 秒,服務實際負載低于 50%。但如果當時用戶過多,互動過于火爆,到達后臺的請求超過 5000 萬次 / 秒,系統就會進入降級模式,客戶端可以在服務器的控制下,減少請求,防止服務器過載。

c)紅包發放速度過快,后端處理不過來怎么辦?

正如前面所述,用戶搶紅包是在信息流完成的,完成后請求放到紅包異步隊列再轉到業務流。如果領取紅包請求量過大,隊列會出現積壓,紅包的入賬會出現延時,但不會導致用戶請求失敗。

類似的降級方案還有很多,每個環節都有若干個不同的降級方案,有些是針對業務專門設計的(如 a 和 b),還有些是使用基礎組件 / 服務 / 方案本身就具備的降級能力(如 c)。這些方案都遵循著一個原則:降級時,盡可能保證用戶的核心體驗

八、資金與紅包準備的難點


除夕活動資金和紅包準備的難點總體來說有以下 4 點。

1)紅包的數量:

  • a. 由于招商的不確定性,最終投入微信搖企業紅包的資金不可準確預估;
  • b. 不同的商戶其對品牌的曝光量的需求不同,有的要求多曝光,有的要求多關注,紅包金額或大或小,數量則或多或少;
  • c. 從準備到除夕當天,期間各種變化,活動方案變數很多。

紅包的數量可能從幾億到幾百億變化,資金與紅包的準備需要能夠滿足需求的巨大變化。

2)資金的就位:

  • a. 企業各行各業,營銷經費的審批流程不盡相同,資金最終支付到位時間前后差異很大,甚至有些在除夕前一周才會最終敲定支付到賬;
  • b. 某些企業可能在最后階段停止合作;
  • c. 某些企業可能在最后階段調整資金的使用方式。

以上情況會導致資金的到位時間不完全可控,本著盡可能多的資金能夠投入到活動中的原則,希望可以盡可能壓縮活動的準備時間,讓更多的資金能夠上車。

3)資金預算的配置方案(資金劇本):

  • a. 按設想的活動方案,紅包會分為三大類:圖片紅包、視頻紅包、品牌 logo 紅包。活動方案較去年又有新的變化,特別是 logo 紅包的認知度和接受度不確定,logo 紅包過度會否導致未領完而浪費資金,不容易確定 logo 紅包的資金占比;
  • b. 除夕當天的活動劇本可能會反復調整優化,紅包時段的劃分可能修改,不同時段的資金投放量可能變化。

大筆資金、大量的紅包、復雜的活動方案、善變的商戶要求,都可能反復調整,如果面對百億量級的紅包配置調整時,技術上如何實現縮短準備時間,支持方便的變化。

4)資金的安全:

  • a. 如何防止紅包的金額被篡改;
  • b. 如何防止未被領取的紅包被入賬給用戶;
  • c. 如何防止紅包金額重復入賬給用戶;
  • d. 如何防止機器被攻破產生了不存在的紅包;
  • e. 如何防止紅包被不同用戶重復領取;
  • f. 如何在確保資金安全的情況下盡可能保證用戶的到賬體驗(最好是實時或準實時到賬)。

技術上必須做萬無一失的準備,確保資金足夠安全,活動順利完成。

九、微信搖企業紅包全過程


如果在除夕當天搖的過程中按前邊提到的超級復雜的配置方案即時生成隨機紅包,這顯然是風險齊高邏輯奇復雜的。對待只許成功不許失敗的項目,主流程必須極簡高效,所以這里全部的資金和紅包數量都需要按方案規則提前切分和準備好。

將預生成好的紅包數據(預紅包數據)進行準確的部署,搖紅包的資金和紅包準備的整體流程方案有兩個選擇。

社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節_2.jpg

方案一:預紅包數據提供部署給微信的接入機和寫入紅包 DB,搖紅包過程由紅包接入機控制紅包的發放,拆紅包時修改紅包 DB 中的紅包數據;
方案二:預紅包數據只提供部署給微信接入機,搖紅包過程由紅包接入機控制紅包的發放,拆紅包直接 Insert 到紅包 DB。

第二個方案減少一次 DB 操作,如果是百億量級的紅包數據,可以極大減少數據導入、對賬等活動準備時間,特別是方案需要變更時。

十、充足準備


10.1對資金預算和資金劇本進行合理的建模


首先,面對如此大量的資金和復雜的資金劇本,如何準確高效地管理和控制邏輯呢?要杜絕傻大黑粗,我們需要一個優雅的解決方案——建模。

社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節_3.jpg

對資金預算和資金劇本進行合理的建模,讓模型涵蓋、掌管、控制一切——讓工具基于模型進行自動化的處理和校驗。

這里需要做的就是:

  • 1)落地該模型的設計,讓一切圍著模型轉;
  • 2)按規定的格式文件導入預算和配置,并進行數據和邏輯合理性校驗;
  • 3)一切利用工具進行處理,資金的支付、退款、紅包的隨機生成和多商戶隨機打散、預紅包文件分割、預紅包數據的校驗,減少人為過程導致的潛在失誤;
  • 4)優化紅包隨機算法和文件處理方法,將紅包隨機分割和多商戶隨機打散算法的 n^2 時間復雜度優化 n,壓測 30 億紅包的生成時間為 2~3 小時,極大縮減準備時間,增加方案調整的回旋時間,可以讓更多的資金上車。

其次,前邊提到方案有如此多的變數、調整、變更,如何支持?還是回歸模型,建模時就要考慮支持同樣的預算多套資金配置方案。

社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節_4.jpg

同樣的資金預算,同時或依次生成多套預紅包數據文件,提前做多手準備,方便方案變更。

再次,如此大量的資金就意味著如此大量的誘惑,會不會出問題呢?

  • 1)方案預紅包數據未提前落地 DB,導致拆紅包時缺少一次紅包數據有效性的檢驗;
  • 2)預紅包數據存放在微信接入機上,存在被攻陷獲取或篡改的可能;
  • 3)紅包數據在傳輸的過程中存在系統異常或惡意攻擊,導致數據錯誤特別是金額錯誤的可能;
  • 4)系統內部可能存在惡意人員直接調用拆紅包的接口寫入不存在的紅包。

墨菲定律要求我們必須重視以上安全隱患,解決方案就是加密——對預紅包數據進行加密,加密庫和解密庫獨立維護保證密鑰不被泄漏,通過工具生成預紅包數據時用密鑰進行加密,預紅包數據在部署存儲和傳輸的過程中保持加密狀態,僅在拆紅包的邏輯中編譯二進制緊密庫進行解密。

同時,雞蛋也不能放在一個籃子里,為了控制密鑰泄漏導致的影響,確保資金風險可控,整個預生成的紅包數據可能分別使用了幾百到幾千個密鑰進行加密,一個密鑰加密的紅包資金量在 20~30 萬。解密庫還需要能設置密鑰 ID 的白名單和黑名單,確保未被使用的密鑰不能被利用,確認泄漏的密鑰可以進行攔截。

10.1極限壓縮


如果是百億個紅包,那么產生預紅包數據文件的大小不經過壓縮是非常恐怖的,傳輸部署幾百 GB 或幾 TB 的數據是很艱苦的,一旦發生調整變更會變得非常艱難,所以需要對數據進行極限的壓縮。

數據進行極限的壓縮的實施內容:

  • 1)對于支付單號、商戶號、紅包賬戶等信息,由工具導成配置文件,配置到拆紅包邏輯中,加密的紅包數據中僅用一個批次 ID 表達;
  • 2)拆分紅包 ID,部分分段同樣轉為 ID,解密庫解密后利用配置進行還原;
  • 3)加密部分(Ticket):紅包 ID、金額、批次 ID、密鑰 ID,壓縮到 16 字節;
  • 4)單條紅包記錄二進制表達,壓縮到 26 字節。

10.3對賬


上面所有都做到就安全了么?真的就有人寫了一個不存在紅包進來會怎樣?是否還有其他未考慮到的潛在風險?所以我們需要一個兜底——對賬,把一切都要對清楚才放心。

對賬后再入賬的時效在 30~60 分鐘,會造成不好的用戶體驗。為了提升用戶體驗,將大額的預紅包數據(占比 10% 左右)導入 KV(高速緩存),拆紅包時進行即時校驗,即時進行轉賬入賬,未命中 KV 的紅包則等待對賬后異步完成入賬。

主要要點有:

  • 1)資金配置與資金預算要總分對賬;
  • 2)紅包數據文件與資金劇本進行總分對賬;
  • 3)紅包數據進行全局去重驗證;
  • 4)紅包數據進行解密驗證和金額驗證;
  • 5)如果密鑰泄漏紅包金額等被篡改,兜底要進行紅包 DB 中已拆紅包數據與預紅包數據的對賬后,才能實際進行轉賬入賬。

十一、本文小結


未來我們可能還繼續會有類似的活動,雖然我們已經有了一個經過實踐的可復用的技術方案,接下來我們希望能夠繼續優化,并實現一些可復用的模塊和服務,可以快速應用到下一次活動或者其他業務場景中。例如,我們在當初的 2015 年春節首次完成除夕活動后,就把其中的資源預下載系統進行了完善和通用化,隨后應用在多個業務場景和后來的 2016 年除夕活動中。未來可以有更多類似的系統和服務可以被復用和通用化。

(原文鏈接:https://www.infoq.cn/article/1-billion-bonus-from-the-clouds

附錄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的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
>> 更多同類文章 ……

[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與微信到底有什么區別
還原真實的騰訊:從最不被看好,到即時通訊巨頭的草根創業史
>> 更多同類文章 ……

附錄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的艱辛成長之路
>> 更多同類文章 ……

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

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

上一篇:社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進下一篇:社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的

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

推薦方案
評論 3
學習
零數據庫存儲,這塊比較神秘啊!你的業務邏輯是什么?如何通過零數據庫存儲滿足業務邏輯的!

應該說的是利用內存緩存
簽名: 《網易云信技術分享:IM中的萬人群聊技術方案實踐總結》http://www.emxvra.tw/thread-2707-1-1.html
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
777彩票走势图表