蘑菇街電商交易平臺(tái)服務(wù)架構(gòu)及改造優(yōu)化歷程(含PPT)

導(dǎo)讀：高可用架構(gòu) 7 月 30 日在上海舉辦了『互聯(lián)網(wǎng)架構(gòu)的基石』專題沙龍著拭，進(jìn)行了閉門私董會(huì)研討及對(duì)外開放的四個(gè)專題的演講泊藕，期望能促進(jìn)業(yè)界對(duì)互聯(lián)網(wǎng)基礎(chǔ)架構(gòu)的建設(shè)及發(fā)展，本文是潘福江分享蘑菇街電商交易系統(tǒng)架構(gòu)志鹃。

潘福江，蘑菇街高級(jí)研發(fā)工程師，2014 年之前在阿里尤莺，搞過電商垂直業(yè)務(wù)平臺(tái)建設(shè)，也搞過中間件相關(guān)的研發(fā)工作生棍，2015 年加入蘑菇街（現(xiàn)美麗聯(lián)合集團(tuán)）颤霎，負(fù)責(zé)蘑菇街交易資金，購物車等電商基礎(chǔ)平臺(tái)的服務(wù)化建設(shè)工作涂滴。

我來自蘑菇街友酱，蘑菇街是一個(gè)主要面向女性用戶的電商平臺(tái)，男同胞們可能用的比較少柔纵。不過蘑菇街里有大量的模特妹子, ?而且顏值都比較高缔杉，建議大家可以下來用用，寫代碼累的時(shí)候搁料，可以偷偷打開蘑菇街看看妹子或详，感覺還是很不錯(cuò)的。

今天我的主題是蘑菇街交易平臺(tái)的服務(wù)架構(gòu)郭计，以及在服務(wù)化建設(shè)過程中霸琴，我們做的一些改造歷程分享。

蘑菇街導(dǎo)購時(shí)期 業(yè)務(wù)結(jié)構(gòu)

蘑菇街是做導(dǎo)購起家的拣宏，當(dāng)時(shí)所有的業(yè)務(wù)都是基于用戶和內(nèi)容這兩大核心展開沈贝。那個(gè)時(shí)候前臺(tái)業(yè)務(wù)主要做的是社交導(dǎo)購，后臺(tái)業(yè)務(wù)主要做的是內(nèi)容管理勋乾。一句話總結(jié)就是小而美的狀態(tài)宋下，業(yè)務(wù)相對(duì)來也不是很復(fù)雜。

當(dāng)時(shí)的技術(shù)架構(gòu)是典型的創(chuàng)業(yè)型公司技術(shù)架構(gòu)辑莫。網(wǎng)站整體是用 PHP 搭建的学歧，系統(tǒng)做了簡(jiǎn)單的分層，基礎(chǔ)設(shè)施以現(xiàn)成的開源產(chǎn)品為主各吨。2013 年時(shí)蘑菇街做了轉(zhuǎn)型枝笨，主要原因那段時(shí)間很大一批導(dǎo)購網(wǎng)站遭到了封殺，于是就轉(zhuǎn)型做社會(huì)化電商平臺(tái)。

社會(huì)化電商平臺(tái)分兩部分横浑，一部分社會(huì)化剔桨，我們之前做導(dǎo)購時(shí)積累了一些經(jīng)驗(yàn)。電商是我們之前沒有接觸過的徙融，這塊基本上是從零開始一手建立起來洒缀。要做電商平臺(tái)，首先就要搭建一個(gè)交易平臺(tái)欺冀。起初比較簡(jiǎn)單树绩，我們重寫了一套系統(tǒng)，系統(tǒng)結(jié)構(gòu)和之前相比并沒有本質(zhì)上的變化隐轩，所有業(yè)務(wù)都寫在一個(gè)巨大的工程里面, 中間通過一套代理層和我們的基礎(chǔ)設(shè)施進(jìn)行交互饺饭。

電商轉(zhuǎn)型面臨的問題

業(yè)務(wù)高速發(fā)展，每年保持 3 倍以上的增長(zhǎng)（2015 年用戶過億职车，PV 超過 10億）

用戶購買鏈路大促峰值是日常的百倍（2015 年初最高只支持 400 單/秒）

業(yè)務(wù)異常復(fù)雜瘫俊，業(yè)務(wù)形態(tài)快速膨脹

歷史包袱沉重，系統(tǒng)耦合非常嚴(yán)

蘑菇街轉(zhuǎn)型到電商平臺(tái)以后提鸟，業(yè)務(wù)基本上每年以三倍以上的速度增長(zhǎng)军援，這個(gè)時(shí)候問題開始暴露了。電商平臺(tái)在發(fā)展過程中尤其在發(fā)展中期遇到的一些的問題称勋，不僅僅是蘑菇街的胸哥，其它平臺(tái)可能也會(huì)遇到。如系統(tǒng)代碼臃腫赡鲜、模塊耦合程度高空厌，依賴復(fù)雜，業(yè)務(wù)擴(kuò)展能力差等银酬。

蘑菇街那個(gè)時(shí)候主要面臨了幾個(gè)問題：

一個(gè)是我們業(yè)務(wù)在高速增長(zhǎng)嘲更，系統(tǒng)容量跟不上，當(dāng)時(shí)交易系統(tǒng)只能支持到每秒四百單的容量(大促的時(shí)候流量是平時(shí)的百倍以上)揩瞪。

另一個(gè)是電商業(yè)務(wù)形態(tài)變的特別快赋朦，業(yè)務(wù)支撐不夠靈活，不夠快李破。

此外還有歷史包袱宠哄，系統(tǒng)耦合非常嚴(yán)重。

解決這一系列問題的關(guān)鍵就一個(gè)字：“拆”嗤攻。

系統(tǒng)拆分歷程

DB 垂直拆分

業(yè)務(wù)系統(tǒng)垂直拆分（購物車毛嫉，下單，資金…）

數(shù)據(jù) & 業(yè)務(wù)模型統(tǒng)一妇菱，服務(wù)接口設(shè)計(jì)邏輯清晰承粤，粒度合適

基礎(chǔ)業(yè)務(wù)邏輯下沉到服務(wù)暴区，Web 層專注表示邏輯和編排

服務(wù)治理

系統(tǒng)拆分——交易購物車為例

以交易購物車的例子來說明下我們的改造過程，以前我們就一個(gè)工程辛臊，所有的代碼都寫在這仙粱，不同的終端或業(yè)務(wù)都有一個(gè)不同的模塊代碼在維護(hù)。訪問數(shù)據(jù)也比較隨意浪讳，各自維護(hù)一套數(shù)據(jù)訪問的代碼缰盏。因此就有兩個(gè)非常頭疼的問題：

一方面由于交易就一個(gè)庫，所有內(nèi)容都是放在里面淹遵，因此這些隨意散亂的 SQL 可能會(huì)冷不丁的給你來個(gè)慢查詢，別的業(yè)務(wù)代碼帶來的不穩(wěn)定會(huì)相互影響负溪，還很難定位這種“野 SQL”是哪里查過來的透揣，導(dǎo)致我們的 DB 很不穩(wěn)定，對(duì)后續(xù)改造非常不利川抡。

另外一個(gè)是業(yè)務(wù)支撐方面辐真，產(chǎn)品提一個(gè)需求過來，在各種端都要實(shí)現(xiàn)一遍崖堤，復(fù)用性很差侍咱，業(yè)務(wù)支撐非常不靈活，系統(tǒng)毫無擴(kuò)展性密幔，開發(fā)同學(xué)也是苦不堪言楔脯，經(jīng)常加班加點(diǎn)搞，還經(jīng)常搞出一堆 bug胯甩。

于是我們就去拆系統(tǒng)昧廷，到底怎么拆？其實(shí)也是有些講究的偎箫。

系統(tǒng)拆分的優(yōu)先順序

如果把 DB 比如成一個(gè)木桶木柬，各類業(yè)務(wù)就可以比喻為往里面倒的水，一開始往木桶里面倒的水可能并不多淹办，木桶裝的下沒問題眉枕。但是隨著業(yè)務(wù)增長(zhǎng)，木桶總有一天是會(huì)裝不下的怜森。

首先木桶需要足夠大速挑，并且能很方便擴(kuò)容，這樣才不會(huì)有后顧之憂塔插。業(yè)務(wù)量有時(shí)候并不好預(yù)測(cè)梗摇，指不定什么時(shí)候量就起來了，如果不把這個(gè)底層的木桶做得足夠強(qiáng)大想许，而優(yōu)先去搞業(yè)務(wù)上的拆分優(yōu)化伶授，那量一旦起來整個(gè)系統(tǒng)就歇菜了断序。

因此DB 是系統(tǒng)拆分的基礎(chǔ)，需要優(yōu)先拆分糜烹。

DB 拆出來的同時(shí)還要關(guān)注穩(wěn)定性违诗，前面也提到，當(dāng)時(shí) SQL 是比較散亂疮蹦，極易造成 DB 不穩(wěn)定诸迟，所以數(shù)據(jù)訪問/模型統(tǒng)一也很關(guān)鍵，我們建了統(tǒng)一的數(shù)據(jù)訪問層愕乎。有了這一層之后阵苇，后面對(duì) DB 的改造擴(kuò)容都能夠比較有效的掌控。

基礎(chǔ)的東西都建好了感论，再來解決業(yè)務(wù)支撐困難這個(gè)問題绅项。業(yè)務(wù)模型上需要統(tǒng)一抽象，能夠支持定制擴(kuò)展比肄。流程改造過程同時(shí)也孵化出了SPI 業(yè)務(wù)框架快耿、流程引擎、規(guī)則引擎等這些基礎(chǔ)業(yè)務(wù)框架芳绩。在業(yè)務(wù)支撐上做到了靈活可擴(kuò)展掀亥。系統(tǒng)也做了比較合理的分層，每層只需要關(guān)心本層所需關(guān)注的能力即可妥色。

系統(tǒng)拆分成果

交易系統(tǒng)在整體拆分完成以后搪花，公司 SOA 化雛形也基本已經(jīng)形成了，包括基礎(chǔ)服務(wù)化框架垛膝、消息中間件鳍侣、數(shù)據(jù)中間件、配置中心也都落地實(shí)施了吼拥，此外還孵化了一系列基礎(chǔ)設(shè)施工具倚聚，包括監(jiān)控系統(tǒng)，調(diào)度系統(tǒng)凿可，日志搜集惑折，鏈路跟蹤系統(tǒng)等。

還有一個(gè)背景拆分過程中枯跑，公司戰(zhàn)略整體往 Java 語言轉(zhuǎn)惨驶，這個(gè)是公司綜合層面考慮，Java的人才尤其是杭州相對(duì)比較多敛助，技術(shù)體系也比較成熟粗卜，有大牛在能 hold 住問題，當(dāng)時(shí)確實(shí) PHP 資源比較少纳击。

容量提升

做了系統(tǒng)拆分改造以后续扔，接下來更多的會(huì)去關(guān)注應(yīng)用本身的容量攻臀、性能以及穩(wěn)定性方面的事情。我們也在這些方面分別作了一些改造和嘗試纱昧。

按業(yè)務(wù)對(duì) DB 進(jìn)行垂直拆分

讀寫分離刨啸，保證讀可以任意擴(kuò)展

分庫分表，提升中心服務(wù)寫入容量

系統(tǒng)拆分時(shí)识脆，已經(jīng)按業(yè)務(wù)把 DB 垂直拆分出來了设联，并且 DB 也做了讀寫分離（基于 MySQL）。

下面重點(diǎn)介紹一下分庫分表上的改造灼捂，當(dāng)時(shí)目的主要是為了提升中心服務(wù)的寫入容量离例，因?yàn)楫?dāng)時(shí) DB 讀寫分離是單 Master 結(jié)構(gòu)，會(huì)有一個(gè)寫入瓶頸纵东。

以交易創(chuàng)建為例來說明我們分庫分表的歷程粘招，交易創(chuàng)建應(yīng)該算是交易里面最為復(fù)雜的業(yè)務(wù)場(chǎng)景之一。創(chuàng)建一筆訂單的時(shí)偎球，會(huì)同同時(shí)寫入其他很多的數(shù)據(jù)，當(dāng)時(shí)系統(tǒng)容量大約是每秒能夠處理一千單辑甜，DB 單點(diǎn)存在寫入瓶頸衰絮，并且寫入過多會(huì)造成主從延遲嚴(yán)重。另外 DB 磁盤空間也已經(jīng)突破了 80%磷醋，不穩(wěn)定性非常高猫牡，有可能隨時(shí)會(huì)崩掉。

所以我們就決定去做拆分邓线，當(dāng)時(shí)的背景是中間件還沒建立起來淌友，沒有分庫分表相關(guān)的組件，于是就決定內(nèi)部先搞起來骇陈。

當(dāng)時(shí)對(duì)比了業(yè)內(nèi)比較流行的一些方案震庭，比如阿里的 TDDL，Cobar你雌，谷歌的 Vitess 等器联，比較下來發(fā)現(xiàn)這些組件都比較重，接入和使用成本都相對(duì)比較高婿崭。我們的原則是符合我們業(yè)務(wù)場(chǎng)景下拨拓，選一種接入和使用成本都相對(duì)簡(jiǎn)單的組件。于是我們采取的是最后一種方式氓栈，通過 MyBatis Plugin 字節(jié)碼增強(qiáng)的方式實(shí)現(xiàn)分庫分表功能渣磷，該組件目前已開源：https://github.com/baihui212/tsharding

分庫分表業(yè)界方案對(duì)比如下圖：

自研分庫分表組件 TSharding，完成分庫分表

足夠簡(jiǎn)單授瘦，投入較少資源

支持分庫分表

支持?jǐn)?shù)據(jù)源路由

支持事務(wù)

支持結(jié)果集合并

支持讀寫分離

這個(gè)組件叫 TSharding醋界，它的特點(diǎn)是足夠簡(jiǎn)單竟宋，是符合我們預(yù)期的，支持分庫且分表物独，支持?jǐn)?shù)據(jù)源路由袜硫，支持事務(wù)，支持結(jié)果集合并挡篓，支持讀寫分離婉陷，滿足我們所有的要求。

性能優(yōu)化

我們?cè)谛阅軆?yōu)化上也做了一些嘗試官研，主要舉下面三個(gè)場(chǎng)景：

分布式事務(wù)處理

單機(jī)異步并行

預(yù)處理 & 緩存

分布式事務(wù)處理----交易創(chuàng)建為例

優(yōu)化思路：異步消息解耦

交易創(chuàng)建流程中秽澳，訂單、券和庫存的狀態(tài)必須要保證一致性

營(yíng)銷優(yōu)惠券服務(wù)和庫存中心庫存服務(wù)戏羽，與下單服務(wù)是分開部署的

調(diào)用券/庫存服務(wù)超時(shí)/失敗担神，異步發(fā)消息通知回滾；復(fù)雜性可控

MQ 產(chǎn)生端發(fā)送失敗重試 + 消費(fèi)接受 ACK 機(jī)制保證做種一致

消除了二階段提交等分布式事務(wù)框架的侵入性影響

首先講分布式事務(wù)處理始花，這里還是以交易創(chuàng)建為例妄讯，交易創(chuàng)建過程會(huì)跟多個(gè)服務(wù)進(jìn)行交互，并且有些服務(wù)是強(qiáng)依賴酷宵，比如扣減庫存亥贸，鎖券服務(wù)，必須保持一致性浇垦。二階段/多階段協(xié)議這種方式很重炕置，當(dāng)時(shí)并沒有采納。

我們當(dāng)時(shí)想了一個(gè)方法是男韧，通過異步消息解耦的方式來解決朴摊，具體流程：

下單時(shí)先不要急著讓這個(gè)訂單暴露出來，我們先創(chuàng)建一筆不可見的訂單（或者可以認(rèn)為是先預(yù)創(chuàng)建了一筆訂單）此虑，然后再去做減庫存甚纲，鎖券操作，當(dāng)這些操作異彻炎常或者失敗時(shí)贩疙，下單系統(tǒng)就會(huì)發(fā)出一條廢單消息，它的下游系統(tǒng)（如促銷况既，庫存系統(tǒng)）收到這個(gè)廢單消息以后这溅，就會(huì)幫我們做回滾的操作，用這樣的方式來解決我們分布式事務(wù)的問題棒仍。

分布式事務(wù)處理——支付回調(diào)為例

支付回調(diào)流程中悲靴，資金系統(tǒng)回調(diào)交易后會(huì)促發(fā)訂單狀態(tài)更新，減庫存莫其，發(fā)券等操作

資金作為發(fā)起方保證重試癞尚，消息可達(dá)耸三，交易以及下游做好等

失敗業(yè)務(wù)進(jìn)任務(wù)重試表，做異步補(bǔ)償重試

消除了二階段提交等分布式事務(wù)框架的侵入性影響

還有一個(gè)場(chǎng)景就是支付回調(diào)浇揩，支付系統(tǒng)在訂單完成付款之后會(huì)通知交易系統(tǒng)仪壮，交易系統(tǒng)會(huì)進(jìn)行一些列的操作如定單狀態(tài)更新，減庫存胳徽，發(fā)券等积锅，也是一個(gè)分布式事務(wù)問題。

我們的策略是养盗，當(dāng)業(yè)務(wù)失敗的時(shí)候這個(gè)請(qǐng)求會(huì)進(jìn)入我們的一個(gè)失敗補(bǔ)償表缚陷，通過不斷的做異步補(bǔ)償重試(階梯式)，保證最終一致性往核。

單機(jī)異步并行——購物車為例

分析思路

購物車是典型 IO 密集型應(yīng)用

代碼串行執(zhí)行箫爷，同步等待時(shí)間較長(zhǎng)

CPU利用率低

分析一下，購物車其實(shí)本身是一個(gè)典型的 IO 密集型的應(yīng)用聂儒，有很多類似的應(yīng)用都是這樣的虎锚，會(huì)存在大量的網(wǎng)絡(luò) IO 請(qǐng)求。還有一點(diǎn)是我們習(xí)慣上代碼是串行寫的衩婚，所以存在很多同步等待時(shí)間翁都。

既然每次購物車的查詢都會(huì)經(jīng)過這么多的節(jié)點(diǎn)，那如果兩個(gè)節(jié)點(diǎn)之間沒有依賴關(guān)系谅猾，我是不是就可以并行的去搞，分析一下其實(shí)每一次查詢都會(huì)對(duì)應(yīng)一顆查詢依賴樹鳍悠，同一層節(jié)點(diǎn)之間是沒有依賴關(guān)系的税娜，在這一層我們其實(shí)是可以去做并行操作的，所以基于這個(gè)思路我們當(dāng)時(shí)做了優(yōu)化藏研，并且效果還挺不錯(cuò)敬矩。

具體的優(yōu)化就是加入這個(gè)概念，去查的時(shí)候我們先等一下別的查詢蠢挡，我們一塊兒去查弧岳，最終做一個(gè)匯總，查詢結(jié)果就出來了业踏，就是這么一個(gè)流程禽炬。然后做的效果也不錯(cuò)，整個(gè) RT 基本上能夠降到一半以上勤家。

預(yù)處理 & 緩存——營(yíng)銷計(jì)價(jià)服務(wù)為例

使用緩存降低 DB 讀壓力

盡可能地緩存需要的數(shù)據(jù)

DB 數(shù)據(jù)有變化主動(dòng)失效緩存（異步腹尖，低延遲），減少不一致問題

大促高峰前開啟本地緩存伐脖；做緩存預(yù)熱热幔，有助于提高緩存命中率

預(yù)處理達(dá)到計(jì)價(jià)接口部分耦合：報(bào)名大促活動(dòng)商品的折扣同步到商品表

預(yù)處理跟緩存化乐设，其實(shí)也是一種比較通用的優(yōu)化手段。我們采用了多級(jí)緩存的策略绎巨，本地緩存+分布式緩存近尚。優(yōu)先讀取本地緩存，本地緩存沒有就去分布式緩存取场勤。分布式緩存取不到才去 DB 里面取戈锻。當(dāng)數(shù)據(jù)發(fā)生變化的時(shí)候我們會(huì)有一套異步刷新緩存的系統(tǒng)來及時(shí)更新緩存里面的數(shù)據(jù)。

服務(wù) SLA 保障

SLA: Service Level Agreement却嗡，是對(duì)服務(wù)提供者的要求舶沛。SLA 體現(xiàn)在對(duì)容器（QPS）、性能（RT）窗价、程度（分布情況如庭；可用性；出錯(cuò)率）的約束撼港。提高 SLA 的一些手段如下

基礎(chǔ)監(jiān)控先行坪它，把關(guān)鍵指標(biāo)監(jiān)控起來

依賴治理、邏輯優(yōu)化：減少不必要的依賴

負(fù)載均衡帝牡；服務(wù)分組往毡；限流

降級(jí)預(yù)案、容災(zāi)靶溜、壓測(cè)开瞭、在線演練

這個(gè)是我們內(nèi)部的一個(gè)監(jiān)控系統(tǒng)，我們會(huì)監(jiān)控每個(gè)應(yīng)用的一些關(guān)鍵指標(biāo)罩息，觀察整個(gè)鏈路上的情況嗤详。

總結(jié)及下一步規(guī)劃

總結(jié)

服務(wù)化構(gòu)架不是一成不變的，是隨著業(yè)務(wù)不斷發(fā)展而演化

沒有最佳的方案瓷炮，在合適場(chǎng)景下采用合適的方案

目前在做

服務(wù)治理葱色、SLA 保障系統(tǒng)化

下一步

同城/異地雙活

Q&A

提問：如果消費(fèi)者收到一條消息，這時(shí)候我就告訴系統(tǒng)可以把這個(gè)消息刪除了娘香，那我后端在執(zhí)行這條消息的過程當(dāng)中苍狰，比如我做一些入庫操作或者其他的操作，但是這個(gè)服務(wù)死掉了烘绽，那么你們有沒有遇到類似這樣的情況淋昭，你們是怎么來處理的？

潘福江：目前沒有诀姚，因?yàn)槠鋵?shí)這是一個(gè)需要合作的過程响牛，我們需要下游系統(tǒng)去配合保證，保證業(yè)務(wù) OK 之后才去 ACK 消息，主要是幾個(gè)系統(tǒng)之間的協(xié)作問題呀打。

提問：電商大部分分布式事務(wù)解決方案用消息隊(duì)列的機(jī)制矢赁，有沒有一種更通用的解決方式？我們開發(fā)一套分布式組件贬丛，比如兩階段協(xié)議撩银，更高效解決這種分布式事務(wù)。

潘福江：分布式事務(wù)問題其實(shí)還是看場(chǎng)景的豺憔，支付寶（以前在支付寶）有類似的框架额获，但是比較重，也需要一定的接入成本恭应，需要一定的配合抄邀。Case by Case 的分析問題會(huì)更好一些，比如有些場(chǎng)景他的一致性要求并沒有那么高昼榛，沒有必要采用兩階段協(xié)議這種來處理境肾，主要還是看業(yè)務(wù)場(chǎng)景。

提問：數(shù)據(jù)庫遷移的時(shí)候胆屿，能做到平滑遷移嗎奥喻？因?yàn)槲铱吹侥阒坝玫闹虚g件的時(shí)候切換過兩次，這個(gè)時(shí)候肯定遇到一些數(shù)據(jù)庫在線平滑遷移非迹，你是怎么弄的环鲤？

潘福江：這個(gè)我們內(nèi)部會(huì)有一套數(shù)據(jù)同步工具，另外有套開關(guān)系統(tǒng)來完成灰度切換憎兽，你可以動(dòng)態(tài)去推送一些值冷离，到你的應(yīng)用里面，然后動(dòng)態(tài)的可以把這個(gè)值改掉纯命。此外我們這個(gè)數(shù)據(jù)同步工具是支持回溯的酒朵，遇到緊急情況可以迅速切回，并且把數(shù)據(jù)回溯回來扎附。

提問：你做了一個(gè)分庫之后你要把老的庫保留到新的庫里面，因?yàn)樯先ブ竽阋植桨l(fā)布结耀，但你的老庫還在跑留夜，這個(gè)時(shí)候有人在用你的老庫，但是因?yàn)槟阌衷诎l(fā)布图甜，一半流量已經(jīng)切到新的庫上去了碍粥，如果這個(gè)時(shí)候有人正在修改數(shù)據(jù)怎么辦？

潘福江：上文也提到黑毅，老庫和新庫是有建立一個(gè)通道的（數(shù)據(jù)同步通道），并且數(shù)據(jù)同步工具一直在工作。老庫的數(shù)據(jù)會(huì)實(shí)時(shí)的同步到新庫银室，并且我們的灰度是通過開關(guān)系統(tǒng)動(dòng)態(tài)推送的，實(shí)時(shí)生效愿卒。

提問：在分庫分表的拆分之后，假如有表的關(guān)聯(lián)查詢你們?cè)趺刺幚淼模?/b>

潘福江：我們貌似沒有關(guān)聯(lián)查詢潮秘，也不推薦琼开，關(guān)聯(lián)查詢對(duì)后續(xù)水平拆分十分不利，不利于 DB 的擴(kuò)展枕荞」窈颍可以分開查，然后在應(yīng)用層把關(guān)聯(lián)的事情做掉躏精。

提問：如果分開去查的話渣刷，性能上會(huì)不會(huì)受影響呢？

潘福江：性能上可能是會(huì)受到一定的影響矗烛，會(huì)多訪問幾次數(shù)據(jù)庫辅柴，但是 DB 擴(kuò)展性能大大的提升，互聯(lián)網(wǎng)玩的是大數(shù)據(jù)高诺，比起這點(diǎn)碌识，DB 擴(kuò)展性更重要，應(yīng)用層可以有很多的方式去優(yōu)化(比如緩存)虱而，如果你用了 JOIN 再去做水平拆分是非常困難的筏餐。

提問：你們?cè)诓饚熘埃袥]有考慮什么好的方案回退牡拇？

潘福江：我們的數(shù)據(jù)同步工具是支持回溯的魁瞪，出了問題通過開關(guān)系統(tǒng)可以立馬切回，并且能回溯數(shù)據(jù)惠呼，把影響面降到可控范圍导俘。

相關(guān)閱讀

（點(diǎn)擊標(biāo)題可直接閱讀）

Mercury:唯品會(huì)全鏈路應(yīng)用監(jiān)控系統(tǒng)解決方案詳解

同程旅游緩存系統(tǒng)設(shè)計(jì):如何打造Redis時(shí)代的完美體系

保證分布式系統(tǒng)數(shù)據(jù)一致性的6種方案（含蘑菇街方案）

對(duì)話：一個(gè)工程師在蘑菇街4年的架構(gòu)感悟

10個(gè)互聯(lián)網(wǎng)團(tuán)隊(duì)?wèi)?yīng)對(duì)高壓的容量評(píng)估與高可用體系:私董會(huì)1期

本文及本次沙龍相關(guān) PPT 鏈接如下，也可點(diǎn)擊閱讀原文直接下載

http://pan.baidu.com/s/1nvnOEBf

想更多了解高可用架構(gòu)沙龍內(nèi)容剔蹋，請(qǐng)關(guān)注「ArchNotes」微信公眾號(hào)以閱讀后續(xù)文章旅薄。關(guān)注公眾號(hào)并回復(fù)城市圈可以更及時(shí)了解后續(xù)活動(dòng)信息。轉(zhuǎn)載請(qǐng)注明來自高可用架構(gòu)及包含以下二維碼泣崩。

高可用架構(gòu)

改變互聯(lián)網(wǎng)的構(gòu)建方式

長(zhǎng)按二維碼 關(guān)注「高可用架構(gòu)」公眾號(hào)