2018年10月22日，QCon全球軟體開發大會上海站成功落下帷幕。融雲聯合創始人兼首席架構師李淼再次受邀出席大會，并進行《高性能消息資料存儲引擎的設計解析》的主題演講，為參會者深入剖析了融雲首次公開的最新技術研究成果“資料存儲引擎設計”。
作為網際網路通信雲獨角獸的融雲每天要存儲的消息量高達數十億條，多年來融雲一直緻力于消息存儲的優化，從原型階段的MySQL到後來的Redis、LevelDB，融雲不停的探索實踐。随着業務的發展和資料的持續增長，融雲需要一個既能滿足業務需求，又能滿足大業務量的消息資料存儲，是以融雲研究院在2017年決定研發可以滿足自身業務特點的高性能消息存儲服務（内部代号RCTSDB），并使用全新設計的資料存儲引擎。
以下内容摘自李淼演講實錄。
融雲消息存儲曆程
首先是融雲在開始時的原型産品驗證階段，大概是在2013年初創階段，為了驗證融雲的即時通信業務模式，此時的消息都是存儲在MySQL中，其特點是開發簡單，可以滿足各種産品需求。
在原型驗證通過後，正式上線前融雲将離線消息遷移到了Redis中以滿足性能需求，而曆史消息則繼續儲存在MySQL中。
融雲經過一年多業務飛速的發展，要存儲的消息越來越多，而Redis叢集也幾乎每1-2個月就要進行擴容。當時處于對成本的考量，融雲決定采用相對低廉的磁盤存儲方案。此時融雲做了很多選型，最終決定采用基于levelDB作為存儲引擎并自研DB。但是當時的由于levelDB資料歸并消耗高，資料淘汰困難等問題，運作兩個月後替換了原來的Redis存儲方案。
目前融雲的線上情況是Redis存儲離線消息，levelDB存儲曆史消息，而融雲的業務也相對進入了平穩期，Redis最近一次擴容是在2018年的5、6月份，根據業務增速情況可以支援到2018年底。
存儲架構相對穩定，為什麼融雲還要啟動自研存儲項目呢？
- 滿足一些複雜的業務場景需求
基于目前的存儲方案，一些需求實作起來非常困難，而這些需求都是來自客戶，進而制約産品的演進，是以融雲急需一個替代方案；
- 降低整體的成本投入
融雲線上的Redis叢集成本是所有裝置投入的一半以上，對于存儲的優化，顯然是可以持續降低公司營運成本；
- 簡化部署模型
對于Redis的部署不是很複雜，但是融雲除了公有雲的業務以外還有私有雲項目，繼續使用Redis對客戶側的運維部署成本就會變的很高；
- 源碼可控
之前融雲使用過很多的開源産品，當這些産品不能滿足業務需求時，融雲又急需某些特性時，這就需要和作者聯系，但是大部分時候作者都不能及時響應或者根本不在其計劃内，而這時融雲隻能等或者自己改，自己改的又回饋不了開源産品的主幹上，或者當開源産品更新沒辦法合并，這樣就迫使融雲必須啟動自研存儲項目。
即時通信類産品，自研存儲需具備哪些特點？
- 快速的資料淘汰能力
資料淘汰的過程不能對系統産生任何的影響；
- 避免資料合并
相對于levelDB來講，當寫入很多操作的時候levelDB的資料合并經常會發生CPU報警，導緻寫入查詢響應速度慢等情況；
- 讀寫性能要求高
至少不能比融雲現有使用的Redis速度慢；
- 開發使用靈活
在融雲存儲引擎設計過程中，不僅隻是存儲資料，而是當作開發架構來進行設計的，在各操作點上都提供Hook，進而能夠滿足各種業務場景需求。
站在前人的肩膀上遠眺
融雲在存儲引擎設計過程中借鑒很多已有的成熟方案，并将這些方案進行優化整合，最終完成了自有的引擎設計。下面将羅列一些方案，并向前人緻敬。
- 資料寫入采用WAL模式
資料在寫入記憶體時同時記錄，當服務當機或重新開機的時候可以根據這些恢複記憶體資料。這些都是按照磁盤順序寫入，可以變相的提高存儲引擎性能。一般主流的資料庫都會采用這種模式完成資料寫入。
- 借鑒InfluxDB中的LSM資料結構
LSM資料結構是目前一些新興資料庫采用的資料結構，像LevelDB、RocksDB、HBase、Cassandra等。即時通訊消息具備時序資料的特點，而InfluxDB更是時序資料庫中的佼佼者，融雲對InfulxDB做了一些改造，使其更适合存儲一些時序資料
- 借鑒whiskey 的 K / V 分離存儲設計
whiskey 是2016年發表的一篇論文，主要解決了LSM中大數量寫入後頻繁資料歸并的問題，在LSM這種資料結構中，資料的Key和Value值都是要寫入記憶體的，當資料到達記憶體設定的門檻值時進行歸檔處理。對于value值較大的資料來說，這個歸檔就會變得特變頻繁，而whiskey的理念是将value單獨儲存至另外的檔案位置，LSM結構内儲存的是Key以及這個Value所在檔案的偏移量和長度，以此來降低歸檔頻。按照論文上的介紹，歸檔頻率可以降低一個數量級。
- 借鑒MyISAM的存儲檔案設計
在檔案設計這塊融雲一共經曆四版改動，最終殊途同歸。融雲發現Mysql中MyISAM引擎的檔案設計很有類似之處。
融雲消息存儲引擎設計
- 存儲邏輯劃分
2. 存儲檔案規劃
關于Table檔案分為三種檔案進行組織存儲：
- xxx.data 資料存儲檔案；
- xxx.index 資料索引檔案；
- xxx.info table資訊檔案。
檔案并沒有按照Table檔案進行劃分存儲，是按照序号字段進行排序，為的是在設計過程中解決主從複制，提高便捷性。
- 資料寫入邏輯
- 資料檔案設計
- 日志檔案設計
- 索引檔案設計
- 資訊檔案設計
記憶體優化
- 在M_block中融雲重度依賴跳表這種資料結構，融雲的存儲引擎是用java寫的，主要考慮是後面可移植的問題。起初融雲采用了java裡面内置的ConcurrentSkipList，但是其記憶體消耗很高，這個主要是java的中對象記憶體配置設定的規則導緻的。是以融雲重寫了SkipList，放棄了java中的對象模式。重新造的輪子其記憶體消耗隻有原始 1/4，同時也犧牲了一些東西，例如：删除跳表内的資料時，其删除的資料所占的記憶體無法釋放，但是對于即時通信消息來講基本上不存在删除的場景，同樣一些時序資料也極少存在删除場景；
- 索引資料融雲進行了一系列緊湊處理。優化後40億級的索引資料，隻消耗記憶體400MB。放棄java對象模式，直接采用byte數值的方式進行資料組織；
- 對很多的對象又做了一些細節處理，想辦法把Java本身的一些記憶體模型給抹平掉，通過這種方式來降低記憶體使用率；
- 最後融雲做了LIRS的緩存機制。
存儲優化
- 索引資料字首壓縮，降低磁盤的寫入量；
- 數值資料采用VarInt編碼；
- 業務資料QuickLZ壓縮，平衡了存儲及CPU的使用率；
- 資料寫入采用雙循環可變長度Buffer，使資料寫入過程中是沒有直接操作的，有效降低延遲的産生；
- 重複資料引用寫入，該優化對于即時通信場景有顯著成效。
服務端架構
該架構主要包含Broker，以及一些資料的分組Master、Slaver，這些資料是根據ZooKeeper進行管理，同時向Broker進行彙報。在Broker上會開設不同的端口去設定各種不同的協定。最後是DB manger，主要是用于管理引擎的各種資料查詢的插件，就像前文提到的該引擎除了是用于資料存儲外還是開發架構，程式員在架構上可以靈活按照熟悉的開發語言去直接操作這些資料。
資料存儲引擎項目将在年底開源
李淼在會上表示，為了促進産業内的技術交流，融雲會在未來兩個月時間對資料存儲引擎項目進行開源，開源前除了對引擎做一些優化以外，還會補充一些相關的文檔，同時為了友善開發者內建參考還會對代碼增加一些注釋。項目開源後意味着融雲是國内首家将自研的消息存儲引擎開源的雲通信廠商，也正在為中國的開源環境貢獻自己應盡的力量。
關于融雲：融雲，安全、可靠的全球網際網路通信雲服務商，向開發者和企業提供即時通訊和實時音視訊通信雲服務，據艾瑞等權威資料顯示，融雲即時通訊雲業務市場佔有率穩居第一。目前，已有數十萬網際網路使用者及上千家企業級使用者通過融雲實作了場景化溝通，并從中獲益，包括招商銀行、工商銀行、交通銀行、民生銀行、中國移動、四川航空、CCTV微視、中聯重科、58 趕集、大河報業、新東方、陸金所、易車網、豬八戒、蔚來汽車、得到APP、荔枝 FM、汽車之家、優酷來瘋、攜程愛玩、聚力視訊、百姓網等知名企業及應用。