背景

之前做過(guò)一個(gè)項(xiàng)目，數(shù)據(jù)庫(kù)存儲(chǔ)采用的是mysql。當(dāng)時(shí)面臨著業(yè)務(wù)指數(shù)級(jí)的增長(zhǎng)，存儲(chǔ)容量不足。當(dāng)時(shí)采用的措施是

1>短期解決容量的問(wèn)題

mysql從5.6升級(jí)5.7，因?yàn)閿?shù)據(jù)核心且重要，數(shù)據(jù)庫(kù)主從同步采用的是全同步， 利用5.7并行復(fù)制新特性，減少了主從同步的延遲，提高了吞吐量。

當(dāng)時(shí)業(yè)務(wù)量高峰是2000TPS，5.6時(shí)可承受的最大TPS是3000，升級(jí)到5.7壓測(cè)可承受的最大TPD是5000.

2>流量拆分，從根本上解決容量問(wèn)題

首先進(jìn)行容量評(píng)估，通過(guò)對(duì)于業(yè)務(wù)開(kāi)展規(guī)劃、活動(dòng)預(yù)估，年底的容量會(huì)翻5倍。由于目前指數(shù)級(jí)增長(zhǎng)的特性，數(shù)據(jù)庫(kù)要預(yù)留至少4倍的冗余。

要對(duì)數(shù)據(jù)庫(kù)進(jìn)行擴(kuò)容，因?yàn)槲覀円呀?jīng)使用的是最頂配的SSD物理機(jī)了，就算可以在linux內(nèi)核層面對(duì)numa進(jìn)行綁核和非綁核等測(cè)試調(diào)參優(yōu)化性能，提升容量也很有限。注意：一般的業(yè)務(wù)系統(tǒng)numa綁核會(huì)提高性能，但是mysql等數(shù)據(jù)庫(kù)系統(tǒng)是相反的。

所以垂直擴(kuò)容不成功，就看看是否可以拆分流量。mysql流量拆分方式有x軸拆分(水平拆分)、y軸拆分(垂直拆分)、z軸拆分。

其中y軸拆分(垂直拆分)就是目前都在說(shuō)做垂直領(lǐng)域，就是在一個(gè)細(xì)分領(lǐng)域里做深入的意思。由此可以很容易的記住垂直拆分的意思就是按照業(yè)務(wù)領(lǐng)域進(jìn)行拆分，專(zhuān)庫(kù)專(zhuān)用。實(shí)際上能按領(lǐng)域拆分是最理想的，因?yàn)檫@種拆分業(yè)務(wù)清晰；拆分規(guī)則明確；系統(tǒng)之間整合或擴(kuò)展容易。但是因?yàn)楫?dāng)時(shí)的業(yè)務(wù)已經(jīng)很簡(jiǎn)單，y軸拆分已經(jīng)沒(méi)有什么空間，這種拆分不能達(dá)到擴(kuò)容20倍的目的。

z軸拆分近幾年沒(méi)有聽(tīng)說(shuō)過(guò)了，實(shí)際上大家也一直在用。這種方式是將一張大表拆分為子母表，就是分為概要信息和詳細(xì)信息。這種拆分方式對(duì)解決容量問(wèn)題意義不大。

比較可行的一個(gè)方案是水平拆分。就是常說(shuō)的分庫(kù)分表。按照容量評(píng)估，數(shù)據(jù)庫(kù)水平拆分一拆十，根據(jù)業(yè)務(wù)特點(diǎn)找一個(gè)標(biāo)準(zhǔn)字段來(lái)進(jìn)行取模。

水平拆分一個(gè)技術(shù)點(diǎn)在于新老切換。

采用的是數(shù)據(jù)庫(kù)雙寫(xiě)的方式，采用異步確保性的補(bǔ)償型事務(wù)，發(fā)送實(shí)時(shí)和延遲兩個(gè)MQ，通過(guò)開(kāi)關(guān)來(lái)控制以老數(shù)據(jù)為準(zhǔn)還是新數(shù)據(jù)庫(kù)為準(zhǔn)。開(kāi)始時(shí)以老數(shù)據(jù)庫(kù)為準(zhǔn)，觀察新老數(shù)據(jù)沒(méi)有一致性問(wèn)題之后，在一個(gè)低峰期，關(guān)閉了系統(tǒng)入口，等數(shù)據(jù)庫(kù)沒(méi)有任何變更之后切換開(kāi)關(guān)，再打開(kāi)系統(tǒng)入口。

問(wèn)題

對(duì)于容量問(wèn)題，上面采用的是一次性拆分到位的方法。對(duì)于一個(gè)規(guī)模稍大的公司來(lái)講，10組物理機(jī)(1組包含1主N從)的成本還好。

1>如果量級(jí)再次升級(jí)，需要每周增加10臺(tái)數(shù)據(jù)庫(kù)才能支撐容量呢？

2>并且對(duì)系統(tǒng)可用性還有強(qiáng)要求，1s的停機(jī)都不可以接受呢？

解決方案分析

垂直流量拆分

首先我要分析的是每周增加10臺(tái)數(shù)據(jù)庫(kù)這個(gè)容量是不是合理的。是否存在放大效應(yīng)或者說(shuō)可以減少對(duì)mysql這種昂貴資源的使用，轉(zhuǎn)為增加對(duì)HBase、Elasticsearch這種低成本高擴(kuò)展性資源的使用呢？

基于這個(gè)思路，我們需要梳理下是否有可垂直拆分的流量。比如正向流量和負(fù)向流量。所謂正向流量是指比如交易下單，負(fù)向流量就是取消訂單，包括已付款取消、未付款取消、已到貨取消、未到貨取消等等。實(shí)際上負(fù)向流量在總訂單里占比很少，但是業(yè)務(wù)要比正向交易業(yè)務(wù)復(fù)雜。將正向和逆向拆分的一個(gè)主要優(yōu)勢(shì)是分治思想，可以降低兩部分各自的復(fù)雜度。將流量拆分重心轉(zhuǎn)移到正向流量上。

對(duì)于正向流量，一個(gè)業(yè)務(wù)比較常用的流量拆分思路是CQRS命令查詢(xún)分離，也就是常說(shuō)的讀寫(xiě)分離。如果讀流量大于寫(xiě)流量?？梢钥紤]能否將讀流量進(jìn)一步拆分。拆分成實(shí)時(shí)和離線(xiàn)，將實(shí)時(shí)性要求不高的查詢(xún)走ES。ES的數(shù)據(jù)可以通過(guò)同步binlog變更獲得。

另外一個(gè)思路是將數(shù)據(jù)庫(kù)按照歷史數(shù)據(jù)來(lái)拆分。就是數(shù)據(jù)庫(kù)里只保存一定時(shí)間內(nèi)的實(shí)時(shí)數(shù)據(jù)。超過(guò)指定時(shí)間則進(jìn)行數(shù)據(jù)歸檔。將數(shù)據(jù)歸檔到HBase等，一般對(duì)于歷史的查詢(xún)實(shí)時(shí)性要求也不是很高。

垂直流量拆分可能遇到的問(wèn)題

以上方法都是只考慮問(wèn)題1如果量級(jí)再次升級(jí)，需要每周增加10臺(tái)數(shù)據(jù)庫(kù)才能支撐容量的方案。如果再考慮問(wèn)題2并且對(duì)系統(tǒng)可用性還有強(qiáng)要求，1s的停機(jī)都不可以接受。就需要看上述方案可能會(huì)遇到的問(wèn)題。

拆分正向流量和負(fù)向流量、CQRS都需要改造，改造過(guò)程就需要過(guò)渡。過(guò)渡可以采用上面說(shuō)的雙寫(xiě)方式，觀察運(yùn)行情況進(jìn)行切換。切換過(guò)程中也可以不關(guān)閉流量。

麻煩的是數(shù)據(jù)歸檔。因?yàn)閿?shù)據(jù)歸檔后刪除數(shù)據(jù)庫(kù)的數(shù)據(jù)，變更生效時(shí)，針對(duì)innodb來(lái)說(shuō)，意味著數(shù)據(jù)結(jié)構(gòu)重建，頻繁IO。這會(huì)影響OLTP在線(xiàn)事務(wù)的處理?？梢钥紤]按表來(lái)歸檔，控制操作頻率，控制單位時(shí)間內(nèi)對(duì)IO的影響。

分布式關(guān)系型數(shù)據(jù)庫(kù)

分布式關(guān)系型數(shù)據(jù)庫(kù)本質(zhì)上是通過(guò)增加代理等方式將分庫(kù)分表做的更加隱蔽。

阿里巴巴分布式關(guān)系數(shù)據(jù)庫(kù)(DRDS)，前身是淘寶分布式數(shù)據(jù)層(TDDL)，核心就是用于分庫(kù)分表管理的代理層，宣稱(chēng)可實(shí)現(xiàn)平滑擴(kuò)容。

擴(kuò)容過(guò)程實(shí)際是物理數(shù)據(jù)遷移的過(guò)程，引擎層按照分庫(kù)遷移后的邏輯先在物理節(jié)點(diǎn)上建立新的分庫(kù)，然后保留一個(gè)時(shí)間點(diǎn)進(jìn)行全量的數(shù)據(jù)遷移。完成全量遷移后，開(kāi)始基于先前保留的時(shí)間點(diǎn)進(jìn)行增量的數(shù)據(jù)追趕。當(dāng)增量數(shù)據(jù)追趕到兩邊的數(shù)據(jù)幾乎一致時(shí)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行瞬時(shí)停寫(xiě)，將最后的數(shù)據(jù)追平，引擎層進(jìn)行分庫(kù)邏輯的路由切換，路由規(guī)則切換完成后就完成了核心的擴(kuò)容邏輯，整個(gè)切換過(guò)程在毫秒級(jí)別完成。

因?yàn)檎麄€(gè)過(guò)程是毫秒級(jí)，所以可以做到業(yè)務(wù)層沒(méi)有感知，等多就是看到擴(kuò)容過(guò)程中請(qǐng)求延時(shí)增加了不到1s。從原理上來(lái)說(shuō)是可行的。

NOSQL解決方案

像這么大的數(shù)據(jù)量一個(gè)很好的參考是12306。12306采用的是Geode。它是有數(shù)據(jù)庫(kù)功能的內(nèi)存數(shù)據(jù)網(wǎng)格（In-Memory Data Grid,IMDG）。其重要特性是

1)集群內(nèi)存總?cè)萘?，現(xiàn)在Geode可以實(shí)現(xiàn)單個(gè)節(jié)點(diǎn)200-300GB內(nèi)存，總集群包含300個(gè)節(jié)點(diǎn)的大型集群，因此總?cè)萘靠梢赃_(dá)到90TB左右的級(jí)別。

2)Geode集群功能非常強(qiáng)大，實(shí)現(xiàn)了內(nèi)存中數(shù)據(jù)Shard分布，自動(dòng)管理，集群故障自動(dòng)恢復(fù)，自動(dòng)平均分布等一系列企業(yè)級(jí)的功能，而且有自帶的集群間數(shù)據(jù)同步功能。

3)在CAP原理下（不了解的話(huà)可以百度一下CAP不可能三角），Geode可以保證集群內(nèi)數(shù)據(jù)的強(qiáng)一致性，注意是真正的強(qiáng)一致性而不是最終一致性，再加上分區(qū)可用性，因此是一個(gè)CP型的產(chǎn)品，可以提供統(tǒng)一的數(shù)據(jù)視圖，支持高并發(fā)下的acid事務(wù)。

采用新的解決方案最大問(wèn)題是平滑過(guò)渡，平滑過(guò)渡方面我還是覺(jué)得上面提到的數(shù)據(jù)庫(kù)雙寫(xiě)方式安全可靠。

系統(tǒng)共建的解決方案

如果達(dá)到我所說(shuō)的量級(jí)，基本上在一個(gè)行業(yè)中是處于壟斷地位的。并不是一家純的互聯(lián)網(wǎng)公司。這種公司可以采用和互聯(lián)網(wǎng)大廠合作的方式、用已經(jīng)有這方面經(jīng)驗(yàn)的大廠，來(lái)根據(jù)自己內(nèi)部系統(tǒng)的特性共建一套合適自己的定制化數(shù)據(jù)庫(kù)。