?

杭州湖畔網(wǎng)絡(luò)技術(shù)有限公司是一家專業(yè)提供SaaS化電商ERP服務(wù)的創(chuàng)業(yè)公司，主要用戶群體為經(jīng)營淘寶、天貓、京東等主流電商平臺、自建商城、線下渠道的商家及中小企業(yè)。作為SaaS服務(wù)提供商，服務(wù)數(shù)萬乃至數(shù)十萬級用戶是業(yè)務(wù)架構(gòu)初期就必須考慮的問題。龐大的用戶群以及海量的用戶數(shù)據(jù)意味著基礎(chǔ)設(shè)施的構(gòu)建必須兼顧高效與穩(wěn)定，而按照通用的基礎(chǔ)設(shè)施建設(shè)方案的話，需要面對成本過高、實(shí)現(xiàn)復(fù)雜、需要投入太多精力等問題，這對當(dāng)時(shí)的湖畔網(wǎng)絡(luò)這樣的初創(chuàng)公司來說，完全不能承受。因此，更經(jīng)濟(jì)、更方便擴(kuò)展的云服務(wù)平臺成為首選。在對比現(xiàn)有各家云服務(wù)后，我們選擇了穩(wěn)定性與成熟度都經(jīng)過大量用戶檢驗(yàn)的阿里云。

但要構(gòu)建高性能的SaaS應(yīng)用，僅憑云服務(wù)基礎(chǔ)設(shè)施是不夠的。如何基于云服務(wù)平臺設(shè)計(jì)并實(shí)施符合自身業(yè)務(wù)特點(diǎn)的系統(tǒng)架構(gòu)，也是決定產(chǎn)品性能的關(guān)鍵。本文將講述我們?nèi)绾卫迷品?wù)，使用相對經(jīng)濟(jì)的方案，解決海量用戶的數(shù)據(jù)庫使用問題。

架構(gòu)

我們的SaaS化電商ERP服務(wù)的整體架構(gòu)是基于阿里云服務(wù)平臺實(shí)施的，如圖1所示。

圖1 ?系統(tǒng)架構(gòu)精簡示意圖

通過該方案，不僅發(fā)揮了阿里云的優(yōu)勢（不涉及物理機(jī)器的維護(hù)和折損，靈活地配置升級，成熟的備份與快照方案），而且通過集群，避免了系統(tǒng)可能會遇到的單點(diǎn)故障，提高了系統(tǒng)彈性擴(kuò)容的靈活性和可用性。

作為一個(gè)SaaS化、數(shù)據(jù)更集中、數(shù)據(jù)體量龐大的企業(yè)應(yīng)用，數(shù)據(jù)庫是我們整體架構(gòu)中的關(guān)鍵節(jié)點(diǎn)，如何保證其穩(wěn)定與性能，是本文講述的重點(diǎn)。

當(dāng)用戶進(jìn)入快速增長期后，隨著業(yè)務(wù)量迅速增加，核心業(yè)務(wù)表的存量數(shù)據(jù)和增長速度絕對不是單個(gè)DB所能承受的（幾乎所有單DB配置都存在性能物理上限瓶頸，即使選擇升級配置也會受到成本和資源上限的約束）。因此，我們一開始就將數(shù)據(jù)庫分庫分片（Sharding）作為一個(gè)可行方案優(yōu)先考慮，主要分析如下。

考慮到業(yè)務(wù)特性，我們最終采用了行業(yè)比較通用的水平拆分+垂直拆分策略，并自主完成DAO與JDBC之間的數(shù)據(jù)訪問封裝層開發(fā)工作。

水平拆分：按用戶將數(shù)據(jù)拆分到多個(gè)庫的相同表中

水平拆分的思路，就是將原本存放在單個(gè)RDS數(shù)據(jù)庫中的數(shù)據(jù)，根據(jù)業(yè)務(wù)ID不同，拆分到多個(gè)數(shù)據(jù)庫中（參見圖2）。拆分后，各庫的表數(shù)量及表結(jié)構(gòu)都保持一致。水平拆分首先需要確立唯一的業(yè)務(wù)主表，即其他所有表的數(shù)據(jù)都與主表ID（前文所說的業(yè)務(wù)ID）存在直接或間接的主從關(guān)系，可以通過主表ID對全部數(shù)據(jù)做很好的切分。我們選擇的業(yè)務(wù)主表為用戶表，其他業(yè)務(wù)表或表的父表都包含一個(gè)用戶ID。因此，我們切分的目標(biāo)就是將不同用戶數(shù)據(jù)存放到不同的數(shù)據(jù)庫中。

圖2 ?水平拆分示意圖

確定了拆分規(guī)則后，下一步是著手封裝Sping數(shù)據(jù)訪問封裝層（DBWrapper）。DBWrapper介于DAO與JDBC之間，每個(gè)業(yè)務(wù)DAO進(jìn)行數(shù)據(jù)庫基本操作，都會經(jīng)過DBWrapper。它的主要作用是將數(shù)據(jù)庫架構(gòu)的變化對業(yè)務(wù)層透明，業(yè)務(wù)層可以如同操作單個(gè)DB一樣，調(diào)用DBWrapper提供的數(shù)據(jù)庫操作接口，而判斷操作哪個(gè)數(shù)據(jù)庫的邏輯，則全部交由DBWrapper封裝完成（參見圖3）。?

圖3 ?水平拆分架構(gòu)示意圖

DBWrapper主要提供新用戶初始化和數(shù)據(jù)庫操作接口。在新增用戶初始化到系統(tǒng)時(shí)，需先動(dòng)態(tài)判斷系統(tǒng)各庫的負(fù)載分布情況。粗略一點(diǎn)的算法就是判斷各庫的用戶數(shù)，如共有4個(gè)庫，可以根據(jù)user_id%4的情況決定目標(biāo)庫；再精細(xì)一點(diǎn)可以挖掘下核心業(yè)務(wù)數(shù)據(jù)的分布情況，具體分配算法需要基于業(yè)務(wù)設(shè)定（如考慮不同用戶的平均訂單量）。通過各庫壓力綜合計(jì)算后，分析出壓力最小的目標(biāo)數(shù)據(jù)庫，并將該新增用戶數(shù)據(jù)存放到指定的目標(biāo)庫，同時(shí)更新路由信息（Router）。

當(dāng)用戶完成初始化進(jìn)行業(yè)務(wù)操作時(shí)，則需由業(yè)務(wù)層調(diào)用DBWrapper的操作接口。DBWrapper接收到請求后，會根據(jù)業(yè)務(wù)層傳入的User_id匹配Router，判斷最終需要操作的RDS實(shí)例和數(shù)據(jù)庫。判斷完成后，只需要按部就班地開連接執(zhí)行就可以了。具體的代碼實(shí)現(xiàn)，需要結(jié)合自身的持久層框架，找一名研究過持久層框架實(shí)現(xiàn)的開發(fā)人員即可完成。

這樣就將系統(tǒng)用戶整體數(shù)據(jù)壓力，相對均勻地分布到多個(gè)RDS實(shí)例與數(shù)據(jù)庫上。事實(shí)證明，這確實(shí)是一個(gè)非常有效的方案，尤其是對于數(shù)據(jù)量大、增長迅猛的表。只是在后續(xù)實(shí)施過程中，我們發(fā)現(xiàn)有時(shí)會有單個(gè)用戶的業(yè)務(wù)壓力比較突出，針對這種情況，我們可以通過一些人工干預(yù)（如遷移數(shù)據(jù)到單獨(dú)的庫）進(jìn)行微調(diào)，當(dāng)然最終的解決方案還是要不斷調(diào)優(yōu)路由算法。

切分后，不可避免地需要考慮數(shù)據(jù)字典（DD）和數(shù)據(jù)路由（Router）的處理。暫時(shí)我們采用的方法是將所有數(shù)據(jù)字典與路由放入獨(dú)立的庫，這也是后文中垂直拆分的一種應(yīng)用。需要說明的是，數(shù)據(jù)庫僅是這兩個(gè)業(yè)務(wù)的一種實(shí)現(xiàn)方式，一般還可以通過或結(jié)合分布式緩存來處理這些業(yè)務(wù)（我們選用了OCS）。而對于可能出現(xiàn)的單點(diǎn)障礙，預(yù)留的擴(kuò)展方案為水平拆分或創(chuàng)建只讀節(jié)點(diǎn)（只讀節(jié)點(diǎn)可以使用RDS最新提供的只讀實(shí)例，目前還在內(nèi)測階段）。

垂直拆分：按業(yè)務(wù)將表分組拆分到多個(gè)庫中

與水平拆分相比，垂直拆分要更簡單一些。其基本思路就是將存放在單個(gè)數(shù)據(jù)庫的表分組，把其中業(yè)務(wù)耦合度較高、聯(lián)系緊密的表分為一組，拆分到其他DB中（參見圖4）。拆分后，各庫的表結(jié)構(gòu)及其業(yè)務(wù)意義將完全不同。雖然規(guī)則簡單、實(shí)施方便，但垂直拆分總是需打斷些關(guān)聯(lián)，因?yàn)閷?shí)際操作中，基礎(chǔ)資源常常出現(xiàn)在各個(gè)業(yè)務(wù)場景，在切分時(shí)又不得不切分到兩個(gè)庫中，此時(shí)就需要業(yè)務(wù)層多次查詢后，在內(nèi)存處理數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)庫Join的效果。

圖4 ?垂直拆分示意圖

垂直拆分同樣需要DBWrapper，但封裝規(guī)則與水平拆分略有不同，需要針對不同的業(yè)務(wù)，建立不同的DBWrapper。此時(shí)不再是完全業(yè)務(wù)層無感知，需要業(yè)務(wù)層根據(jù)業(yè)務(wù)場景有針對性使用。單個(gè)DBWrapper的實(shí)現(xiàn)與水平拆分一致。

垂直拆分的好處在于，將整體業(yè)務(wù)數(shù)據(jù)切分成相對獨(dú)立的幾塊，隔離了不同業(yè)務(wù)之間的性能影響。而由于拆分后的數(shù)據(jù)庫業(yè)務(wù)比較集中，也更容易找到業(yè)務(wù)主表，更有利于水平拆分。

對于垂直拆分，目前我們主要用于解決數(shù)據(jù)路由（包含了用戶的基本信息）、數(shù)據(jù)字典模塊，以及常見的冷數(shù)據(jù)問題。冷數(shù)據(jù)的處理一直是行業(yè)的常見問題（其實(shí)對于冷數(shù)據(jù)的劃分，也是水平拆分），目前我們采用的方案是集中存儲，即按自己的冷數(shù)據(jù)切分方式，通過自行開發(fā)的遷移程序?qū)⑴卸ǖ睦鋽?shù)據(jù)增量遷移到一個(gè)庫中。這個(gè)方案既能夠分離冷數(shù)據(jù)對熱點(diǎn)數(shù)據(jù)的操作影響，也可以為大數(shù)據(jù)的挖掘提供比較便利的條件。使用相對獨(dú)立的冷數(shù)據(jù)存儲結(jié)構(gòu)，能方便以后采用更高效、成本更低廉的存儲介質(zhì)。當(dāng)然該方案存在一些潛在問題，如果冷數(shù)據(jù)庫滿了該怎么辦？目前我們預(yù)留的設(shè)計(jì)方案是，歷史庫的水平拆分，也可以考慮其他存儲形式。

水平拆分與垂直拆分組合使用

拆分一直是數(shù)據(jù)庫優(yōu)化的關(guān)鍵詞（無論是庫表結(jié)構(gòu)還是SQL寫法），它是每個(gè)高并發(fā)產(chǎn)品最終都要經(jīng)歷的一步。拆分方案的核心主要在于可以通過添加更多RDS實(shí)例和數(shù)據(jù)庫（常常為了節(jié)約成本，多個(gè)數(shù)據(jù)庫可以部署在一個(gè)RDS實(shí)例上），靈活擴(kuò)容系統(tǒng)的負(fù)載能力。在數(shù)據(jù)庫架構(gòu)中，水平拆分和垂直拆分一般都是搭配使用的，兩者的先后順序視具體情況而定。一般而言，垂直拆分更容易，也可以為水平拆分做鋪墊，一是業(yè)務(wù)集中，便于提取主表，二是垂直拆分后，可以只水平拆分壓力高的表，而業(yè)務(wù)增長緩慢的表則可以保留單DB，從而提高拆分效率以及降低實(shí)施成本（參見圖5）。

圖5 ?數(shù)據(jù)庫Sharding方案示意圖?

我們之所以優(yōu)先水平拆分，主要原因還是成本和效率及當(dāng)時(shí)的一些局限性。只按業(yè)務(wù)ID（用戶）做好路由配置，這樣各個(gè)庫中的結(jié)構(gòu)完全一致，保留了原本的業(yè)務(wù)邏輯與實(shí)現(xiàn)，避免了跨庫關(guān)聯(lián)，能大大節(jié)省實(shí)現(xiàn)成本。

盡管拆分有種種好處，但由于分布式事務(wù)及跨庫Join的實(shí)現(xiàn)復(fù)雜度較高及可用性較差，所以分布式事務(wù)一般都通過業(yè)務(wù)層使用樂觀鎖控制。而跨庫的表間關(guān)聯(lián)一定要打斷，否則性能和實(shí)現(xiàn)復(fù)雜度都會超出可接受范圍。對于跨庫的Join、Group by等問題，都需要在業(yè)務(wù)層處理。目前我們采用的是分批查詢，在業(yè)務(wù)層組裝結(jié)果的方式。

有些遺憾的是，由于我們早期使用RDS時(shí)，阿里云尚未推出DRDS（分布式數(shù)據(jù)庫）產(chǎn)品，所以上述拆分的數(shù)據(jù)庫底層架構(gòu)均是由我們自行研發(fā)的，投入了大量的精力。而現(xiàn)在有了DRDS，正準(zhǔn)備做拆分的團(tuán)隊(duì)，則無需再自己造輪子，直接拿來用即可，這樣團(tuán)隊(duì)可以將更多的精力放在業(yè)務(wù)上。

小處大有可為

雖然我們在架構(gòu)上做了優(yōu)化，但在產(chǎn)品發(fā)展過程中還是會出現(xiàn)性能不太理想的情況。在阿里云支持中心和論壇上，也可以看到其他業(yè)務(wù)型團(tuán)隊(duì)反饋使用RDS時(shí)遇到類似的情況。最初大家都懷疑是不是RDS的底層資源隔離有問題，多個(gè)用戶共享資源時(shí)發(fā)生爭搶，導(dǎo)致RDS的性能問題。但在阿里云DBA的指導(dǎo)和協(xié)助下，發(fā)現(xiàn)是由于產(chǎn)品設(shè)計(jì)時(shí)對數(shù)據(jù)庫的使用太“不拘小節(jié)”，而隨著并發(fā)壓力與數(shù)據(jù)量增加，大量細(xì)小的性能問題被放大，集中暴露出來。

解決燈下黑：修正業(yè)務(wù)層的數(shù)據(jù)庫操作陋習(xí)

在數(shù)據(jù)庫的優(yōu)化過程中，研發(fā)團(tuán)隊(duì)最容易忽視的往往是業(yè)務(wù)層中的數(shù)據(jù)庫使用。一些優(yōu)化方案可以作為開發(fā)的常態(tài)化準(zhǔn)則。下面僅列舉幾個(gè)常用的優(yōu)化方案。

擠掉海綿里的水：優(yōu)化數(shù)據(jù)庫執(zhí)行計(jì)劃

由于執(zhí)行計(jì)劃的優(yōu)化往往涉及到數(shù)據(jù)庫的運(yùn)行機(jī)制與底層設(shè)計(jì)，此處實(shí)難三言兩語說清。所以下面僅列舉幾個(gè)我們受益頗深的優(yōu)化方案。建議大家優(yōu)化執(zhí)行計(jì)劃時(shí)，多關(guān)注、分析iDB Cloud控制臺中的性能報(bào)告和建議，也盡量多向阿里云DBA們請教，一般可以通過提工單的方式。有條件或興趣的話，DBA可以通過預(yù)約到阿里云現(xiàn)場學(xué)習(xí)。另外，執(zhí)行計(jì)劃的優(yōu)化需要大量的調(diào)試工作，通過在阿里云控制臺創(chuàng)建生產(chǎn)數(shù)據(jù)庫的臨時(shí)實(shí)例，可以準(zhǔn)確模擬當(dāng)前系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)、分布與壓力。

字段類型選擇

選擇合理的字段，往往可以大大減少數(shù)據(jù)庫行數(shù)據(jù)的大小，并提高索引匹配的效率，進(jìn)而大大提升數(shù)據(jù)庫性能。使用更小的數(shù)據(jù)類型，如日期采用date代替datetime、類型或標(biāo)記使用tinyint代替smallint和int、使用定長字段代替非定長字段（如char代替varchar），都能或多或少減少數(shù)據(jù)行大小，提高數(shù)據(jù)庫緩沖池的命中率。而作為表字段中特殊的一員—主鍵，其選型更會對表索引的穩(wěn)定和效率帶來很大的影響，一般建議考慮數(shù)據(jù)庫自增或自主維護(hù)的唯一數(shù)值。

高分離度字段建立索引

對于查詢來講，高分離度字段往往意味著精準(zhǔn)或部分精準(zhǔn)的條件。相對來講是最好優(yōu)化的一種場景，只需要對分離度較高的字段單獨(dú)建立索引即可。當(dāng)然實(shí)際使用中會有更多細(xì)節(jié)需要摸索。精確條件在各業(yè)務(wù)中基本都會用到，在越復(fù)雜的業(yè)務(wù)場景中，精確條件優(yōu)先的原則，將是最有效的優(yōu)化方案。需要注意的是，盡管高分離度字段單獨(dú)建立索引效率很高，但過多的索引會影響表寫入的效率，所以需要謹(jǐn)慎添加。這一點(diǎn)iDB Cloud中有大表索引的建議可以參考。

覆蓋索引（Covering Index）

通俗一點(diǎn)理解，就是執(zhí)行計(jì)劃可以通過索引完成數(shù)據(jù)查找和結(jié)果集獲取，而無需回表（去緩沖池或磁盤查找數(shù)據(jù)）。而由于MySQL的索引機(jī)制限制，一次查詢時(shí)，將只用到一個(gè)索引或?qū)蓚€(gè)索引聚合（index_merge）起來使用，所以意味著復(fù)雜的業(yè)務(wù)場景中，單獨(dú)對每個(gè)字段建立索引可能沒有什么用處。所以對于一些特定的查詢場景，建立合適的組合索引，應(yīng)用覆蓋索引方法可以避免大量隨機(jī)I/O，是更為推薦的優(yōu)化方案（如果執(zhí)行計(jì)劃Explain的Extra中有Using Index，就說明使用了覆蓋索引）。但實(shí)際業(yè)務(wù)總是會比索引本身更復(fù)雜，業(yè)務(wù)中需要查找或者獲取的字段信息往往是很多的，而組合索引并不能涵蓋所有的字段（否則我們將擁有一個(gè)比數(shù)據(jù)還要龐大的索引）。此時(shí)，為了應(yīng)用覆蓋索引，就需要使用主鍵延遲關(guān)聯(lián)（Deferred Join），即先通過組合索引中包含的字段條件，初步查詢出相對較小的結(jié)果集（面向結(jié)果集原則），該結(jié)果集只包含主鍵字段；然后通過獲取到的這個(gè)主鍵隊(duì)列，再對數(shù)據(jù)表做關(guān)聯(lián)。

適當(dāng)妥協(xié)

見招拆招：升配置

一般業(yè)務(wù)型的研發(fā)團(tuán)隊(duì)，很難有額外的精力投入到數(shù)據(jù)庫方面，也沒有專業(yè)的DBA來不斷調(diào)優(yōu)數(shù)據(jù)庫配置、優(yōu)化數(shù)據(jù)庫服務(wù)器性能。所以早期團(tuán)隊(duì)可以選擇的方案不多，也很難在技術(shù)上深挖下去，只能用成本換時(shí)間：性能配置不夠，那就升級服務(wù)器配置。

那么問題來了：自己部署的數(shù)據(jù)庫要升級配置，除了調(diào)整數(shù)據(jù)庫配置參數(shù)，還會受到物理機(jī)的限制，因此就要考慮更加復(fù)雜的數(shù)據(jù)庫備份和同步策略。但這是業(yè)務(wù)團(tuán)隊(duì)所不能接受，甚至短期內(nèi)無法實(shí)現(xiàn)的，升配置也就變成了一個(gè)復(fù)雜的問題。不過我們使用了RDS，其彈性升級策略，正是這個(gè)問題的最佳解決方案。

二八原則

在長期的數(shù)據(jù)庫乃至整個(gè)產(chǎn)品的優(yōu)化過程中，我感受最深刻的就是：完美的方案可遇不可求。選擇方案時(shí)，如果能解決80%的問題，并規(guī)避或保留剩下的20%，則將大大提升團(tuán)隊(duì)的整體效率。產(chǎn)品與架構(gòu)都是在不斷優(yōu)化演變的，我們要循序漸進(jìn)、不斷努力，將今天的終點(diǎn)留作明天的起點(diǎn)。

總結(jié)與展望

作為一位創(chuàng)業(yè)公司的技術(shù)開發(fā)人員，通過實(shí)際使用阿里云產(chǎn)品，我總結(jié)了幾點(diǎn)關(guān)于使用云計(jì)算產(chǎn)品的優(yōu)勢。

1. 便利的服務(wù)器彈性升級功能，可隨時(shí)應(yīng)付像“雙十一”這樣的大促。而通過使用傳統(tǒng)IDC托管模式，物理機(jī)的維護(hù)、升級以及升級后的數(shù)據(jù)遷移都是比較頭疼的。

2. 成熟可靠的數(shù)據(jù)備份與快照、數(shù)據(jù)庫主從分離與同步的底層方案。創(chuàng)業(yè)團(tuán)隊(duì)無須承受自己造輪子的代價(jià)，可專注于業(yè)務(wù)開發(fā)。

3. 云計(jì)算產(chǎn)品經(jīng)過檢驗(yàn)、值得信賴的安全防護(hù)。

4. 精簡了創(chuàng)業(yè)團(tuán)隊(duì)人員規(guī)模。云計(jì)算平臺具備專業(yè)的技術(shù)支持與服務(wù)，使得創(chuàng)業(yè)團(tuán)隊(duì)不再需要數(shù)據(jù)庫和服務(wù)器管理員。

除了使用云產(chǎn)品的心得，數(shù)據(jù)庫調(diào)優(yōu)實(shí)踐是本文的重點(diǎn)。在數(shù)據(jù)庫的架構(gòu)設(shè)計(jì)與性能優(yōu)化方面，我秉承的原則是解決主要問題，按先分而擊之、再挖掘細(xì)節(jié)的步驟，周返往復(fù)不斷進(jìn)行，同時(shí)系統(tǒng)架構(gòu)也在這個(gè)過程中不斷演變。相信隨著時(shí)間推移，會有更多優(yōu)秀的方案出現(xiàn)。尤其隨著云服務(wù)不斷發(fā)展，業(yè)務(wù)研發(fā)團(tuán)隊(duì)投入到基礎(chǔ)設(shè)施的精力與成本，將會無限減少。會有越來越多專注于業(yè)務(wù)研發(fā)的團(tuán)隊(duì)，推出更多優(yōu)秀的互聯(lián)網(wǎng)產(chǎn)品，用互聯(lián)網(wǎng)服務(wù)推動(dòng)企業(yè)創(chuàng)新，重塑中小企業(yè)信息化形態(tài)。?

?

• 采用SLB（Server Load Balance，負(fù)載均衡）作為Web集群訪問入口，負(fù)責(zé)為Web端的多臺服務(wù)器進(jìn)行流量分發(fā)。SLB是基于集群建設(shè)的，并且可以隨時(shí)變配，按量付費(fèi)。它不僅為我們實(shí)現(xiàn)了成熟的負(fù)載均衡方案，其穩(wěn)定性與靈活性也為Web集群提供了更多可能。
• 后端配置多臺ECS（Elastic Compute Service，云服務(wù)器）實(shí)例，將主要應(yīng)用服務(wù)都部署在ECS上。除了可彈性擴(kuò)容這一特性，ECS提供的安全防護(hù)和快照備份為服務(wù)器安全和容災(zāi)提供了非常成熟的解決方案，這恰恰是我們這種業(yè)務(wù)型創(chuàng)業(yè)團(tuán)隊(duì)積累相對最薄弱的方面。另外，ECS多線接入骨干網(wǎng)絡(luò)能保證網(wǎng)絡(luò)的穩(wěn)定和性能，使得任何網(wǎng)絡(luò)的用戶訪問應(yīng)用服務(wù)都非常順暢。
• DB集群由多臺RDS（Relational Database Service，關(guān)系型數(shù)據(jù)庫服務(wù)）實(shí)例組成。RDS是云數(shù)據(jù)庫，簡單易用，使用方法與自行部署的數(shù)據(jù)庫完全一樣。其成熟的雙機(jī)熱備與底層資源隔離，保證了我們這兩年來數(shù)據(jù)庫的平穩(wěn)運(yùn)行。另外，強(qiáng)大的iDB Cloud控制臺、專業(yè)的DBA團(tuán)隊(duì)支持，為我們監(jiān)控?cái)?shù)據(jù)庫運(yùn)行狀況、定位和解決數(shù)據(jù)庫問題，提供了非常多的建議和幫助。
• 集群之間的共享資源統(tǒng)一存放在OCS（Open Cache Service，開放緩存服務(wù)）中。我們用OCS來存放數(shù)據(jù)路由和實(shí)時(shí)性不高的業(yè)務(wù)數(shù)據(jù)。緩存作為我們架構(gòu)性能中非常重要的一個(gè)環(huán)節(jié)，在承受了來自整個(gè)集群各方面壓力的同時(shí)，還要保證響應(yīng)穩(wěn)定高速。

• 場景：業(yè)務(wù)熱點(diǎn)數(shù)據(jù)持續(xù)增加，團(tuán)隊(duì)有一定的數(shù)據(jù)庫架構(gòu)積累能支撐獨(dú)立研發(fā)或熟悉成熟的中間件（如Cobar）。
• 優(yōu)點(diǎn)：成本低（可以利用開源免費(fèi)的數(shù)據(jù)庫集群替代大型商業(yè)DB）；可靈活擴(kuò)容（不斷增加新的數(shù)據(jù)庫切片即可）；相對均勻分布的數(shù)據(jù)讀寫，避免單點(diǎn)障礙。
• 缺點(diǎn)：需要研發(fā)團(tuán)隊(duì)在數(shù)據(jù)庫架構(gòu)上投入大量精力；數(shù)據(jù)庫集群維護(hù)需要成本投入。

• 場景：數(shù)據(jù)庫性能有問題，應(yīng)優(yōu)先從業(yè)務(wù)層分析。
• 優(yōu)點(diǎn)：減輕數(shù)據(jù)庫的直接壓力，比執(zhí)行數(shù)據(jù)庫優(yōu)化方案更加迅速有效。
• 缺點(diǎn)：業(yè)務(wù)研發(fā)需要關(guān)注一些數(shù)據(jù)庫操作內(nèi)容；有時(shí)會犧牲一些業(yè)務(wù)；產(chǎn)品規(guī)模越大實(shí)施越困難。

• 延遲加載。很多頁面展現(xiàn)時(shí)，單個(gè)實(shí)體實(shí)際只展現(xiàn)部分內(nèi)容，因此可按需加載，減輕數(shù)據(jù)庫壓力，又節(jié)省網(wǎng)絡(luò)流量。延遲加載也可體現(xiàn)在數(shù)據(jù)庫表的拆分設(shè)計(jì)上。
• 適當(dāng)緩存，以空間換時(shí)間。對于很多實(shí)時(shí)性較低或干脆就是數(shù)據(jù)字典的內(nèi)容，無需實(shí)時(shí)到數(shù)據(jù)庫中加載，只需在使用前加載到內(nèi)存中，實(shí)際使用時(shí)到內(nèi)存中獲取即可。
• 減少不必要的開連接（連接池、批量查詢及提交）。對于大部分的Web應(yīng)用，連接池大大減少了系統(tǒng)因開數(shù)據(jù)庫連接產(chǎn)生的開銷。而在查詢和提交中，將多個(gè)任務(wù)合并到一次數(shù)據(jù)庫操作中，也可以大大提高數(shù)據(jù)庫使用效率。
• 樂觀鎖是高并發(fā)下不錯(cuò)的解決方式。相比于數(shù)據(jù)庫的悲觀鎖，業(yè)務(wù)層實(shí)現(xiàn)的樂觀鎖，不僅能減少鎖爭搶，還可以減少數(shù)據(jù)庫的鎖開銷，進(jìn)而提高數(shù)據(jù)庫使用效率。
• 分解大事務(wù)。數(shù)據(jù)庫對于大事務(wù)的原子性保證，也是不容忽視的開銷。業(yè)務(wù)使用時(shí)，盡量將大事務(wù)切分為小事務(wù)，或者適當(dāng)利用異步提交，精簡事務(wù)體積。
• 合理使用Join。數(shù)據(jù)庫執(zhí)行計(jì)劃中，有一條準(zhǔn)則是越簡單越快速。所以通過適當(dāng)冗余數(shù)據(jù)設(shè)計(jì)或業(yè)務(wù)層分批查詢后內(nèi)存組裝數(shù)據(jù)，減少數(shù)據(jù)庫Join語句及SQL復(fù)雜度，對于數(shù)據(jù)庫執(zhí)行效率和執(zhí)行計(jì)劃的優(yōu)化都有不可忽視的好處。

• 場景：并發(fā)不多、數(shù)據(jù)量并不很大，或系統(tǒng)整體壓力較低，只有某幾個(gè)業(yè)務(wù)點(diǎn)性能較差。
• 優(yōu)點(diǎn)：在不改變基本條件的情況下，挖掘數(shù)據(jù)庫更大潛力。
• 缺點(diǎn)：需要DBA協(xié)助或研發(fā)團(tuán)隊(duì)對數(shù)據(jù)庫執(zhí)行計(jì)劃做研究。

• 場景：性能問題緊迫，團(tuán)隊(duì)時(shí)間資源有限。
• 優(yōu)點(diǎn)：簡單粗暴見效快，基本適用于任何優(yōu)化階段。
• 缺點(diǎn)：增加成本；治標(biāo)不治本，只是延遲問題再次爆發(fā)時(shí)間；資源總有上限，遲早升無可升。

轉(zhuǎn)載于:https://www.cnblogs.com/SUNSHINEC/p/8617989.html

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的数据库拆分案例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。