PB級數據持久化緩存系統——lest

本文根據徐海峰2018年5月12日在【第九屆中國資料庫技術大會】上的演講內容整理而成。

講師介紹：

徐海峰，花名：大嘴。10年互聯網經驗。現任閱文集團首席架構師、技術專家。主要負責閱文集團內容中心分散式系統的架構與實現、海量數據的分散式存儲與分散式計算。兼負責公司的專利、技術等開源佈道。曾任ctrip國際機票計價引擎架構師、5173分散式存儲與計算架構師等工作。多年來一直專心致力於網站的分散式架構、海量數據存儲與計算等中間件的研究與實現，並形成有成型的技術認知與理論體系。對大型網站的架構與分散式系統有豐富的實戰經驗。

內容摘要：

通常的緩存系統(典型如memcahed)普遍都將數據內存化，而不支持持久化。縱使後來的Redis解決了數據無法持久化的「硬傷」，但通常緩存系統的持久化功能是否啟用也一直是一個讓人很糾結的問題。之所以糾結主要是幾個原因：1. 緩存系統啟用持久化後性能明顯下降;2. 數據開啟了持久化，但機器down機恢復後依然無法使用或者數據無法自動更新到最新版本;3. 主存依然是內存，所以數據大小需受制於內存，依然無法存儲比內存大的數據，故持久化僅僅是備份;4. 設計的時候沒考慮持久化，啟用持久化後使用非常彆扭;而我們的lest從設計開始就解決了這些問題，並且還帶來了更多很有意思、也很有實用價值的技術，比如私有的通訊與存儲協議、全程無鎖的多線程模型等等。

正文演講：

今天主要是想和大家分享我們現在用的持久化緩存—lest，說是緩存，但因為是持久化，所以我個人認為稱作存儲系統可能更好一些，它確實是KV結構，並且包含了String、List、Map等等。目前已上線使用，支持1PB到2PB的數據。

講到緩存，在大家的印象中緩存像什麼?其實緩存和神葯有很多的相同之處，首先它們都是為了解決「行不行」的問題，使用之後99%作用明顯，1%無作用，而且是立馬見效，通常會在幾分鐘或者幾小時失效，而且都是走的「治標治本」的路子，多級緩存，從客戶端到資料庫。

除此之外，二者的出發點都是為了穩定、快速和持久，通常用戶都是不管三七二十一，先用了再說，且還會產生心理依賴，領導對於其效果也會比較滿意，自己也感覺從苦逼碼農晉陞到了金光閃閃的框架師。

雖然現實生活中我們很難拒絕使用緩存，但是緩存用多了也會出現很多問題，尤其是當數據量大和機器多了以後，各種問題就會接踵而至。例如現在的緩存基本都是內存式的，一斷電數據就沒有了，恢復起來也是相當困難。

做了主備之後，你會發現備機其實沒有什麼用，主機宕了，切到備機上，很多數據都是不同步的，想要同步還需要時間。前兩天，我們還討論，主備好像沒什麼用，還是多主比較好用。

最關鍵的問題就是很難管理。緩存用了之後就扔不了，只敢加量，不敢減量。緩存伺服器越來越多，可能從一台變成了兩台、四台、八台……不僅管理成本越來越高，寫代碼也變得很複雜，因為很多緩存系統都會為了速度快而設在客戶端，所以，每增加一個機器，所有的客戶端都要配置，可能有的做得好的團隊會有配置系統自動完成，但要是做的不好的團隊，就需要重新發布一下程序，如果要是個新手，很可能還會給你寫成個死的。

所以，歸根結底還是要強身健體的，為了杜絕這些情況，我們實現了Lest。

首先就是緩存同步，可以做到擴容時無感知;第二，主機宕機了也能很容易的起來，備機可能需要稍微頂一下，但主機必須很快起來，因為我們的訪問基本上一天七、八億次，如果主機宕掉打到資料庫上，緩存穿透的話，那就基本上完了。所以我們採用了上述四個策略來解決了這個問題。

我們的緩存內容是String、List和Map。這其中List和Map的存儲比較難做，因為其包含有結構的數據。例如，如果要在List中查詢從第二個到第十個的數據，Redis很容易就做到了，但如果是全內存，存儲在磁碟上就比較困難。

所以，我們自己做了一些設計來實現，上圖中就是我們的總體架構圖。右上是Tracker，類似於很多大廠都在做的緩存代理層，接下來是存儲機器，操作機器會分段，如256段、128段等等，數據會分配到不同的段上去。通訊和存儲的實現，我們用了自己設計的協議。

負載均衡，其實是老生常談了，緩存的一個最大特點就是key要自定義。業務自定義因為要存儲到磁碟上，因此很難做類似元數據管理的工作。我們選擇的方式是Hash，不過使用Hash比較麻煩的地方是，如果機器增加的話，Hash值也會發生變化。所以，我們在增加機器的時候會有一個小竅門，以2*數字的方式去增加，比如一台變兩台，兩條邊四台，四台變八台。這種方式同步量是最少的，50%，假設你是一台變三台，那麼動的數據就是66.7%。如果大家是使用Hash，我建議大家用2*數字的擴容方式會比較好。

數據存儲下來之後，我們就需要同步，我們有組的標籤，同組之內可以數據同步，相互備份，它是沒有Slave的，全部都是主。這裡會牽扯到版本問題，我們後面會講到。

負載均衡的演算法就是二次Hash到加權二次Hash的演變，剛開始的時候，我們使用兩次Hash去做，第一次Hash得到段，第二次Hash得到是哪台機器，但其實ID生成器生成的ID因為業務的關係並不均衡，這導致緩存的存儲量大小很偏，可能出現一台機器中有20%，另一台則有80%。

這種情況也很好處理，加權就可以了，相當於一致性Hash，每台機器都有一個類似7%這樣的素數百分數加權。為什麼選擇素數呢?這是因為對素數Hash會比較均勻。

我們在磁碟上做了一個256×256的文件夾，在磁碟層面就把一些文件打亂。我們知道磁碟對小文件其實是比較可怕的，因為使用SSD，我們現在的成本還是比較高，之後我們會考慮使用磁碟，會加類似B樹這樣子的東西。

目前，因為考慮到有很多小文件，選用了SSD，從而避免掉了磁碟會遇到的一些問題。如果是1億KB的數據，經過Hash放到一個文件夾中大概也只有幾百KB，不會超過3000KB，這個壓力還是可以接受的。

上圖是數據存儲的模型，最前面是Head，頭部加了很多元數據。比如整個是一個string，那麼黃色的部分是客戶端存下來的真正內容，len表示長度，Version表示版本，我們整套都是用C來寫的，因此性能大概會提升十倍以上。並且我們還做了一個保證單調遞增的ID生成器，它的演算法其實就是一個時間向量演算法的衍生，解決了版本控制的問題，換句話說就是哪個數字最大，肯定就是最後的版本。Reserved代表類型，這裡存的可能是string、list或者是map。同時為了未來的擴展，我們還會有一個預留出來的地方。

其實List和Map與String差不多，大家看圖即可，就不再一一介紹了。

這些存儲如果要手工實現可能有些困難，所以我們去做了一個HMS對象，這是一個支持全部類型的數據協議，包括int、long等等。最經典的使用方式是部署在伺服器端，因為伺服器端使用C無法像Java那樣反射，這時我們會用一個數學結構來代表整個內容，如果使用Key的話可以達到log N的查詢效率。

以上是我們做的API，幾乎可以支持所有的操作，用法與Redis差不多，Redis能做的操作，lest基本也能做。

同步架構如上圖，如果是同組的話，兩個storage之間到Tracker上拿到數據，然後再做同步，這其中還會涉及到一個高速IP協議。

每次記錄都會產生binlog，將binlog分門別類的記下來，然後去其上讀即可。

同步複製狀態，狀態轉移就是1+1大於等於2，控制簡單，傳輸數據量大，而複製狀態機，控制比較複雜，傳輸的數據其實很少。

上圖是我們第一次對lest做性能測試得到的結果。前段時間，我們申請到了新的機器，我們又重新做了一遍測試。

上圖是處理請求正確響應數，其中紅色的是萬兆伺服器+SSD，黃色的是千兆伺服器+SATA硬碟。得到的這個性能結果我個人認為還有提升空間，因為我們的客戶端不夠多，只有十台，至少要有二三十台才能壓出它的真實性能。現在的性能數據差不多是它真正性能的60%。

從圖中我們可以看到，當數據達到10K以上，性能其實一直在走下坡路，如果大家去對比Redis也會發現，當數據到10K，Redis性能也會下降45%。這說明緩存還是和小數據更合拍。

上圖是最大響應時間，圖中的822我也不知道怎麼來的，可能是一個特別異常的值，除去這個值，其它數值的狀態還是比較平穩的，最大響應時間的單位是毫秒，基本上是在一兩百毫秒之間。

上圖是最小響應時間，其值基本分布在一點幾毫秒。

上圖是傳輸量，也就是網卡，很明顯，萬兆佔據優勢，這是因為它本來就比千兆要大，其可能只打到了80%，還有10%的增長空間。

上圖是SSD伺服器壓力，CPU的狀況差不多，如果十個伺服器瘋狂打，那麼CPU的壓力在20%左右，隨著數據變大，處理時間變多，CPU壓力就下降了。圖中還有網路的出和入，其中入會比較小，而出會比較大，如果是Redis，出會更大。

Lest的優劣勢很明顯，它是一個吃磁碟不太吃內存的東西，具體優劣勢可參考上圖。相比來說，如果使用Redis伺服器需要二三十台的場景，lest三台就可以扛下來。另外，相比其它緩存，lest基本可以做到寫代碼無感知，另外，我比較推薦使用SSD，因為現在SSD還是蠻便宜的，比內存要便宜。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！