電商不僅僅是大數(shù)據(jù)驅(qū)動的，京東用大數(shù)據(jù)為用戶、商品等帶來運營效率的提升。同時，從在線的數(shù)據(jù)訪問來講，電商業(yè)務(wù)需要非?？焖俚臄?shù)據(jù)訪問。大家可以看到，京東隨便打開京東首頁或類似的電商首頁，圖片是京東的資產(chǎn)，是商品形象的描述，可以用CDN加速。除了圖片之外，其他幾乎都是動態(tài)內(nèi)容，量很大，且是頻繁被改寫的，它們需要非常快速的訪問，比如說商品的詳情、價格、品類下推薦的結(jié)果等許多內(nèi)容，打開個商品詳情頁面或列表頁，后臺邏輯是很復(fù)雜的，需要非常多的數(shù)據(jù)去展現(xiàn)。

這個過程中，一個是快速的數(shù)據(jù)訪問對終端用戶的體驗有非常關(guān)鍵的影響。另外，從京東產(chǎn)品工程師開發(fā)的產(chǎn)品角度出發(fā)，另一個訴求就是關(guān)注業(yè)務(wù)邏輯，而不應(yīng)該花時間優(yōu)化后臺在線存儲的性能。Jim Gray是數(shù)據(jù)庫領(lǐng)域的泰斗級人物，他其中一句話我記得很清楚，即“Memory is the new disk（內(nèi)存是新的磁盤）”。07、08年時京東買的內(nèi)存大小標(biāo)準(zhǔn)配置是4G左右，很快4G、8G、16G一路下來，很多公司都會采購158、265G內(nèi)存，估計明年都會用1T內(nèi)存。京東都用265G內(nèi)存加萬兆網(wǎng)卡來做，單機(jī)內(nèi)存在快速變大，整體很多在線的小結(jié)構(gòu)和半結(jié)構(gòu)化數(shù)據(jù)存放在內(nèi)存里，這個問題是不大的，也是非常合理的。而且用內(nèi)存做在線存儲確實有弊端，就是成本在一個時間段內(nèi)有些偏高，但是除此之外卻帶來很多性能、管理等各方面的便捷性，兩相權(quán)衡下，在一定程度上，成本的升高對有一定規(guī)模和業(yè)務(wù)比較重要的公司可以接受，而且京東可以用技術(shù)手段降低這個成本。

JIMDB的全稱為The Jingdong In-Memory Database，這個系統(tǒng)的名字是大概2014年初起的，它并不是嚴(yán)格的關(guān)系型數(shù)據(jù)庫，而是一種新型的，以內(nèi)存為中心的全部托管、全管理服務(wù)化的數(shù)據(jù)庫。它是以內(nèi)存為中心的數(shù)據(jù)存儲，主要針對在線的結(jié)構(gòu)或半結(jié)構(gòu)化的數(shù)據(jù)，過去兩年一直在持續(xù)建設(shè)。從目前的業(yè)務(wù)價值角度，它支撐了京東幾乎所有的在線業(yè)務(wù)。除圖片之外，幾乎所有的動態(tài)內(nèi)容都被它所服務(wù)，或者嚴(yán)格來說，圖片的有些信息也用它來存儲。越來越呈現(xiàn)一個趨勢，就是京東更多地用它來做主存儲，MySQL或者DataBase會進(jìn)行歸檔。

接下來從技術(shù)角度做個簡單介紹。JIMDB基于redis，redis是一個非常優(yōu)秀的開源軟件，它做對了兩個事情。第一，它是基于內(nèi)存的，簡單且高性能；第二，也是基于內(nèi)存，它提供了非常豐富的數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)。對許多互聯(lián)網(wǎng)公司來說非常方便，比如商品的詳情、屬性等，非常便捷。兩年前，京東為了解決它的痛點，因為之前的監(jiān)控系統(tǒng)已不能滿足京東的業(yè)務(wù)需求，便不斷演進(jìn)，一路做下來。

它是相對分散的分布式系統(tǒng)，有許多分支、模塊，不同模塊做不同的事情。從用戶（業(yè)務(wù)的開發(fā)人員）的角度，給他們提供Java、C driver，其他小眾語言是給他們提供代理，完全兼容但是不限于RAM servers 。對于任何一個業(yè)務(wù)都給它集群，所有集群都在京東的物理資源池上。京東這個團(tuán)隊的核心任務(wù)是做一套復(fù)雜的平臺，一套健壯的分布式系統(tǒng)，管理目前大概四五千臺大內(nèi)存機(jī)器，為眾多業(yè)務(wù)提供可靠的、性能穩(wěn)定的、數(shù)據(jù)有持久性保證的高可用服務(wù)。

這個系統(tǒng)從部署結(jié)構(gòu)來講，是單個物理服務(wù)器、多實力的結(jié)構(gòu)，任何大內(nèi)存物理servers上都會部署多個內(nèi)存，好處是便于流量監(jiān)控等，但是給業(yè)務(wù)和監(jiān)控帶來很多復(fù)雜性。對行業(yè)來說目前還是比較合理，故障的檢測與切換，擴(kuò)容的管理、升級、監(jiān)控等都是獨立的模塊。存儲的servers是復(fù)用原來redis網(wǎng)絡(luò)編程的框架，但是復(fù)制的協(xié)議、存儲的引擎等各方面都是自己來開發(fā)。

在此列舉幾個技術(shù)點。第一，怎么做故障切換？分布式系統(tǒng)要解決的第一個問題是怎么處理故障。故障是個很嚴(yán)肅的事情，并不能簡單說有一個進(jìn)程有一個servers不通了就是故障，會發(fā)生網(wǎng)絡(luò)不穩(wěn)定等等，各個方面都有可能。在一個或多個數(shù)據(jù)中心有若干個故障檢測器，當(dāng)多數(shù)人認(rèn)為它故障并且沒有人認(rèn)為它健康時，才能定位確實故障。發(fā)給故障的控制器做下一步事情，重新觸發(fā)新的配置，改變集群的拓?fù)?。所以故障的檢測和自動的Failover是2014年做的第一個事情，把故障自動化，這個事情說起來簡單，其實是最基礎(chǔ)和最重要的，因為整個過程分很多步驟，前一段時間還出現(xiàn)過Bug。

第二個關(guān)鍵問題是任何一個邏輯的集群、業(yè)務(wù)數(shù)據(jù)量會增長、變化，所以必須支持在線、動態(tài)、重新的分片，或者說重新的Sharding，這個Sharding核心思想不是簡單把集群分片，中間要加一個抽象，才能進(jìn)行動態(tài)的重新分片。對于這個策略來說，中間加一個bucket的抽象，然后來進(jìn)行管理。遷移的過程是通過復(fù)制來做的，學(xué)術(shù)界或工程界喜歡管它叫“Partial replication”。舉例來說，原來是3個分片，現(xiàn)在怎么變成4個分片？通過調(diào)度算法，決策把哪些分片中的bucket遷移到這里，遷移是通過復(fù)制來做的，建一個復(fù)制關(guān)系，但是這個復(fù)制關(guān)系并不是復(fù)制它原來所有的數(shù)據(jù)，所以要求復(fù)制協(xié)議的實現(xiàn)是要做特殊的事情，只要這一個區(qū)間的復(fù)制，復(fù)制全部完成之后更改拓?fù)?，最后生效，這可以做并行的Partial replication做遷移。從數(shù)據(jù)的可靠性保證比較高，技術(shù)也比較簡單和傳統(tǒng)。

過去兩年從底層技術(shù)研發(fā)分三個方面一步步演進(jìn)做了些事情，從存儲引擎的角度，用的最多的是這個，第二個存儲引擎是LSM，京東用RAM+SSD做混合的兩級存儲，這三種不是取代的關(guān)系，而是互為補(bǔ)充。第二種更多應(yīng)用的場景，是有些東西比較大，京東可以把這個放在SSD上，把K依然放在RAM里，這樣可以適當(dāng)?shù)墓?jié)省成本，目前第二類線上已經(jīng)有百分之十幾的用量，但是數(shù)據(jù)量要乘四五倍，因為每臺機(jī)器單機(jī)容量更大。第三類是B+TREE，可以排序，可以支持按范圍查找和便利，這個線上用得不是特別多，京東只支持有需要按范圍、需要便利查詢的場景。

復(fù)制協(xié)議更加關(guān)鍵，因為對于存儲來說最核心的是復(fù)制，除了異步復(fù)制就是同步復(fù)制，京東上半年做了狀態(tài)機(jī)的復(fù)制。分片策略京東用哈希最多，因為哈希最簡單，業(yè)務(wù)更多時候需要單K去查詢，有些業(yè)務(wù)需要按范圍，京東支持Range。這三個方面技術(shù)可以做合理的按業(yè)務(wù)場景組合，滿足不同的業(yè)務(wù)需求，比如業(yè)務(wù)更多是用Dict+異步復(fù)制+哈希分片策略，比較大的是RAM+SSD兩級存儲，然后配合其他的策略。

從業(yè)務(wù)使用場景角度，京東是分而治之，不同的軟件、不同的集群，根據(jù)業(yè)務(wù)的需要，可以分成這么兩大類。不少業(yè)務(wù)是做純緩存，后臺還有數(shù)據(jù)庫和其他存儲，京東更多是用異步復(fù)制或者不復(fù)制，哈希的分片，可以做LUR的淘汰。但是線上也有將近一半左右的集群，他們不僅僅用這個東西做緩存，他們做持久存儲，京東有更高的可靠性保證，一般用來開啟同步或者狀態(tài)機(jī)的復(fù)制，然后用范圍或哈希分片，而且對它的快照做定時備份，備份到內(nèi)部對象存儲上去。

對任何一個系統(tǒng)來說，底層的基礎(chǔ)技術(shù)研發(fā)僅僅是它的一個環(huán)節(jié)，當(dāng)系統(tǒng)達(dá)到一定規(guī)模之后，更多工作會放在監(jiān)控和運維體系的建設(shè)方面。整個平臺京東有比較完善的監(jiān)控體系，這更多是數(shù)據(jù)驅(qū)動的，從各個方面，連接樹、網(wǎng)絡(luò)入出流量等等，產(chǎn)生很多時間序列進(jìn)行分析、預(yù)警，并且驅(qū)動各種控制器做決策。比如有的分片存的數(shù)據(jù)因為是個華為的手機(jī)，它太熱了，京東就可以把它做分列，很多時候做擴(kuò)容做分列并不是因為容量，而是因為數(shù)據(jù)的熱度。數(shù)據(jù)監(jiān)控也存在這個系統(tǒng)里做快速的展現(xiàn)。

基于容器的自動化運維，因為我剛才說過，整個系統(tǒng)規(guī)模比較大，有幾千臺機(jī)器，而且每臺機(jī)器上部署很多的存儲節(jié)點，所以運維的復(fù)雜性比較高。在整個2013年更多是依靠手工的運維，怎么樣選機(jī)器，怎么樣部署，運維工作量極大，在2014年下半年和2015年上半年，京東花了很長時間做全自動化運維的平臺，它是基于Docker，簡單來說是大的Linux大內(nèi)存服務(wù)器上上面有很多Docker，每個進(jìn)程是Docker實例，用Docker軟件管理版本，智能做機(jī)器的選擇，做定期的軟件升級，各個方面很多工作。這個平臺通過容器技術(shù)也在這里面有所發(fā)揮。

說一說規(guī)模吧，因為對于任何一個底層系統(tǒng)建設(shè)來說，它核心的價值只有一定規(guī)模、真實驅(qū)動業(yè)務(wù)才能有收獲力。線上京東有多個數(shù)據(jù)中心，有幾千臺大內(nèi)存機(jī)器，都需要跨數(shù)據(jù)中心的復(fù)制，有的基于容災(zāi)的考慮，比如不同的機(jī)房有不同的規(guī)則，有可能跨機(jī)房做異步復(fù)制，有可能同步，預(yù)計明年有512G內(nèi)存或者1T內(nèi)存機(jī)器的采購。線上支持了1000多個線上的業(yè)務(wù)，每個應(yīng)用相當(dāng)于一個邏輯的集群。從運維角度來說，這么多臺機(jī)器里面有大概3萬多Docker的實例。

內(nèi)存存儲帶來什么？花了很多內(nèi)存片、內(nèi)存條，帶來了極佳的性能、非常穩(wěn)定的性能，這是京東線上某一個比較重要的集群，在雙十一期間可以看到它整體的QPS超過200多萬，是非常穩(wěn)定的，99%的請求都在2毫秒之內(nèi)返回，這個讓用戶體驗更好，讓京東的業(yè)務(wù)開發(fā)起來更加簡單，讓公司運維團(tuán)隊更加省心、更加輕松。

內(nèi)存存儲考慮的一個主要因素是，內(nèi)存可以花錢買，但是不能因為軟件因素再去浪費內(nèi)存，內(nèi)存存儲是分出來的，線上很多集群比較夸張、比較大，可能因為它使用場景比較特殊，才產(chǎn)生了碎片。但是整個分布來說，京東也做一些優(yōu)化的工作，從內(nèi)存分布器選擇來看，主要的集群內(nèi)存碎片率基本在1.1-1.3左右。我個人工程上的經(jīng)驗來說，這是非常好的內(nèi)存分配器，內(nèi)存分配器自行開發(fā)意義很小。

正在做的事情比較多，優(yōu)先級比較高的是讓它更穩(wěn)定更好的運維，除此之外進(jìn)一步提升性能，通過軟件硬件協(xié)同創(chuàng)新，引入更大、更便宜的內(nèi)存、更快的網(wǎng)卡，考慮重新實現(xiàn)用戶的網(wǎng)絡(luò)協(xié)議加速小包的處理性能。Linux網(wǎng)絡(luò)協(xié)議站不是為數(shù)據(jù)中心高速的網(wǎng)絡(luò)、高速的在線應(yīng)用而設(shè)計，每一次包都要中斷，對于大包是合理的，對于小包是不劃算的，這樣的存儲性能更多的是小包處理，京東在考慮重寫用戶協(xié)議，來加速小包處理的性能。在功能方面京東也在做個事情，這更多是工作量的事情，考慮從NoSQL支持SQL接口，因為底層有了橫向擴(kuò)張、靈活復(fù)制的內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)的存儲。通過JAVA等等提供，這是工作量的問題而已。

另外，希望在某種程度上降低成本，因為平臺化第一步是求規(guī)模穩(wěn)定，讓它有很好的性能和效率的保證，第二是從整體來說能降低成本，比大家分散、自由去用更省錢。基本的想法是這樣的，目前是專署集群，京東希望從專署集群過渡到聚合各個IDC的RAM資源，比如說京東私有云機(jī)器去分容器、去分虛擬機(jī)，很多時候CPU是瓶頸，分完了內(nèi)存有剩余，非結(jié)構(gòu)化機(jī)器磁盤是瓶頸，磁盤或SSD被分完了但內(nèi)存有空余，京東聚合整個RAM資源，讓數(shù)據(jù)動態(tài)流動、去降低成本。

云數(shù)據(jù)庫服務(wù)是一項基礎(chǔ)性的云服務(wù)，解決用戶自己搭建數(shù)據(jù)庫時需要考慮的各種問題，讓用戶在使用時可以按需申請數(shù)據(jù)庫資源，保證整個數(shù)據(jù)庫服務(wù)的穩(wěn)定性及數(shù)據(jù)的可靠性，同時提供彈性伸縮等的支持，盡可能的降低用戶在使用云數(shù)據(jù)庫時的成本。

本主題主要是分享京東私有云分布式數(shù)據(jù)庫集群的實現(xiàn)，包括如何支撐上億級數(shù)據(jù)量的業(yè)務(wù)，如何保證數(shù)據(jù)高可靠、服務(wù)高可用以及在線集群擴(kuò)容等機(jī)制。另外還會分享京東公有云數(shù)據(jù)庫的架構(gòu)與設(shè)計，如何實現(xiàn)一個穩(wěn)定、可靠、可彈性伸縮的公有云數(shù)據(jù)庫服務(wù)，涉及到備份、恢復(fù)、監(jiān)控、遷移、高可用切換等一整套方案。

京東內(nèi)部有大量業(yè)務(wù)的數(shù)據(jù)是存放在Oracle中的，為了完成京東內(nèi)部去O的過程，京東為此打造了一套私有云分布式數(shù)據(jù)庫集群，這套私有云分布式數(shù)據(jù)庫集群目前支撐著京東大量擁有上百億級數(shù)據(jù)量的業(yè)務(wù)，本主題中會重點介紹去O過程中遇到的難點同時詳細(xì)介紹在內(nèi)部數(shù)據(jù)庫云化以及在支撐大規(guī)模業(yè)務(wù)過程中積累的經(jīng)驗，包括如何打造一套高性能的私有云分布式數(shù)據(jù)庫集群服務(wù)，如何在支撐京東上百億級別數(shù)據(jù)量業(yè)務(wù)正常服務(wù)的情況下做到在線無縫集群擴(kuò)容，分享來自京東生產(chǎn)一線的經(jīng)驗。

云服務(wù)最重要的是要做到可彈性伸縮可按需獲取資源，讓用戶可以盡可能的花最少的代價滿足業(yè)務(wù)的需求。用戶使用云數(shù)據(jù)庫時面臨當(dāng)業(yè)務(wù)量增長時申請的資源不夠，需要做到快速的擴(kuò)張現(xiàn)有資源，當(dāng)業(yè)務(wù)量降低時需要快速縮小現(xiàn)有資源。當(dāng)數(shù)據(jù)庫實例甚至整個機(jī)房發(fā)生故障時，要做到用戶在云數(shù)據(jù)庫中的數(shù)據(jù)是安全的可靠的，可以第一時間恢復(fù)云數(shù)據(jù)庫服務(wù)，包括跨機(jī)房恢復(fù)等，保證云上的用戶業(yè)務(wù)是不受影響的，這些都是云服務(wù)尤其是云數(shù)據(jù)庫服務(wù)需要解決的事情，本主題也會介紹京東公有云數(shù)據(jù)庫是怎么解決這些問題的以及在解決這些問題時積累的經(jīng)驗。

京東云數(shù)據(jù)庫主要包括公有云數(shù)據(jù)庫服務(wù)和私有云數(shù)據(jù)庫服務(wù)兩部分。公有云數(shù)據(jù)庫主要是面向外部用戶，定位是中小型公司；私有云數(shù)據(jù)庫主要針對公司內(nèi)部業(yè)務(wù)，有時候甚至?xí)厥鈽I(yè)務(wù)特殊對待，會針對業(yè)務(wù)的特點來具體問題具體分析，數(shù)據(jù)量較大的業(yè)務(wù)京東會建議業(yè)務(wù)使用京東私有云分布式數(shù)據(jù)庫集群，將數(shù)據(jù)進(jìn)行拆分等。這兩項服務(wù)在京東都是由同一個團(tuán)隊來提供支持，京東云數(shù)據(jù)庫的總體做法是將私有云數(shù)據(jù)庫中積累的經(jīng)驗逐步的輸出到公有云數(shù)據(jù)庫上。

云數(shù)據(jù)庫集群服務(wù)主要是指分布式數(shù)據(jù)庫集群，用戶在使用這個集群的時候可以像使用單臺數(shù)據(jù)庫一樣去使用，在業(yè)務(wù)層面不用關(guān)心集群中的數(shù)據(jù)是如何分布的，對用戶來說后端的數(shù)據(jù)庫實例是不可見的或者不需要關(guān)心的，在使用層面來說心智負(fù)擔(dān)會大大降低。

N個數(shù)據(jù)庫同時提供服務(wù)一般是指N個數(shù)據(jù)庫服務(wù)多個不同的業(yè)務(wù)，或者是某個業(yè)務(wù)同時使用了N個數(shù)據(jù)庫，但是業(yè)務(wù)對這些數(shù)據(jù)庫是有感知的，換句話說這N個數(shù)據(jù)庫對業(yè)務(wù)都是可見的。

云數(shù)據(jù)庫服務(wù)其實也可以理解為將傳統(tǒng)的數(shù)據(jù)庫服務(wù)搬到云上，但是云數(shù)據(jù)庫服務(wù)尤其是公有云數(shù)據(jù)庫和傳統(tǒng)的數(shù)據(jù)庫確實是有區(qū)別的，最大的挑戰(zhàn)在于不僅僅要提供數(shù)據(jù)庫服務(wù)，還需要與用戶的私有網(wǎng)絡(luò)及云主機(jī)甚至包括云存儲等各項云服務(wù)相互配合提供高可用的服務(wù)、保證數(shù)據(jù)的高可靠，是一整套云服務(wù)中的一項。傳統(tǒng)的數(shù)據(jù)庫技術(shù)更多關(guān)注的是數(shù)據(jù)庫本身的，網(wǎng)絡(luò)及主機(jī)等問題一般會比較簡單。

京東公有云數(shù)據(jù)庫的架構(gòu)都是基于私有云數(shù)據(jù)庫的實踐經(jīng)驗所得，在實際輸出的時候考慮到安全及彈性伸縮等的考慮，公有云上采用基于虛機(jī)部署的方式，結(jié)合云主機(jī)云存儲以及云數(shù)據(jù)庫系統(tǒng)自身相配套的信息采集系統(tǒng)再整合公司的監(jiān)控系統(tǒng)等各項服務(wù)，對外提供可伸縮高可用及高可靠的公有云數(shù)據(jù)庫服務(wù)。

私有云中的分布式數(shù)據(jù)庫集群架構(gòu)主要是采用引入中間件的方式來支撐業(yè)務(wù)，中間件本身完全兼容mysql協(xié)議，在內(nèi)部業(yè)務(wù)使用的時候可以像使用原生數(shù)據(jù)庫一樣簡單。

公司內(nèi)部有一套完整的統(tǒng)一的監(jiān)控系統(tǒng)，云數(shù)據(jù)庫自身還有一套信息采集系統(tǒng)，采集系統(tǒng)會采集數(shù)據(jù)庫實例上的相關(guān)信息包括慢查詢以及機(jī)器負(fù)載等信息，這些采集的信息經(jīng)分析處理以后如果如果發(fā)現(xiàn)有異常比如有慢查詢或者機(jī)器負(fù)載較高，會通過統(tǒng)一的監(jiān)控系統(tǒng)觸發(fā)報警，做到及時發(fā)現(xiàn)問題及時處理問題。

在私有云分布式數(shù)據(jù)庫集群中的性能監(jiān)控主要是兩部分構(gòu)成，一部分是分布式數(shù)據(jù)庫中間件會對查詢做一些統(tǒng)計信息，這些統(tǒng)計信息中有超過某些閾值的情況就會觸發(fā)報警，另外一部分是數(shù)據(jù)庫本身的完善的監(jiān)控系統(tǒng)。

京東公有云數(shù)據(jù)庫目前是部署在虛擬機(jī)里的，基于虛擬機(jī)的快速創(chuàng)建京東可以做到公有云數(shù)據(jù)庫實例的較快的創(chuàng)建。私有云數(shù)據(jù)庫目前有很大一部分已經(jīng)將數(shù)據(jù)庫實例放到容器里，在創(chuàng)建部署方面將更加的便捷，當(dāng)內(nèi)部驗證以后后續(xù)京東也會考慮輸出到公有云上。

京東的業(yè)務(wù)發(fā)展非常的迅猛，所以在很大程度上來說京東的技術(shù)都在被業(yè)務(wù)驅(qū)動著往前跑，很多業(yè)務(wù)早期數(shù)據(jù)可能是放在Oracle或者Sqlserver中的，等到業(yè)務(wù)量比較龐大的時候再著手將數(shù)據(jù)從原來的數(shù)據(jù)庫遷移到mysql里的時候就會比較痛苦，一般都需要業(yè)務(wù)方和數(shù)據(jù)庫團(tuán)隊緊密配合才能真正的完整的遷移出來，但是也正是因為有這些實際的業(yè)務(wù)需求驅(qū)使著京東的技術(shù)不斷的提升。

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。