• <strike id="fdgpu"><input id="fdgpu"></input></strike>
    <label id="fdgpu"></label>
    <s id="fdgpu"><code id="fdgpu"></code></s>

  • <label id="fdgpu"></label>
  • <span id="fdgpu"><u id="fdgpu"></u></span>

    <s id="fdgpu"><sub id="fdgpu"></sub></s>
    您當前的位置是:  首頁(yè) > 新聞 > 文章精選 >
     首頁(yè) > 新聞 > 文章精選 >

    融云高性能消息數據存儲引擎的設計解析

    2018-10-26 11:10:46   作者:   來(lái)源:CTI論壇   評論:0  點(diǎn)擊:


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

    專(zhuān)題

    亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩 安康市| 高唐县| 福州市| 山西省| 桂平市| 万宁市| 伊吾县| 顺平县| 顺义区| 霸州市| 利津县| 兰坪| 五大连池市| 云林县| 托克逊县| 竹溪县| 会同县| 临江市| 尼玛县| 夏邑县| 蕲春县| 荣成市| 自贡市| 扎囊县| 宁波市| 永安市| 博爱县| 科尔| 海口市| 台湾省| 金门县| 英山县| 利川市| 玉林市| 澎湖县| 吴旗县| 蒙阴县| 亳州市| 陕西省| 宜黄县| 九寨沟县| http://444 http://444 http://444 http://444 http://444 http://444