概述
分庫(kù)分表的必要性
首先我們來(lái)了解一下為什么要做分庫(kù)分表。在我們的業(yè)務(wù)（web應(yīng)用）中，關(guān)系型數(shù)據(jù)庫(kù)本身比較容易成為系統(tǒng)性能瓶頸，單機(jī)存儲(chǔ)容量、連接數(shù)、處理能力等都很有限，數(shù)據(jù)庫(kù)本身的“有狀態(tài)性”導(dǎo)致了它并不像Web和應(yīng)用服務(wù)器那么容易擴(kuò)展。那么在我們的業(yè)務(wù)中，是否真的有必要進(jìn)行分庫(kù)分表，就可以從上面幾個(gè)條件來(lái)考慮。
· 單機(jī)儲(chǔ)存容量。您的數(shù)據(jù)量是否在單機(jī)儲(chǔ)存中碰到瓶頸。比如餓了么一天產(chǎn)生的用戶行為數(shù)據(jù)就有24T，那么在傳統(tǒng)的單機(jī)儲(chǔ)存中肯定是不夠的。
· 連接數(shù)、處理能力。在我們的用戶量達(dá)到一定程度時(shí)，特定時(shí)間的并發(fā)量又成了一個(gè)大問題，在一個(gè)高并發(fā)的網(wǎng)站中秒級(jí)數(shù)十萬(wàn)的并發(fā)量都是很正常的。在普通的單機(jī)數(shù)據(jù)庫(kù)中秒級(jí)千次的操作問題都很大。
所以在我們進(jìn)行分庫(kù)分表之前我們最好考慮一下，我們的數(shù)據(jù)量是不是夠大，并發(fā)量是不是夠大。如果回答是肯定的，那我們就開始做吧。
在此推薦：個(gè)人整理了學(xué)習(xí)資料以PDF文件的形式分享給大家，需要查閱的程序員朋友可以來(lái)免費(fèi)領(lǐng)取。還有我的學(xué)習(xí)筆記PDF文件也免費(fèi)分享給有需要朋友！Java高級(jí)架構(gòu)學(xué)習(xí)資料分享+架構(gòu)師成長(zhǎng)之路?
分庫(kù)分表的幾種方法：
在分庫(kù)分表中，我們有幾種不同的劃分方式：垂直分表、垂直分庫(kù)、水平分表、水平分庫(kù)分表。分的方式大同小異，主要思想都是化大為小，且可以融合使用。
垂直分表
垂直分表在日常的開發(fā)和設(shè)計(jì)中比較常見，簡(jiǎn)單來(lái)講就是“大表拆小表”，拆分是基于關(guān)系型數(shù)據(jù)庫(kù)中的列進(jìn)行的。我們?cè)诨A(chǔ)數(shù)據(jù)庫(kù)課程中老師就教導(dǎo)我們，一個(gè)表的字段不要太多，就算數(shù)據(jù)量沒有那么大，為了表的合理性我們也會(huì)做。比如，某個(gè)表中的字段比較多，可以新建立一張“擴(kuò)展表”，將不經(jīng)常使用或者長(zhǎng)度較大的字段拆分出去放到“擴(kuò)展表”中。
比如在一張產(chǎn)品表中（id, name, price, company, ），我們將常用的（id, name, price, company）字段放在一個(gè)表中，而不常用的（）字段放在拓展表中，那我們查詢時(shí)優(yōu)先查詢常用字段，在有必要時(shí)才查詢拓展字段?？梢杂行У奶岣咝剩瑫r(shí)減少字段后我們?cè)谝粋€(gè)表中可以容納的數(shù)據(jù)數(shù)量也提高了。
垂直分表還有一個(gè)好處，能使得我們的微服務(wù)的關(guān)注點(diǎn)更加明確。
Note：分表的操作最好在數(shù)據(jù)庫(kù)設(shè)計(jì)階段就做完，如果在后續(xù)開發(fā)過程中再拆分，則可能需要大量的更改SQL語(yǔ)句。
垂直分庫(kù)
垂直分庫(kù)的基本思路便是我們按照不同的業(yè)務(wù)模塊來(lái)劃分出不同的數(shù)據(jù)庫(kù)。垂直分庫(kù)在“微服務(wù)”盛行的今天已經(jīng)非常普及了。就像我們上面所說(shuō)的，這能使得我們的微服務(wù)的關(guān)注點(diǎn)更加明確。也就是業(yè)務(wù)邏輯更加清晰。
比如在我們的業(yè)務(wù)中，User, Product, Company等都屬于不同業(yè)務(wù)模塊，便可將其放在不同的數(shù)據(jù)庫(kù)。
水平分表
水平分表的思想很簡(jiǎn)單，就相當(dāng)于一摞烙餅一百個(gè)，然后我每十個(gè)放一個(gè)籃子。在數(shù)據(jù)庫(kù)中的表現(xiàn)就是，我一個(gè)User表有100萬(wàn)條數(shù)據(jù)，那么我0-10w放在一個(gè)表中，10-20w放一個(gè)表中，類推（當(dāng)然這只是其中一種分布規(guī)律）。這樣可以降低單表的數(shù)據(jù)量，優(yōu)化查詢性能。
水平分表能夠降低單表的數(shù)據(jù)量，在一定程度上能夠緩解查詢性能的瓶頸。但其本質(zhì)上還是在一個(gè)數(shù)據(jù)庫(kù)中，所以當(dāng)查詢上升到數(shù)據(jù)庫(kù)級(jí)，其IO瓶頸并沒有得到好的解決。所以并不推薦單純的水平分表做法。
水平分庫(kù)分表
水平分庫(kù)分表與水平分表的思想相同，即將同一表中的大量數(shù)據(jù)分層次的儲(chǔ)存，不同的在于將分出來(lái)的表放在不同的數(shù)據(jù)庫(kù)中。在高并發(fā)和海量數(shù)據(jù)的場(chǎng)景下，分庫(kù)分表能夠有效緩解單機(jī)和單庫(kù)的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源的瓶頸。當(dāng)然，投入的硬件成本也會(huì)更高。同時(shí)，這也會(huì)帶來(lái)一些復(fù)雜的技術(shù)問題和挑戰(zhàn)（例如：跨分片的復(fù)雜查詢，跨分片事務(wù)等）。
在此推薦：個(gè)人整理了學(xué)習(xí)資料以PDF文件的形式分享給大家，需要查閱的程序員朋友可以來(lái)免費(fèi)領(lǐng)取。還有我的學(xué)習(xí)筆記PDF文件也免費(fèi)分享給有需要朋友！Java高級(jí)架構(gòu)學(xué)習(xí)資料分享+架構(gòu)師成長(zhǎng)之路?
主要內(nèi)容包括：
水平分庫(kù)說(shuō)明
分庫(kù)維度-- 根據(jù)哪個(gè)字段分庫(kù)
分庫(kù)策略-- 記錄如何分配到不同庫(kù)
分庫(kù)數(shù)量-- 初始庫(kù)數(shù)量及庫(kù)數(shù)量如何增長(zhǎng)
路由透明-- 如何實(shí)現(xiàn)庫(kù)路由，支持應(yīng)用透明
分頁(yè)處理-- 跨多個(gè)庫(kù)的分頁(yè)case如何處理
Lookup映射—非分庫(kù)字段映射到分庫(kù)字段，實(shí)現(xiàn)單庫(kù)訪問
整體架構(gòu)-- 分庫(kù)的整體技術(shù)架構(gòu)
上線步驟-- 分庫(kù)改造實(shí)施上線
項(xiàng)目總結(jié)
水平分庫(kù)說(shuō)明
數(shù)據(jù)庫(kù)拆分有兩種：
- 垂直分庫(kù)
數(shù)據(jù)庫(kù)里的表太多，拿出部分到新的庫(kù)里，一般是根據(jù)業(yè)務(wù)劃分表，關(guān)系密切的表放同一數(shù)據(jù)庫(kù)，應(yīng)用修改數(shù)據(jù)庫(kù)連接即可，比較簡(jiǎn)單。 - 水平分庫(kù)
某張表太大，單個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)不下或訪問性能有壓力，把一張表拆成多張，每張表存放部分記錄，保存在不同的數(shù)據(jù)庫(kù)里，水平分庫(kù)需要對(duì)系統(tǒng)做大的改造。
訂單表存儲(chǔ)在Oracle數(shù)據(jù)庫(kù)，記錄有上億條，字段有上百個(gè)，訪問的模式也是復(fù)雜多樣，隨著業(yè)務(wù)快速增長(zhǎng)，無(wú)論存儲(chǔ)空間或訪問性能都面臨巨大挑戰(zhàn)，特別在大促時(shí)，訂單庫(kù)已成為系統(tǒng)瓶頸。
通常有兩種解決辦法：
Scale up，升級(jí)Oracle數(shù)據(jù)庫(kù)所在的物理機(jī)，提升內(nèi)存/存儲(chǔ)/IO性能，但這種升級(jí)費(fèi)用昂貴，并且只能滿足短期需要。
Scale out，把訂單庫(kù)拆分為多個(gè)庫(kù)，分散到多臺(tái)機(jī)器進(jìn)行存儲(chǔ)和訪問，這種做法支持水平擴(kuò)展，可以滿足長(zhǎng)遠(yuǎn)需要。
采取后一種做法，它的訂單庫(kù)主要包括訂單主表/訂單明細(xì)表（記錄商品明細(xì)）/訂單擴(kuò)展表，水平分庫(kù)即把這3張表的記錄分到多個(gè)數(shù)據(jù)庫(kù)中，訂單水平分庫(kù)效果如下圖所示：
原來(lái)一個(gè)Oracle庫(kù)被多個(gè)MySQL庫(kù)取代，支持1主多備和讀寫分離，主備之間通過MySQL自帶的數(shù)據(jù)同步機(jī)制（SLA<1秒），所有應(yīng)用通過訂單服務(wù)訪問訂單數(shù)據(jù)。
在此推薦：個(gè)人整理了學(xué)習(xí)資料以PDF文件的形式分享給大家，需要查閱的程序員朋友可以來(lái)免費(fèi)領(lǐng)取。還有我的學(xué)習(xí)筆記PDF文件也免費(fèi)分享給有需要朋友！Java高級(jí)架構(gòu)學(xué)習(xí)資料分享+架構(gòu)師成長(zhǎng)之路?
分庫(kù)維度
水平分庫(kù)首先要考慮根據(jù)哪個(gè)字段作為分庫(kù)維度，選擇標(biāo)準(zhǔn)是盡量避免應(yīng)用代碼和SQL性能受影響，這就要求當(dāng)前SQL在分庫(kù)后，訪問盡量落在單個(gè)庫(kù)里，否則單庫(kù)訪問變成多庫(kù)掃描，讀寫性能和應(yīng)用邏輯都會(huì)受較大影響。
對(duì)于訂單拆分，大家首先想到的是按照用戶Id拆分，結(jié)論沒錯(cuò)，但最好還是數(shù)據(jù)說(shuō)話，不能拍腦袋。好的做法是首先收集所有SQL，挑選where語(yǔ)句最常出現(xiàn)的過濾字段，比如用戶Id/訂單Id/商家Id，每個(gè)字段在SQL中有三種情況：
單Id過濾，如用戶Id=？
多Id過濾，如用戶Id IN (?,?,?)
該Id不出現(xiàn)
然后進(jìn)一步統(tǒng)計(jì)，假設(shè)共有500個(gè)SQL訪問訂單庫(kù)，3個(gè)過濾字段出現(xiàn)情況如下：
過濾字段單Id過濾多Id過濾不出現(xiàn)
用戶Id12040330
訂單Id6080360
商家Id150485
結(jié)論明顯，應(yīng)該選擇用戶Id進(jìn)行分庫(kù)。
等一等，這只是靜態(tài)分析，每個(gè)SQL訪問的次數(shù)是不一樣的，因此還要分析每個(gè)SQL的訪問量。我們分析了Top15執(zhí)行最多的SQL (它們占總執(zhí)行次數(shù)85%)，如果按照用戶Id分庫(kù)，這些SQL 85%落到單個(gè)數(shù)據(jù)庫(kù), 13%落到多個(gè)數(shù)據(jù)庫(kù)，只有2%需要遍歷所有數(shù)據(jù)庫(kù)，明顯優(yōu)于使用其他Id進(jìn)行分庫(kù)。
通過量化分析，我們知道按照用戶Id分庫(kù)是最優(yōu)的，同時(shí)也大致知道分庫(kù)對(duì)現(xiàn)有系統(tǒng)的影響，比如這個(gè)例子中，85%的SQL會(huì)落到單個(gè)數(shù)據(jù)庫(kù)，這部分的訪問性能會(huì)優(yōu)化，堅(jiān)定了各方對(duì)分庫(kù)的信心。
分庫(kù)策略
分庫(kù)維度確定后，如何把記錄分到各個(gè)庫(kù)里呢？一般有兩種方式：
根據(jù)數(shù)值范圍，比如用戶Id為1-9999的記錄分到第一個(gè)庫(kù)，10000-20000的分到第二個(gè)庫(kù)，以此類推。
根據(jù)數(shù)值取模，比如用戶Id mod n，余數(shù)為0的記錄放到第一個(gè)庫(kù)，余數(shù)為1的放到第二個(gè)庫(kù)，以此類推。
兩種分法的優(yōu)劣比較如下：
評(píng)價(jià)指標(biāo)按照范圍分庫(kù)按照Mod分庫(kù)
庫(kù)數(shù)量前期數(shù)目比較小，可以隨用戶/業(yè)務(wù)按需增長(zhǎng)前期即根據(jù)mode因子確定庫(kù)數(shù)量，數(shù)目一般比較大
訪問性能前期庫(kù)數(shù)量小，全庫(kù)查詢消耗資源少，單庫(kù)查詢性能略差前期庫(kù)數(shù)量大，全庫(kù)查詢消耗資源多，單庫(kù)查詢性能略好
調(diào)整庫(kù)數(shù)量比較容易，一般只需為新用戶增加庫(kù)，老庫(kù)拆分也只影響單個(gè)庫(kù)困難，改變mod因子導(dǎo)致數(shù)據(jù)在所有庫(kù)之間遷移
數(shù)據(jù)熱點(diǎn)新舊用戶購(gòu)物頻率有差異，有數(shù)據(jù)熱點(diǎn)問題新舊用戶均勻到分布到各個(gè)庫(kù)，無(wú)熱點(diǎn)
實(shí)踐中，為了處理簡(jiǎn)單，選擇mod分庫(kù)的比較多。同時(shí)二次分庫(kù)時(shí)，為了數(shù)據(jù)遷移方便，一般是按倍數(shù)增加，比如初始4個(gè)庫(kù)，二次分裂為8個(gè)，再16個(gè)。這樣對(duì)于某個(gè)庫(kù)的數(shù)據(jù)，一半數(shù)據(jù)移到新庫(kù)，剩余不動(dòng)，對(duì)比每次只增加一個(gè)庫(kù)，所有數(shù)據(jù)都要大規(guī)模變動(dòng)。
補(bǔ)充下，mod分庫(kù)一般每個(gè)庫(kù)記錄數(shù)比較均勻，但也有些數(shù)據(jù)庫(kù)，存在超級(jí)Id，這些Id的記錄遠(yuǎn)遠(yuǎn)超過其他Id，比如在廣告場(chǎng)景下，某個(gè)大廣告主的廣告數(shù)可能占總體很大比例。如果按照廣告主Id取模分庫(kù)，某些庫(kù)的記錄數(shù)會(huì)特別多，對(duì)于這些超級(jí)Id，需要提供單獨(dú)庫(kù)來(lái)存儲(chǔ)記錄。
分庫(kù)數(shù)量
分庫(kù)數(shù)量首先和單庫(kù)能處理的記錄數(shù)有關(guān)，一般來(lái)說(shuō)，Mysql 單庫(kù)超過5000萬(wàn)條記錄，Oracle單庫(kù)超過1億條記錄，DB壓力就很大(當(dāng)然處理能力和字段數(shù)量/訪問模式/記錄長(zhǎng)度有進(jìn)一步關(guān)系)。
在滿足上述前提下，如果分庫(kù)數(shù)量少，達(dá)不到分散存儲(chǔ)和減輕DB性能壓力的目的；如果分庫(kù)的數(shù)量多，好處是每個(gè)庫(kù)記錄少，單庫(kù)訪問性能好，但對(duì)于跨多個(gè)庫(kù)的訪問，應(yīng)用程序需要訪問多個(gè)庫(kù)，如果是并發(fā)模式，要消耗寶貴的線程資源；如果是串行模式，執(zhí)行時(shí)間會(huì)急劇增加。
最后分庫(kù)數(shù)量還直接影響硬件的投入，一般每個(gè)分庫(kù)跑在單獨(dú)物理機(jī)上，多一個(gè)庫(kù)意味多一臺(tái)設(shè)備。所以具體分多少個(gè)庫(kù)，要綜合評(píng)估，一般初次分庫(kù)建議分4-8個(gè)庫(kù)。
路由透明
分庫(kù)從某種意義上來(lái)說(shuō)，意味著DB schema改變了，必然影響應(yīng)用，但這種改變和業(yè)務(wù)無(wú)關(guān)，所以要盡量保證分庫(kù)對(duì)應(yīng)用代碼透明，分庫(kù)邏輯盡量在數(shù)據(jù)訪問層處理。當(dāng)然完全做到這一點(diǎn)很困難，具體哪些應(yīng)該由DAL負(fù)責(zé)，哪些由應(yīng)用負(fù)責(zé)，這里有一些建議：
對(duì)于單庫(kù)訪問，比如查詢條件指定用戶Id，則該SQL只需訪問特定庫(kù)。此時(shí)應(yīng)該由DAL層自動(dòng)路由到特定庫(kù)，當(dāng)庫(kù)二次分裂時(shí)，也只要修改mod 因子，應(yīng)用代碼不受影響。
對(duì)于簡(jiǎn)單的多庫(kù)查詢，DAL負(fù)責(zé)匯總各個(gè)數(shù)據(jù)庫(kù)返回的記錄，此時(shí)仍對(duì)上層應(yīng)用透明。
對(duì)于帶聚合運(yùn)算的多庫(kù)查詢，如帶groupBy/orderby/min/max/avg等關(guān)鍵字，建議DAL匯總單個(gè)庫(kù)返回的結(jié)果，上層應(yīng)用做進(jìn)一步處理。一方面DAL全面支持各種case，實(shí)現(xiàn)很復(fù)雜；另一方面，從1號(hào)店實(shí)踐來(lái)看，這樣的例子不多，在上層應(yīng)用作針對(duì)性處理，更加靈活。
DAL可進(jìn)一步細(xì)分為JDBC和DAL兩層，基于JDBC層面實(shí)現(xiàn)分庫(kù)路由，系統(tǒng)開發(fā)難度大，靈活性低，目前也沒有很好的成功案例；一般是基于持久層框架進(jìn)一步封裝成DDAL(分布式數(shù)據(jù)訪問層)，實(shí)現(xiàn)分庫(kù)路由，1號(hào)店DAL即基于iBatis進(jìn)行上層封裝而來(lái)。
分頁(yè)處理
分庫(kù)后，有些分頁(yè)查詢需要遍歷所有庫(kù)，這些case是分庫(kù)最大的受害者L。
舉個(gè)分頁(yè)的例子，比如要求按時(shí)間順序展示某個(gè)商家的訂單，每頁(yè)100條記錄，由于是按商家查詢，需要遍歷所有數(shù)據(jù)庫(kù)，假設(shè)庫(kù)數(shù)量是8，我們來(lái)看下分頁(yè)處理邏輯：
如果取第1頁(yè)數(shù)據(jù)，則需要從每個(gè)庫(kù)里按時(shí)間順序取前100條記錄，8個(gè)庫(kù)匯總后有800條，然后對(duì)這800條記錄在應(yīng)用里進(jìn)行二次排序，最后取前100條。
如果取第10頁(yè)數(shù)據(jù)，則需要從每個(gè)庫(kù)里取前1000(10010)條記錄，匯總后有8000條記錄，然后對(duì)這8000條記錄二次排序后取（900,1000）條記錄。
分庫(kù)情況下，對(duì)于第k頁(yè)記錄，每個(gè)庫(kù)要多取100(k-1)條記錄，所有庫(kù)加起來(lái)，多取的記錄更多，所以越是靠后的分頁(yè)，系統(tǒng)要耗費(fèi)更多內(nèi)存和執(zhí)行時(shí)間。
對(duì)比沒分庫(kù)的情況，無(wú)論取那一頁(yè)，都只要從單個(gè)DB里取100條記錄，而且無(wú)需在應(yīng)用內(nèi)部做二次排序，非常簡(jiǎn)單。
那如何解決分庫(kù)情況下的分頁(yè)問題呢？有以下幾種辦法：
如果是在前臺(tái)應(yīng)用提供分頁(yè)，則限定用戶只能看前面n頁(yè)，這個(gè)限制在業(yè)務(wù)上也是合理的，一般看后面的分頁(yè)意義不大（如果一定要看，可以要求用戶縮小范圍重新查詢）。
如果是后臺(tái)批處理任務(wù)要求分批獲取數(shù)據(jù)，則可以加大page size，比如每次獲取5000條記錄，有效減少分頁(yè)數(shù)（當(dāng)然離線訪問一般走備庫(kù)，避免沖擊主庫(kù)）。
分庫(kù)設(shè)計(jì)時(shí)，一般還有配套大數(shù)據(jù)平臺(tái)匯總所有分庫(kù)的記錄，有些分頁(yè)查詢可以考慮走大數(shù)據(jù)平臺(tái)。
Lookup映射
分庫(kù)字段只有一個(gè)，比如這里是用戶Id，但訂單表還有其他字段可唯一區(qū)分記錄，比如訂單Id，給定一個(gè)訂單Id，相應(yīng)記錄一定在某個(gè)庫(kù)里。如果盲目地查詢所有分庫(kù)，則帶來(lái)不必要的開銷，Lookup映射可根據(jù)訂單Id，找到相應(yīng)的用戶Id，從而實(shí)現(xiàn)單庫(kù)定位。
可以事先檢索所有訂單Id和用戶Id，保存在Lookup表里，Lookup表的記錄數(shù)和訂單庫(kù)記錄總數(shù)相等，但它只有2個(gè)字段，所以存儲(chǔ)和查詢性能都不是問題。實(shí)際使用時(shí)，一般通過分布式緩存來(lái)優(yōu)化Lookup性能。對(duì)于新增的訂單，除了寫訂單表，同時(shí)要寫Lookup表。
整體架構(gòu)
訂單生成水平分庫(kù)的總體技術(shù)架構(gòu)如下圖所示：
上層應(yīng)用通過訂單服務(wù)/分庫(kù)代理和DAL訪問數(shù)據(jù)庫(kù)。
代理對(duì)訂單服務(wù)實(shí)現(xiàn)功能透明，包括聚合運(yùn)算，非用戶Id到用戶Id的映射。
Lookup表用于訂單Id/用戶Id映射，保證按訂單Id訪問時(shí)，可以直接落到單個(gè)庫(kù)，Cache是Lookup的內(nèi)存數(shù)據(jù)映像，提升性能，cache故障時(shí)，直接訪問Lookup表。
DAL提供庫(kù)的路由，根據(jù)用戶Id定位到某個(gè)庫(kù)，對(duì)于多庫(kù)訪問，DAL支持可選的并發(fā)訪問模式，并支持簡(jiǎn)單記錄匯總。
Lookup表初始化數(shù)據(jù)來(lái)自于現(xiàn)有分庫(kù)數(shù)據(jù)，新增記錄時(shí)，直接由代理異步寫入。
上線步驟
訂單表是核心業(yè)務(wù)表，它的水平拆分影響很多業(yè)務(wù)，本身的技術(shù)改造也很大，很容易出紕漏，上線時(shí)，必須謹(jǐn)慎考慮，整個(gè)方案實(shí)施過程如下：
首先實(shí)現(xiàn)Oracle和MySQL兩套庫(kù)并行，所有數(shù)據(jù)訪問指向Oracle庫(kù)，通過數(shù)據(jù)同步程序把數(shù)據(jù)從Oracle拆分到多個(gè)MySQL分庫(kù)，比如3分鐘增量同步一次。
按照上述架構(gòu)圖搭建整個(gè)體系，選擇幾個(gè)對(duì)數(shù)據(jù)實(shí)時(shí)性不高的訪問例子（如訪問歷史訂單），轉(zhuǎn)向MySQL分庫(kù)訪問，然后逐漸增加更多非實(shí)時(shí)case，以檢驗(yàn)整套體系可行性。
如果性能和功能都沒問題，再一次性把所有實(shí)時(shí)讀寫訪問轉(zhuǎn)向MySQL，廢棄Oracle。
這個(gè)上線步驟多了數(shù)據(jù)同步程序的開發(fā)（大約1人周工作量，風(fēng)險(xiǎn)很低），但分散了風(fēng)險(xiǎn)，把第一步的技術(shù)風(fēng)險(xiǎn)（Lookup/DAL等基礎(chǔ)設(shè)施改造）和第二步的業(yè)務(wù)功能風(fēng)險(xiǎn)（Oracle改MySQL語(yǔ)法）分開。兩階段上線都是一次性成功，特別是第二階段上線，100多個(gè)依賴方應(yīng)用簡(jiǎn)單重啟即完成升級(jí)，中間沒有出現(xiàn)一例較大問題。
文章來(lái)源網(wǎng)絡(luò)，對(duì)文章有所疑問可以通過私信解決。
在此推薦：個(gè)人整理了學(xué)習(xí)資料以PDF文件的形式分享給大家，需要查閱的程序員朋友可以來(lái)免費(fèi)領(lǐng)取。還有我的學(xué)習(xí)筆記PDF文件也免費(fèi)分享給有需要朋友！Java高級(jí)架構(gòu)學(xué)習(xí)資料分享+架構(gòu)師成長(zhǎng)之路?
