背景
數(shù)據(jù)庫(kù)作為一個(gè)非?；A(chǔ)的系統(tǒng)，任何一家互聯(lián)網(wǎng)公司都會(huì)使用，數(shù)據(jù)庫(kù)產(chǎn)品也很多，有Oracle、SQL Server?、MySQL、PostgeSQL、MariaDB等，像SQLServer/Oracle?這類數(shù)據(jù)庫(kù)在初期可以幫業(yè)務(wù)搞定很多棘手的事情，我們可以花更多的精力在業(yè)務(wù)本身的發(fā)展上，但眾所周知也得交不少錢。
涉及到錢的事情在公司發(fā)展壯大以后總是會(huì)回來(lái)重新審視這個(gè)事情的，在京東早期發(fā)展的過(guò)程中確實(shí)有一些業(yè)務(wù)的數(shù)據(jù)就是直接存在oracle或者sqlserver中。
后來(lái)隨著業(yè)務(wù)的發(fā)展以及數(shù)據(jù)量訪問(wèn)量的不斷增加及成本等方面的考慮，從長(zhǎng)遠(yuǎn)考慮需要把這些業(yè)務(wù)用免費(fèi)的MySQL來(lái)存，但單機(jī)的MySQL往往無(wú)法直接抗住這些業(yè)務(wù)，自然而然的我們就需要考慮引入分布式的MySQL解決方案幫助業(yè)務(wù)去SQLServer/Oracle以及支撐未來(lái)的發(fā)展。
方案選型對(duì)比及京東實(shí)現(xiàn)方案
說(shuō)到分布式MySQL的解決方案一般來(lái)說(shuō)解決方案主要就兩種，客戶端的方案或者中間代理的方案，如下圖所示。
這兩種方案各有各的優(yōu)缺點(diǎn)：客戶端的方案是指會(huì)給業(yè)務(wù)提供一個(gè)專門的客戶端的包，這種方案在實(shí)現(xiàn)上會(huì)更容易一點(diǎn)，如果公司需要快速出一個(gè)相對(duì)通用的解決方案，客戶端的方案可以優(yōu)先考慮。
客戶端方案需要為不同的語(yǔ)言提供不同的客戶端的包，這點(diǎn)有所局限。客戶端方案只需要走一段網(wǎng)絡(luò)，理論上性能會(huì)更好一點(diǎn)。
客戶端方案對(duì)業(yè)務(wù)有侵入，有一些系統(tǒng)部署及實(shí)現(xiàn)方面的可能可以控制得更好，但對(duì)業(yè)務(wù)本身不友好，客戶端包升級(jí)等方面比較麻煩。
中間代理的方案是指采用一個(gè)兼容MySQL協(xié)議的代理的方式，業(yè)務(wù)可以使用任何語(yǔ)言的MySQL客戶端的包，對(duì)業(yè)務(wù)本身無(wú)侵入的，這種方案相對(duì)來(lái)說(shuō)是最友好的。
中間代理方案開發(fā)難度上來(lái)說(shuō)門檻會(huì)更高一點(diǎn)，需要考慮前后端的東西，尤其是與MySQL端交互時(shí)自己解析協(xié)議的情況下會(huì)更復(fù)雜一些。中間代理方案多走一段TCP，對(duì)性能理論上會(huì)有一些影響。
上述兩種方案有一個(gè)非常重要的因素沒(méi)有提及，在實(shí)際生產(chǎn)環(huán)境中面臨一個(gè)非?，F(xiàn)實(shí)的問(wèn)題是MySQL能支持的連接數(shù)是有限的。以MySQL5.5來(lái)說(shuō)假設(shè)一個(gè)MySQL實(shí)例配置1000個(gè)連接，業(yè)務(wù)應(yīng)用實(shí)例部署了100個(gè)，每個(gè)應(yīng)用實(shí)例的數(shù)據(jù)庫(kù)連接池配置20個(gè)，采用客戶端方案這個(gè)MySQL實(shí)例都沒(méi)法正常工作了。
大多數(shù)情況下并不是每個(gè)應(yīng)用實(shí)例的每條連接都是活躍的，中間代理的方案可以很好的解決這個(gè)問(wèn)題，應(yīng)用實(shí)例可以有很多連接打到代理上，代理只需要維護(hù)較少的與MySQL的連接即可滿足需求，代理與MySQL之間的連接會(huì)被業(yè)務(wù)打過(guò)來(lái)的訪問(wèn)重復(fù)使用。
另外關(guān)于多走一次TCP對(duì)性能的影響，從我們的實(shí)際經(jīng)驗(yàn)來(lái)看其實(shí)可以忽略不計(jì)，業(yè)務(wù)實(shí)例一多優(yōu)先遇到的是MySQL連接數(shù)的問(wèn)題，從這個(gè)角度來(lái)說(shuō)中間代理的方案會(huì)更優(yōu)。
我們采用的就是中間代理的方案，京東的分布式MySQL方案由很多部分組成，有JManager、?JProxy、?JTransfer、JMonitor、JConsole、MySQL，在實(shí)際部署的時(shí)候還涉及到LVS以及域名系統(tǒng)等。
JManager是中心管理節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)負(fù)責(zé)統(tǒng)一管理系統(tǒng)的元信息，元信息包括路由信息、權(quán)限管理信息、資源相關(guān)的信息等。
JProxy就是一個(gè)兼容MySQL協(xié)議的代理，負(fù)責(zé)把客戶端發(fā)送過(guò)來(lái)的SQL按照路由規(guī)則發(fā)送到相應(yīng)的數(shù)據(jù)庫(kù)節(jié)點(diǎn)上，再把返回的結(jié)果進(jìn)行合并并返回給客戶端。JProxy在啟動(dòng)的時(shí)候會(huì)先去JManager中拉取相關(guān)的元信息，并在自己的內(nèi)存中維護(hù)一份，平時(shí)使用的時(shí)候只用自身內(nèi)存維護(hù)的這一份就可以了。
JProxy的內(nèi)部實(shí)現(xiàn)原理如圖所示。
JTransfer是在線遷移系統(tǒng)，我們針對(duì)業(yè)務(wù)的數(shù)據(jù)進(jìn)行拆分以后，比如某個(gè)MySQL實(shí)例上有32個(gè)庫(kù)，等到業(yè)務(wù)數(shù)據(jù)量繼續(xù)增大以后在這個(gè)實(shí)例上就放不下了，我們就需要往整個(gè)集群中加MySQL實(shí)例，將之前的32個(gè)庫(kù)中一部分遷移到這個(gè)新增加的實(shí)例上，如何在不停業(yè)務(wù)的情況完成數(shù)據(jù)的在線遷移就是JTransfer這個(gè)系統(tǒng)來(lái)保證的。
JConsole系統(tǒng)可以理解為將多個(gè)業(yè)務(wù)的中心管理節(jié)點(diǎn)整合起來(lái)的一個(gè)后臺(tái)管理控制系統(tǒng)，這個(gè)系統(tǒng)可以與每個(gè)JManager交互。在具體使用的時(shí)候，業(yè)務(wù)方需要申請(qǐng)創(chuàng)建庫(kù)表、拆分規(guī)則、什么權(quán)限、對(duì)哪些IP授權(quán)，我們會(huì)通過(guò)JConsole系統(tǒng)與JManager交互完成元數(shù)據(jù)的配置。
JMonitor系統(tǒng)會(huì)將各個(gè)業(yè)務(wù)的jproxy以及MySQL相關(guān)的信息采集起來(lái)，整合到一起形成一個(gè)統(tǒng)一的監(jiān)控系統(tǒng)，完成對(duì)系統(tǒng)的全面詳盡的監(jiān)控。
網(wǎng)絡(luò)模型
JProxy作為一個(gè)非常典型的代理服務(wù)，程序本身的性能非常關(guān)鍵，具體在實(shí)現(xiàn)的時(shí)候我們參考了Nginx的網(wǎng)絡(luò)模型。
大家都知道Nginx的性能非常高，根據(jù)機(jī)器核數(shù)配置相應(yīng)的worker數(shù)就可以，每個(gè)worker可以理解為圍繞一個(gè)epoll把前后端的連接以完全基于事件驅(qū)動(dòng)的方式串在一起，避免了上下文切換避免了鎖等待等各種可能阻塞或者耗時(shí)的操作。
同樣的網(wǎng)絡(luò)模型也可以參考一下Redis的實(shí)現(xiàn)，redis雖然不像nginx需要考慮前后端連接的處理，但redis的模型也是一種非常類似的經(jīng)典的實(shí)現(xiàn)方式。
JProxy整個(gè)網(wǎng)絡(luò)模型如圖所示，采用一個(gè)全局的nioacceptor以及多個(gè)nioreactor，由nioacceptor統(tǒng)一accept連接，之后把連接分給某個(gè)nioreactor。
nioreactor可以理解為底層就是一個(gè)epoll（java nio實(shí)現(xiàn)），前后端的連接都是注冊(cè)在這個(gè)epoll上，我們只需要根據(jù)事件是讀事件或?qū)懯录{(diào)用相應(yīng)的回調(diào)函數(shù)即可。這種模型的特點(diǎn)是系統(tǒng)幾乎沒(méi)有太多的上下文切換，而且性能很高。
基于事件驅(qū)動(dòng)的網(wǎng)絡(luò)模型的好處是性能很高，但問(wèn)題也很明顯，編寫時(shí)復(fù)雜度非常高，一條SQL發(fā)送過(guò)來(lái)到收到結(jié)果的上下文被切成很多片段，同一時(shí)刻有來(lái)自很多不同上下文的不同的片段要處理，全程只有一個(gè)進(jìn)(線)程來(lái)處理這些片段(暫且假設(shè)NIOReactor只配置成一個(gè))，所以在實(shí)現(xiàn)的過(guò)程中要求把所有的細(xì)節(jié)都考慮非常周全，一旦某個(gè)片段的處理有阻塞或者耗時(shí)，整個(gè)程序都將阻塞，個(gè)人覺得這種編程方式有點(diǎn)反人類思維。
關(guān)于分布式事務(wù)的思考
另外關(guān)于分布式事務(wù)的支持也是一個(gè)大家可能比較感興趣的點(diǎn)，基于MySQL的方式來(lái)做分布式數(shù)據(jù)庫(kù)的時(shí)候分布式事務(wù)是不可能滿足嚴(yán)格的分布式事務(wù)語(yǔ)義的。
數(shù)據(jù)庫(kù)事務(wù)有ACID四個(gè)屬性，分別是原子性、一致性、隔離性、持久性。
原子性(Atomicity)的意思是整個(gè)事務(wù)最終只能是要么成功要么失敗，不能存在中間狀態(tài)，如果發(fā)生錯(cuò)誤了就需要回滾回去，就像這個(gè)事務(wù)從來(lái)沒(méi)有執(zhí)行過(guò)一樣。
一致性(Consistency)是指系統(tǒng)要處于一個(gè)一致的狀態(tài)，不能因?yàn)椴l(fā)事務(wù)的多少影響到系統(tǒng)的一致性，舉個(gè)典型的例子就是轉(zhuǎn)帳的情況，假設(shè)有ABC三個(gè)帳號(hào)各有100元，那么不管這三個(gè)帳號(hào)之間怎么轉(zhuǎn)賬，整個(gè)系統(tǒng)總的額度是300元這一點(diǎn)是應(yīng)該是不變的。其實(shí)ACID里的一致性更多的是應(yīng)用程序需要考慮的問(wèn)題，和分布式系統(tǒng)里的CAP里的一致性完全不是一個(gè)概念。
隔離性(Isolation)，本質(zhì)上是解決并發(fā)執(zhí)行的事務(wù)如何保證數(shù)據(jù)庫(kù)狀態(tài)是正確的，抽象描述叫可串行化，就是并發(fā)的事務(wù)在執(zhí)行的時(shí)候效果要求達(dá)到看起來(lái)像是一個(gè)個(gè)事務(wù)串行執(zhí)行的效果。有沖突的事務(wù)之間的隔離性如果保證不了會(huì)引起前面的一致性(consistency)也無(wú)法滿足。
每個(gè)事務(wù)包含多個(gè)動(dòng)作，這些動(dòng)作如果按照事務(wù)本身的順序依次執(zhí)行就是所謂的串行執(zhí)行，這些動(dòng)作也可以重新排列，排列完以后的動(dòng)作如果效果可以等價(jià)于事務(wù)串行執(zhí)行的效果我們就叫做可串行化調(diào)度。
實(shí)際實(shí)現(xiàn)的時(shí)候往往采用的是沖突可串行化，這個(gè)條件比可串行化要求會(huì)更高一點(diǎn)，規(guī)定了一些讀寫順序規(guī)定了一些訪問(wèn)沖突的情況規(guī)定了哪些情況兩個(gè)事物的動(dòng)作可以調(diào)換哪些是不可以的，可以理解為沖突可串行化是可串行化的充分條件。
持久性(Durability)，在事務(wù)完成以后所有的修改可以持久的保存在數(shù)據(jù)庫(kù)中，一般會(huì)采用WAL的方式，會(huì)把操作提前記錄到日志中來(lái)保證即使操作還沒(méi)有刷到磁盤就宕機(jī)的情況下有日志可以恢復(fù)。
介紹完事務(wù)的ACID屬性以后，我們?cè)賮?lái)分析為什么基于MySQL無(wú)法提供嚴(yán)格的分布式事務(wù)語(yǔ)義的支持。
如果客戶端發(fā)送的SQL只涉及到一個(gè)節(jié)點(diǎn)，那自然是可以保證事務(wù)的，但是如果客戶端發(fā)送的SQL涉及到兩個(gè)及以上節(jié)點(diǎn)的SQL，那就無(wú)法保證事務(wù)語(yǔ)義了。
原因主要是兩個(gè)，一是原子性無(wú)法保證，另一個(gè)是隔離性無(wú)法保證。在一個(gè)節(jié)點(diǎn)commit成功以后，在另外的節(jié)點(diǎn)commit失敗了，這個(gè)事務(wù)就處在一個(gè)中間狀態(tài)，此時(shí)原子性被打破。
引起的另一個(gè)問(wèn)題就是隔離性，這個(gè)事務(wù)的一部分提交了，另一部分未提交，此時(shí)該事務(wù)正常是不該被讀取到的，但是提交成功的部分會(huì)被其他事務(wù)讀到，此時(shí)就無(wú)法保證隔離性了。
另外就算是涉及多個(gè)節(jié)點(diǎn)的操作都是成功的，理論上來(lái)說(shuō)也是無(wú)法保證隔離性的。因?yàn)榧僭O(shè)A事務(wù)的一個(gè)節(jié)點(diǎn)先commit成功，其他的節(jié)點(diǎn)后commit成功，而此時(shí)B事務(wù)在讀取的時(shí)候可能會(huì)讀取到了A事務(wù)最早commit成功的那部分內(nèi)容，卻沒(méi)有讀到后來(lái)commit成功的內(nèi)容，此時(shí)依然無(wú)法保證隔離性。
更本質(zhì)一點(diǎn)的原因是MySQL的事務(wù)都是每個(gè)實(shí)例維護(hù)自身的事務(wù)ID，而基于MySQL集群的分布式方案沒(méi)有一個(gè)全局的事務(wù)ID來(lái)標(biāo)識(shí)每個(gè)MySQL實(shí)例上的事務(wù)以及全局事務(wù)的元信息的管理，所以無(wú)法做到嚴(yán)格的分布式事務(wù)語(yǔ)義。
但實(shí)際上絕大多數(shù)業(yè)務(wù)對(duì)這個(gè)需求未必那么強(qiáng)烈，因?yàn)榻^大多數(shù)的業(yè)務(wù)邏輯都是可以拆分的，拆成一個(gè)個(gè)只落在一個(gè)分庫(kù)里的操作在絕大多數(shù)場(chǎng)景下是完全可行的，而且拆分完以后也會(huì)更可控，所以這個(gè)問(wèn)題在我們支撐業(yè)務(wù)的過(guò)程中也不是一個(gè)特別大的問(wèn)題。
生產(chǎn)環(huán)境監(jiān)控很關(guān)鍵
在實(shí)際生產(chǎn)環(huán)境中有很多方面都非常重要，高可用高可靠可擴(kuò)展等，但是除了這些之外還有一個(gè)非常關(guān)鍵的是監(jiān)控。
一個(gè)再健壯再牛x的系統(tǒng)都需要配備完善的監(jiān)控系統(tǒng)，監(jiān)控系統(tǒng)是生產(chǎn)環(huán)境中非常重要的一道防線，沒(méi)有監(jiān)控的系統(tǒng)就像是在裸奔，線上突發(fā)狀況很多完善的監(jiān)控系統(tǒng)可以做到第一時(shí)間發(fā)現(xiàn)問(wèn)題及時(shí)定位以及解決問(wèn)題。
物理機(jī)監(jiān)控。
我們?cè)谏a(chǎn)環(huán)境中會(huì)對(duì)系統(tǒng)所在物理機(jī)進(jìn)行監(jiān)控，京東有一個(gè)專門的物理機(jī)監(jiān)控系統(tǒng)，可以監(jiān)控包括CPU、內(nèi)存、網(wǎng)卡、TCP連接數(shù)、磁盤使用情況、機(jī)器load等很多基礎(chǔ)指標(biāo)，針對(duì)這些指標(biāo)可以設(shè)置相應(yīng)的報(bào)警閾值，當(dāng)超過(guò)一定閾值時(shí)會(huì)以郵件及短信的方式報(bào)警。
存活監(jiān)控
但物理機(jī)的監(jiān)控對(duì)于具體的系統(tǒng)的來(lái)說(shuō)是遠(yuǎn)遠(yuǎn)不夠的，我們還需要關(guān)注很多系統(tǒng)本身的信息，首先要有存活監(jiān)控，這是最基本的。一個(gè)系統(tǒng)在線上運(yùn)行的時(shí)候服務(wù)本身宕掉一定要求是可以第一時(shí)間監(jiān)控到的。
但除了物理機(jī)監(jiān)控以外，還有一個(gè)非常關(guān)鍵的是存活監(jiān)控。系統(tǒng)的一切前提是可以活著，我們?cè)诿總€(gè)模塊都會(huì)提供相應(yīng)的http接口，接入公司的統(tǒng)一監(jiān)控平臺(tái)，一旦有異常統(tǒng)一監(jiān)控平臺(tái)會(huì)及時(shí)通知相應(yīng)的負(fù)責(zé)人。
系統(tǒng)內(nèi)部狀態(tài)可視化監(jiān)控。
除了活下來(lái)以后，如何活得更好也是很關(guān)鍵的，所以我們還有專門針對(duì)分布式MySQL集群的JMonitor系統(tǒng)，該系統(tǒng)會(huì)整合各個(gè)模塊的內(nèi)部詳細(xì)狀態(tài)信息，包括慢查詢、用戶訪問(wèn)情況以及數(shù)據(jù)分布情況等。
一句話一個(gè)穩(wěn)定健壯的系統(tǒng)一定要配備相應(yīng)的完善的監(jiān)控系統(tǒng)。今天我的分享就是這些，主要就是介紹一些分布式MySQL的相關(guān)方案以及京東是怎么做的，討論了一下分布式事務(wù)的問(wèn)題，最后是一小部分生產(chǎn)實(shí)踐經(jīng)驗(yàn)，謝謝大家。
Q&A
問(wèn)題1：請(qǐng)介紹下分布式事務(wù)保證數(shù)據(jù)最終一致性的具體方案例子。
首先分布式事務(wù)涉及到的一致性和CAP中一致性是兩個(gè)概念，事務(wù)ACID屬性中的一致性不涉及最終一致性，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)中事務(wù)的概念，我的理解都是強(qiáng)一致的（通過(guò)原子性和隔離型保證）。只有涉及到某一個(gè)節(jié)點(diǎn)（內(nèi)容是相同的情況）多副本之間的復(fù)制問(wèn)題才會(huì)涉及到弱一致性或者最終一致性(CAP中C)的問(wèn)題。而分布式事務(wù)本身如果保證了原子性和隔離性，數(shù)據(jù)庫(kù)層面就提供了一致性保證，其余的是應(yīng)用邏輯層面保證。如果問(wèn)的是數(shù)據(jù)庫(kù)主從復(fù)制之間的一致性問(wèn)題，這個(gè)事情本質(zhì)上和事務(wù)（ACID的C）的一致性就沒(méi)有關(guān)系了，所以這個(gè)問(wèn)題本身可能有待商榷。
問(wèn)題2：分布式事務(wù)如何支持，現(xiàn)在可以支持多大規(guī)模的集群。
基于Mysql的分布式集群方案無(wú)法保證嚴(yán)格的分布式事務(wù)語(yǔ)義，但是在實(shí)際使用的時(shí)候看業(yè)務(wù)情況，如果事務(wù)之間不怎么沖突的情況下也是ok的，如果可以改成只涉及一個(gè)分庫(kù)的情況下那就繞開分布式事務(wù)的問(wèn)題了。另外支持的集群，我們其實(shí)是根據(jù)業(yè)務(wù)來(lái)劃分資源的，目前整體資源不能說(shuō)特別大，千臺(tái)規(guī)模。
問(wèn)題3：JProxy是否可以支持所有復(fù)雜sql查詢，主要是夸庫(kù)的關(guān)聯(lián)查詢，具體內(nèi)部邏輯可否介紹下？
我們目前不支持夸庫(kù)關(guān)聯(lián)查詢，從業(yè)務(wù)層面來(lái)解決。因?yàn)榇蟊碇g分庫(kù)以后如果要支持跨庫(kù)關(guān)聯(lián)查詢的話，作為一個(gè)OLTP系統(tǒng)在實(shí)際生產(chǎn)環(huán)境估計(jì)就沒(méi)法用了。
問(wèn)題4：請(qǐng)介紹下MySQL實(shí)際應(yīng)用中主從復(fù)制的方案，以及主從的數(shù)據(jù)差異會(huì)在什么程度,謝謝!
這個(gè)其實(shí)更多的是主從之間關(guān)注的問(wèn)題，一般會(huì)采用基于mix的模式。另外主從差異這個(gè)不同業(yè)務(wù)不一樣，加上嚴(yán)格的監(jiān)控，正常訪問(wèn)的情況下一般不會(huì)出現(xiàn)延遲，但是如果涉及到業(yè)務(wù)倒數(shù)據(jù)或者突增的訪問(wèn)量可能會(huì)引起延遲，所以這個(gè)不太好參考，如果有異常我們都會(huì)第一時(shí)間及時(shí)介入處理。
問(wèn)題5：長(zhǎng)時(shí)間SQL不會(huì)造成堵塞嗎？
主要看這條SQL具體是做什么的，如果是抽數(shù)據(jù)，就正常抽就可以了。如果有阻塞基本都是因?yàn)樵贛ySQL端因?yàn)殒i沖突等原因造成阻塞，最終可能是這個(gè)事務(wù)被abort掉或者最終搶到鎖成功做完了這個(gè)事務(wù)。
問(wèn)題6：請(qǐng)介紹一下JTransfers的工作機(jī)制，以及實(shí)現(xiàn)過(guò)程中最難的部分。
遷移確實(shí)是比較刺手的一件事情，要考慮的細(xì)節(jié)很多。大體的步驟是：我們提交遷移計(jì)劃，指定什么時(shí)間開始遷移，到時(shí)間點(diǎn)以后JTransfer就會(huì)自動(dòng)遷移。JTransfer一開始是dump源分庫(kù)的數(shù)據(jù)，然后將這些數(shù)據(jù)恢復(fù)到目標(biāo)實(shí)例上，但是在這個(gè)期間業(yè)務(wù)是正常訪問(wèn)的，需要將增量數(shù)據(jù)遷移完，所以會(huì)有追增量過(guò)程。當(dāng)增量追到一定程度，我們會(huì)阻塞這個(gè)庫(kù)的訪問(wèn)，最后將剩余的少量數(shù)據(jù)遷移完。因?yàn)樽詈笫Ｓ鄶?shù)據(jù)量不多的時(shí)候，阻塞過(guò)程其實(shí)很短暫，所以對(duì)業(yè)務(wù)影響非常小。
最難的部分是：整個(gè)遷移過(guò)程中的路由變更，要保證路由變更的過(guò)程中數(shù)據(jù)不能寫花，且變更以后的路由要準(zhǔn)確的推送到JProxy中，由JManager和多個(gè)JProxy之間在變更路由的時(shí)候采用類似兩階段提交的協(xié)議，從而保證路由的變更是正確的。
問(wèn)題7：可以分享一下JProxy的并發(fā)性能優(yōu)化，以及JProxy中間狀態(tài)的異常與恢復(fù)機(jī)制嗎？謝謝！
并發(fā)性能優(yōu)化我們主要是通過(guò)采用基于事件驅(qū)動(dòng)的網(wǎng)絡(luò)模型，這種方式的特點(diǎn)是避免上下文切換避免鎖的開銷，但是代價(jià)的話剛才也說(shuō)了需要考慮得非常周全，把一個(gè)上下文切成很多片段，不太符合人類思維。
JProxy中間件狀態(tài)的異常與恢復(fù)機(jī)制這個(gè)我不是太理解什么含義哈，我的理解是如果jproxy運(yùn)行過(guò)程中訪問(wèn)出異常了怎么處理，如果是某個(gè)連接過(guò)來(lái)的sql出了問(wèn)題我們的做法是將整個(gè)連接涉及到的資源都關(guān)閉，把該次查詢涉及到的前后端資源清理干凈，這樣就不會(huì)影響到其他客戶端的訪問(wèn)。正常來(lái)說(shuō)不應(yīng)該出現(xiàn)這種情況，所以也需要完善的日志信息以及監(jiān)控信息。
講師介紹
張成遠(yuǎn)
京東資深架構(gòu)師，ArchSummit北京專題講師《Mariadb原理與實(shí)現(xiàn)》作者，開源項(xiàng)目speedy作者。畢業(yè)于東北大學(xué)，碩士階段研究分布式數(shù)據(jù)庫(kù)相關(guān)方向，2012年加入京東數(shù)據(jù)庫(kù)系統(tǒng)研發(fā)團(tuán)隊(duì)。擅長(zhǎng)高性能服務(wù)器開發(fā)、分布式數(shù)據(jù)庫(kù)、分布式存儲(chǔ)/緩存等大規(guī)模分布式系統(tǒng)架構(gòu)。目前負(fù)責(zé)京東分布式數(shù)據(jù)庫(kù)系統(tǒng)的架構(gòu)與研發(fā)工作，主要關(guān)注云數(shù)據(jù)庫(kù)及分布式數(shù)據(jù)庫(kù)相關(guān)領(lǐng)域。
長(zhǎng)按下方二維碼關(guān)注ArchSummit公眾號(hào)，獲取更多干貨，不錯(cuò)過(guò)任何一次大牛分享……
