本文根據(jù)徐海峰2018年5月12日在【第九屆中國數(shù)據(jù)庫技術(shù)大會】上的演講內(nèi)容整理而成。
講師介紹：
徐海峰，花名：大嘴。10年互聯(lián)網(wǎng)經(jīng)驗?，F(xiàn)任閱文集團(tuán)首席架構(gòu)師、技術(shù)專家。主要負(fù)責(zé)閱文集團(tuán)內(nèi)容中心分布式系統(tǒng)的架構(gòu)與實現(xiàn)、海量數(shù)據(jù)的分布式存儲與分布式計算。兼負(fù)責(zé)公司的專利、技術(shù)等開源布道。曾任ctrip國際機(jī)票計價引擎架構(gòu)師、5173分布式存儲與計算架構(gòu)師等工作。多年來一直專心致力于網(wǎng)站的分布式架構(gòu)、海量數(shù)據(jù)存儲與計算等中間件的研究與實現(xiàn)，并形成有成型的技術(shù)認(rèn)知與理論體系。對大型網(wǎng)站的架構(gòu)與分布式系統(tǒng)有豐富的實戰(zhàn)經(jīng)驗。
內(nèi)容摘要：
通常的緩存系統(tǒng)(典型如memcahed)普遍都將數(shù)據(jù)內(nèi)存化，而不支持持久化?？v使后來的Redis解決了數(shù)據(jù)無法持久化的“硬傷”，但通常緩存系統(tǒng)的持久化功能是否啟用也一直是一個讓人很糾結(jié)的問題。之所以糾結(jié)主要是幾個原因：1. 緩存系統(tǒng)啟用持久化后性能明顯下降;2. 數(shù)據(jù)開啟了持久化，但機(jī)器down機(jī)恢復(fù)后依然無法使用或者數(shù)據(jù)無法自動更新到最新版本;3. 主存依然是內(nèi)存，所以數(shù)據(jù)大小需受制于內(nèi)存，依然無法存儲比內(nèi)存大的數(shù)據(jù)，故持久化僅僅是備份;4. 設(shè)計的時候沒考慮持久化，啟用持久化后使用非常別扭;而我們的lest從設(shè)計開始就解決了這些問題，并且還帶來了更多很有意思、也很有實用價值的技術(shù)，比如私有的通訊與存儲協(xié)議、全程無鎖的多線程模型等等。
正文演講：
今天主要是想和大家分享我們現(xiàn)在用的持久化緩存—lest，說是緩存，但因為是持久化，所以我個人認(rèn)為稱作存儲系統(tǒng)可能更好一些，它確實是KV結(jié)構(gòu)，并且包含了String、List、Map等等。目前已上線使用，支持1PB到2PB的數(shù)據(jù)。
講到緩存，在大家的印象中緩存像什么?其實緩存和神藥有很多的相同之處，首先它們都是為了解決“行不行”的問題，使用之后99%作用明顯，1%無作用，而且是立馬見效，通常會在幾分鐘或者幾小時失效，而且都是走的“治標(biāo)治本”的路子，多級緩存，從客戶端到數(shù)據(jù)庫。
除此之外，二者的出發(fā)點都是為了穩(wěn)定、快速和持久，通常用戶都是不管三七二十一，先用了再說，且還會產(chǎn)生心理依賴，領(lǐng)導(dǎo)對于其效果也會比較滿意，自己也感覺從苦逼碼農(nóng)晉升到了金光閃閃的框架師。
雖然現(xiàn)實生活中我們很難拒絕使用緩存，但是緩存用多了也會出現(xiàn)很多問題，尤其是當(dāng)數(shù)據(jù)量大和機(jī)器多了以后，各種問題就會接踵而至。例如現(xiàn)在的緩存基本都是內(nèi)存式的，一斷電數(shù)據(jù)就沒有了，恢復(fù)起來也是相當(dāng)困難。
做了主備之后，你會發(fā)現(xiàn)備機(jī)其實沒有什么用，主機(jī)宕了，切到備機(jī)上，很多數(shù)據(jù)都是不同步的，想要同步還需要時間。前兩天，我們還討論，主備好像沒什么用，還是多主比較好用。
最關(guān)鍵的問題就是很難管理。緩存用了之后就扔不了，只敢加量，不敢減量。緩存服務(wù)器越來越多，可能從一臺變成了兩臺、四臺、八臺……不僅管理成本越來越高，寫代碼也變得很復(fù)雜，因為很多緩存系統(tǒng)都會為了速度快而設(shè)在客戶端，所以，每增加一個機(jī)器，所有的客戶端都要配置，可能有的做得好的團(tuán)隊會有配置系統(tǒng)自動完成，但要是做的不好的團(tuán)隊，就需要重新發(fā)布一下程序，如果要是個新手，很可能還會給你寫成個死的。
所以，歸根結(jié)底還是要強(qiáng)身健體的，為了杜絕這些情況，我們實現(xiàn)了Lest。
首先就是緩存同步，可以做到擴(kuò)容時無感知;第二，主機(jī)宕機(jī)了也能很容易的起來，備機(jī)可能需要稍微頂一下，但主機(jī)必須很快起來，因為我們的訪問基本上一天七、八億次，如果主機(jī)宕掉打到數(shù)據(jù)庫上，緩存穿透的話，那就基本上完了。所以我們采用了上述四個策略來解決了這個問題。
我們的緩存內(nèi)容是String、List和Map。這其中List和Map的存儲比較難做，因為其包含有結(jié)構(gòu)的數(shù)據(jù)。例如，如果要在List中查詢從第二個到第十個的數(shù)據(jù)，Redis很容易就做到了，但如果是全內(nèi)存，存儲在磁盤上就比較困難。
所以，我們自己做了一些設(shè)計來實現(xiàn)，上圖中就是我們的總體架構(gòu)圖。右上是Tracker，類似于很多大廠都在做的緩存代理層，接下來是存儲機(jī)器，操作機(jī)器會分段，如256段、128段等等，數(shù)據(jù)會分配到不同的段上去。通訊和存儲的實現(xiàn)，我們用了自己設(shè)計的協(xié)議。
負(fù)載均衡，其實是老生常談了，緩存的一個大特點就是key要自定義。業(yè)務(wù)自定義因為要存儲到磁盤上，因此很難做類似元數(shù)據(jù)管理的工作。我們選擇的方式是Hash，不過使用Hash比較麻煩的地方是，如果機(jī)器增加的話，Hash值也會發(fā)生變化。所以，我們在增加機(jī)器的時候會有一個小竅門，以2*數(shù)字的方式去增加，比如一臺變兩臺，兩條邊四臺，四臺變八臺。這種方式同步量是最少的，50%，假設(shè)你是一臺變?nèi)_，那么動的數(shù)據(jù)就是66.7%。如果大家是使用Hash，我建議大家用2*數(shù)字的擴(kuò)容方式會比較好。
數(shù)據(jù)存儲下來之后，我們就需要同步，我們有組的標(biāo)簽，同組之內(nèi)可以數(shù)據(jù)同步，相互備份，它是沒有Slave的，全部都是主。這里會牽扯到版本問題，我們后面會講到。
負(fù)載均衡的算法就是二次Hash到加權(quán)二次Hash的演變，剛開始的時候，我們使用兩次Hash去做，第一次Hash得到段，第二次Hash得到是哪臺機(jī)器，但其實ID生成器生成的ID因為業(yè)務(wù)的關(guān)系并不均衡，這導(dǎo)致緩存的存儲量大小很偏，可能出現(xiàn)一臺機(jī)器中有20%，另一臺則有80%。
這種情況也很好處理，加權(quán)就可以了，相當(dāng)于一致性Hash，每臺機(jī)器都有一個類似7%這樣的素數(shù)百分?jǐn)?shù)加權(quán)。為什么選擇素數(shù)呢?這是因為對素數(shù)Hash會比較均勻。
我們在磁盤上做了一個256×256的文件夾，在磁盤層面就把一些文件打亂。我們知道磁盤對小文件其實是比較可怕的，因為使用SSD，我們現(xiàn)在的成本還是比較高，之后我們會考慮使用磁盤，會加類似B樹這樣子的東西。
目前，因為考慮到有很多小文件，選用了SSD，從而避免掉了磁盤會遇到的一些問題。如果是1億KB的數(shù)據(jù)，經(jīng)過Hash放到一個文件夾中大概也只有幾百KB，不會超過3000KB，這個壓力還是可以接受的。
上圖是數(shù)據(jù)存儲的模型，最前面是Head，頭部加了很多元數(shù)據(jù)。比如整個是一個string，那么黃色的部分是客戶端存下來的真正內(nèi)容，len表示長度，Version表示版本，我們整套都是用C來寫的，因此性能大概會提升十倍以上。并且我們還做了一個保證單調(diào)遞增的ID生成器，它的算法其實就是一個時間向量算法的衍生，解決了版本控制的問題，換句話說就是哪個數(shù)字大，肯定就是最后的版本。Reserved代表類型，這里存的可能是string、list或者是map。同時為了未來的擴(kuò)展，我們還會有一個預(yù)留出來的地方。
其實List和Map與String差不多，大家看圖即可，就不再一一介紹了。
這些存儲如果要手工實現(xiàn)可能有些困難，所以我們?nèi)プ隽艘粋€HMS對象，這是一個支持全部類型的數(shù)據(jù)協(xié)議，包括int、long等等。最經(jīng)典的使用方式是部署在服務(wù)器端，因為服務(wù)器端使用C無法像Java那樣反射，這時我們會用一個數(shù)學(xué)結(jié)構(gòu)來代表整個內(nèi)容，如果使用Key的話可以達(dá)到log N的查詢效率。
以上是我們做的API，幾乎可以支持所有的操作，用法與Redis差不多，Redis能做的操作，lest基本也能做。
同步架構(gòu)如上圖，如果是同組的話，兩個storage之間到Tracker上拿到數(shù)據(jù)，然后再做同步，這其中還會涉及到一個高速IP協(xié)議。
每次記錄都會產(chǎn)生binlog，將binlog分門別類的記下來，然后去其上讀即可。
同步復(fù)制狀態(tài)，狀態(tài)轉(zhuǎn)移就是1+1大于等于2，控制簡單，傳輸數(shù)據(jù)量大，而復(fù)制狀態(tài)機(jī)，控制比較復(fù)雜，傳輸?shù)臄?shù)據(jù)其實很少。
上圖是我們第一次對lest做性能測試得到的結(jié)果。前段時間，我們申請到了新的機(jī)器，我們又重新做了一遍測試。
上圖是處理請求正確響應(yīng)數(shù)，其中紅色的是萬兆服務(wù)器+SSD，黃色的是千兆服務(wù)器+SATA硬盤。得到的這個性能結(jié)果我個人認(rèn)為還有提升空間，因為我們的客戶端不夠多，只有十臺，至少要有二三十臺才能壓出它的真實性能。現(xiàn)在的性能數(shù)據(jù)差不多是它真正性能的60%。
從圖中我們可以看到，當(dāng)數(shù)據(jù)達(dá)到10K以上，性能其實一直在走下坡路，如果大家去對比Redis也會發(fā)現(xiàn)，當(dāng)數(shù)據(jù)到10K，Redis性能也會下降45%。這說明緩存還是和小數(shù)據(jù)更合拍。
上圖是大響應(yīng)時間，圖中的822我也不知道怎么來的，可能是一個特別異常的值，除去這個值，其它數(shù)值的狀態(tài)還是比較平穩(wěn)的，大響應(yīng)時間的單位是毫秒，基本上是在一兩百毫秒之間。
上圖是最小響應(yīng)時間，其值基本分布在一點幾毫秒。
上圖是傳輸量，也就是網(wǎng)卡，很明顯，萬兆占據(jù)優(yōu)勢，這是因為它本來就比千兆要大，其可能只打到了80%，還有10%的增長空間。
上圖是SSD服務(wù)器壓力，CPU的狀況差不多，如果十個服務(wù)器瘋狂打，那么CPU的壓力在20%左右，隨著數(shù)據(jù)變大，處理時間變多，CPU壓力就下降了。圖中還有網(wǎng)絡(luò)的出和入，其中入會比較小，而出會比較大，如果是Redis，出會更大。
Lest的優(yōu)劣勢很明顯，它是一個吃磁盤不太吃內(nèi)存的東西，具體優(yōu)劣勢可參考上圖。相比來說，如果使用Redis服務(wù)器需要二三十臺的場景，lest三臺就可以扛下來。另外，相比其它緩存，lest基本可以做到寫代碼無感知，另外，我比較推薦使用SSD，因為現(xiàn)在SSD還是蠻便宜的，比內(nèi)存要便宜。
重慶分公司
重慶分公司
