京東分布式存儲(chǔ)建設(shè)之路
一拍而合，京東分布式存儲(chǔ)起航
在項(xiàng)目中你經(jīng)常會(huì)遇到，有一些圖片、視頻或者文本需要存儲(chǔ)，你希望它不丟失的同時(shí)還要能提供高速讀寫(xiě)的能力。對(duì)于京東來(lái)說(shuō)，這樣的需求每天都在發(fā)生著，而且要求會(huì)更高，因?yàn)檫@些可能是用戶的訂單數(shù)據(jù)，你希望即使在寫(xiě)的時(shí)候斷電了、磁盤(pán)壞了，你的數(shù)據(jù)還在;你希望即使服務(wù)器故障了、交換機(jī)壞了甚至機(jī)房掛了，用戶還能正常訪問(wèn);你希望在大促來(lái)臨時(shí)即使用戶訪問(wèn)量倍級(jí)增長(zhǎng)，它依然能提供高速讀寫(xiě)。沒(méi)錯(cuò)，現(xiàn)在很多人都會(huì)告訴你，用JFS京東文件系統(tǒng)，它能滿足你的需求。
時(shí)間回到2013年，海鋒哥剛來(lái)到京東，很快地他發(fā)現(xiàn)京東對(duì)存儲(chǔ)有強(qiáng)烈的需求，既有海量小文件的在線存儲(chǔ)，又有大量離線數(shù)據(jù)的存儲(chǔ)，當(dāng)前公司內(nèi)部在這塊做的并不好，各個(gè)業(yè)務(wù)部門(mén)自己做自己的，很多慢慢開(kāi)始滿足不了業(yè)務(wù)增長(zhǎng)的需要了。一個(gè)想法油然而生，他決定做京東統(tǒng)一的分布式存儲(chǔ)平臺(tái)，滿足公司各個(gè)業(yè)務(wù)線的需要。
有另外一個(gè)存儲(chǔ)的小團(tuán)隊(duì)，成員只有6,7個(gè)人，雖然工作年限普遍不長(zhǎng)，有幾個(gè)還是剛畢業(yè)，但也都想著在存儲(chǔ)方向做出一番業(yè)績(jī)。同樣的愿景，很快大家走到了一起。在海鋒哥的領(lǐng)導(dǎo)下，系統(tǒng)技術(shù)部存儲(chǔ)組正式成立，開(kāi)始京東分布式存儲(chǔ)的研發(fā)。
從2013年到2016年，這一做就是三年，當(dāng)年的小鮮肉都成為了公司存儲(chǔ)方向的中堅(jiān)力量，成為了存儲(chǔ)專家，而JFS也成為了京東業(yè)務(wù)核心底層存儲(chǔ)，支撐了公司1000多個(gè)業(yè)務(wù)。一路走來(lái)，踩過(guò)很多坑，也有一些體會(huì)，給大家分享下。
艱難抉擇，分布式存儲(chǔ)技術(shù)選型
京東有各種各樣的數(shù)據(jù)存儲(chǔ)需求，有大小10KB的訂單數(shù)據(jù)，每天以上億的速度增長(zhǎng);有大小90k-200k的圖片數(shù)據(jù)，總量超過(guò)幾十億，且每天還在以千萬(wàn)的速度增長(zhǎng);也有幾十兆的App客戶端文件，每次更新都伴隨著巨量的用戶訪問(wèn);還有1GB甚至10GB以上的內(nèi)部日志文件存儲(chǔ)。各個(gè)業(yè)務(wù)部門(mén)使用的存儲(chǔ)方式也五花八門(mén)，有用Mysql的Blob類型存儲(chǔ)，也有用開(kāi)源的FastDFS和Hdfs。誠(chéng)然，這些軟件在京東的快速發(fā)展中起了至關(guān)重要的作用，但隨著業(yè)務(wù)規(guī)模的持續(xù)增長(zhǎng)，也開(kāi)始暴露出來(lái)了各種各樣的問(wèn)題。擺在我們面前的路有兩條：一種是在開(kāi)源系統(tǒng)的基礎(chǔ)上做定制開(kāi)發(fā)，還有一種是自研。兩種方式各有優(yōu)缺點(diǎn)，最終經(jīng)過(guò)一輪輪調(diào)研下來(lái)，我們還是決定走自研之路。這里以大家熟知的Hdfs及其生態(tài)為例，回顧下當(dāng)時(shí)抉擇的過(guò)程。
毫無(wú)疑問(wèn)，Hdfs是一個(gè)相當(dāng)優(yōu)秀的開(kāi)源存儲(chǔ)項(xiàng)目，但它畢竟是為離線大文件設(shè)計(jì)，對(duì)于京東海量的在線小文件無(wú)能為力，二次開(kāi)發(fā)需要對(duì)整個(gè)架構(gòu)動(dòng)手術(shù)。還有一種考慮，使用Hdfs存儲(chǔ)大文件，使用HBase存儲(chǔ)小文件。當(dāng)然，這種方案也不適合京東，主要有兩點(diǎn)：***、HBase讀取文件時(shí)，請(qǐng)求先打到RegionServer上，由RegionServer去Hdfs取數(shù)據(jù)，再返回，相當(dāng)于一次IO請(qǐng)求經(jīng)過(guò)了兩次網(wǎng)絡(luò)傳輸，這對(duì)于追求***速度的很多應(yīng)用場(chǎng)景是不合適的;第二、HBase在做Split的時(shí)候會(huì)導(dǎo)致服務(wù)短暫的不可用，這對(duì)很多要求提供7*24小時(shí)無(wú)間斷服務(wù)的業(yè)務(wù)則更是不可接受。
雖然自研的周期會(huì)更長(zhǎng)，但它靈活可控，且從長(zhǎng)期來(lái)看，也能獲得技術(shù)收益。
日夜挑燈，JFS小文件存儲(chǔ)
廚師到位，菜已洗凈，接下來(lái)就是從哪里下手了。要做京東統(tǒng)一的分布式存儲(chǔ)，這是一件非常困難的事情，因?yàn)榧幢闶乾F(xiàn)在，也沒(méi)有見(jiàn)到能同時(shí)很好的支持海量在線小文件和離線大文件的開(kāi)源解決方案。很慶幸的是，當(dāng)時(shí)我們并沒(méi)有選擇一步到位的***解決方案，而是緊扣業(yè)務(wù)，高度定制，分期展開(kāi)這條路。
小文件存儲(chǔ)則被選為了桌上的***道菜。無(wú)論是商品圖片、交易訂單，還是庫(kù)房訂單，這些電商數(shù)據(jù)都需要非常強(qiáng)的可靠性、可用性和一致性。在復(fù)制協(xié)議上，我們采取了三副本強(qiáng)一致性復(fù)制，由1Primary +2Followers構(gòu)成，如下圖所示。寫(xiě)操作時(shí)，由Client將數(shù)據(jù)發(fā)送到主上，然后由主同時(shí)發(fā)給兩個(gè)從副本，三副本都寫(xiě)入成功后才返回給用戶成功。而在讀取時(shí)，優(yōu)先在從上讀取，來(lái)提高系統(tǒng)的并發(fā)能力。
在數(shù)據(jù)存儲(chǔ)上，考慮到文件比較小，如果用戶上傳一個(gè)文件，對(duì)應(yīng)在服務(wù)器上建一個(gè)文件存儲(chǔ)數(shù)據(jù)的話，那么一塊2T的盤(pán)上面將存放幾千萬(wàn)甚至上億個(gè)文件，給服務(wù)器帶來(lái)沉重的負(fù)擔(dān)。我們采取了事先建好大文件，然后不停的追加寫(xiě)入方式，使用偏移量和大小來(lái)訪問(wèn)數(shù)據(jù)。當(dāng)然為了避免單個(gè)大文件集中讀寫(xiě)造成文件鎖資源競(jìng)爭(zhēng)激烈，我們采取了多文件追加方式，如下圖所示：
現(xiàn)在已記不清經(jīng)過(guò)多少個(gè)日日夜夜的挑燈夜戰(zhàn)，慢慢地加班餐的小姑娘因?yàn)槭熳R(shí)了，會(huì)有意給我們多舀一些菜;團(tuán)隊(duì)的年輕小伙伴白凈的臉上多了一圈黑眼圈。終于，在4個(gè)月后的一天，我們迎來(lái)了***個(gè)孩子，京東小文件存儲(chǔ)系統(tǒng)終于正式落地。當(dāng)然，它也沒(méi)令大家失望，在與同類的開(kāi)源軟件對(duì)比測(cè)試中，性能等各項(xiàng)指標(biāo)都占優(yōu)。
一個(gè)新系統(tǒng)的推廣總是很艱難的，最初我們開(kāi)始推廣給在一些非核心業(yè)務(wù)的數(shù)據(jù)存儲(chǔ)上，慢慢的應(yīng)用起來(lái)。當(dāng)然，我們也一直在準(zhǔn)備著一條大魚(yú)的到來(lái)。
小試牛刀，京東新圖片系統(tǒng)
時(shí)間回到了2014年，老一些的員工可能還有印象，隨著圖片數(shù)據(jù)量和訪問(wèn)量的暴增，老的圖片服務(wù)已經(jīng)達(dá)到了性能瓶頸。客服每天都會(huì)收到大量用戶投訴圖片訪問(wèn)速度慢，IO異常、多副本數(shù)據(jù)不一致的情況也時(shí)有發(fā)生，告警郵件都快塞滿了相關(guān)業(yè)務(wù)部門(mén)的郵箱。
老的圖片系統(tǒng)最早可以追溯到好多年前，當(dāng)時(shí)也是選擇了一個(gè)業(yè)內(nèi)使用廣泛的開(kāi)源存儲(chǔ)方案。最初的一兩年一直相安無(wú)事，但隨著數(shù)據(jù)量的暴增，開(kāi)始暴露各種各樣的問(wèn)題。最開(kāi)始業(yè)務(wù)部門(mén)還能通過(guò)修改配置，加一些緩存策略來(lái)解決，到了后來(lái)，這些完全不起作用了，需要從整體存儲(chǔ)架構(gòu)上優(yōu)化。
這時(shí)候的JFS在一些非核心的業(yè)務(wù)上獲得了較好口碑，于是，圖片的業(yè)務(wù)部門(mén)找到我們，希望能將圖片業(yè)務(wù)遷移到JFS上來(lái)。
時(shí)間已經(jīng)到了14年的4月份，離京東上市的日期也就一個(gè)月了。我們需要在JFS存儲(chǔ)之上開(kāi)發(fā)一個(gè)新的圖片系統(tǒng)，還需要在不影響現(xiàn)有的業(yè)務(wù)情況下，完成20億歷史圖片的遷移，這其中蘊(yùn)藏的巨大風(fēng)險(xiǎn)大家都心知肚明，但并沒(méi)有經(jīng)過(guò)太多復(fù)雜的權(quán)衡，我們很快應(yīng)允了下來(lái)。
再接下來(lái)就是一段與時(shí)間賽跑的歷程，團(tuán)隊(duì)成員快速分工，幾個(gè)同事用了一周的時(shí)間完成新圖片系統(tǒng)搭建，同時(shí)另幾個(gè)同事完成了數(shù)據(jù)雙寫(xiě)、遷移和校驗(yàn)方案的實(shí)現(xiàn)，然后再用了三個(gè)星期完成了全部20億存量數(shù)據(jù)遷移和校驗(yàn)。最終在公司上市前夕，完成了新老圖片系統(tǒng)的切換，徹底解決了圖片訪問(wèn)慢的問(wèn)題。
京東的圖片規(guī)格很多，同一副圖片可能有10多種不同的規(guī)格，因此我們?cè)谠凑局淮嬉桓痹瓐D，CDN沒(méi)有***的圖片回源站進(jìn)行實(shí)時(shí)壓縮，這樣不僅節(jié)約了存儲(chǔ)空間，也滿足了業(yè)務(wù)不斷變化的需求。如下圖所示：
當(dāng)然，在解決最核心的圖片存儲(chǔ)和簡(jiǎn)單圖片處理后，我們也做了一些工作推動(dòng)了京東圖片技術(shù)的發(fā)展。在縮放效率上，我們和Intel進(jìn)行了緊密合作，通過(guò)代碼重構(gòu)、ICC編譯、IPP編譯將圖片縮放速度提升到最初的3倍以上。在2014年我們創(chuàng)新性的將圖片Webp格式引入京東，與無(wú)線部門(mén)緊密合作，將移動(dòng)端的圖片全部替換成Webp格式。圖片整體大小下降了50%，給CDN節(jié)約了30%的流量，也給用戶節(jié)約了巨大的下行流量，讓用戶訪問(wèn)速度更快，大大提升了用戶體驗(yàn)。
繼續(xù)前行，JFS大文件存儲(chǔ)
對(duì)于大文件來(lái)說(shuō)，單客戶端的上傳和下載性能同樣是一個(gè)重要的指標(biāo)。小文件的復(fù)制協(xié)議1Primary+2Followers方式已不再是***的，Primary拿到數(shù)據(jù)后同時(shí)發(fā)送給兩個(gè)從副本，這樣，Primary的帶寬資源將成為系統(tǒng)的瓶頸。因此，在大文件存儲(chǔ)復(fù)制協(xié)議的選擇上，JFS采取了鏈?zhǔn)綇?fù)制來(lái)***限度利用系統(tǒng)的帶寬資源。鏈?zhǔn)綇?fù)制結(jié)構(gòu)如下圖所示。而在數(shù)據(jù)發(fā)送和接受上，我們使用了流式處理，大大提高大文件的傳輸效率。
在數(shù)據(jù)存儲(chǔ)上，恰恰與小文件相反，我們將一個(gè)大文件分成多個(gè)塊來(lái)存儲(chǔ)，這樣可以規(guī)避局部過(guò)熱的文件造成了單機(jī)磁盤(pán)IO過(guò)載，同時(shí)，分成多塊后也更利于整個(gè)系統(tǒng)資源的調(diào)度。
快速發(fā)展，京東對(duì)象存儲(chǔ)
前面的小文件存儲(chǔ)和大文件存儲(chǔ)，從可靠性、可用性和穩(wěn)定性方面，已經(jīng)滿足了大部分的業(yè)務(wù)需求，但使用起來(lái)不是很方便，上傳和下載都需要通過(guò)SDK，用戶排查問(wèn)題不是那么便捷，且對(duì)多語(yǔ)言的支持也不好。接下來(lái)我們瞄準(zhǔn)了亞馬遜的S3產(chǎn)品形態(tài)。
簡(jiǎn)單對(duì)象存儲(chǔ)，支持Http協(xié)議;支持文本、圖片、視頻等任何類型數(shù)據(jù)的存儲(chǔ);支持1個(gè)字節(jié)到1TB大小的數(shù)據(jù)存儲(chǔ);支持list操作，用戶數(shù)據(jù)可以有層次結(jié)構(gòu)。這對(duì)于業(yè)務(wù)場(chǎng)景眾多、應(yīng)用復(fù)雜的京東來(lái)說(shuō)，太合適了。
于是，我們決定在JFS上面構(gòu)建對(duì)象存儲(chǔ)，提供用戶更便捷的訪問(wèn)。
對(duì)象存儲(chǔ)包含幾個(gè)部分，除了前面我們已經(jīng)提到的大小文件存儲(chǔ)，還需要構(gòu)建Gateway、賬戶和Bucket管理、日志處理等等，當(dāng)然還有最復(fù)雜的元數(shù)據(jù)管理。
對(duì)象存儲(chǔ)的元數(shù)據(jù)管理是一個(gè)業(yè)內(nèi)難題。雖然對(duì)象存儲(chǔ)并無(wú)目錄的概念，但要支持按前綴進(jìn)行List操作，即能通過(guò)Prefix和Delimiter的結(jié)合，實(shí)現(xiàn)層次查詢。在數(shù)據(jù)量不大時(shí)，類似于Hdfs的NameNode將全部用戶Key都存在內(nèi)存中就能滿足需求，但當(dāng)對(duì)象的數(shù)量過(guò)億或者十億時(shí)，將會(huì)耗盡內(nèi)存，無(wú)法做到橫向擴(kuò)展。很多KV存儲(chǔ)能做到隨意橫向擴(kuò)展，但不能很好的支持對(duì)象存儲(chǔ)List請(qǐng)求。
我們的方案也不是一個(gè)***的解決方案，但已經(jīng)能滿足京東百億級(jí)別元數(shù)據(jù)管理，這里發(fā)出來(lái)供大家探討下。我們采取Mysql+Jimdb(京東自研的高速KV緩存系統(tǒng))，將元數(shù)據(jù)扁平化持久存儲(chǔ)在Mysql中，同時(shí)借助于Mysql的B樹(shù)結(jié)構(gòu)實(shí)現(xiàn)元數(shù)據(jù)的List層次查詢。使用Jimdb作為緩存，提供高并發(fā)能力。當(dāng)然，僅僅Mysql并不能做到***橫向擴(kuò)展，我們?cè)贛ysql之上做了一個(gè)自動(dòng)分庫(kù)分表的系統(tǒng)ET，能在不影響業(yè)務(wù)的情況下，實(shí)現(xiàn)Mysql的分裂和數(shù)據(jù)在線遷移。如下圖所示：
正常情況下，Client直接連到對(duì)應(yīng)的Mysql復(fù)制組。當(dāng)某組Mysql記錄數(shù)目達(dá)到一定限度后，Manager觸發(fā)分裂，啟動(dòng)一個(gè)Migrator作為Mysql代理，和Manager緊密配合完成實(shí)時(shí)數(shù)據(jù)處理和歷史數(shù)據(jù)遷移。
對(duì)象存儲(chǔ)一經(jīng)推出就受到業(yè)務(wù)部門(mén)的廣泛歡迎，目前已經(jīng)支持了京東1200多個(gè)業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)，雙十一***峰值每秒同時(shí)25000個(gè)對(duì)象實(shí)時(shí)讀寫(xiě)，存儲(chǔ)的對(duì)象達(dá)到百億級(jí)別，數(shù)據(jù)量超過(guò)10PB。
持續(xù)創(chuàng)新，電子簽收后臺(tái)系統(tǒng)
電子簽收小票的存儲(chǔ)就是對(duì)象存儲(chǔ)的一個(gè)重要應(yīng)用。
京東一天的訂單量就有成百上千萬(wàn)，以前每天都要保留幾百萬(wàn)張的紙質(zhì)小票，堆積在倉(cāng)庫(kù)里面。出現(xiàn)糾紛時(shí)，還需要從上億張紙質(zhì)小票中找到用戶當(dāng)時(shí)簽收的小票，這無(wú)疑是一項(xiàng)繁瑣、費(fèi)時(shí)費(fèi)錢(qián)、又不環(huán)保的工作，且大大提升了京東物流的管理成本。從環(huán)保維度和成本維度考量，運(yùn)營(yíng)系統(tǒng)青龍研發(fā)部創(chuàng)新性的提出了使用電子簽收。
整個(gè)電子簽收產(chǎn)生的海量簽名圖片需要高安全性、高穩(wěn)定性、高持久性的保存。且根據(jù)國(guó)家的快遞管理辦法規(guī)定，物流的簽收保存是一年，再加上簽收的金融小票，意味著系統(tǒng)需要能夠存儲(chǔ)百億級(jí)別的用戶簽收?qǐng)D片。海量的數(shù)據(jù)存儲(chǔ)也給青龍研發(fā)帶來(lái)了一些困難。
這無(wú)疑是對(duì)象存儲(chǔ)很好的一個(gè)應(yīng)用場(chǎng)景，但其定制化的加解密、文字轉(zhuǎn)圖片、圖片合成也給對(duì)象存儲(chǔ)提出了更高的要求。為了更好的支持業(yè)務(wù)創(chuàng)新，我們?cè)趯?duì)象存儲(chǔ)的基礎(chǔ)上，研發(fā)了電子簽收后臺(tái)系統(tǒng)。能夠根據(jù)傳回來(lái)的簽收信息，按照指定樣式生成簽收小票圖片，并與用戶簽名圖片合成;按照業(yè)務(wù)高安全性要求，加密存儲(chǔ)數(shù)據(jù)，保護(hù)用戶數(shù)據(jù)的絕對(duì)安全;對(duì)經(jīng)POS機(jī)加密傳回來(lái)的數(shù)據(jù)，在用戶查看時(shí)解密展示給用戶。
初衷未改，JFS統(tǒng)一存儲(chǔ)
JFS小文件和大文件存儲(chǔ)的實(shí)現(xiàn)，已經(jīng)能夠解決京東大量應(yīng)用場(chǎng)景。但離我們的One team，One storage的愿景還很遠(yuǎn)。接下來(lái)我們開(kāi)始了小文件和大文件存儲(chǔ)的整合。同樣的三副本強(qiáng)一致性復(fù)制，在復(fù)制協(xié)議上，我們進(jìn)行了統(tǒng)一，同時(shí)兼顧到小文件和大文件性能，采取了鏈?zhǔn)綇?fù)制。而在文件存儲(chǔ)上，大小文件處理迥異，無(wú)法強(qiáng)行統(tǒng)一起來(lái)，因此我們將大小文件存儲(chǔ)作為可插拔的不同存儲(chǔ)引擎，分管集群中不同類型文件的存儲(chǔ)。
面向未來(lái)，京東分布式存儲(chǔ)展望
對(duì)于未來(lái)，我們也在規(guī)劃著讓JFS支持共享存儲(chǔ)，可以直接掛載在容器上。這樣，應(yīng)用的非結(jié)構(gòu)化數(shù)據(jù)直接存到了分布式存儲(chǔ)上，減少了日志等數(shù)據(jù)先存在本地磁盤(pán)，再收集到分布式存儲(chǔ)上的環(huán)節(jié)。同時(shí)，和容器技術(shù)的結(jié)合更緊密，也支持了容器故障的快速調(diào)度和轉(zhuǎn)移。
【本文來(lái)自51CTO專欄作者張開(kāi)濤的微信公眾號(hào)(開(kāi)濤的博客)，公眾號(hào)id: kaitao-1234567】
