大家好，我是京東到家后臺研發(fā)部的架構(gòu)師閆文廣，今天將給大家分享京東到家訂單系統(tǒng)的高可用架構(gòu)及演變過程。

京東到家是達達集團旗下中國最大的本地即時零售平臺之一，目標就是實現(xiàn)一個小時配送到家的業(yè)務(wù)。一直到2019年京東到家覆蓋700個縣區(qū)市，合作門店近10萬家，服務(wù)數(shù)千萬消費者。隨著訂單量的增長、業(yè)務(wù)復(fù)雜度的提升，訂單系統(tǒng)也在不斷演變進化，從早期一個訂單業(yè)務(wù)模塊到現(xiàn)在分布式可擴展的高并發(fā)、高性能、高可用訂單系統(tǒng)。整個發(fā)展過程中，訂單系統(tǒng)經(jīng)歷了幾個明顯的階段，通過不同的技術(shù)優(yōu)化方案解決業(yè)務(wù)上遇到的問題。

下面我將為大家逐一介紹我們遇到了哪些問題及如何解決，主要分為以下三部分：

首先來看以下這張流程圖，這個系統(tǒng)架構(gòu)主要由幾個部分構(gòu)成：用戶端分別是C端用戶和B端用戶。B端用戶針對的是像沃爾瑪、永輝超市等的一些商家，商家生產(chǎn)需要用到我們的一些揀貨APP和揀貨助手，后面商家履約完成會用到配送端，配送端就是給騎手接單搶單，最后是結(jié)算部分，分別給騎手和商家結(jié)算。

C端針對的是用戶，用戶進來瀏覽、下單到支付，整個過程是用戶的操作行為?；谟脩舻牟僮餍袨椋覀冇袔状竽K來支撐，首先是京東到家APP的后端業(yè)務(wù)支撐的基礎(chǔ)服務(wù)，另外就是營銷系統(tǒng)、業(yè)務(wù)系統(tǒng)等等?；谏厦孢@些，我們需要有很多系統(tǒng)來支撐，比如運營支撐系統(tǒng)、管理后臺的支撐系統(tǒng)、對商家的履約支撐系統(tǒng)。這些業(yè)務(wù)系統(tǒng)的底層大概有三塊的持久化，分別是緩存（LocalCache、Redis等）、DB（MySQL、MongoDB等數(shù)據(jù)庫）、ES。這就是京東到家簡版的業(yè)務(wù)架構(gòu)圖。

京東到家的運營支撐業(yè)務(wù)架構(gòu)主要分為商家管理、CMS管理、營銷管理、財務(wù)管理、運營數(shù)據(jù)這五大模塊，每塊包含的內(nèi)容具體如下圖所示：

接下來是我們C端APP的一些網(wǎng)關(guān)后端的接口及基礎(chǔ)服務(wù)的支撐。首先所有的請求都會經(jīng)過網(wǎng)關(guān)協(xié)議，網(wǎng)關(guān)下面分為業(yè)務(wù)系統(tǒng)，包括首頁、門店頁、購物車、結(jié)算頁以及提單系統(tǒng)、支付系統(tǒng)和個人訂單系統(tǒng)，這些系統(tǒng)的支撐都離不開我們的基礎(chǔ)服務(wù)的支撐，比如庫存、商品、門店、價格等等，這些是一些重要的基礎(chǔ)服務(wù)支撐，來保證用戶可以流暢的下單以及到結(jié)算。

業(yè)務(wù)支撐包含了很多業(yè)務(wù)系統(tǒng)，比如用戶、定位、地址庫、運費、promise、推薦、搜索、收銀臺、風控等。

上面說到了營銷的一些管理系統(tǒng)，其實營銷還有一些后端的基礎(chǔ)服務(wù)系統(tǒng)，比如優(yōu)惠券、滿減、秒殺、首單等。

用戶提單以后數(shù)據(jù)怎么流轉(zhuǎn)？提單其實是一個把用戶下單數(shù)據(jù)存儲到數(shù)據(jù)庫，提單系統(tǒng)做了一些分庫分表。那么提完單的數(shù)據(jù)怎么下發(fā)到訂單系統(tǒng)生產(chǎn)？首先我們會有一個管道，提單通過一個分布式異步任務(wù)來下發(fā)訂單管道里。所有的訂單下來都會放到管道里，我們通過一個異步的任務(wù)，按照一定的速率，均勻地把訂單下發(fā)到訂單生產(chǎn)系統(tǒng)。這樣設(shè)計有一個好處，比如像大促時可能會有大量數(shù)據(jù)一下子下發(fā)到訂單生產(chǎn)系統(tǒng)，對訂單生產(chǎn)庫有很大壓力，所以我們中間設(shè)計出一個管道，通過異步任務(wù)來分發(fā)生產(chǎn)訂單。

看了圖可能有人會問為什么要有一個個人訂單DB？其實個人訂單DB跟訂單系統(tǒng)是不同維度的數(shù)據(jù)，因為個人訂單其實是基于用戶去做了一個分庫分表，它每一個查詢的訂單都是基于這種個人，跟訂單生產(chǎn)是不一樣的，所以每個維度的數(shù)據(jù)都是單獨的存儲，來提高系統(tǒng)的穩(wěn)定性，以及適合它自身業(yè)務(wù)特性的設(shè)計。

那么訂單系統(tǒng)跟個人中心是怎么交互的？首先異步，我們是通過MQ來交互這些訂單狀態(tài)的變更。另外C端的訂單取消，是怎么同步到訂單生產(chǎn)系統(tǒng)的？我們是通過RPC的調(diào)用來保證訂單實時取消，有一個返回結(jié)果。

我們的訂單履約分為兩大塊，商家生產(chǎn)和配送履約，具體步驟如下圖所示：

??

整個訂單履約的流程是怎么樣的？在用戶支付完成后，訂單會有一個補全的過程，補全完后，我們會根據(jù)一些門店的設(shè)置，把訂單下發(fā)到商家。下發(fā)商家后，有幾種對接模式：有開發(fā)能力的商家可以通過開放平臺，一些小商家可以通過商家中心以及我們的京明管家來完成訂單的生產(chǎn)履約。在商家拿到新訂單后，通過打印出小票進行揀貨。揀貨會分為幾個業(yè)務(wù)場景，因為有可能商家有貨也有可能沒貨，如果缺貨的話，我們有一個調(diào)整的功能，讓商家通過訂單調(diào)整來保證有商品的訂單可以繼續(xù)履約。

在商家完成揀貨時，我們訂單會分為分區(qū)揀貨、合單揀貨、前置倉揀貨這幾塊業(yè)務(wù)上的操作，其實在系統(tǒng)里我們有一個揀貨的池子，會通過不同維度的數(shù)據(jù)來完成高效的揀貨。揀貨完成后，我們的配送主要分為兩個模塊，一種是單個訂單的配送，另一種是集合單的配送。集合單就是把發(fā)單地址和配送地址在兩個相近的格子里的訂單合并起來，基本上都是基于將同一個門店的配送目的是同一個相近格子里的訂單，進行合單后讓一個騎士完成配送。配送會下發(fā)到一些配送系統(tǒng)，分為兩種模式，集合單和單個訂單的配送，以及和配送系統(tǒng)的整個運單交互的一個流程。

說完業(yè)務(wù)后，接下來介紹一下我們應(yīng)用的一些微服務(wù)的拆分過程。先講一下微服務(wù)理論方面的知識，比如為什么要拆分微服務(wù)？微服務(wù)拆分后可以解決哪些問題？這是接下來一個重點內(nèi)容，大家可以思考一下，系統(tǒng)架構(gòu)必須具備哪些條件才能達到高可用？

簡單總結(jié)來說，微服務(wù)可以降低系統(tǒng)的復(fù)雜度，可以獨立部署，并且有很好的擴展性：

我們訂單系統(tǒng)的架構(gòu)演進如上圖所示，最左邊是最初的一個模型，所有的業(yè)務(wù)都耦合在一個應(yīng)用里面，這個應(yīng)用可能就有一個service來支撐，數(shù)據(jù)庫也是一個單點的數(shù)據(jù)庫。隨著這些年的迭代升級變更，逐步演進到一個應(yīng)用有多個服務(wù)支撐，數(shù)據(jù)庫也在不斷升級變更，以及到后面把應(yīng)用按微服務(wù)拆分成多個模塊，拆成多個領(lǐng)域的支撐，按不同的系統(tǒng)邊界去拆分。并且拆完后，隨著業(yè)務(wù)量越來越大，其實我們也在做一些升級，比如Redis的接入。

Redis的接入解決了什么問題？數(shù)據(jù)庫為什么要分庫？ES為什么在接下來一些系統(tǒng)架構(gòu)升級里會被引入進來？為什么DB要拆成多個集群？這背后的一些根本問題，以及解決業(yè)務(wù)系統(tǒng)的一些背景，接下來我們逐一探討。

在最初搭建項目時，其實我們是要保證業(yè)務(wù)的快速試錯。這個模型會有什么問題？就是系統(tǒng)會有一些單點風險，以及系統(tǒng)發(fā)布是一個短暫停，所有請求都是一個主觀的操作，并發(fā)能力很差，稍微有一些業(yè)務(wù)量時，系統(tǒng)接口就會超時比較嚴重。這是最初2015-2016年的情況。

接下來2016-2017年，隨著業(yè)務(wù)的快速迭代，系統(tǒng)復(fù)雜度也慢慢高了起來，系統(tǒng)邏輯耦合會比較嚴重，改動一塊的邏輯影響就會比較大，導(dǎo)致線上問題頻發(fā)，因為所有的邏輯都耦合在一起，一次發(fā)布可能就會影響范圍比較大。

按微服務(wù)拆分成多個系統(tǒng)，如果發(fā)布有問題也只會影響其中的一些很小的部分。在后面隨著業(yè)務(wù)量越來越大，RPC這種框架的引入，解決故障的自動下線，保證高可用，比如單臺服務(wù)器有問題時，能做到自動下線來保證不影響業(yè)務(wù)。

2017-2018年，我們根據(jù)2016年遇到的問題做了一些拆分，比如按領(lǐng)域拆分不同的APP應(yīng)用。這樣拆分做到的就是系統(tǒng)沒有單點，負載均衡可以橫向擴展，多點部署。包括引入Redis，其實我們用到了Redis的分布式鎖、緩存、有序隊列、定時任務(wù)。

我們數(shù)據(jù)庫為什么升級？因為數(shù)據(jù)庫的數(shù)據(jù)量越來越大，比如添加一些字段，它其實會做一些鎖表操作，隨著數(shù)據(jù)量越大，單表的數(shù)據(jù)越來越多，數(shù)據(jù)主從延遲以及一些鎖表的時間會越來越長，所以在加字段的時候?qū)ιa(chǎn)影響特別大，我們就會對數(shù)據(jù)做一個分離，把一些冷的數(shù)據(jù)單獨做一個歷史庫，剩下的生產(chǎn)庫只留最近幾天的一些生產(chǎn)需要的數(shù)據(jù)，這樣生產(chǎn)庫的訂單數(shù)據(jù)量就會很小，每次修改表的時間是可控的，所以我們會把數(shù)據(jù)按照冷備進行拆分。

至于為什么引入ES，是因為訂單在生產(chǎn)方面會有一些很復(fù)雜的查詢，復(fù)雜查詢對數(shù)據(jù)庫的性能影響非常大，引入ES就可以很好地解決這個問題。

2018-2019年，我們發(fā)現(xiàn)之前在引入數(shù)據(jù)庫時，用數(shù)據(jù)冗余來保證一些數(shù)據(jù)應(yīng)用可互備互降。比如我們之前在用ES低版本1.7的時候，其實就是一個單點，當集群有問題時是會影響生產(chǎn)的。我們后來引入了一個雙集群，雙ES集群互備，當一個集群有問題時，另一個集群可以直接頂上來，確保了應(yīng)用的高可用和生產(chǎn)沒有問題。

另外，引入Redis雙集群，Redis其實有一些大key的問題，當一些核心業(yè)務(wù)和非核心業(yè)務(wù)都用到Redis的時候，我們會把一些核心業(yè)務(wù)拆到一個集群，非核心業(yè)務(wù)拆到另一個集群，來保證Redis集群的穩(wěn)定性，能穩(wěn)定支撐訂單生產(chǎn)。

注：大key（線上看到過list的elements超過百萬的）刪除時會阻塞比較長的時間，大key的危害：

單個應(yīng)用怎么保證高可用？其實我們這邊從最初的一個單機房單實例單IP，一步步演進為單機房的單服務(wù)、單機房的多服務(wù)，最終是多機房的多服務(wù)，比如某個機房某些IP有問題，我們能確保應(yīng)用可以正常請求響應(yīng)，來保證系統(tǒng)的高可用。

下面來介紹一下我們主從架構(gòu)的演進。最初我們就是一些主從的架構(gòu)，并且主讀和寫都會請求到一個主庫，這樣就會給主庫帶來非常大的壓力。而像訂單生產(chǎn)這種天然性就是讀多寫少，主庫的壓力會比較大。所以基于這個問題，我們就做了數(shù)據(jù)庫架構(gòu)的升級。

我們做了讀寫分離，就能很好地解決了這個問題。比如很多查詢，我們就會直接查詢到從庫的，主庫只是用來承載一些寫的流量，這樣主庫就減少了很多壓力。但這樣就會遇到上面說到的問題，因為我們是一個生產(chǎn)表和歷史表的結(jié)構(gòu)，在每次加字段時，數(shù)據(jù)量很多的話，鎖表時間就會很長，導(dǎo)致在這種讀寫分離的架構(gòu)下數(shù)據(jù)延遲就會比較大。

基于這種場景，我們又做了一些升級和改造。我們把數(shù)據(jù)拆出來了，拆成歷史庫，當所有的生產(chǎn)數(shù)據(jù)都很小的時候，對于提高性能是非常有幫助的。我們把生產(chǎn)完的一些數(shù)據(jù)全部都歸檔到歷史中，減輕主庫的整個壓力，以及在添加表字段修改的時候，其實就沒有太大影響了，基本上都很穩(wěn)定。

數(shù)據(jù)的演進最終結(jié)構(gòu)如上圖，當這是基于目前業(yè)務(wù)的一個支撐，在未來業(yè)務(wù)不斷發(fā)展的情況下，這個數(shù)據(jù)庫架構(gòu)是原因不夠的?；谝陨霞軜?gòu)，我們主要是做到了一主多從的主備實時切換，同時確保主從在不同機房來保證數(shù)據(jù)庫的容災(zāi)能力。同時通過業(yè)務(wù)隔離查詢不同的從庫給主庫減輕壓力，以及冷備數(shù)據(jù)的隔離的一個思路來保證訂單數(shù)據(jù)庫的穩(wěn)定性。

最開始我們是單ES集群，DB會通過一個同步寫寫到ES集群。這個時候我們的ES是一個單機群，如果寫失敗的話，我們會起一個異步任務(wù)來保證數(shù)據(jù)的最終一致性，是這樣的一個架構(gòu)。在ES集群沒問題的情況下，這個架構(gòu)也是沒問題的，但當集群有問題時，其實就沒有可降級的了。

為了解決這個問題，我們引入了ES的冷備兩個集群，熱集群只保存跟數(shù)據(jù)庫一樣的生產(chǎn)庫的數(shù)據(jù)，比如說我們現(xiàn)在保證的就是5天的生產(chǎn)數(shù)據(jù)，其它所有數(shù)據(jù)都歸檔在一個ES的冷集群里。通過這種異步跟同步寫，通過異步任務(wù)來保證最終的集群的數(shù)據(jù)一致性。這就是ES的架構(gòu)升級。

其實ES這樣寫的話會帶來一些很大的侵入，每次我們數(shù)據(jù)庫的一個變更都會帶來一些要RPC調(diào)用去同步ES的數(shù)據(jù)。這種瓶頸以及侵入式的問題怎么解決？我們接入了開源的Canal，通過監(jiān)聽數(shù)據(jù)庫變更了binlog，來通過Canal、kafka，然后異步通過消息來同步到ES集群。這個集群目前已經(jīng)應(yīng)用到線上的一些業(yè)務(wù)，經(jīng)過灰度發(fā)布、后期驗證沒有問題后，會逐步接入生產(chǎn)系統(tǒng)。

如上圖所示，是我們整個訂單系統(tǒng)的結(jié)構(gòu)。整個過程我們是通過業(yè)務(wù)網(wǎng)關(guān)、RPC高可用、業(yè)務(wù)聚合、DB冗余、多機房部署，來保證整個訂單應(yīng)用的一些系統(tǒng)架構(gòu)高可用。上述就是整體的訂單架構(gòu)演進過程。

大家思考一下，如果你要負責一些核心系統(tǒng)，你怎么保證穩(wěn)定性？接下來我會從訂單系統(tǒng)可用性建設(shè)、系統(tǒng)容災(zāi)能力、系統(tǒng)容量能力、系統(tǒng)預(yù)警能力分享一下我們在穩(wěn)定性保障上的實踐。

業(yè)務(wù)的快速發(fā)展對可用性保證要求越來越高，在方法論層面，我們按照系統(tǒng)故障的時間順序提出了事前、事中、事后三個階段，同時提出了四方面的能力建設(shè)——預(yù)防能力、診斷能力、解決能力、規(guī)避能力。

具體在工作上，我們會劃分為流程和系統(tǒng)建設(shè)兩個方面。其實最開始我們是為了完成工作，保證的是結(jié)果，最后發(fā)現(xiàn)每一個過程我們會把它平臺化，來提升人效。以上是一個大概的框架，下面我們一項一項詳細分析一下。

容災(zāi)能力這塊，我們從ES冷熱集群互備、Redis緩存集群業(yè)務(wù)隔離，到業(yè)務(wù)接口的可降級和可異步，再到多維度的灰度發(fā)布。

就像上面提到的，我們對開放平臺、商家中心、京明管家等業(yè)務(wù)系統(tǒng)的支撐怎么做到互備？其實就是通過ES的冷熱集群，冷集群存全量的數(shù)據(jù)，熱集群存最近幾天的生產(chǎn)數(shù)據(jù)。而Redis是做業(yè)務(wù)隔離，Redis 存儲有一些大key會影響核心業(yè)務(wù)，我們就會把非核心的業(yè)務(wù)拆出來，拆到另外一個Redis集群。這就是我們系統(tǒng)的業(yè)務(wù)隔離和集群的互備。

業(yè)務(wù)接口可降級，其實是在一些復(fù)雜的業(yè)務(wù)操作接口里，我們可以通過一些異步處理，比如在訂單狀態(tài)變更的操作接口、除了更新DB和ES、發(fā)送MQ，訂單狀態(tài)的變更通過消息去同步發(fā)送。那么我們哪些可降低？比如說我們在業(yè)務(wù)核心操作接口里有一些push消息和發(fā)送短信，像這樣的非核心操作就可以用異步可降級的方案來解決。

灰度發(fā)布其實很重要，線上如果有一些新業(yè)務(wù)或系統(tǒng)的架構(gòu)升級、技術(shù)的迭代，我們這邊都會通過灰度發(fā)布，比如可以通過一些門店先做門店匯總，如果單個門店沒問題，再通過一些商家，如果商家沒問題，就會灰度到整個城市，如果城市也沒問題，我們就會通過全量。

另一個維度來看，我們也會先灰度單臺機器，再到單機房、多機房。當然這個很局限，因為跟你灰度的一些功能有關(guān)系，大家要酌情根據(jù)自己的業(yè)務(wù)借鑒這種方案思路。

至于系統(tǒng)容量的能力，主要分為評估和擴容兩個方面。容量評估可以借助一些輔助的工具，然后進行場景的壓測和全鏈路的壓測；而擴容方面，可以分階段依次實施冗余備份（主從分離）、垂直拆分（拆分核心屬性與非核心屬性）、自動歸檔。

最后是預(yù)警能力，我們這邊用的是京東自研的UMP監(jiān)控。

在接口層面，我們可以監(jiān)控到：

在應(yīng)用層面，我們可以監(jiān)控到：

下面是關(guān)于DB、ES、Redis的集群監(jiān)控，包括：

如果大家有排查過線上的問題，就應(yīng)該能感受到比如像IO高、TCP連接、重傳等，都會影響到線上一些核心接口的響應(yīng)時間，包括你CPU高的時候，線程數(shù)是否飆高？系統(tǒng)負載是否飆高？當這些指標都發(fā)生異常變化時，對于接口的響應(yīng)時間都會有很大影響。

另外，我們還要做一些積壓監(jiān)控，比如一些異步任務(wù)正常來說一分鐘最多積壓1000，就需要添加對應(yīng)的監(jiān)控，否則數(shù)據(jù)異常了都不知道；再比如訂單支付的狀態(tài)，當積壓到一定數(shù)量，可能是系統(tǒng)出了問題，就需要人工介入。

一個企業(yè)的架構(gòu)師團隊，需要長期關(guān)注技術(shù)驅(qū)動業(yè)務(wù)、明確領(lǐng)域職責與邊界等關(guān)鍵問題，同時架構(gòu)的演進過程也是不斷考慮ROI的權(quán)衡取舍過程。技術(shù)的持續(xù)發(fā)展，有助于不斷提升用戶體驗、業(yè)務(wù)規(guī)模，降低運營成本，而架構(gòu)在其中需要解決的問題就是化繁為簡，將復(fù)雜問題拆解為簡單的問題逐個攻破。隨著企業(yè)規(guī)模的持續(xù)增長、業(yè)務(wù)的持續(xù)創(chuàng)新，會給系統(tǒng)架構(gòu)提出越來越高的要求，所以系統(tǒng)架構(gòu)設(shè)計將是我們長期研究的課題。在這條架構(gòu)演進之路上，希望能與大家共勉共進。

Q1：集群規(guī)模大概是什么樣的？各集群節(jié)點規(guī)模如何？

A：京東到家訂單中心ES 集群目前大約有將近30億文檔數(shù)，數(shù)據(jù)大小約1.3TB，集群結(jié)構(gòu)是8個主分片，每個主分片有兩個副本，共24個分片。每個機器上分布1-2個分片，如果企業(yè)不差錢最好的狀態(tài)就是每個分片獨占一臺機器。這些集群規(guī)模和架構(gòu)設(shè)計不應(yīng)該是固定的，每一個業(yè)務(wù)系統(tǒng)應(yīng)該根據(jù)自身實際業(yè)務(wù)去規(guī)劃設(shè)計。

這樣做確定分片數(shù)：

Q2：ES優(yōu)化做過哪些措施？

A：ES使用最佳實踐：寫入的數(shù)據(jù)考慮清楚是否會過期，ES擅長的不是存儲而是搜索，所以一般存入ES的數(shù)據(jù)難免會隨著時間刪除舊數(shù)據(jù)。刪除方法有兩種：①按記錄（不推薦）②按索引。推薦使用后者，所以需要業(yè)務(wù)根據(jù)數(shù)據(jù)特點，按天、月、季度等創(chuàng)建索引。分片數(shù)夠用就好，不要過多不要過少。ES不是數(shù)據(jù)庫，不建議做頻繁的更新。

Q3：集群可承受的TPS是多少？

A：這個沒有具體的數(shù)字，根據(jù)不同規(guī)模集群、不同的索引結(jié)構(gòu)等不同，建議根據(jù)業(yè)務(wù)評估自己的流量，壓測雙倍流量，若ES無法承受或滿足，可以考慮擴容集群，不要流量暴增于平時的3倍、4倍，甚至更多的規(guī)模。

Q4：ES主要是用于明細單查詢，還是聚合統(tǒng)計？Join對資源耗用大嗎？如何控制內(nèi)存及優(yōu)化？

A：ES在訂單系統(tǒng)中的實踐主要是解決復(fù)雜查詢的問題，ES不建議使用聚合統(tǒng)計，如果非要使用那我也攔不住你，哈哈哈。

深分頁的問題【內(nèi)存】

ES處理查詢的流程如下：

1. Client需要第N到N+m條結(jié)果；

2. 接到這個請求的ES server（后繼稱之為協(xié)調(diào)者）向每一個數(shù)據(jù)分片所在的數(shù)據(jù)節(jié)點發(fā)送請求；

3. 每一個數(shù)據(jù)節(jié)點都需要向協(xié)調(diào)者返回(N+m)個結(jié)果；

4. 如果有n個數(shù)據(jù)分片，那么協(xié)調(diào)者拿到n * (N+m)個結(jié)果，排序，扔掉(n-1) * (N+m)個結(jié)果，返回給client N+m個結(jié)果；

5. 如果N是10W，100W，那么協(xié)調(diào)者的內(nèi)存壓力會非常大；

6. 在我們目前維護的2.1版本中，ES已經(jīng)不容許N>10000了。

深分頁的危害：導(dǎo)致打爆節(jié)點內(nèi)存引起集群整體不可用。

Q5：應(yīng)用canal同步數(shù)據(jù)，會有延遲嗎？

A：首先來說下ES 特點：Elasticsearch是一個接近實時的搜索平臺。這意味著，從索引一個文檔直到這個文檔能夠被搜索到有一個輕微的延遲（通常是1秒），這個參數(shù)也是可以調(diào)整的，根據(jù)業(yè)務(wù)場景調(diào)整。

可以肯定的是延遲是肯定的。其實延遲大小完全取決你整個同步流程中是否有瓶頸點，如果業(yè)務(wù)要求實時的，其實不建議在這種場景下使用ES。就好比數(shù)據(jù)庫查詢從庫不能接受延遲，那就不要做讀寫分離，或者都查詢主庫。

Q6：sqlproxy具體用的哪個？

A：sqlproxy這個是指MySQL讀寫分離的實現(xiàn)，大家可以網(wǎng)上查詢下有很多資料。官網(wǎng)地址：https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-master-slave-replication-connection.html

• Redis集群；

• ES集群；

• MySQL集群。