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

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

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

接下來從技術(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è)務需求，便不斷演進，一路做下來。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

公司內(nèi)部有一套完整的統(tǒng)一的監(jiān)控系統(tǒng)，云數(shù)據(jù)庫自身還有一套信息采集系統(tǒng)，采集系統(tǒng)會采集數(shù)據(jù)庫實例上的相關(guān)信息包括慢查詢以及機器負載等信息，這些采集的信息經(jīng)分析處理以后如果如果發(fā)現(xiàn)有異常比如有慢查詢或者機器負載較高，會通過統(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ù)庫目前是部署在虛擬機里的，基于虛擬機的快速創(chuàng)建京東可以做到公有云數(shù)據(jù)庫實例的較快的創(chuàng)建。私有云數(shù)據(jù)庫目前有很大一部分已經(jīng)將數(shù)據(jù)庫實例放到容器里，在創(chuàng)建部署方面將更加的便捷，當內(nèi)部驗證以后后續(xù)京東也會考慮輸出到公有云上。

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