Cassandra 在 360 的實踐與改進

分享嘉賓：王鋒 奇虎360 技術總監

文章整理：王彥

內容來源：Cassandra Meetup

出品平臺：DataFunTalk

注：歡迎轉載，轉載請留言。

導讀：2010年，Dropbox 在線雲存儲在國外被用戶熟知，同時國內如360、金山、百度等各個廠商也都陸續推出了自家的網盤類產品；而在 "360雲盤" 背後的存儲技術支撐之一就是以 Cassandra 爲基礎的雲端存儲方案。自此，Cassandra 在360實現技術落地和大規模生產應用，並被持續改進優化，最終造成高峯時期超 10k+ 物理節點的使用規模，成爲互聯網公司中 Cassandra 生產環境落地規模最大的公司。

本次分享的主要內容是 Cassandra 在360的落地實踐過程當中遇到的問題，以及一些重要的改進和優化，主要包括：

Cassandra 的特色簡介

Cassandra 在360的選型

Cassandra 在360的應用場景

Cassandra 在360的技術演進

——Cassandra 的特色簡介——

Cassandra 大體有如下的特色：

Cassandra 徹底無中心化設計使得其具有極高的可用性和可平滑的拓展性，而且具備模式靈活，多數據中心，範圍查詢，列表數據結構，分佈式寫操做等優點：

❶ 因爲其架構在中小規模部署時不須要主節點，相較於徹底中心化的分佈式存儲設計具備更優的成本優點，從3臺物理機開始一直拓展到幾百臺物理機，都可徹底不停服狀況下平滑拓展，整個過程只須要把拓展節點的進程啓動加入集羣；

❷ 模式靈活使得 Cassandra 能夠在系統運行時隨意添加或移除字段，這是一個很驚人的效率提高，特別是在大型部署上；

❸ 多數據中心是指能夠調整節點佈局來避免某一個數據中心失效，一個備用的數據中心將至少有每條記錄的徹底複製；

❹ 範圍查詢是指若是你不喜歡所有的鍵值查詢，則能夠設置鍵的範圍來查詢，對於每一個用戶的索引，這是很是方便的；

❺ 分佈式寫操做是指有能夠在任何地方任什麼時候間集中讀或寫任何數據，而且不會有任何單點失敗。

除了以上幾點，Cassandra 還有以下的優勢：

❶ 海量數據，隨時在線，分佈式數據庫，性能極優

❷ always online，無中心，無單點故障引起抖動

❸ 節點對等，配置一致，線性擴展，易於維護

❹ cql/sdk 能力，易用性好，開發者 & DBA 快速上手

❺ 功能強大，主要有如下幾點功能，多 DC 兩地三中心，在線更改 schema，豐富數據結構，豐富的索引，監控及工具。

——Cassandra 在360的選型——

選型之始，咱們總結評估了雲存儲的技術需求特徵和當時可承載大規模數據的分佈式 K-V 數據庫——Cassandra 和 HBase，最終權衡以後，使用 Cassandra 作爲主要在線存儲。對於 "網盤/雲盤" 類產品，其主要流量特徵爲 "寫多讀少"，要求服務可靠性和數據安全性極高，基本不可容忍服務中斷和數據丟失的狀況。具體選型分析以下：

❶ Cassandra 相較於 HBase，前者是徹底無中心設計，然後者 ( 包括依賴的 HDFS ) 總體來看是強中心化設計，所以 Cassandra 與生俱來不存在關鍵單點故障影響服務的問題；

❷ Cassandra 使用最終一致性策略，而非 HBase 的強一致性策略，配合讀寫策略的處理，Cassandra 能夠在確保數據安全性、可靠性、一致性的前提下，出現節點宕機而不須要恢復時間，集羣讀寫不產生任何停頓，而此場景下，HBase 須要等待 region 從新分配過程，而這個過程大概會有數秒至數分鐘的待分配 region 不可讀寫；

❸ 從技術細節上，雖然兩者均採用了 LSM 的架構，但 Cassandra 直接操做本地磁盤，而 HBase 須要依賴 HDFS 共享存儲，加之上述所說的架構設計差別，同等基礎設施性能的 Cassandra 寫入性能優於 HBase 近乎一個數量級，讀性能基本持平。

綜上所述，Cassandra 能夠更好的適用於雲盤在線場景。

——Cassandra 在360的應用場景——

基於360雲盤使用 Cassandra，雲盤從15臺機器一直到14000+臺機器，應用場景主要是我的數據，本身產品中間的圖片，內部視頻對象等；在2015年，360雲盤轉型爲企業雲盤，機器數量就降低了，到2018年，智匯雲又繼續前行，目前機器差很少是3000左右的規模，以上是360的應用場景。

——Cassandra 在360的技術演進——

Cassandra 自2010在360開始調研技術落地；2011年使用 Cassandra 0.7.3做爲基礎版本應用於生產環境；2012年完善數據可靠性和安全性，實現不停機和不單純依賴讀修復的數據快速恢復；2013-2014年以節省成本爲目的，實現可擦除編碼技術應用於 Cassandra，在確保數據安全和可靠性的前提下實現成本下降60%；2014-2015年面對超大規模集羣的超複雜性問題，實現運維自動化，集羣具有自主自愈、自主風控等自主運維能力 ( 近 1w5 物理節點，89個集羣，兩人運維 )；2018年，咱們發現 Cassandra 社區版本與360版本至關因而不一樣場景異曲同工 ( 社區爲輕 Value，360爲重 Value )，而且社區不少好的思路很是值得考慮，所以咱們從新調整研發策略，與社區共同成長。

Cassandra 是一種無中心的系統，對於消息的廣播，有一些規模的限制，基本單節點到600臺的時候就差很少了，當時雲盤的集羣規模，單集羣是600臺，Cassandra 集羣規模達到了88個，磁盤使用率達到了90%，主要是爲了成本考慮，把磁盤使用率達到了90%。這其中用的是預先劃分 range，畢竟當時沒有 VNode，使用預先劃分首先是使用 RandomPartitioner，使用例如 hash，md5 讓數據隨機打到環上，這個是使用最多的；還有一種是 OrdePerservingPartitinoer，這是一種保序的方式，把一些 key 保序的存在環上，文件 I/O 使用的 standard 跟 Mmapped，Mmapped 理論上是減小內存拷貝，對性能很好，可是若是數據量漲到80%到90%的時候，Linux 內核頁表的開銷佔用量很大，因此最後放棄了 Mmapped 的方式，使用了 standard 的方式。

對於 Cassandra 的改進，第一個就是進行可靠性的改進，使用 Local Repair 跟 Backup。影響數據可靠性的因素有：

❶ One/Quorum 存在新增副本不足的問題；

❷ 磁盤/扇區故障：文件損壞、數據丟失 ( 月均故障25-30塊 )；

❸ 現有數據恢復機制存在不完善之處。

因素 ❶ 是第三副本是否能夠成功寫入的問題，使用非 ALL 策略寫入 Cassandra 時，只要知足寫入策略即返回成功，例如 quorum 級別寫入3副本數據，當兩個節點寫入成功即返回寫入成功，雖然原始設計爲了保障第三副本寫入成功使用 hintedhandoff 機制來保證，但程序設計最多能支撐3小時的時間，雖然該項可配但也受限於接入節點的存儲容量，所以360針對此問題作了優化，研發 proxycheck 功能將未成功寫入打散到全集羣，當故障節點恢復時，基於 proxycheck 會修復殘缺副本；

因素 ❷ 是磁盤故障，雖然小規模磁盤不多見磁盤損壞，但對於極大規模的存儲系統來講，磁盤故障就變得不可忽略了，而 Cassandra 的架構又決定了若是磁盤損壞形成了副本殘缺很難發現，只能等待讀修復觸發或者 repair 工具修復，但對長時間不讀取的冷數據很顯然存在較大數據風險；

因素 ❸ 是修復機制，不管是因素 ❷ 致使的仍是其餘問題形成的數據殘缺都須要恢復機制儘快恢復數據，但 Cassandra 讀修復對冷數據不友好，repair 工具會耗盡整個集羣的資源，對於這些挑戰，除了讀修復，咱們實現了一套至關於 RowRepair 的機制。

首先來講一下文件/磁盤的自動摘除， 存在的問題主要有兩點，一點是讀寫異常，SEEKIOException 影響正常讀寫，另一點是各類修復機制，Compact 機制執行失效，針對以上的兩點問題，主要採用了基於文件異常訪問次數的統計，摘除故障文件數據比重，外部發現基於 SmartCtl 規則反饋，將以上的問題反饋到系統中，就能夠精確的知道哪塊磁盤有哪些問題。

修復磁盤故障摘除，此處針對的是全量數據的磁盤故障摘除，使用全盤數據掃描恢復的目的主要有兩點，一是用來解決全量文件，因磁盤故障/文件損壞等緣由帶來的副本不足的狀況，二是文件/目錄/磁盤摘除，觸發後臺主動副本修復。全盤數據掃描修復，從 Range 的開始，三個節點都讀數據，若是數據存在衝突，就使用另外兩個節點去解決數據衝突，最後把數據恢復。每一個節點都會附一個 range，range 的主要做用就是從三個節點上把數據取過來進行比對，而後把解決衝突的數據恢復掉，另一種方式使用 KeyScan+Read-All，使用 KeyScan 拿到的是一些 key，對於大量的插入，像雲盤用戶是大量的插入比較多，刪除的操做不多，這種場景下數據存儲使用的是 key-value 的數據格式存儲，這種狀況下，若是節點上丟掉了哪些數據，能夠直接使用 key 來修復這些丟掉的數據。經過這兩種方式能夠解決文件丟失或者損壞的問題。

解決了全量數據，接着解決增量數據的檢查修復問題。增量數據檢查修復主要存在如下三個問題：

❶ 如何保證新寫入的數據副本是足夠的 ( 拒絕/超時 )

❷ 如何彌補 Hinted handoff 的缺點 ( 時間窗口 )

❸ Quorum 寫存在 W<N

針對以上問題，Hinted handoff 對於 i/o 負載或者 i/o 假死沒有考慮到，這種狀況下，Hintedhandoff 沒有去把出問題的東西記下來，時間窗口存在的問題是若是超時了，丟失的數據可能就記錄不下來，因此須要把這兩種狀況記錄下來，以便更好的解決增量數據存在的問題。其原理是：若是提供兩種方式，第一種若是 proxycheck 把 value 記錄進來之後，數據有問題，能夠直接使用另外的副本進行數據修復，還有一種若是不記錄的話，可使用 all 級別讀修復來對數據進行恢復。使用 Proxy 節點負責記錄副本不全的 row，超時拒絕致使的三個副本可能只寫成功了兩個，這種狀況也須要記錄下來，這種狀況下，實時的去作數據的恢復或者副本的補全，使用 proxycheck 表來存儲輔助的 Keyspace，把全部檢測到的副本不足的數據都記錄到這張表中，Proxy 節點還用於記錄數據的修復，把數據存儲，proxycheck 用了兩副本，這樣作會加大系統的開銷，可是數據的可靠性獲得保證。

數據的恢復，涉及到存儲，同時，還須要用到數據的備份。當時沒有所謂的多 DC 方式，都是自研的備份系統，當時 Cassandra 的集羣數量有88個，若是採用 Cassandra+Cassandra 的主備模式，那將又是88個集羣，這是對運維和成本的巨大挑戰；所以咱們選擇了在極大規模場景下擴展更好的 HBase 做爲備份存儲，使用 Cassandra ( 主 ) +HBase ( 備 ) 方案，這樣全球88個集羣數據備份集中至四大備份中心。大量的數據備份，常用的方式就是消息隊列，數據的匯聚會增長運維的成本以及數據的落地而後再去作，這樣操做的話，延時會比較高。因此在 Cassandra 中作了一個機制，每一個節點負責本身的 range 管理，能夠記錄到本身的緩存表中，從緩衝表取出來備份到數據中心，使用 Thirft 接口，HBase 跟 Cassandra 的接口徹底是兼容的，這樣設計 HBase 備份中心就至關於一個 Cassandra 的數據中心了，若是數據大量丟失，或者數據出現大量的錯誤問題，能夠直接無縫切換到 HBase 上提供服務，而後再使用 HBase 備份的數據慢慢恢復丟失的數據，用戶徹底不會感受到服務異常，提升了用戶的體驗。

前面介紹的是數據方面的問題，下面介紹下如何提升磁盤的利用率也就是下降成本。主要是利用虛擬目錄來提升磁盤的利用率，磁盤的利用率提升主要問題存在兩點：

❶ 節點數量大，SSTable 文件多，磁盤空間致使沒法作 major 消重；

❷ SSTable 文件數多，Scan 操做致使 CPU 消耗嚴重。

對於這兩個問題，當時磁盤的利用率達到50%就沒法再提升利用率，繼而咱們採用了分而治之的思想，把一個大 range 使用 Daily—Compact 完成數據 SubRange，切分爲幾個小 range，每一個 range 表明一個目錄，因爲切分之後，數據量變小，每一個 range 均可以作本身的 major，能夠把重複的部分都清除掉 ( 可是若是在磁盤利用率90%以上，作一次 major 就很消耗 CPU 性能 ) ，這樣作之後，對於 Scan 請求定位 SSTable 打開的文件會更少，效率就會更高，速度也會更快。

避免寫放大的問題。對於如何減小寫放大問題，主要存在如下兩個問題：

❶ 原有的 Compaction 機制 ( SizeTiered/Leveled ) 較難避免數據重複參與 Compaction 的問題；

❷ 尤爲在 SizeTiered 按文件大小分組 Compaction，插入刪除頻繁的業務難以消重。

針對上述問題，咱們採用給 SSTable 增長 level 概念。正常的是給每層的數據從 level 0 -> level 2，到 level 2 後，compaction 就不會參加，也就說最多作兩次。360對於這一塊作了以下的改進：讓每層的 compaction 結合虛擬目錄，在 level 0 作 compaction 的時候，分紅各類各樣的虛擬目錄進行 subrange，subrange 裏邊再去作 compaction，這樣的話，就至關於虛擬目錄沒有重複的數據出現，控制文件參與 compaction 的次數，經過這兩種方式，使磁盤的利用率達到了90%左右。

成本壓力。基於成本的考量，使用了 EC 的方式，讓3副本變成了1.4個副本，在較少副本數量的同時保證數據的可靠性，同時從數據可用性上考慮的話，數據可用性基本保持如下兩點就能夠：

❶ 副本方式，也就是連續3節點磁盤故障，數據必丟失；

❷ 條帶方式，相鄰的14節點故障任意4個數據仍可修復。

對於這個內容，EC 是把原有的數據進行塊切分，算出校驗塊，而後校驗塊打散到整個集羣中，若是丟失了幾個塊，能夠用其餘的10個塊進行修復，再把分散的塊 key 存儲到 cfindex 的表中。對於前邊的條帶方式，主要使用切分 value，value 採用的是 512k 切成等份的4等份，能夠獲得4個校驗塊，須要所有打散到不一樣的數據塊上，好比下圖中的 k13，k14 不能放到一臺機器上，這樣纔有意義，一旦數據丟失了，還能夠方便恢復，若是四個塊在一臺機器上，壞了兩臺機器就無法恢復了，key 的數據有兩部分，一個是元數據，一個是條帶數據。元數據仍是保持多副本的形式，可是算出來的條帶數據其實是按環分佈，分紅單副本的方式去存儲，這樣其實就能夠達到三副本到1.4副本，編碼能夠在線調整，還可使用指令集加速，經過指令集對 EC 進行加速，這塊比較難的問題是如何把 Key 值分散在整個環上，並且還在不一樣的機器上，若是使用 Md5 算出來 value 值看成 key 值，仍是有可能 Key 值存儲在一臺機器上，因此仍是採用了 OrderPreservingPartitioner 保序的方式去存儲。

接着作了一個 Keyspace 級別的 Patition 策略，之前的 key 存在如下問題：

❶ RandomPartition 能夠解決大部分 Key 隨機分佈的問題；
❷ key 存儲有序問題，OrderPreservingPartitioner；
❸ 是條帶數據散佈的須要，Keyspace 級別的 Partitioner 設定。
前面說 key 存儲用到了 OrderPreservingPartitioner，這樣在一套系統裏須要兩套不一樣的 partition 機制，若是進行數據交互，就須要既要保持 RandomPartition 的結構，還要保持 OrderPreservingPartitioner 的結構。這樣的話，數據交換會變的異常的複雜，因此作了一個消息傳遞，過程當中仍是使用 LongToken 去存，在使用時，仍是須要維護兩套，當撤出或者加入環中時，都要進行轉化，因此係統會看到兩套內容。

其餘的改進點以下：

❶ Hinted handoff ：外部工具，解決宕機時間過長，超過 Hinted 時間窗口；

❷ MemTable Flush 選盤策略：避免併發 dump MemTable 帶來的 CPU 開銷，避免小文件的產生；

❸ Cassandra 集羣管控，配置自動加載，磁盤自動下線報修。

PS： DataFunTalk NLP交流羣，跟同行零距離交流。如想進羣，請加逃課兒同窗的微信 ( 微信號：DataFunTalker )，回覆：NLP，逃課兒會自動拉你進羣。