分享嘉賓：王鋒 奇虎360 技術總監 文章整理：王彥 內容來源：Cassandra Meetup 出品平臺：DataFunTalk 註：歡迎轉載，轉載請留言。 導讀：2010年，Dropbox 線上雲存儲在國外被用戶熟知，同時國內如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，逃課兒會自動拉你進群。
