OCS概要介紹

據(jù)AlertSite網(wǎng)絡(luò)分析公司表示，F(xiàn)acebook的響應(yīng)時(shí)間在2010年平均為1秒鐘，到2011年中期已提高到了0.73秒。對(duì)比來(lái)看，響應(yīng)時(shí)間占第二位的LinkedIn，網(wǎng)絡(luò)下載內(nèi)容時(shí)要花費(fèi)將近2倍的時(shí)間。Twitter的響應(yīng)時(shí)間則整整遲了2秒鐘。響應(yīng)時(shí)間優(yōu)化的首要手段就是采用緩存技術(shù)，減少系統(tǒng)間交互請(qǐng)求和磁盤(pán)IO。

OCS是阿里巴巴集團(tuán)的分布式緩存產(chǎn)品，支撐著淘寶、阿里巴巴、支付寶的日常運(yùn)作，尤其在雙11等大型活動(dòng)上，承載了絕大多數(shù)的數(shù)據(jù)請(qǐng)求。與OCS相比，著名的Memcached具備了分布式集群管理的功能。2014年OCS經(jīng)歷了從分布式到云服務(wù)的進(jìn)化，作為阿里云服務(wù)的緩存產(chǎn)品正式商業(yè)化。

OCS技術(shù)講解

OCS的核心存儲(chǔ)是淘寶的開(kāi)源產(chǎn)品TAIR（發(fā)音：太愛(ài)兒）

TAIR原理

角色上分為DataServer，ConfigServer：

1. ConfigServer負(fù)責(zé)數(shù)據(jù)的路由表管理，決定著哪些數(shù)據(jù)應(yīng)該去哪里訪問(wèn)。同時(shí)也管理著DataServer節(jié)點(diǎn)的存活狀態(tài)，自動(dòng)踢出宕機(jī)或者異常節(jié)點(diǎn)。
2. DataServer是數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)的增刪改查。通過(guò)Plugin機(jī)制支持多種存儲(chǔ)引擎。常用的有基于內(nèi)存的，所有的數(shù)據(jù)保存在內(nèi)存之中，查詢速度快，但不持久化，網(wǎng)絡(luò)正常的情況下，客戶端在0.2ms內(nèi)得到請(qǐng)求響應(yīng)。另外一種常用存儲(chǔ)引擎基于SSD介質(zhì)再依靠?jī)?nèi)存加速，特點(diǎn)是容量大，成本低，性能上接近內(nèi)存引擎，客戶端請(qǐng)求響應(yīng)時(shí)間大概是1ms。

集群初始化時(shí)ConfigServer會(huì)根據(jù)DataServer的數(shù)量分配BucketID到DataServer上，這層映射關(guān)系就是數(shù)據(jù)路由索引，BucketID屬于[0-1023]的范圍內(nèi)。客戶端第一次啟動(dòng)時(shí)會(huì)從ConfigServer上拉取映射關(guān)系，之后的讀寫(xiě)請(qǐng)求，根據(jù)全局約定的Hash算法(例如MurmurHash(key)24)計(jì)算出BucketID，根據(jù)映射關(guān)系描述向指定的DataServer上發(fā)送請(qǐng)求。

ConfigServer上的路由信息會(huì)根據(jù)DataServer存活狀況動(dòng)態(tài)修改更新；新結(jié)果再告知給DataServer；當(dāng)DataServer處理客戶端響應(yīng)時(shí)，將變更通知給客戶端。

圖1 路由路徑

從TAIR到OCS

云服務(wù)化的過(guò)程中，首要問(wèn)題是滿足用戶的兼容性需求，用戶訪問(wèn)接口上支持廣泛流行的Memcached接口，原生于Memcached的應(yīng)用，可以無(wú)縫遷移到OCS上來(lái)。

其次是穩(wěn)定性，集群升級(jí)時(shí)，由于進(jìn)程重啟會(huì)造成應(yīng)用請(qǐng)求OCS瞬間報(bào)錯(cuò)，OCS實(shí)現(xiàn)了一套熱升級(jí)方案，在保持TCP鏈接不中斷的情況下重啟進(jìn)程。

云服務(wù)還有一個(gè)重要特性就是多租戶，多租戶的情況下，為了防止某一兩個(gè)用戶的高并發(fā)訪問(wèn)造成集群負(fù)載上升，從而影響了其他租戶的穩(wěn)定性。OCS內(nèi)部對(duì)不同的租戶進(jìn)行了資源隔離，針對(duì)請(qǐng)求量、帶寬、內(nèi)存使用量做了嚴(yán)格的限制。不同規(guī)格的用戶可以購(gòu)買(mǎi)不同規(guī)格的OCS實(shí)例，之間不會(huì)互相干擾。

與OCS相比，自建的Memcached解決了單機(jī)容量上線問(wèn)題，實(shí)現(xiàn)擴(kuò)容自動(dòng)化且不需要修改客戶端配置，同時(shí)輸出了性能監(jiān)控指標(biāo)，網(wǎng)頁(yè)版Console命令等。

緩存失效一致性問(wèn)題

一般緩存的使用方式是：先讀取緩存，若不存在則從DB中讀取，并將結(jié)果寫(xiě)入到緩存中；下次數(shù)據(jù)讀取時(shí)便可以直接從緩存中獲取數(shù)據(jù)。

數(shù)據(jù)的修改是直接失效緩存數(shù)據(jù)，再修改DB內(nèi)容，避免DB修改成功，但由于網(wǎng)絡(luò)或者其他問(wèn)題導(dǎo)致緩存數(shù)據(jù)沒(méi)有清理，造成了臟數(shù)據(jù)。

但這樣仍然無(wú)法避免臟數(shù)據(jù)的產(chǎn)生，一種并發(fā)的場(chǎng)景下：假設(shè)業(yè)務(wù)對(duì)數(shù)據(jù)Key:Hello Value:World有大量的讀取和修改請(qǐng)求。線程A向OCS讀取Key:Hello，得到Not Found結(jié)果，開(kāi)始向DB請(qǐng)求數(shù)據(jù)，得到數(shù)據(jù)Key:Hello Value:World；接下來(lái)準(zhǔn)備向OCS寫(xiě)入此條數(shù)據(jù)，但在寫(xiě)入OCS前（網(wǎng)絡(luò)，CPU都等可能導(dǎo)致A線程處理速度降低）另一B線程請(qǐng)求修改數(shù)據(jù)Key:Hello Value:OCS，首先執(zhí)行失效緩存動(dòng)作（因?yàn)锽線程并不知道是否有此條數(shù)據(jù)，因此直接執(zhí)行失效操作），OCS成功處理了失效請(qǐng)求。轉(zhuǎn)回到A線程繼續(xù)執(zhí)行寫(xiě)入OCS，將Key:Hello Value:World寫(xiě)入到緩存中，A線程任務(wù)結(jié)束；B線程也成功修改了DB數(shù)據(jù)內(nèi)容為Key:Hello Value:OCS。

圖2 并發(fā)時(shí)序

此時(shí)OCS中的數(shù)據(jù)為Key:Hello Value:World；DB中的數(shù)據(jù)為Key:Hello Value:OCS，出現(xiàn)緩存臟數(shù)據(jù)！

為了解決這個(gè)問(wèn)題，OCS擴(kuò)充了Memcached協(xié)議（公有云即將支持），增加了deleteAndIncVersion接口。此接口并不會(huì)真的刪除數(shù)據(jù)，而是給數(shù)據(jù)打了標(biāo)簽，表明已失效狀態(tài)，并且增加數(shù)據(jù)版本號(hào)；如果數(shù)據(jù)不存在則寫(xiě)入NULL，同時(shí)也生成隨機(jī)數(shù)據(jù)版本號(hào)。OCS寫(xiě)入支持原子對(duì)比版本號(hào)：假設(shè)傳入的版本號(hào)與OCS保存的數(shù)據(jù)版本號(hào)一致或者原數(shù)據(jù)不存在，則準(zhǔn)許寫(xiě)入，否則拒絕修改。

回到剛才的場(chǎng)景上：線程A向OCS讀取Key:Hello，得到Not Found結(jié)果，開(kāi)始向DB請(qǐng)求數(shù)據(jù)，得到數(shù)據(jù)Key:Hello Value:World；接下來(lái)準(zhǔn)備向OCS寫(xiě)入此條數(shù)據(jù)，版本號(hào)信息默認(rèn)為1；在A寫(xiě)入OCS前另一個(gè)B線程發(fā)起了動(dòng)作修改數(shù)據(jù)Key:Hello Value:OCS，首先執(zhí)行刪除緩存動(dòng)作，OCS順利處理了deleteAndIncVersion請(qǐng)求，生成了隨機(jī)版本號(hào)12345（約定大于1000）。轉(zhuǎn)回到A線程繼續(xù)執(zhí)行寫(xiě)入OCS，請(qǐng)求將Key:Hello Value:World寫(xiě)入，此時(shí)緩存系統(tǒng)發(fā)現(xiàn)傳入的版本號(hào)信息不匹配（1 ?。?nbsp;12345），寫(xiě)入失敗，A線程任務(wù)結(jié)束；B線程也成功修改了DB數(shù)據(jù)內(nèi)容為Key:Hello Value:OCS。

此時(shí)OCS中的數(shù)據(jù)為Key:Hello Value:NULL Version:12345；DB中的數(shù)據(jù)為Key:Hello Value:OCS，后續(xù)讀任務(wù)時(shí)會(huì)再次嘗試將DB中的數(shù)據(jù)寫(xiě)入到OCS中。

類(lèi)似的并發(fā)場(chǎng)景還有很多，讀者可以自行推演，同時(shí)也可以思考下為何約定隨機(jī)生成的版本要大于1000？

緩存數(shù)據(jù)的同步的一致性問(wèn)題

隨著網(wǎng)站規(guī)模增長(zhǎng)和可靠性的提升，會(huì)面臨多IDC的部署，每個(gè)IDC都有一套獨(dú)立的DB和緩存系統(tǒng)，這時(shí)緩存一致性又成了突出的問(wèn)題。

首先緩存系統(tǒng)為了保證高效率，會(huì)杜絕磁盤(pán)IO，哪怕是寫(xiě)B(tài)INLOG；當(dāng)然緩存系統(tǒng)為了性能可以只同步刪除，不同步寫(xiě)入，那么緩存的同步一般會(huì)優(yōu)先于DB同步到達(dá)（畢竟緩存系統(tǒng)的效率要高得多），那么就會(huì)出現(xiàn)緩存中無(wú)數(shù)據(jù)，DB中是舊數(shù)據(jù)的場(chǎng)景。此時(shí)，有業(yè)務(wù)請(qǐng)求數(shù)據(jù)，讀取緩存Not Found，從DB讀取并加載到緩存中的仍然是舊數(shù)據(jù)，DB數(shù)據(jù)同步到達(dá)時(shí)也只更新了DB，緩存臟數(shù)據(jù)無(wú)法被清除。

圖3 并發(fā)時(shí)序

從上面的情況可以看出，不一致的根本原因是異構(gòu)系統(tǒng)之間無(wú)法協(xié)同同步，不能保證DB數(shù)據(jù)先同步，緩存數(shù)據(jù)后同步。所以就要考慮緩存系統(tǒng)如何等待DB同步，或者能否做到兩者共用一套同步機(jī)制？緩存同步也依賴DB BINLOG是一個(gè)可行的方案。

IDC1中的DB，通過(guò)BINLOG同步給IDC2中的DB，此事IDC2-DB數(shù)據(jù)修改也會(huì)產(chǎn)生自身的BINLOG，緩存的數(shù)據(jù)同步就可以通過(guò)IDC2-DB BINLOG進(jìn)行。緩存同步模塊分析BINLOG后，失效相應(yīng)的緩存Key，同步從并行改為串行，保證了先后順序。

這樣，IDC間的數(shù)據(jù)同步架構(gòu)更加簡(jiǎn)單清晰，系統(tǒng)服用率高，做好BINLOG同步和抓取即可。

圖4 異地同步

總結(jié)

不同系統(tǒng)之間的數(shù)據(jù)同步一直是一個(gè)世界性的問(wèn)題，目前仍然沒(méi)有方法解除CAP魔咒，只能根據(jù)實(shí)際的情況在三者之間尋找理想的平衡點(diǎn)。本文介紹的解決方案，其一是利用了緩存系統(tǒng)的原子操作，其二是利用了外部系統(tǒng)同步機(jī)制保證先后，都是在犧牲最小的性能代價(jià)時(shí)獲取最大的一致性保證，但仍然無(wú)法覆蓋全部場(chǎng)景下的一致性問(wèn)題。

作者：楊成虎

作者簡(jiǎn)介：花名葉翔，阿里巴巴集團(tuán)技術(shù)專家，擅長(zhǎng)通過(guò)NoSQL存儲(chǔ)系統(tǒng)、Cache系統(tǒng)去解決海量數(shù)據(jù)的互聯(lián)網(wǎng)問(wèn)題。2009年加入阿里巴巴，先后開(kāi)發(fā)了阿里的小文件系統(tǒng)，KV存儲(chǔ)系統(tǒng)，負(fù)責(zé)阿里Tair系統(tǒng)的開(kāi)發(fā)與架構(gòu)設(shè)計(jì)。2013年至今主導(dǎo)研發(fā)了阿里云分布式緩存服務(wù)OCS，目前仍致力于NoSQL產(chǎn)品的云服務(wù)化工作。