?一、問題

在好大夫在線內(nèi)部，S3系統(tǒng)負責(zé)各業(yè)務(wù)方操作日志的集中存儲、查詢和管理。目前，該系統(tǒng)日均查詢量數(shù)千萬次，插入量數(shù)十萬次。隨著日志量的不斷累積，主表已經(jīng)達到數(shù)十億，單表占用磁盤空間400G+。S3是業(yè)務(wù)早期就存在的系統(tǒng)，當(dāng)時為了簡單快速落地，使用了Mysql來存儲，隨著業(yè)務(wù)的不斷增長，同時也要兼顧性能和可擴展性，到了必須要重新選型的時候了。

新項目命名為：LogStore。

二、目標(biāo)

?1、安全性

S3系統(tǒng)在設(shè)計之初，沒有按業(yè)務(wù)系統(tǒng)考慮數(shù)據(jù)隔離，而是直接采用 key(系統(tǒng) + 類名 + id) + 有限固定字段 + 序列化value 的方式進行存儲，這種方式顯然不便于后續(xù)集群拆分和管理。LogStore系統(tǒng)要在邏輯上進行數(shù)據(jù)區(qū)域劃分，業(yè)務(wù)方在接入時要指定app進行必要的權(quán)限驗證，以區(qū)分不同業(yè)務(wù)數(shù)據(jù)，進而再進行插入和查詢操作。

?2、通用性

S3主要提供一種3層結(jié)構(gòu)，采用MySQL固定字段進行存儲，這就不可避免地會造成字段空間的浪費。LogStore系統(tǒng)需要提供一種通用的日志存儲格式，由業(yè)務(wù)方自行規(guī)定字段含義，并且保留一定程度的可查詢維度。

?3、高性能

S3系統(tǒng)的QPS在300+，單條數(shù)據(jù)最大1KB左右。LogStore系統(tǒng)要支持當(dāng)前QPS 10倍以上的寫入和讀取速度。

?4、可審計

要滿足內(nèi)部安全審計的要求，LogStore系統(tǒng)不提供對數(shù)據(jù)的更新，只允許數(shù)據(jù)的插入和查詢。

?5、易拓展

LogStore系統(tǒng)以及底層存儲要滿足可擴展特性，可以在線擴容，滿足公司未來5年甚至更長時間的日志存儲需求，并且要最大化節(jié)省磁盤空間。

三、方案選型

為了達成改造目標(biāo)，本次調(diào)研了四種存儲改造方案，各種方案對比如下：

?1、我們不合適—分庫分表

分庫分表主要分為應(yīng)用層依賴類中間件和代理中間件，無論哪種均需要修改現(xiàn)有PHP和Java框架，同時對DBA管理數(shù)據(jù)也帶來一定的操作困難。為了降低架構(gòu)復(fù)雜度，架構(gòu)團隊否定了引入DB中間件的方案，還是要求運維簡單、成本低的方案。

?2、我們不合適—TiDB

TiDB也曾一度進入了我們重點調(diào)研對象，只是由于目前公司的DB生態(tài)主要還是在MGR、MongoDB、MySQL上，在可預(yù)見的需求中，也沒有能充分發(fā)揮TiDB的場景，所以就暫時擱置了。

?3、我們不合適—ElasticSearch

ELK-stack提供的套件確實讓ES很有吸引力，公司用ES集群也有較長時間了。ES優(yōu)勢在于檢索和數(shù)據(jù)分析領(lǐng)域，也正是因為其檢索和分析的功能的強大，無論寫入、查詢和存儲成本都比較高，在日志處理的這個場景下，性價比略低，所以也被pass了。

?4、適合的選擇—MongoDB

業(yè)務(wù)操作日志讀多寫少，很適合文檔型數(shù)據(jù)庫MongoDB的特點。同時，MongoDB在業(yè)界得到了廣泛的使用，公司也有很多業(yè)務(wù)在使用，在MongoDB上積累了一定的運維經(jīng)驗，最終決定選擇MongoDB作為新日志系統(tǒng)存儲方案。

四、性能測試

為了驗證MongoDB的性能能否達到要求，我們搭建了MongoDB集群，機器配置、架構(gòu)圖和測試結(jié)果如下：

?1、機器配置

MongoDB集群3臺機器配置如下：

?2、架構(gòu)圖

?3、測試場景

本次MongoDB測試采用YCSB（https://github.com/brianfrankcooper/YCSB）性能測試工具，ycsb的workloads目錄下保存了6種不同的workload類型，代表了不同的壓測負載類型，本次我們只用到了其中5種，具體場景和測試結(jié)果如下。

1) 插入平均文檔大小為5K，數(shù)據(jù)量為100萬，并發(fā)100，數(shù)據(jù)量總共5.265G 左右，執(zhí)行的時間以及磁盤壓力

結(jié)論：插入100w數(shù)據(jù)，總耗時219s,平均 insert 耗時21.8ms，吞吐量 4568/s

2) 測試90%讀，10%更新，并發(fā)100的場景

結(jié)論：總耗時236s，read 平均耗時23.6ms， update 平均耗時23.56ms,吞吐量達到 4225/s

3) 測試讀多寫少，100%讀 ，并發(fā)100的場景

結(jié)論：總耗時123s，平均read 耗時12.3ms，吞吐量達到8090/s

4) 測試讀多寫少，90%讀，10%插入，并發(fā)100的場景

結(jié)論：總耗時220s，read 平均耗時 21.9ms，insert 平均耗時21.9ms，吞吐量達到4541/s

5) 測試混合讀寫，50%讀，25%插入、25%更新，并發(fā)100的場景

結(jié)論：總耗時267s，read 平均耗時26.7ms，update  平均耗時26.7ms，insert  平均耗時26.6ms ,吞吐量 為3739/s

?4、測試結(jié)果對比

可以看出mongodb適合讀多寫少的時候，性能最好，讀寫速率能滿足生產(chǎn)需求。

五、無縫遷移實踐

為了保障業(yè)務(wù)的無縫遷移，也為了最大化降低業(yè)務(wù)研發(fā)同學(xué)的投入成本，我們決定采用分階段切換的方案。

?1、系統(tǒng)應(yīng)用層改造+LogStore系統(tǒng)搭建

首先，在S3系統(tǒng)中內(nèi)置讀開關(guān)和寫開關(guān)，可將讀寫流量分別引入到LogStore系統(tǒng)中，而新應(yīng)用的接入可以直接調(diào)用LogStore系統(tǒng)，此時結(jié)構(gòu)示意圖如下：

?2、增量數(shù)據(jù)同步

為了讓S3系統(tǒng)和LogStore系統(tǒng)中新增數(shù)據(jù)達到一致，在底層數(shù)據(jù)庫采用Maxwell訂閱MySQL Binlog的方式同步到MongoDB中，示意圖如下：

Maxwell(http://maxwells-daemon.io)實時讀取MySQL二進制日志binlog，并生成 JSON 格式的消息，作為生產(chǎn)者發(fā)送給 Kafka，Logstore系統(tǒng)消費Kafka中的數(shù)據(jù)寫入到mongodb數(shù)據(jù)庫中。

至此，對于業(yè)務(wù)方現(xiàn)有日志類型，新增數(shù)據(jù)在底層達到雙寫目的，S3系統(tǒng)和LogStore系統(tǒng)存儲兩份數(shù)據(jù)；如果業(yè)務(wù)方新增日志類型，則直接調(diào)用LogStore系統(tǒng)接口即可。接下來，我們將對已有日志類型老數(shù)據(jù)進行遷移。

?3、存量數(shù)據(jù)遷移

此次遷移S3老數(shù)據(jù)采用php定時任務(wù)腳本(多個)查詢數(shù)據(jù)，將數(shù)據(jù)投遞到RabbitMQ隊列中，LogStore系統(tǒng)從RabbitMQ隊列拉取消息進行消費存儲到MongoDB中，示意圖如下：

由于原mysql表中id為varchar類型并且非主鍵索引，只能利用ctime索引分批次進行查詢，數(shù)據(jù)密集處進行chunk投遞到mq隊列中。

• 數(shù)據(jù)無法一天就遷移完，遷移過程中可能存在中斷的情況。腳本采用定時任務(wù)每天執(zhí)行20h, 在上線時間停止執(zhí)行，同時將停止時間記錄到Redis中。
• 由于需要遷移數(shù)據(jù)量較大，在mq和消費者能承受的情況下，盡可能多地增加腳本數(shù)量，縮短導(dǎo)數(shù)據(jù)的時間。

• 腳本執(zhí)行期間，觀察業(yè)務(wù)延時情況和MySQL監(jiān)控情況，發(fā)現(xiàn)有影響立即進行調(diào)整，以保障不影響正常業(yè)務(wù)。

?4、檢驗數(shù)據(jù)

老數(shù)據(jù)導(dǎo)入完成后，下面就要對老數(shù)據(jù)進行校驗，校驗從兩個方面進行: 數(shù)據(jù)量和數(shù)據(jù)完整性。

1）數(shù)據(jù)量

基于S3系統(tǒng)老數(shù)據(jù)的id, 查詢在MongoDB中是否存在，如果不存在則進行補償重發(fā)。

2）數(shù)據(jù)完整性

對于S3和MongoDB中的數(shù)據(jù)按照相同規(guī)則進行md5校驗，校驗不通過則進行補償重發(fā)。

?5、數(shù)據(jù)雙寫

將應(yīng)用層預(yù)制的寫開關(guān)打開，將流量導(dǎo)入到LogStore中，此時mysql的流量并沒有停掉，繼續(xù)執(zhí)行binlog同步。結(jié)構(gòu)如下：

從圖中可以看到，從S3調(diào)用點的寫接口的流量都寫入到MongoDB數(shù)據(jù)庫backuplogs集合中，為什么不直接寫入到logs表中呢？留個小懸念，在后文中有解釋。

6、灰度切換S3讀到LogStore系統(tǒng)

上文我們提到，對于S3系統(tǒng)應(yīng)用層讀寫調(diào)用點均分別內(nèi)置了切換開關(guān)，打開應(yīng)用層讀開關(guān)，所有的讀操作全部走LogStore, 切換后示意圖如下所示：

?7、灰度切換寫接口到LogStore系統(tǒng)

打開應(yīng)用層寫開關(guān)，所有寫操作會通過mq異步寫到MongoDB中，那如何證明應(yīng)用層寫調(diào)用點修改完全了呢？

上文中雙寫數(shù)據(jù)一份到logs表中，一份到backuplogs表中，通過Maxwell的Binlog同步的數(shù)據(jù)肯定是最全的，數(shù)據(jù)量上按理來說 count( logs) >= count(backuplogs), 如果兩個集合一段時間內(nèi)的數(shù)據(jù)增量相同，則證明寫調(diào)用點修改完全，可以去掉雙寫，只保留LogStore這條線，反之需要檢查修改再次驗證。切換寫完成后，示意圖如下：

六、MongoDB與故障演練

故障演練能夠檢測服務(wù)是否真正高可用，及時發(fā)現(xiàn)系統(tǒng)薄弱的環(huán)節(jié)，提前準(zhǔn)備好預(yù)案減少故障恢復(fù)時間。為了驗證MongoDB是否真正高可用，我們在線下搭建了MongoDB集群：

同時，我們編寫腳本模擬用戶MongoDB數(shù)據(jù)插入和讀取，基于好大夫在線自研故障演練平臺，對機器進行故障注入，查看各種故障對用戶的影響。故障演練內(nèi)容CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)和進程Kill等操作，詳情如下圖所示：

實驗結(jié)果：

• CPU、磁盤填充和磁盤負載對MongoDB集群影響較小。

• 內(nèi)存滿載可能會發(fā)生系統(tǒng)OOM，導(dǎo)致MongoDB進程被操作系統(tǒng)Kill，由于MongoDB存在數(shù)據(jù)副本和自動主從切換，對用戶影響較小。

• 網(wǎng)絡(luò)抖動、延遲和丟包會導(dǎo)致mongos連接服務(wù)器時間變長，客戶端卡頓的現(xiàn)象發(fā)生，可通過網(wǎng)絡(luò)監(jiān)控的手段監(jiān)測。

• 分別主動Kill掉MongoDB的主節(jié)點、從節(jié)點、仲裁節(jié)點、mongos、config節(jié)點，對整個集群影響較小。

整體而言，MongoDB存在副本和自動主從切換，客戶端存在自動檢測重連機制，單個機器發(fā)生故障時對整體集群可用性影響較小。同時，可增加對單機器的資源進行監(jiān)控，達到閾值進行報警，減小故障發(fā)現(xiàn)和恢復(fù)時間。

七、總結(jié)

?1、MongoDB的使用

MongoDB數(shù)據(jù)寫入可能各個分片不均勻，此時可以開啟塊均衡策略；由于均衡器會增加系統(tǒng)負載，最好選擇在業(yè)務(wù)量較小的時候進行；

合理選擇分片鍵和建立索引，會使你的查詢速度更快，這個要具體場景具體分析。

?2、遷移數(shù)據(jù)

必須保留唯一標(biāo)識數(shù)據(jù)的字段，最好是主鍵id，方便校驗數(shù)據(jù)；

一定要考慮多進程，腳本要自動化，縮短遷移時間和減小人工介入；

遷移過程中，要時刻關(guān)注數(shù)據(jù)庫、中間件及應(yīng)用相關(guān)指標(biāo)，防止導(dǎo)出導(dǎo)入數(shù)據(jù)影響正常業(yè)務(wù)；

要在同樣配置的環(huán)境下充分演練，提前制定數(shù)據(jù)比對測試用例，以防止數(shù)據(jù)丟失；

每一步線上操作（如切換讀寫），都要有對應(yīng)的回滾計劃，最大限度降低對業(yè)務(wù)的影響。?