轉(zhuǎn)載:MySQL 高可用架構(gòu)在業(yè)務(wù)層面細(xì)化分析研究
相對(duì)于傳統(tǒng)行業(yè)的相對(duì)服務(wù)時(shí)間9x9x6或者9x12x5村缸，因?yàn)榛ヂ?lián)網(wǎng)電子商務(wù)以及互聯(lián)網(wǎng)游戲的實(shí)時(shí)性擅憔，所以服務(wù)要求7*24小時(shí)纸镊，業(yè)務(wù)架構(gòu)不管是應(yīng)用還是數(shù)據(jù)庫(kù)倍阐，都需要容災(zāi)互備，在mysql的體系中逗威，最好通過(guò)在最開(kāi)始階段的數(shù)據(jù)庫(kù)架構(gòu)階段來(lái)實(shí)現(xiàn)容災(zāi)系統(tǒng)峰搪。所以這里從業(yè)務(wù)宏觀角度闡述下mysql架構(gòu)的方方面面。
一凯旭，MySQL架構(gòu)設(shè)計(jì)—業(yè)務(wù)分析
虛線(xiàn)表示跨機(jī)房部署概耻，比如電子商務(wù)系統(tǒng)，一個(gè)Master既有讀也有些寫(xiě)罐呼，對(duì)讀數(shù)據(jù)一致性需要比較重要的鞠柄，讀要放在Master上面。
M(R)僅僅是一個(gè)備庫(kù)嫉柴，只有M(WR)掛了之后厌杜，才會(huì)切換到M(R)上，這個(gè)時(shí)候M(R)就變成了讀寫(xiě)庫(kù)计螺。比如游戲系統(tǒng)夯尽，有很多Salve會(huì)掛載后面一個(gè)M(R)上面。
如果是電子商務(wù)類(lèi)型的登馒，這種讀多寫(xiě)少的呐萌，一般是1個(gè)master拖上4到6個(gè)slave，所有slave掛載在一個(gè)master也足夠了谊娇。
切換的時(shí)候肺孤，把M1的讀寫(xiě)業(yè)務(wù)切換到M2上面，然后把所有M1上的slave掛到M2上面去济欢，如下所示：
如果是游戲行業(yè)的話(huà)赠堵，讀非常多蠻明顯的，會(huì)出現(xiàn)一般1個(gè)Master都會(huì)掛上10個(gè)以上的Slave的情況法褥，所以這個(gè)時(shí)候茫叭，可以把一部分Slave掛載新的M(R)上面。至少會(huì)減少一些壓力半等，這樣至少服務(wù)器掛掉的時(shí)候揍愁，不會(huì)對(duì)所有的slave有影響，還有一部分在M(R)上的slave在繼續(xù)杀饵，不會(huì)對(duì)所有的slave受到影響莽囤，見(jiàn)圖3，
意味著讀并不會(huì)影響寫(xiě)的效率切距，所以讀寫(xiě)都可以放在一個(gè)M1(WR)朽缎，而另外一個(gè)不提供讀也不提供寫(xiě)，只提供standby冗余異地容災(zāi)。
這個(gè)異地容災(zāi)是非常重要的话肖，否則如果是單機(jī)的北秽，單邊的業(yè)務(wù)，萬(wàn)一idc機(jī)房故障了最筒，一般就會(huì)影響在線(xiàn)業(yè)務(wù)的贺氓，這種 造成業(yè)務(wù)2小時(shí)無(wú)法應(yīng)用，對(duì)于在線(xiàn)電子商務(wù)交易來(lái)說(shuō)床蜘，影響是蠻大的掠归，所以為了最大限度的保證7*24小時(shí)，必須要做到異地容災(zāi)悄泥，MM要跨idc機(jī)房虏冻。雖然對(duì)資源有一些要求，但是對(duì)HA來(lái)說(shuō)是不可缺少的弹囚，一定要有這個(gè)MM機(jī)制厨相。
做切換的時(shí)候，把所有的讀寫(xiě)從M1直接切換到M2上就可以了鸥鹉。
讀和寫(xiě)差不多蛮穿，但是讀不能影響寫(xiě)的能力，把讀寫(xiě)放在M1(WR)上毁渗，然后把一部分讀也放在M2(R)上面践磅，當(dāng)然M1和M2也是跨機(jī)房部署的。
切換的時(shí)候灸异，把一部分讀和全部寫(xiě)從M1切換到M2上就可以了府适。
二：MySQL架構(gòu)設(shè)計(jì)—常見(jiàn)架構(gòu)
對(duì)讀一致性的權(quán)衡，如果是對(duì)讀寫(xiě)實(shí)時(shí)性要求非常高的話(huà)肺樟，就將讀寫(xiě)都放在M1上面檐春，M2只是作為standby，就是采取和上面的一（4）的讀少寫(xiě)多的一樣的架構(gòu)模式么伯。
比如疟暖，訂單處理流程，那么對(duì)讀需要強(qiáng)一致性田柔，實(shí)時(shí)寫(xiě)實(shí)時(shí)讀俐巴，類(lèi)似這種涉及交易的或者動(dòng)態(tài)實(shí)時(shí)報(bào)表統(tǒng)計(jì)的都要采用這種架構(gòu)模式
如果是弱一致性的話(huà)，可以通過(guò)在M2上面分擔(dān)一些讀壓力和流量硬爆，比如一些報(bào)表的讀取以及靜態(tài)配置數(shù)據(jù)的讀取模塊都可以放到M2上面欣舵。比如月統(tǒng)計(jì)報(bào)表，比如首頁(yè)推薦商品業(yè)務(wù)實(shí)時(shí)性要求不是很高摆屯，完全可以采用這種弱一致性的設(shè)計(jì)架構(gòu)模式邻遏。
如果既不是很強(qiáng)的一致性又不是很弱的一致性，那么我們就采取中間的策略虐骑，就是在同機(jī)房再部署一個(gè)S1(R)准验，作為備庫(kù)，提供讀取服務(wù)廷没，減少M(fèi)1(WR)的壓力糊饱，而另外一個(gè)idc機(jī)房的M2只做standby容災(zāi)方式的用途。
當(dāng)然這里會(huì)用到3臺(tái)數(shù)據(jù)庫(kù)服務(wù)器颠黎，也許會(huì)增加采購(gòu)壓力另锋，但是我們可以提供更好的對(duì)外數(shù)據(jù)服務(wù)的能力和途徑，實(shí)際中盡可能兩者兼顧狭归。
比如PV夭坪、UV操作、頁(yè)數(shù)的統(tǒng)計(jì)过椎、流量的統(tǒng)計(jì)室梅、數(shù)據(jù)的匯總等等，都可以劃歸為統(tǒng)計(jì)類(lèi)型的業(yè)務(wù)疚宇。
數(shù)據(jù)庫(kù)上做大查詢(xún)的統(tǒng)計(jì)是非常消耗資源的亡鼠。統(tǒng)計(jì)分為實(shí)時(shí)的統(tǒng)計(jì)和非實(shí)時(shí)的統(tǒng)計(jì)，由于mysql主從是邏輯sql的模式敷待，所以不能達(dá)到100%的實(shí)時(shí)间涵，如果是online要嚴(yán)格的非常實(shí)時(shí)的統(tǒng)計(jì)比如像火車(chē)票以及金融異地結(jié)算等的統(tǒng)計(jì)，mysql這塊不是它的強(qiáng)項(xiàng)榜揖，就只有查詢(xún)M1主庫(kù)來(lái)實(shí)現(xiàn)了勾哩。
A，但是對(duì)于不是嚴(yán)格的實(shí)時(shí)性的統(tǒng)計(jì)举哟，mysql有個(gè)很好的機(jī)制是binlog钳幅，我們可以通過(guò)binlog進(jìn)行解析Parser，解析出來(lái)寫(xiě)入統(tǒng)計(jì)表進(jìn)行統(tǒng)計(jì)或者發(fā)消息給應(yīng)用端程序來(lái)進(jìn)行統(tǒng)計(jì)炎滞。這種是準(zhǔn)實(shí)時(shí)的統(tǒng)計(jì)操作敢艰，有一定的短暫的可接受的統(tǒng)計(jì)延遲現(xiàn)象，如果要100%實(shí)時(shí)性統(tǒng)計(jì)只有查詢(xún)M1主庫(kù)了册赛。
通過(guò)binlog的方式實(shí)現(xiàn)統(tǒng)計(jì)钠导，在互聯(lián)網(wǎng)行業(yè)，尤其是電商和游戲這塊森瘪，差不多可以解決90%以上的統(tǒng)計(jì)業(yè)務(wù)牡属。有時(shí)候如果用戶(hù)或者客戶(hù)提出要實(shí)時(shí)read-time了，大家可以溝通一下為什么需要實(shí)時(shí)扼睬，了解具體的業(yè)務(wù)場(chǎng)景逮栅，有些可能真的不需要實(shí)時(shí)統(tǒng)計(jì)悴势，需要有所權(quán)衡，需要跟用戶(hù)和客戶(hù)多次有效溝通措伐，做出比較適合業(yè)務(wù)的統(tǒng)計(jì)架構(gòu)模型特纤。
B，還有一種offline統(tǒng)計(jì)業(yè)務(wù)侥加，比如月份報(bào)表年報(bào)表統(tǒng)計(jì)等捧存，這種完全可以把數(shù)據(jù)放到數(shù)據(jù)倉(cāng)庫(kù)里面或者第三方Nosql里面進(jìn)行統(tǒng)計(jì)。
歷史數(shù)據(jù)遷移担败，需要盡量不影響現(xiàn)在線(xiàn)上的業(yè)務(wù)昔穴，盡量不影響現(xiàn)在線(xiàn)上的查詢(xún)寫(xiě)入操作，為什么要做歷史數(shù)據(jù)遷移提前？因?yàn)橛行I(yè)務(wù)的數(shù)據(jù)是有時(shí)效性的吗货，比如電商中的已經(jīng)完成的歷史訂單等，不會(huì)再有更新操作了狈网，只有很簡(jiǎn)單的查詢(xún)操作卿操，而且查詢(xún)也不會(huì)很頻繁，甚至可能一天都不會(huì)查詢(xún)一次孙援。
如果這時(shí)候歷史數(shù)據(jù)還在online庫(kù)里面或者online表里面害淤，那么就會(huì)影響online的性能，所以對(duì)于這種拓售，可以把數(shù)據(jù)遷移到新的歷史數(shù)據(jù)庫(kù)上窥摄，這個(gè)歷史數(shù)據(jù)庫(kù)可以是mysql也可以是nosql，也可以是數(shù)據(jù)倉(cāng)庫(kù)甚至hbase大數(shù)據(jù)等础淤。
實(shí)現(xiàn)途徑是通過(guò)slave庫(kù)查詢(xún)出所有的數(shù)據(jù)崭放，然后根據(jù)業(yè)務(wù)規(guī)則比如時(shí)間、某一個(gè)緯度等過(guò)濾篩選出數(shù)據(jù)鸽凶，放入歷史數(shù)據(jù)庫(kù)(History Databases)里面币砂。遷移完了，再回到主庫(kù)M1上玻侥，刪除掉這些歷史數(shù)據(jù)决摧。這樣在業(yè)務(wù)層面，查詢(xún)就要兼顧現(xiàn)在實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)凑兰，可以在filter上面根據(jù)遷移規(guī)則把online查詢(xún)和history查詢(xún)對(duì)接起來(lái)掌桩。比如說(shuō)一個(gè)月之內(nèi)的在online庫(kù)查詢(xún)一個(gè)月之前的在history庫(kù)查詢(xún)，可以把這個(gè)規(guī)則放在DB的遷移filter層和應(yīng)用查詢(xún)業(yè)務(wù)模塊層姑食。如果可以的話(huà)波岛，還可以配置更細(xì)化，通過(guò)應(yīng)用查詢(xún)業(yè)務(wù)模塊層來(lái)影響DB的遷移filter層音半，比如以前查詢(xún)分為一個(gè)月為基準(zhǔn)则拷，現(xiàn)在查詢(xún)業(yè)務(wù)變化了贡蓖，以15天為基準(zhǔn)，那么應(yīng)用查詢(xún)業(yè)務(wù)模塊層變化會(huì)自動(dòng)讓DB的filter層也變化煌茬，實(shí)現(xiàn)半個(gè)自動(dòng)化斥铺，更加智能一些。
像oracle這種基于rac基于共享存儲(chǔ)的方式宣旱，不需要sharding只需要擴(kuò)從rac存儲(chǔ)就能實(shí)現(xiàn)了仅父。但是這種代價(jià)相對(duì)會(huì)比較高一些叛薯，共享存儲(chǔ)一般都比較貴浑吟，隨著業(yè)務(wù)的擴(kuò)展數(shù)據(jù)的爆炸式增長(zhǎng)，你會(huì)不停累計(jì)你的成本耗溜，甚至達(dá)到一個(gè)天文數(shù)字组力。
目前這種share disk的方式，除了oracle的業(yè)務(wù)邏輯層做的非常完善之外其他的解決方案都還不是很完美抖拴。
Mysql的sharding也有其局限性燎字，sharding之后的數(shù)據(jù)查詢(xún)?cè)L問(wèn)以及統(tǒng)計(jì)都會(huì)有很大的問(wèn)題，mysql的sharding是解決share nothing的存儲(chǔ)的一種分布式的方法阿宅，大體上分為垂直拆分和水平拆分候衍。
可以橫向拆分，可以縱向拆分洒放，可以橫向縱向拆分蛉鹿，還可以按照業(yè)務(wù)拆分。
6.1.1橫向拆分
Mysql庫(kù)里面的橫向拆分是指往湿，每一個(gè)數(shù)據(jù)庫(kù)實(shí)例里面都有很多個(gè)db庫(kù)妖异，每一個(gè)db庫(kù)里面都有A表B表，比如db1庫(kù)有A表B表领追，db2庫(kù)里也有A表和B表他膳，那么我們把db1、db2庫(kù)的A表B表拆分出來(lái)绒窑，把一個(gè)庫(kù)分成2個(gè)棕孙，就拆分成db1、db2些膨、db3散罕、db4，其中db1庫(kù)和db2庫(kù)放A表數(shù)據(jù)傀蓉，db3庫(kù)和db4庫(kù)放B表的數(shù)據(jù)欧漱，db1、db2庫(kù)里面只有A表數(shù)據(jù)葬燎，db3误甚、db4庫(kù)里面只有B表的數(shù)據(jù)缚甩。
打個(gè)比方，作為電商來(lái)說(shuō)窑邦，每個(gè)庫(kù)里面都有日志表和訂單表擅威，假如A表是日志表log表，B表是訂單表Order表冈钦，一般說(shuō)來(lái)寫(xiě)日志和寫(xiě)訂單沒(méi)有強(qiáng)關(guān)聯(lián)性郊丛，我們可以講A表日志表和B表訂單表拆分出來(lái)。那么這個(gè)時(shí)候就做了一次橫向的拆分工作瞧筛，將A表日志表和B表訂單表拆分開(kāi)來(lái)放在不同的庫(kù)厉熟，當(dāng)然A表和B表所在的數(shù)據(jù)庫(kù)名也可以保持一致(PS：在不同的實(shí)例里面)，如下圖所示：
PS：這種拆分主要針對(duì)于不同的業(yè)務(wù)對(duì)表的影響不大较幌，表之間的業(yè)務(wù)關(guān)聯(lián)很弱或者基本上沒(méi)有業(yè)務(wù)關(guān)聯(lián)揍瑟。拆分的好處是不相關(guān)的數(shù)據(jù)表拆分到不同的實(shí)例里面，對(duì)數(shù)據(jù)庫(kù)的容量擴(kuò)展和性能提高的均衡來(lái)說(shuō)乍炉，都是蠻有好處的绢片。
6.1.2縱向拆分
把同一個(gè)實(shí)例上的不同的db庫(kù)拆分出來(lái)，放入單獨(dú)的不同實(shí)例中岛琼。這種拆分的適應(yīng)場(chǎng)景和要求是db1和db2是沒(méi)有多少業(yè)務(wù)聯(lián)系的底循，類(lèi)似6.1.2里面的A表和B表那樣。如果你用到了跨庫(kù)業(yè)務(wù)同時(shí)使用db1和db2的話(huà)槐瑞，個(gè)人建議要重新考慮下業(yè)務(wù)熙涤，重新梳理下盡量把一個(gè)模塊的表放在一個(gè)庫(kù)里面，不要垮庫(kù)操作随珠。
這種庫(kù)縱向拆分里面灭袁，單獨(dú)的庫(kù)db1，表A和表B是強(qiáng)關(guān)聯(lián)的窗看。如下圖所示：
PS：看到很多使用mysql的人茸歧，總是把很多沒(méi)有業(yè)務(wù)關(guān)聯(lián)性的表放在一個(gè)庫(kù)里面，或者總是把很多個(gè)的db庫(kù)放在同一個(gè)實(shí)例里面显沈，就像使用oracle那樣就一個(gè)instance的概念而已软瞎。Mysql的使用一大原則就是簡(jiǎn)單，盡量單一拉讯，簡(jiǎn)單的去使用mysql涤浇，庫(kù)要嚴(yán)格的分開(kāi)；表沒(méi)有關(guān)系的魔慷，要嚴(yán)格拆分成庫(kù)只锭。這樣的話(huà)擴(kuò)展我們的業(yè)務(wù)就非常方便簡(jiǎn)單了，只需要把業(yè)務(wù)模塊所在的db拆分出來(lái)院尔，放入新的數(shù)據(jù)庫(kù)服務(wù)器上即可蜻展。
6.1.3?橫向縱向拆分
有些剛起步的喉誊，開(kāi)始為了快速出產(chǎn)品，就把所以的庫(kù)所有的表都放在一個(gè)實(shí)例上纵顾，等業(yè)務(wù)發(fā)展后伍茄，就面臨著數(shù)據(jù)拆分，這里就會(huì)把橫向縱向拆分結(jié)合起來(lái)施逾，一起實(shí)現(xiàn)敷矫，如下圖所示：
6.1.4?業(yè)務(wù)拆分
跟水平拆分有點(diǎn)類(lèi)似，但是有不同的地方汉额。比如一個(gè)供應(yīng)商曹仗，可能整個(gè)網(wǎng)站上有10個(gè)供應(yīng)商，一個(gè)網(wǎng)站上面每一個(gè)供應(yīng)商都有一定的量闷愤，而且供應(yīng)商之間的數(shù)據(jù)量規(guī)模都差不多的規(guī)模整葡，那么這個(gè)時(shí)候就可以使用供應(yīng)商的緯度來(lái)做拆分件余。
比如usern庫(kù)中讥脐，a、b啼器、c表都是強(qiáng)關(guān)聯(lián)的旬渠，都有完整的業(yè)務(wù)邏輯存在，這里只有用戶(hù)（供應(yīng)商）緯度是沒(méi)有關(guān)聯(lián)的端壳，那這個(gè)時(shí)候就可以把數(shù)據(jù)以用戶(hù)的緯度來(lái)進(jìn)行拆分告丢。
就是用戶(hù)1和用戶(hù)2各自都有一套完整的業(yè)務(wù)邏輯，而且彼此之間不關(guān)聯(lián)损谦，所以就可以把用戶(hù)1和用戶(hù)2數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)實(shí)例上面岖免。目前很多互聯(lián)網(wǎng)公司或者游戲公司有很多業(yè)務(wù)都是以用戶(hù)緯度進(jìn)行拆分的，比如qunaer照捡、sohu game颅湘、sina等。
水平拆分相對(duì)要簡(jiǎn)單一些栗精，但是難度偏大闯参，會(huì)導(dǎo)致分布式的情況、跨數(shù)據(jù)的情況悲立、跨事務(wù)的情況可以分為大概三類(lèi)鹿寨，1是歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)拆分，2是單庫(kù)多表拆分薪夕，3是多庫(kù)多表拆分脚草。
6.2.1?實(shí)時(shí)數(shù)據(jù)歷史數(shù)據(jù)的拆分
和歷史數(shù)據(jù)遷移是一樣的邏輯，就是要將online庫(kù)的數(shù)據(jù)遷移到listory的數(shù)據(jù)庫(kù)里面原献，對(duì)于實(shí)時(shí)的讀寫(xiě)來(lái)說(shuō)馏慨，數(shù)據(jù)是放在online db庫(kù)里面涩蜘，對(duì)于時(shí)間較遠(yuǎn)的數(shù)據(jù)來(lái)說(shuō)，是放在歷史History DB記錄庫(kù)里面的熏纯，這里的歷史庫(kù)可以是mysql也可以是別的nosql庫(kù)等同诫。
6.2.2?單庫(kù)多表拆分
主要不是解決容量問(wèn)題，而是解決性能問(wèn)題而擴(kuò)展的樟澜，加入當(dāng)前實(shí)例只有一個(gè)DB误窖，有一個(gè)大表，一個(gè)大表就把整個(gè)實(shí)例占滿(mǎn)了秩贰，這個(gè)時(shí)候就不能拆分db了霹俺，因?yàn)橹挥幸粋€(gè)單表，這個(gè)時(shí)候我們就只能拆表了毒费，拆表的方式主要是解決性能問(wèn)題丙唧，因?yàn)閱蝹€(gè)表越大，對(duì)于mysql來(lái)說(shuō)遍歷表的樹(shù)形結(jié)構(gòu)遍歷數(shù)據(jù)會(huì)消耗更多的資源觅玻，有時(shí)候一個(gè)簡(jiǎn)單的查詢(xún)就可能會(huì)引起整個(gè)db的很多葉子節(jié)點(diǎn)都要變動(dòng)想际。表的insert、update溪厘、delete操作都會(huì)引起幾乎所有節(jié)點(diǎn)的變更胡本，此時(shí)操作量會(huì)非常大，操作的時(shí)候讀寫(xiě)性能都會(huì)很低畸悬，這個(gè)時(shí)候我們就可以考慮把大表拆分成多個(gè)小表侧甫，工作經(jīng)歷中是按照hash取模打散成16個(gè)小表，也有按照id主鍵/50取模打散到50個(gè)小表當(dāng)中蹋宦，下圖實(shí)例是打散成2個(gè)小表披粟。
6.2.3?多庫(kù)多表拆分
在單庫(kù)多表的基礎(chǔ)上，如果單庫(kù)空間資源已經(jīng)不足以提供業(yè)務(wù)支撐的話(huà)冷冗，可以考慮多庫(kù)多表的方式來(lái)做守屉，解決了空間問(wèn)題和性能問(wèn)題，不過(guò)會(huì)有一個(gè)問(wèn)題就是跨庫(kù)查詢(xún)操作贾惦，查詢(xún)就會(huì)有另外的策略胸梆，比如說(shuō)加一個(gè)logic db層來(lái)實(shí)現(xiàn)跨庫(kù)跨實(shí)例自動(dòng)查詢(xún)，簡(jiǎn)單如下圖所示：
6.2.4水平拆分小結(jié)
水平拆分原則：
– a.?盡量均勻的拆分維度须板。
– b.?盡量避免跨庫(kù)事務(wù)碰镜。
– c.?盡量避免跨庫(kù)查詢(xún)。
設(shè)計(jì)：
–a根據(jù)拆分維度习瑰，做mod進(jìn)行數(shù)據(jù)表拆分绪颖，大部分都是取模的拆分機(jī)制，比如hash的16模原則等。
–b根據(jù)數(shù)據(jù)容量柠横，劃分?jǐn)?shù)據(jù)庫(kù)拆分
數(shù)據(jù)操作
–a跨事務(wù)操作：分布式事務(wù)窃款，通過(guò)預(yù)寫(xiě)日志的方式來(lái)間接地實(shí)現(xiàn)。
–b跨庫(kù)查詢(xún)：數(shù)據(jù)匯總or消息服務(wù)
6.2.5?案例說(shuō)明
u? 案例：
–????? 按照用戶(hù)維度進(jìn)行拆分成64個(gè)分庫(kù)牍氛，1024個(gè)分表
????????user_id%1024?拆分到1024張分表中
??????? 每個(gè)分庫(kù)中存放1024/64張分表
??????? 取模的時(shí)候晨继，可以用id的最后4位數(shù)據(jù)或者3位數(shù)字來(lái)取模就可以了。
u? 操作1：采用Configure DB
–????? 拆分之后的查詢(xún)操作搬俊，做一個(gè)Configure DB紊扬，這個(gè)DB存放的是所有實(shí)例的庫(kù)表的映射關(guān)系，當(dāng)我APP發(fā)來(lái)有一個(gè)請(qǐng)求查詢(xún)user1的數(shù)據(jù)唉擂，那么這個(gè)user1的數(shù)據(jù)是存放在上千個(gè)實(shí)例中的哪一個(gè)庫(kù)表呢餐屎？這個(gè)關(guān)聯(lián)信息就在Configure DB里面，APP先去Configure DB里面取得user1的關(guān)聯(lián)系信息(比如是存放在d_01庫(kù)上的t_0016表里面)玩祟，然后APP根據(jù)關(guān)聯(lián)信息直接去查詢(xún)對(duì)應(yīng)的d_01實(shí)例的t_0016表里面取得數(shù)據(jù)腹缩。
u? 操作2：采用Proxy
–????? 拆分之后的查詢(xún)操作，做一個(gè)Proxy空扎，APP訪(fǎng)問(wèn)Proxy藏鹊，Proxy根據(jù)訪(fǎng)問(wèn)規(guī)則就可以直接路由到具體的db實(shí)例，生成新的sql去操作對(duì)應(yīng)的db實(shí)例勺卢，然后通過(guò)Proxy協(xié)議進(jìn)行操作把操作結(jié)果返回給APP伙判。
–????? 優(yōu)勢(shì)是Proxy和db實(shí)例是在一個(gè)網(wǎng)段象对，這樣Proxy與db實(shí)例的操作的時(shí)間是非常短的黑忱。
u? 操作3：采用Data Engine
–????? 拆分之后的查詢(xún)操作，有一個(gè)Data Engine Service勒魔，這個(gè)DES里面配置了所有數(shù)據(jù)庫(kù)實(shí)例的映射關(guān)系甫煞，需要在APP應(yīng)用端安裝一個(gè)Agent，是同步邏輯冠绢，在JDBC層實(shí)現(xiàn)抚吠，DES可以實(shí)現(xiàn)讀寫(xiě)分離，原理可以參考TDDL的實(shí)現(xiàn)弟胀。
6.3?集群管理
縱向擴(kuò)容：一個(gè)實(shí)例拆分成多個(gè)實(shí)例楷力，縱向拆分比較簡(jiǎn)單，修改的東西比較少孵户，拆分的時(shí)候要通知到Configure DB或者DES萧朝，以免拆分之后查詢(xún)不到數(shù)據(jù)或者數(shù)據(jù)錄入不到新的db上面，如下圖所示：
橫向擴(kuò)容：比較復(fù)雜夏哭，在縱向擴(kuò)容成2個(gè)庫(kù)的基礎(chǔ)之上检柬，再一次對(duì)庫(kù)的表進(jìn)行擴(kuò)容，所以需要及時(shí)通知Configure DB和DES更細(xì)庫(kù)和表的路由連接信息竖配。
