淘寶開放平臺（open.taobao.com）是阿里系統(tǒng)與外部系統(tǒng)通訊的最重要平臺，每天承載百億級的API調(diào)用，百億級的消息推送，十億級的數(shù)據(jù)同步，經(jīng)歷了8年雙11成倍流量增長的洗禮。本文將為您揭開淘寶開放平臺的高性能API網(wǎng)關(guān)、高可靠消息服務(wù)、零漏單數(shù)據(jù)同步的技術(shù)內(nèi)幕。

高性能API網(wǎng)關(guān)

阿里巴巴內(nèi)部的數(shù)據(jù)分布在各個(gè)獨(dú)立的業(yè)務(wù)系統(tǒng)中，如：商品中心、交易平臺、用戶中心，各個(gè)獨(dú)立系統(tǒng)間通過HSF（High-speed Service Framework）進(jìn)行數(shù)據(jù)交換。如何將這些數(shù)據(jù)安全可控的開放給外部商家和ISV，共建繁榮電商數(shù)據(jù)生態(tài)，在這個(gè)背景下API網(wǎng)關(guān)誕生。

API網(wǎng)關(guān)采用管道設(shè)計(jì)模式，處理業(yè)務(wù)、安全、服務(wù)路由和調(diào)用等邏輯。為了滿足雙11高并發(fā)請求（近百萬的峰值QPS）下的應(yīng)用場景，網(wǎng)關(guān)在架構(gòu)上做了一些針對性的優(yōu)化：

1. 元數(shù)據(jù)讀取采用富客戶端多級緩存架構(gòu)，并異步刷新緩存過期數(shù)據(jù)，該架構(gòu)能支持千萬級QPS請求，并能良好的控制機(jī)房網(wǎng)絡(luò)擁塞。
2. 同步調(diào)用受限于線程數(shù)量，而線程資源寶貴，在API網(wǎng)關(guān)這類高并發(fā)應(yīng)用場景下，一定比例的API超時(shí)就會讓所有調(diào)用的RT升高，異步化的引入徹底的隔離API之間的影響。網(wǎng)關(guān)在Servlet線程在進(jìn)行完API調(diào)用前置校驗(yàn)后，使用HSF或HTTP NIO client發(fā)起遠(yuǎn)程服務(wù)調(diào)用，并結(jié)束和回收到該線程。待HSF或者HTTP請求得到響應(yīng)后，以事件驅(qū)動(dòng)的方式將遠(yuǎn)程調(diào)用響應(yīng)結(jié)果和API請求上下文信息，提交到TOP工作線程池，由TOP工作線程完成后續(xù)的數(shù)據(jù)處理。最后使用Jetty Continuation特性喚起請求將響應(yīng)結(jié)果輸出給ISV，實(shí)現(xiàn)請求的全異步化處理。線程模型如圖所示。

在API調(diào)用鏈路中會依賴對元數(shù)據(jù)的獲取，比如需要獲取API的流控信息、字段等級、類目信息、APP的密鑰、IP白名單、權(quán)限包信息，用戶授權(quán)信息等等。在雙11場景下，元數(shù)據(jù)獲取QPS高達(dá)上千萬，如何優(yōu)化元數(shù)據(jù)獲取的性能是API網(wǎng)關(guān)的關(guān)鍵點(diǎn)。

千萬級QPS全部打到DB是不可取的，盡管DB有做分庫分表處理，所以我們在DB前面加了一層分布式緩存；然而千萬級QPS需要近百臺緩存服務(wù)器，為了節(jié)約緩存服務(wù)器開銷以及減少過多的網(wǎng)絡(luò)請求，我們在分布式緩存前面加了一層LRU規(guī)則的本地緩存；為了防止緩存被擊穿，我們在本地緩存前面加了一層BloomFilter。一套基于漏斗模型的元數(shù)據(jù)讀取架構(gòu)產(chǎn)生。緩存控制中心可以動(dòng)態(tài)推送緩存規(guī)則，如數(shù)據(jù)是否進(jìn)行緩存、緩存時(shí)長、本地緩存大小。為了解決緩存數(shù)據(jù)過期時(shí)在極端情況下可能出現(xiàn)的并發(fā)請求問題，網(wǎng)關(guān)會容忍拿到過期的元數(shù)據(jù)（多數(shù)情況對數(shù)據(jù)時(shí)效性要求不高），并提交異步任務(wù)更新數(shù)據(jù)信息。

在雙11高并發(fā)的場景下，對商家和ISV的系統(tǒng)同樣是一個(gè)考驗(yàn)，如何提高ISV請求API的性能，降低請求RT和網(wǎng)絡(luò)消耗同樣是一個(gè)重要的事情。在ISV開發(fā)的系統(tǒng)中通常存在這樣的邏輯單元，需要調(diào)用多個(gè)API才能完成某項(xiàng)業(yè)務(wù)，在這種串行調(diào)用模式下RT較長同時(shí)多次調(diào)用發(fā)送較多重復(fù)的報(bào)文導(dǎo)致網(wǎng)絡(luò)消耗過多，在弱網(wǎng)環(huán)境下表現(xiàn)更加明顯。

API網(wǎng)關(guān)提供批量API調(diào)用模式緩解ISV在調(diào)用RT過高和網(wǎng)絡(luò)消耗上的痛點(diǎn)。ISV發(fā)起的批量請求會在TOP SDK進(jìn)行合并，并發(fā)送到指定的網(wǎng)關(guān)；網(wǎng)關(guān)接收到請求后在單線程模式下進(jìn)行公共邏輯計(jì)算，計(jì)算通過后將調(diào)用安裝API維度拆分，并分別發(fā)起異步化遠(yuǎn)程調(diào)用，至此該線程結(jié)束并被回收；每個(gè)子API的遠(yuǎn)程請求結(jié)果返回時(shí)會拿到一個(gè)線程進(jìn)行私有邏輯處理，處理結(jié)束時(shí)會將處理結(jié)果緩存并將完成計(jì)數(shù)器加一；最后完成處理的線程，會將結(jié)果進(jìn)行排序合并和輸出。

TOP API網(wǎng)關(guān)暴露在互聯(lián)網(wǎng)環(huán)境，日調(diào)用量達(dá)幾百億。特別是在雙11場景中，API調(diào)用基數(shù)大、調(diào)用者眾多以及各個(gè)API的服務(wù)能力不一致，為了保證各個(gè)API能夠穩(wěn)定提供服務(wù)，不會被暴漲的請求流量擊垮，那么多維度流量控制是API網(wǎng)關(guān)的一個(gè)重要環(huán)節(jié)。API網(wǎng)關(guān)提供一系列通用的流量控制規(guī)則，如API每秒流控、API單日調(diào)用量控制、APPKEY單日調(diào)用量控制等。

在雙11場景中，也會有一些特殊的流量控制場景，比如單個(gè)API提供的能力有限，例如只能提供20萬QPS的能力而實(shí)際的調(diào)用需求可能會有40萬QPS。在這種場景下怎么去做好流量分配，保證核心業(yè)務(wù)調(diào)用不被限流。

TOP API網(wǎng)關(guān)提供了流量分組的策略，比如我們可以把20萬QPS的能力分為3個(gè)組別，并可以動(dòng)態(tài)去配置和調(diào)整每個(gè)組別的比例，如：分組1占比50%、如分組2占比40%、分組3占比10%。我們將核心重要的調(diào)用放到分組1，將實(shí)時(shí)性要求高的調(diào)用放到分組2，將一些實(shí)時(shí)性要求不高的調(diào)用放到分組3。通過該模式我們能夠讓一些核心或者實(shí)時(shí)性要求高的調(diào)用能夠較高概率通過流量限制獲取到相應(yīng)的數(shù)據(jù)。同時(shí)TOP API網(wǎng)關(guān)是一個(gè)插件化的網(wǎng)關(guān)，我們可以編寫流控插件并動(dòng)態(tài)部署到網(wǎng)關(guān)，在流控插件中我們可以獲取到調(diào)用上下文信息，通過Groovy腳本或簡單表達(dá)式編寫自定義流控規(guī)則，以滿足雙11場景中豐富的流控場景。

使用集群流控還是單機(jī)流控？單機(jī)流控的優(yōu)勢是系統(tǒng)開銷較小，但是存在如下短板：

1. 集群單機(jī)流量分配不均。
2. 單日流控計(jì)數(shù)器在某臺服務(wù)器掛掉或者重啟時(shí)比較難處理。
3. API QPS限制小于網(wǎng)關(guān)集群機(jī)器數(shù)量時(shí)，單機(jī)流控?zé)o法配置。

基于這些問題，API網(wǎng)關(guān)最開始統(tǒng)一使用集群流控方案，但在雙11前壓測中發(fā)現(xiàn)如下一些問題：

1. 單KEY熱點(diǎn)問題，當(dāng)單KEY QPS超過幾十萬時(shí)，單臺緩存服務(wù)器RT明顯增加。
2. 緩存集群QPS達(dá)到數(shù)百萬時(shí)，服務(wù)器投入較高。

針對第一個(gè)問題的解法是，將緩存KEY進(jìn)行分片可將請求離散多臺緩存服務(wù)器。針對第二個(gè)問題，API網(wǎng)關(guān)采取了單機(jī)+集群流控相結(jié)合的解決方案，對于高QPS API流控采取單機(jī)流控方案，服務(wù)端使用Google ConcurrentLinkedHashMap緩存計(jì)數(shù)器，在并發(fā)安全的前提下保持了較高的性能，同時(shí)能做到LRU策略淘汰過期數(shù)據(jù)。

高可靠消息服務(wù)

有了API網(wǎng)關(guān)，服務(wù)商可以很方便獲取淘系數(shù)據(jù)，但是如何實(shí)時(shí)獲取數(shù)據(jù)呢？輪詢 ！數(shù)據(jù)的實(shí)時(shí)性依賴于應(yīng)用輪詢間隔時(shí)間，這種模式，API調(diào)用效率低且浪費(fèi)機(jī)器資源。基于這樣的場景，開放平臺推出了消息服務(wù)技術(shù)，提供一個(gè)實(shí)時(shí)的、可靠的、異步雙向數(shù)據(jù)交換通道，大大提高API調(diào)用效率。目前，整個(gè)系統(tǒng)日均處理百億級消息，可支撐百萬級瞬時(shí)流量，如絲般順滑。

消息系統(tǒng)從部署上分為三個(gè)子系統(tǒng)，路由系統(tǒng)、存儲系統(tǒng)以及推送系統(tǒng)。消息數(shù)據(jù)先存儲再推送，保證每條消息至少推送一次。寫入與推送分離，發(fā)送方不同步等待接收方應(yīng)答，客戶端的任何異常不會影響發(fā)送方系統(tǒng)的穩(wěn)定性。系統(tǒng)模塊交互如圖所示。

路由系統(tǒng)，各個(gè)處理模塊管道化，擴(kuò)展性強(qiáng)。系統(tǒng)監(jiān)聽主站的交易、商品、物流等變更事件，針對不同業(yè)務(wù)進(jìn)行消息過濾、鑒權(quán)、轉(zhuǎn)換、存儲、日志打點(diǎn)等。系統(tǒng)運(yùn)行過程記錄各個(gè)消息的處理狀況，通過日志采集器輸出給JStorm分析集群處理并記錄消息軌跡，做到每條消息有跡可循。

存儲系統(tǒng),主要用于削峰填谷，基于BitCask存儲結(jié)構(gòu)和內(nèi)存映射文件，磁盤完全順序?qū)懭耄俣葮O佳。數(shù)據(jù)讀取基于FileRegion零拷貝技術(shù)，減少內(nèi)存拷貝消耗，數(shù)據(jù)讀取速度極快。存儲系統(tǒng)部署在多個(gè)機(jī)房，有一定容災(zāi)能力。

推送系統(tǒng)，基于Disputor構(gòu)建事件驅(qū)動(dòng)模型，使用Netty作為網(wǎng)絡(luò)層框架，構(gòu)建海量連接模型，根據(jù)連接吞吐量智能控制流量，降低慢連接對系統(tǒng)的壓力；使用WebSocket構(gòu)建 長連接通道，延時(shí)更低；使用對象池技術(shù)，有效降低系統(tǒng)GC頻率；從消息的觸發(fā)，到拉取，到發(fā)送，到確認(rèn)，整個(gè)過程完全異步，性能極佳。

在消息系統(tǒng)中，一般有兩種消費(fèi)模式：服務(wù)端推送和客戶端拉取。本系統(tǒng)主要面向公網(wǎng)的服務(wù)器，采用推送模式，有如下優(yōu)點(diǎn) ：

1. 實(shí)時(shí)性高。從消息的產(chǎn)生到推送，總體平均延時(shí)100毫秒，最大不超過200毫秒。
2. 服務(wù)器壓力小。相比于拉取模式，每次推送都有數(shù)據(jù)，避免空輪詢消耗資源。
3. 使用簡便。使用拉取模式，客戶端需要維護(hù)消費(fèi)隊(duì)列的位置，以及處理多客戶端同時(shí)消費(fèi)的并發(fā)問題。而在推送模式中，這些事情全部由服務(wù)器完成，客戶端僅需要啟動(dòng)SDK監(jiān)聽消息即可，幾乎沒有使用門檻。

當(dāng)然，系統(tǒng)也支持客戶端拉取，推送系統(tǒng)會將客戶端的拉取請求轉(zhuǎn)換為推送請求，直接返回。推送服務(wù)器會據(jù)此請求推送相應(yīng)數(shù)據(jù)到客戶端。即拉取異步化，如果客戶端沒有新產(chǎn)生的數(shù)據(jù)，不會返回任何數(shù)據(jù)，減少客戶端的網(wǎng)絡(luò)消耗。

在采用推送模式的分布式消息系統(tǒng)中，最核心的指標(biāo)之一就是推送延時(shí)。各個(gè)長連接位于不同的推送機(jī)器上，那么當(dāng)消息產(chǎn)生時(shí)，該連接所在的機(jī)器如何快速感知這個(gè)事件？

在本系統(tǒng)中，所有推送機(jī)器彼此連接（如圖所示），構(gòu)成一個(gè)通知網(wǎng)，其中任意一臺機(jī)器感知到消息產(chǎn)生事件后，會迅速通知此消息歸屬的長連接的推送機(jī)器，進(jìn)而將數(shù)據(jù)快速推送給客戶端。而路由系統(tǒng)每收到一條消息，都會通知下游推送系統(tǒng)。上下游系統(tǒng)協(xié)調(diào)一致，確保消息一觸即達(dá)。

評估消息系統(tǒng)另外一個(gè)核心指標(biāo)是消息丟失問題。由于面向廣大開發(fā)者，因此系統(tǒng)必須兼顧各種各樣的網(wǎng)絡(luò)環(huán)境問題，開發(fā)者能力問題等。為了保證不丟任何一條消息，針對每條推送的消息，都會開啟一個(gè)事務(wù)，從推送開始，到確認(rèn)結(jié)束，如果超時(shí)未確認(rèn)就會重發(fā)這條消息，這就是消息確認(rèn)。

由于公網(wǎng)環(huán)境復(fù)雜，消息超時(shí)時(shí)間注定不能太短，如果是內(nèi)網(wǎng)環(huán)境，5秒足矣，消息事務(wù)在內(nèi)存就能完成。然后在公網(wǎng)環(huán)境中，5秒遠(yuǎn)遠(yuǎn)不夠，因此需要持久化消息事務(wù)。在推送量不大的時(shí)候，可以使用數(shù)據(jù)庫記錄每條消息的發(fā)送記錄，使用起來也簡單方便。但是當(dāng)每秒推送量在百萬級的時(shí)候，使用數(shù)據(jù)庫記錄的方式就顯得捉襟見肘，即便是分庫分表也難以承受如此大的流量。

對于消息推送事務(wù)數(shù)據(jù)，有一個(gè)明顯特征，99%的數(shù)據(jù)會在幾秒內(nèi)讀寫各一次，兩次操作完成這條數(shù)據(jù)就失去了意義。在這種場景，使用數(shù)據(jù)庫本身就不合理，就像是在數(shù)據(jù)庫中插入一條幾乎不會去讀的數(shù)據(jù)。這樣沒意義的數(shù)據(jù)放在數(shù)據(jù)庫中，不僅資源浪費(fèi)，也造成數(shù)據(jù)庫成為系統(tǒng)瓶頸。

如上圖所示，針對這種場景，本系統(tǒng)在存儲子系統(tǒng)使用HeapMemory、DirectMemory、FileSystem三級存儲結(jié)構(gòu)。為了保護(hù)存儲系統(tǒng)內(nèi)存使用情況，HeapMemory存儲最近10秒發(fā)送記錄，其余的數(shù)據(jù)會異步寫入內(nèi)存映射文件中，并寫入磁盤。HeapMemory基于時(shí)間維度劃分成三個(gè)HashMap，隨著時(shí)鐘滴答可無鎖切換，DirectMemory基于消息隊(duì)列和時(shí)間維度劃分成多個(gè)鏈表，形成鏈表環(huán)，最新數(shù)據(jù)寫入指針頭鏈表，末端指針指向的是已經(jīng)超時(shí)的事務(wù)所在鏈表。這里，基于消息隊(duì)列維護(hù)，可以有效隔離各個(gè)隊(duì)列之間的影響；基于時(shí)間分片不僅能控制鏈表長度，也便于掃描超時(shí)的事務(wù)。

在這種模式下，95%的消息事務(wù)會在HeapMemory內(nèi)完成，5%的消息會在DirectMemory完成，極少的消息會涉及磁盤讀寫，絕大部分消息事務(wù)均在內(nèi)存完成，節(jié)省大量服務(wù)器資源。

零漏單數(shù)據(jù)同步

我們已經(jīng)有了API網(wǎng)關(guān)以及可靠的消息服務(wù)，但是對外提供服務(wù)時(shí)，用戶在訂單數(shù)據(jù)獲取中常常因?yàn)榻?jīng)驗(yàn)不足和代碼缺陷導(dǎo)致延遲和漏單的現(xiàn)象，于是我們對外提供數(shù)據(jù)同步的服務(wù)。

傳統(tǒng)的數(shù)據(jù)同步技術(shù)一般是基于數(shù)據(jù)庫的主備復(fù)制完成的。在簡單的業(yè)務(wù)場景下這種方法是可行的，并且已經(jīng)很多數(shù)據(jù)庫都自帶了同步工具。 但是在業(yè)務(wù)復(fù)雜度較高或者數(shù)據(jù)是對外同步的場景下，傳統(tǒng)的數(shù)據(jù)同步工具就很難滿足靈活性、安全性的要求了，基于數(shù)據(jù)的同步技術(shù)無法契合復(fù)雜的業(yè)務(wù)場景。

雙11場景下，數(shù)據(jù)同步的流量是平常的數(shù)十倍，在峰值期間是百倍，而數(shù)據(jù)同步機(jī)器資源不可能逐年成倍增加。保證數(shù)據(jù)同步寫入的平穩(wěn)的關(guān)鍵在于流量調(diào)控及變更合并。

在數(shù)據(jù)同步服務(wù)中，我們使用了消息 + 對賬任務(wù)雙重保障機(jī)制，消息保障數(shù)據(jù)同步的實(shí)時(shí)性，對賬任務(wù)保障數(shù)據(jù)同步一致性。以訂單數(shù)據(jù)同步為例，訂單在創(chuàng)建及變更過程中都會產(chǎn)生該訂單的消息，消息中夾帶著訂單號。接受到該消息后，對短時(shí)間內(nèi)同一訂單的消息做合并，數(shù)據(jù)同步客戶端會拿消息中的訂單號請求訂單詳情，然后寫入DB。消息處理過程保證了訂單在創(chuàng)建或者發(fā)生了任意變更之后都能在極短的延遲下更新到用戶的DB中。

對賬任務(wù)調(diào)度體系會同步運(yùn)行。初始化時(shí)每個(gè)用戶都會生成一個(gè)或同步任務(wù)，每個(gè)任務(wù)具有自己的唯一ID。數(shù)據(jù)同步客戶端存活時(shí)每30秒發(fā)出一次心跳數(shù)據(jù)，針對同一分組任務(wù)的機(jī)器的心跳信息將會進(jìn)行匯總排序，排序結(jié)果一般使用IP順序。每臺客戶端在獲取需執(zhí)行的同步任務(wù)列表時(shí)，將會根據(jù)自身機(jī)器在存活機(jī)器總和x中的順序y，取得任務(wù)ID % x = y – 1的任務(wù)列表作為當(dāng)前客戶端的執(zhí)行任務(wù)。執(zhí)行同步任務(wù)時(shí)，會從訂單中心取出在過去一段時(shí)間內(nèi)發(fā)生過變更的訂單列表及變更時(shí)間，并與用戶DB中的訂單進(jìn)行一一對比，如果發(fā)現(xiàn)訂單不存在或者與存儲的訂單變更時(shí)間不一致，則對DB中的數(shù)據(jù)進(jìn)行更新。

在雙11場景下如何保證數(shù)據(jù)同步的高可用，資源調(diào)配是重點(diǎn)。最先面臨的問題是，如果每臺機(jī)器都是冪等的對應(yīng)全體用戶，那么光是這些用戶身后的DB連接數(shù)消耗就是很大問題；其次，在淘寶的生態(tài)下，賣家用戶存在熱點(diǎn)，一個(gè)熱點(diǎn)賣家的訂單量可能會是一個(gè)普通賣家的數(shù)萬倍，如果用戶之間直接共享機(jī)器資源，那么大流量用戶將會占用幾乎全部的機(jī)器資源，小流量用戶的數(shù)據(jù)同步實(shí)效會受到很大的影響。

為了解決以上問題，我們引入了分組隔離。數(shù)據(jù)同步機(jī)器自身是一個(gè)超大集群，在此之上，我們將機(jī)器和用戶進(jìn)行了邏輯集群的劃分，同一邏輯集群的機(jī)器只服務(wù)同一個(gè)邏輯集群的用戶。在劃分邏輯集群時(shí)，我們將熱點(diǎn)用戶從用戶池中取出，劃分到一批熱點(diǎn)用戶專屬集群中。分組隔離解決了DB連接數(shù)的問題，在此場景下固定的用戶只會有固定的一批機(jī)器為他服務(wù)，只需要對這批機(jī)器分配連接數(shù)即可，而另一個(gè)好處是，我們可以進(jìn)行指定邏輯集群的資源傾斜保障大促場景下重點(diǎn)用戶的數(shù)據(jù)同步體驗(yàn)。

數(shù)據(jù)同步服務(wù)大集群的機(jī)器來源于三個(gè)機(jī)房， 在劃分邏輯集群時(shí)，每個(gè)邏輯分組集群都是至少由兩個(gè)以上機(jī)房的機(jī)器組成，在單個(gè)機(jī)房宕機(jī)的場景下，邏輯集群還會有存活機(jī)器，此時(shí)消息和任務(wù)都會向存活的機(jī)器列表進(jìn)行重新分配，保證該邏輯集群所服務(wù)的用戶不受影響。 在機(jī)器發(fā)生宕機(jī)或者單個(gè)邏輯集群的壓力增大時(shí)，調(diào)度程序?qū)z測到這一情況并且對冗余及空閑機(jī)器再次進(jìn)行邏輯集群劃分，以保證數(shù)據(jù)同步的正常運(yùn)行。在集群壓力降低或宕機(jī)機(jī)器恢復(fù)一段時(shí)間后，調(diào)度程序會自動(dòng)將二次劃分的機(jī)器回收，或用于其他壓力較大的集群。

訂單上存儲的數(shù)據(jù)結(jié)構(gòu)隨著業(yè)務(wù)的發(fā)展也在頻繁的發(fā)生的變化，進(jìn)行訂單數(shù)據(jù)的同步，需要在上游結(jié)構(gòu)發(fā)生變化時(shí)，避免對數(shù)據(jù)同步服務(wù)產(chǎn)生影響，同時(shí)兼顧用戶的讀取需求。對此我們設(shè)計(jì)了應(yīng)對結(jié)構(gòu)易變數(shù)據(jù)的大字段存儲模型。在訂單數(shù)據(jù)的存儲模型中，我們將訂單號、賣家昵稱、更新時(shí)間等需要被當(dāng)做查詢/索引條件的字段抽出獨(dú)立字段存儲，將整個(gè)的訂單數(shù)據(jù)結(jié)構(gòu)當(dāng)成json串存入一個(gè)大字段中。

這樣的好處是通過大字段存儲做到對上游業(yè)務(wù)的變化無感知，同時(shí)，為了在進(jìn)行增量數(shù)據(jù)同步時(shí)避免對大字段中的訂單詳情進(jìn)行對比，在進(jìn)行數(shù)據(jù)同步寫入的同時(shí)將當(dāng)前數(shù)據(jù)的hashcode記錄存儲，這樣就將訂單數(shù)據(jù)對比轉(zhuǎn)換成了hashcode與modified時(shí)間對比，提高了更新效率。

在雙11場景下，數(shù)據(jù)同步的瓶頸一般不在淘寶內(nèi)部服務(wù)，而在外部用戶的DB性能上。數(shù)據(jù)同步是以消息的方式保證實(shí)時(shí)性。在處理非創(chuàng)建消息的時(shí)候，我們會使用直接update + modified時(shí)間判斷的更新方式，替換傳統(tǒng)的先select進(jìn)行判斷之后再進(jìn)行update的做法。這一優(yōu)化降低了90%的DB訪問量。