融云QCon上海站深度解析：超大規模即時(shí)通訊系統

10月17日至19日，QCon全球軟件開(kāi)發(fā)大會(huì )上海站如約而至。來(lái)自 Google、Facebook、LinkedIn、Twitter、騰訊、百度、青云、融云等國內外知名企業(yè)的百余位技術(shù)專(zhuān)家受邀參會(huì )，針對人工智能、編程語(yǔ)言、業(yè)務(wù)安全、軟件性能等熱點(diǎn)話(huà)題進(jìn)行深入探討，并為與會(huì )嘉賓分享各自領(lǐng)域的技術(shù)干貨。

會(huì )議首日，融云展位便被眾多參會(huì )嘉賓圍住，分別就融云的IM技術(shù)、產(chǎn)品方案及業(yè)務(wù)合作方式等各內容進(jìn)行全面的溝通交流，融云的公有云客戶(hù)汽車(chē)之家、滬江網(wǎng)校及私有云客戶(hù)陸金所等知名企業(yè)的技術(shù)人員也來(lái)到展位交流，紛紛對融云的技術(shù)產(chǎn)品及服務(wù)表達了高度的肯定。

融云展位現場(chǎng)溝通

18日上午，融云首席架構師李淼為大家分享了《超大規模即時(shí)通訊系統性能優(yōu)化探索及實(shí)踐》主題演講，就龐大復雜的系統性能問(wèn)題該如何定位、分析以及工具排查;高并發(fā)系統的技術(shù)要點(diǎn)、難點(diǎn)、重點(diǎn)把控及措施、技巧;特定場(chǎng)景下系統性能問(wèn)題優(yōu)化可行性解決方案等內容進(jìn)入深度解析。雖然臨近午飯時(shí)間，但大量的技術(shù)干貨及精彩的案例分享，讓現場(chǎng)一度爆滿(mǎn)，很多嘉賓即使站著(zhù)也一直堅持聽(tīng)完整場(chǎng)演講;即便會(huì )議結束，還有很多人與李淼進(jìn)一步交流。

融云首席架構師李淼演講

火爆的演講現場(chǎng)

會(huì )議結束后參會(huì )嘉賓與李淼繼續溝通

以下為演講實(shí)錄摘要，希望在適用場(chǎng)景下，對開(kāi)發(fā)者有所脾益。

各位好，臨近中午了，感謝還有這么多同學(xué)和我一起分享。今天的主題是超大規模即時(shí)通訊系統性能優(yōu)化探索及實(shí)踐，介紹即時(shí)通訊模式下性能優(yōu)化如何完成。通過(guò)今天介紹的模型，大家如果有所得的話(huà)可以在系統當中做一些應用實(shí)踐。

　　性能問(wèn)題定位及關(guān)注點(diǎn)

首先說(shuō)性能問(wèn)題的關(guān)注點(diǎn)，對于程序首先最直觀(guān)的關(guān)注點(diǎn)就是程序的響應時(shí)長(cháng)。前提是響應包括你的應答必須是正確的，如果說(shuō)性能優(yōu)化完成之后結果不正確，那可以說(shuō)整個(gè)優(yōu)化失敗。

除了程序響應時(shí)長(cháng)以外我們還會(huì )關(guān)注系統、數據存儲以及數據通訊。系統有一些直觀(guān)指標可以衡量系統的健康性和系統性能。先說(shuō)CPU，我們主要關(guān)注CPU的負載及使用率;接下來(lái)是內存，內存主要關(guān)注正常的內存利用率，是否使用了虛擬內存，以及內存碎片問(wèn)題;I/O問(wèn)題則關(guān)注磁盤(pán)和網(wǎng)絡(luò )I/O問(wèn)題，I/O是整個(gè)系統優(yōu)化過(guò)程中特別需要關(guān)注的點(diǎn)，I/O如果做的好，對于整個(gè)平臺的性能提升幫助是最大的，有可能會(huì )比前面的CPU和內存還要大。

數據存儲方面，在即時(shí)通訊保證消息可靠性的情況下，優(yōu)先進(jìn)行消息存儲，通過(guò)這種方式保證消息不丟失、不亂序、不重復。對于數據存儲而言，其實(shí)和I/O有點(diǎn)類(lèi)似，對于一般的業(yè)務(wù)來(lái)講，如果數據存儲優(yōu)化的好，平臺優(yōu)化方面就完成了60%左右的工作。

一般做系統時(shí)都會(huì )遇到網(wǎng)絡(luò )相關(guān)問(wèn)題，這就會(huì )涉及到網(wǎng)絡(luò )通訊問(wèn)題，怎么想辦法降低你的數據傳輸量，或者說(shuō)降低你和網(wǎng)絡(luò )之間的交互次數，也是數據通訊里面需要完成的一個(gè)優(yōu)化。

下面通過(guò)三個(gè)階段介紹一下融云關(guān)于性能問(wèn)題的定位。第一個(gè)階段融云剛剛成立，那個(gè)時(shí)候性能問(wèn)題的定位主要是通過(guò)系統監控，配合著(zhù)系統日志以及診斷工具，主要監控服務(wù)器里面的CPU、內存及I/O指標。

對于監控來(lái)講，我們有一個(gè)類(lèi)似業(yè)務(wù)監控系統，定時(shí)對每個(gè)節點(diǎn)進(jìn)行相關(guān)性的單元測試，以此來(lái)衡量當前服務(wù)的健康狀況，以及每個(gè)系統的響應速度。當線(xiàn)上出現了系統告警時(shí)，配合日志來(lái)查看業(yè)務(wù)是否正常。

第二個(gè)階段，我們嘗試過(guò)用一些開(kāi)源的APM工具。在整個(gè)系統當中通訊模型是基于A(yíng)ctor模型做的，所以沒(méi)辦法整個(gè)構建服務(wù)監控網(wǎng)絡(luò )，只能看一些相關(guān)數據。但在座各位如果開(kāi)發(fā)系統，用APM是一個(gè)非常好的工具，可以幫助你進(jìn)行服務(wù)治理，系統監控相關(guān)的工作，同時(shí)APM也有很多商業(yè)解決方案。

第三個(gè)階段，我們在對APM調研以及試用出現問(wèn)題之后，只能想辦法自研Monitor監控系統，我們會(huì )記錄每個(gè)信令的調用時(shí)間和調用鏈路，后臺有一個(gè)數據分析平臺，我們查看一些信令前一天和今天的比值，看是不是有幅度變化;同時(shí)我們也會(huì )配合業(yè)務(wù)數據量觀(guān)測數據。一旦某個(gè)信令出現異常，我們就會(huì )進(jìn)行線(xiàn)上的服務(wù)排查。

實(shí)際上對于性能問(wèn)題的定位來(lái)講，第一個(gè)階段是最有效的，后面的手段都是輔助研發(fā)人員對于線(xiàn)上問(wèn)題的定位，這些都是相輔相成的：你判斷問(wèn)題、定位問(wèn)題需要工具，工具也可以提高你判斷問(wèn)題、定位問(wèn)題的速度。

　　高并發(fā)系統技術(shù)要點(diǎn)

對于高并發(fā)系統來(lái)講，其實(shí)技術(shù)要點(diǎn)很多，我羅列了四條：異步通訊、緩存策略、數據結構及算法、數據存儲。對于性能優(yōu)化來(lái)講，這四點(diǎn)僅僅是一部分，但如果把這四點(diǎn)做好，平臺就能得到一個(gè)很大的提升。

首先是異步通訊，對于現在的分布式系統來(lái)講，都需要對服務(wù)進(jìn)行拆分，服務(wù)拆分以后我們需要通過(guò)一種方式將服務(wù)串聯(lián)起來(lái)，現在有很多開(kāi)源的解決方案或框架，但是對于RPC來(lái)講，一般都是同步調用，有點(diǎn)類(lèi)似于訪(fǎng)問(wèn)數據庫，當前的工作線(xiàn)程需要等待調用端反饋結果。

如果說(shuō)某個(gè)服務(wù)的響應時(shí)長(cháng)十毫秒，對于調用端來(lái)講就需要等待十毫秒，為了解決這個(gè)問(wèn)題，現在很多RPC都支持異步RPC的方式，通過(guò)回調的方式解決同步RPC工作線(xiàn)程占用以及等待的問(wèn)題。

最后一個(gè)是Actor模型，Actor模型實(shí)際上在整個(gè)軟件系統上是一個(gè)屬于多線(xiàn)程數據協(xié)調的模型。所有的請求以及返回結果會(huì )以消息的方式進(jìn)行傳遞，融云也是使用了Actor模式作為服務(wù)間調用。

第二個(gè)是緩存策略，我們對于數據分為四層：首先是原始數據，這個(gè)數據是保存在數據庫里面的;第二個(gè)是分布式緩存，對于很多無(wú)狀態(tài)的服務(wù)而言，性能優(yōu)化大部分依賴(lài)于分布式緩存來(lái)完成;第三個(gè)為了對數據訪(fǎng)問(wèn)進(jìn)行加速，可能會(huì )使用一些本地進(jìn)程內緩存，由于沒(méi)有網(wǎng)絡(luò )訪(fǎng)問(wèn)，同時(shí)直接的內存訪(fǎng)問(wèn)速度更快，所以本地緩存策略也會(huì )作為服務(wù)加速的方式;最后就是客戶(hù)端緩存了，現在無(wú)論是App開(kāi)發(fā)，PC客戶(hù)開(kāi)發(fā)都可以使用用戶(hù)側的數據存儲，Web上的H5也可以使用類(lèi)似local storage解決方案，但是一旦使用了客戶(hù)端存儲，我們就需要設計一個(gè)健壯的數據同步模型。刨除客戶(hù)端緩存的問(wèn)題，為了盡可能達到使熱數據離用戶(hù)近一些這個(gè)目的，我們就需要想盡一切辦法提高緩存的命中率。

第三個(gè)是數據結構及算法，適合場(chǎng)景的高效數據結構，首先我們要明確一個(gè)事情，適合的場(chǎng)景一定要對整個(gè)系統以及業(yè)務(wù)有充分的了解，根據這個(gè)方式再選擇合適的數據結構。有的時(shí)候我們需要在時(shí)間復雜度和空間復雜度之間做權衡，什么時(shí)候拿空間換時(shí)間，什么時(shí)候拿時(shí)間換空間。另外就是算法，在開(kāi)發(fā)過(guò)程當中，一定要明確算法的時(shí)間復雜度。由于系統里的需求，你需要提高算法復雜度，這個(gè)時(shí)候開(kāi)發(fā)人員要和產(chǎn)品人員進(jìn)行協(xié)調溝通。算法復雜度太高時(shí)，就要想辦法優(yōu)化業(yè)務(wù)，甚至說(shuō)優(yōu)化場(chǎng)景。

第四數據存儲，我們依然要提場(chǎng)景的問(wèn)題。對于一般系統開(kāi)發(fā)來(lái)講，一個(gè)關(guān)系型數據庫基本上就可以滿(mǎn)足業(yè)務(wù)需求開(kāi)發(fā)了，但實(shí)際上如果僅僅通過(guò)關(guān)系型數據庫來(lái)做的話(huà)，即使能滿(mǎn)足業(yè)務(wù)需求也不一定可以滿(mǎn)足性能需求。所以說(shuō)要熟知你的業(yè)務(wù)場(chǎng)景，根據業(yè)務(wù)場(chǎng)景選擇合適的數據存儲。除此之外，還需要了解這些存儲的原理。

　　性能優(yōu)化案例

下面分享一下融云做的優(yōu)化案例，融云系統上線(xiàn)過(guò)程當中沒(méi)有出現太多的性能問(wèn)題，實(shí)際上我們更多處理的是線(xiàn)上的BUG，或者說(shuō)由于一些低級失誤產(chǎn)生的故障。

首先第一個(gè)案例，字典樹(shù)在我們優(yōu)化之后變成了雙數組字典樹(shù)，場(chǎng)景主要應用于敏感詞過(guò)濾。當時(shí)我們字典樹(shù)的實(shí)現都是以哈希多叉樹(shù)來(lái)做的，有幾個(gè)考慮：第一，敏感詞添加過(guò)程當中不需要字典樹(shù)重建，另外算法復雜度很低。有次通過(guò)監控，我們發(fā)了線(xiàn)上用于審核的系統出現了一些性能問(wèn)題，排查后發(fā)現有大量用戶(hù)錄入了很多業(yè)務(wù)上的關(guān)鍵敏感詞，這時(shí)我們將哈希樹(shù)調整為了雙數組字典樹(shù)，場(chǎng)景我們也做了一些優(yōu)化，敏感詞讓用戶(hù)進(jìn)行批量添加，防止每次都會(huì )重構。另外就是延遲，我們降低了字典樹(shù)重構的時(shí)間。最后，對于審核服務(wù)來(lái)講，優(yōu)化效果直接將CPU的使用率降低了30%。

另外一個(gè)就是跳表，轉換成環(huán)形隊列，場(chǎng)景是做一些消息存儲。消息有一個(gè)時(shí)間遞增的特性，每個(gè)消息都會(huì )有一個(gè)時(shí)間遞增的方式，用于跳表方式來(lái)講復雜度很低，同時(shí)可以進(jìn)行定向掃描，但是由于我們需要做內存保護，要對跳表進(jìn)行流量控制，插入的過(guò)程當中需要對老數據進(jìn)行淘汰，這時(shí)就需要一個(gè)特別大的鎖把內存鎖住，保證線(xiàn)程安全和防止內存溢出。但由于業(yè)務(wù)量不斷增大，我們換了一個(gè)思路，使用環(huán)形隊列，主要底線(xiàn)實(shí)現都是以數組的方式組織，同時(shí)改變之前對于消息的定位模式。之前是通過(guò)一個(gè)用戶(hù)請求的時(shí)間點(diǎn)開(kāi)始往后獲取最新數據，改變模式之后我們通過(guò)最新的數據往前進(jìn)行迭代，查到時(shí)間點(diǎn)為止，通過(guò)這樣的方式整個(gè)降低了占用時(shí)間，同時(shí)針對這塊業(yè)務(wù)吞吐量大概提高了百分之百。

性能優(yōu)化案例內存優(yōu)化篇。這個(gè)場(chǎng)景對于key縮短問(wèn)題，對于系統當中的用戶(hù)ID本身來(lái)講長(cháng)度不可控。我們通過(guò)一個(gè)哈希算法轉變進(jìn)制，變成64進(jìn)制，這樣對于超過(guò)22個(gè)字節的數據進(jìn)行壓縮，最終優(yōu)化效果把內存的利用率降低了大概10%。

第二個(gè)內存優(yōu)化主要是LRU緩存優(yōu)化，如果有大量冷數據訪(fǎng)問(wèn)到系統中之后，會(huì )把熱數據沖掉，這對于系統的吞吐量有很大影響。我們優(yōu)化的方式是做了一個(gè)二級LRU緩存，將冷熱數據按照配比進(jìn)行隔離，冷數據40%，熱數據60%，這樣系統里熱數據被淘汰的問(wèn)題便得以緩解了。

性能優(yōu)化案例。數據狀態(tài)的延遲寫(xiě)入，這個(gè)場(chǎng)景中消息里會(huì )記錄每個(gè)用戶(hù)的狀態(tài)。如果用戶(hù)收了一千條消息，數據就要被寫(xiě)入一千次，我們通過(guò)另外一種模式，消息狀態(tài)數據一直是在本地內存當中進(jìn)行寫(xiě)入，待多次寫(xiě)入直到數據不活躍后，我們才將數據寫(xiě)入真實(shí)的存儲里。通過(guò)這種優(yōu)化，將之前的多次數據寫(xiě)入變成了一次數據寫(xiě)入。

之前監控數據每天有幾千億次需要存儲和寫(xiě)入，通過(guò)添加緩存區，讓將監控數據傳輸量降低了兩個(gè)數量級。

數據存儲。首先對于消息來(lái)講，他的寫(xiě)入和讀取場(chǎng)景是比較特殊，通過(guò)自研的存儲引擎，將存儲的設備降低了一半的數據量，同時(shí)保證了整個(gè)系統的響應速度。另外，調整了數據庫的業(yè)務(wù)引擎，對于業(yè)務(wù)數據占用磁盤(pán)比較高的問(wèn)題，優(yōu)化之后的結果大概只有之前的30%左右，即存儲降低了70%。

　　系統設計把控

系統設計把控是一個(gè)總結性的內容，對于性能優(yōu)化來(lái)講首先應該關(guān)注的是系統設計，需要充分理解你的需求以及業(yè)務(wù)場(chǎng)景，根據業(yè)務(wù)場(chǎng)景來(lái)設計你的整個(gè)系統，系統設計完成之后，我們要開(kāi)始進(jìn)行架構設計，現在很多人做架構分享，例如現在比較火的微服務(wù)。但是這些架構設計大家不要拿過(guò)來(lái)直接引用，需要充分的消化，通過(guò)架構設計帶入系統設計，進(jìn)行整個(gè)架構的演進(jìn)和迭代。

另外，技術(shù)選型需要充分考慮團隊對技術(shù)的接受能力，同時(shí)一定要對每個(gè)你所選東西的原理有充分認識，這樣的話(huà)才能做出一個(gè)比較好的選擇。

最后是程序實(shí)現，是在開(kāi)發(fā)過(guò)程當中要不停進(jìn)行迭代、改進(jìn)和分享。技術(shù)沒(méi)有好壞之分，只有適合你的場(chǎng)景才是最好的。謝謝大家!