一拍而合，京東分布式儲存起航1
有另外乙個儲存的小團隊，成員只有6,7個人，雖然工作年限普遍不長，有幾個還是剛畢業，但也都想著在儲存方向做出一番業績。同樣的願景，很快大家走到了一起。在海鋒哥的領導下，系統技術部儲存組正式成立，開始京東分布式儲存的研發。
從2023年到2023年，這一做就是三年，當年的小鮮肉都成為了公司儲存方向的中堅力量，成為了儲存專家，而jfs也成為了京東業務核心底層儲存，支撐了公司1000多個業務。一路走來，踩過很多坑，也有一些體會，給大家分享下。
艱難抉擇，分布式儲存技術選型2
雖然自研的週期會更長，但它靈活可控，且從長期來看，也能獲得技術收益。
日夜挑燈，jfs小檔案儲存3
小檔案儲存則被選為了桌上的第一道菜。無論是商品、交易訂單，還是庫房訂單，這些電商資料都需要非常強的可靠性、可用性和一致性。在複製協議上，我們採取了三副本強一致性複製，由1primary +2followers構成，如下圖所示。寫操作時，由client將資料傳送到主上，然後由主同時發給兩個從副本，三副本都寫入成功後才返回給使用者成功。而在讀取時，優先在從上讀取，來提高系統的併發能力。
在資料儲存上，考慮到檔案比較小，如果使用者上傳乙個檔案，對應在伺服器上建乙個檔案儲存資料的話，那麼一塊2t的盤上面將存放幾千萬甚至上億個檔案，給伺服器帶來沉重的負擔。我們採取了事先建好大檔案，然後不停的追加寫入方式，使用偏移量和大小來訪問資料。當然為了避免單個大檔案集中讀寫造成檔案鎖資源競爭激烈，我們採取了多檔案追加方式，如下圖所示：
現在已記不清經過多少個日日夜夜的挑燈夜戰，慢慢地加班餐的小姑娘因為熟識了，會有意給我們多舀一些菜；團隊的年輕小夥伴白淨的臉上多了一圈黑眼圈。終於，在4個月後的一天，我們迎來了第乙個孩子，京東小檔案儲存系統終於正式落地。當然，它也沒令大家失望，在與同類的開源軟體對比測試中，效能等各項指標都佔優。
乙個新系統的推廣總是很艱難的，最初我們開始推廣給在一些非核心業務的資料儲存上，慢慢的應用起來。當然，我們也一直在準備著一條大魚的到來。
小試牛刀，京東新系統4
時間回到了2023年，老一些的員工可能還有印象，隨著資料量和訪問量的暴增，老的服務已經達到了效能瓶頸。客服每天都會收到大量使用者投訴訪問速度慢，io異常、多副本資料不一致的情況也時有發生，告警郵件都快塞滿了相關業務部門的郵箱。
老的系統最早可以追溯到好多年前，當時也是選擇了乙個業內使用廣泛的開源儲存方案。最初的一兩年一直相安無事，但隨著資料量的暴增，開始暴露各種各樣的問題。最開始業務部門還能通過修改配置，加一些快取策略來解決，到了後來，這些完全不起作用了，需要從整體儲存架構上優化。
這時候的jfs在一些非核心的業務上獲得了較好口碑，於是，的業務部門找到我們，希望能將業務遷移到jfs上來。
時間已經到了14年的4月份，離京東上市的日期也就乙個月了。我們需要在jfs儲存之上開發乙個新的系統，還需要在不影響現有的業務情況下，完成20億歷史的遷移，這其中蘊藏的巨大風險大家都心知肚明，但並沒有經過太多複雜的權衡，我們很快應允了下來。
再接下來就是一段與時間賽跑的歷程，團隊成員快速分工，幾個同事用了一周的時間完成新系統搭建，同時另幾個同事完成了資料雙寫、遷移和校驗方案的實現，然後再用了三個星期完成了全部20億存量資料遷移和校驗。最終在公司上市前夕，完成了新老系統的切換，徹底解決了訪問慢的問題。
京東的規格很多，同一副可能有10多種不同的規格，因此我們在源站只存一副原圖，cdn沒有命中的回源站進行實時壓縮，這樣不僅節約了儲存空間，也滿足了業務不斷變化的需求。如下圖所示：
當然，在解決最核心的儲存和簡單處理後，我們也做了一些工作推動了京東技術的發展。在縮放效率上，我們和intel進行了緊密合作，通過**重構、icc編譯、ipp編譯將縮放速度提公升到最初的3倍以上。在2023年我們創新性的將webp格式引入京東，與無線部門緊密合作，將移動端的全部替換成webp格式。整體大小下降了50%，給cdn節約了30%的流量，也給使用者節約了巨大的下行流量，讓使用者訪問速度更快，大大提公升了使用者體驗。
繼續前行，jfs大檔案儲存5
在資料儲存上，恰恰與小檔案相反，我們將乙個大檔案分成多個塊來儲存，這樣可以規避區域性過熱的檔案造成了單機磁碟io過載，同時，分成多塊後也更利於整個系統資源的排程。
快速發展，京東物件儲存6
於是，我們決定在jfs上面構建物件儲存，提供使用者更便捷的訪問。
物件儲存包含幾個部分，除了前面我們已經提到的大小檔案儲存，還需要構建gateway、賬戶和bucket管理、日誌處理等等，當然還有最複雜的元資料管理。
物件儲存的元資料管理是乙個業內難題。雖然物件儲存並無目錄的概念，但要支援按字首進行list操作，即能通過prefix和delimiter的結合，實現層次查詢。在資料量不大時，類似於hdfs的namenode將全部使用者key都存在記憶體中就能滿足需求，但當物件的數量過億或者十億時，將會耗盡記憶體，無法做到橫向擴充套件。很多kv儲存能做到隨意橫向擴充套件，但不能很好的支援物件儲存list請求。
正常情況下，client直接連到對應的mysql複製組。當某組mysql記錄數目達到一定限度後，manager觸發**，啟動乙個migrator作為mysql**，和manager緊密配合完成實時資料處理和歷史資料遷移。
物件儲存一經推出就受到業務部門的廣泛歡迎，目前已經支援了京東1200多個業務資料的儲存，雙十一最高峰值每秒同時25000個物件實時讀寫，儲存的物件達到百億級別，資料量超過10pb。
持續創新，電子簽收後台系統7
電子簽收小票的儲存就是物件儲存的乙個重要應用。
京東一天的訂單量就有成百上千萬，以前每天都要保留幾百萬張的紙質小票，堆積在倉庫裡面。出現糾紛時，還需要從上億張紙質小票中找到使用者當時簽收的小票，這無疑是一項繁瑣、費時費錢、又不環保的工作，且大大提公升了京東物流的管理成本。從環保維度和成本維度考量，運營系統青龍研發部創新性的提出了使用電子簽收。
整個電子簽收產生的海量簽名需要高安全性、高穩定性、高永續性的儲存。且根據國家的快遞管理辦法規定，物流的簽收儲存是一年，再加上簽收的金融小票，意味著系統需要能夠儲存百億級別的使用者簽收。海量的資料儲存也給青龍研發帶來了一些困難。
這無疑是物件儲存很好的乙個應用場景，但其定製化的加解密、文字轉、合成也給物件儲存提出了更高的要求。為了更好的支援業務創新，我們在物件儲存的基礎上，研發了電子簽收後台系統。能夠根據傳回來的簽收資訊，按照指定樣式生成簽收小票，並與使用者簽名合成；按照業務高安全性要求，加密儲存資料，保護使用者資料的絕對安全；對經pos機加密傳回來的資料，在使用者檢視時解密展示給使用者。
初衷未改，jfs統一儲存8
jfs小檔案和大檔案儲存的實現，已經能夠解決京東大量應用場景。但離我們的one team，one storage的願景還很遠。接下來我們開始了小檔案和大檔案儲存的整合。同樣的三副本強一致性複製，在複製協議上，我們進行了統一，同時兼顧到小檔案和大檔案效能，採取了鏈式複製。而在檔案儲存上，大小檔案處理迥異，無法強行統一起來，因此我們將大小檔案儲存作為可插拔的不同儲存引擎，分管集群中不同型別檔案的儲存。
面向未來，京東分布式儲存展望9
對於未來，我們也在規劃著讓jfs支援共享儲存，可以直接掛載在容器上。這樣，應用的非結構化資料直接存到了分布式儲存上，減少了日誌等資料先存在本地磁碟，再收集到分布式儲存上的環節。同時，和容器技術的結合更緊密，也支援了容器故障的快速排程和轉移。
分布式儲存
塊儲存，檔案儲存，物件儲存區別 分布式儲存的應用場景相對於其儲存介面，現在流行分為三種 物件儲存 也就是通常意義的鍵值儲存，其介面就是簡單的get put del和其他擴充套件，如七牛 又拍 swift s3 塊儲存 這種介面通常以qemu driver或者kernel module的方式存在，這種...
分布式儲存
普通儲存 das 直連式儲存。nas 連線式儲存。san 儲存網路。大檔案分布儲存 gfs google file system google檔案系統 hdfs hadoop distributed file system hadoop分布式檔案系統 小檔案分布儲存 adfs ali distrib...
分布式學習之路
分布式架構簡介 一致性協議 chubby與paxos zookeeper與paxos zookeeper使用 cli zookeeper客戶端 zookeeper應用場景 zookeeper在大型分布式系統中的應用 zookeeper系統模型 zookeeper序列化及通訊協議 zookeeper客...