一、問(wèn)題
在好大夫在線內(nèi)部，S3系統(tǒng)負(fù)責(zé)各業(yè)務(wù)方操作日志的集中存儲(chǔ)、查詢和管理。目前，該系統(tǒng)日均查詢量數(shù)千萬(wàn)次，插入量數(shù)十萬(wàn)次。隨著日志量的不斷累積，主表已經(jīng)達(dá)到數(shù)十億，單表占用磁盤空間400G+。S3是業(yè)務(wù)早期就存在的系統(tǒng)，當(dāng)時(shí)為了簡(jiǎn)單快速落地，使用了MySQL來(lái)存儲(chǔ)，隨著業(yè)務(wù)的不斷增長(zhǎng)，同時(shí)也要兼顧性能和可擴(kuò)展性，到了必須要重新選型的時(shí)候了。
新項(xiàng)目命名為：LogStore。
二、目標(biāo)
1、安全性
S3系統(tǒng)在設(shè)計(jì)之初，沒(méi)有按業(yè)務(wù)系統(tǒng)考慮數(shù)據(jù)隔離，而是直接采用 key(系統(tǒng) + 類名 + id) + 有限固定字段 + 序列化value 的方式進(jìn)行存儲(chǔ)，這種方式顯然不便于后續(xù)集群拆分和管理。LogStore系統(tǒng)要在邏輯上進(jìn)行數(shù)據(jù)區(qū)域劃分，業(yè)務(wù)方在接入時(shí)要指定App進(jìn)行必要的權(quán)限驗(yàn)證，以區(qū)分不同業(yè)務(wù)數(shù)據(jù)，進(jìn)而再進(jìn)行插入和查詢操作。
2、通用性
S3主要提供一種3層結(jié)構(gòu)，采用MySQL固定字段進(jìn)行存儲(chǔ)，這就不可避免地會(huì)造成字段空間的浪費(fèi)。LogStore系統(tǒng)需要提供一種通用的日志存儲(chǔ)格式，由業(yè)務(wù)方自行規(guī)定字段含義，并且保留一定程度的可查詢維度。
3、高性能
S3系統(tǒng)的QPS在300+，單條數(shù)據(jù)最大1KB左右。LogStore系統(tǒng)要支持當(dāng)前QPS 10倍以上的寫(xiě)入和讀取速度。
4、可審計(jì)
要滿足內(nèi)部安全審計(jì)的要求，LogStore系統(tǒng)不提供對(duì)數(shù)據(jù)的更新，只允許數(shù)據(jù)的插入和查詢。
5、易拓展
LogStore系統(tǒng)以及底層存儲(chǔ)要滿足可擴(kuò)展特性，可以在線擴(kuò)容，滿足公司未來(lái)5年甚至更長(zhǎng)時(shí)間的日志存儲(chǔ)需求，并且要最大化節(jié)省磁盤空間。
三、方案選型
為了達(dá)成改造目標(biāo)，本次調(diào)研了四種存儲(chǔ)改造方案，各種方案對(duì)比如下：
1、我們不合適—分庫(kù)分表
分庫(kù)分表主要分為應(yīng)用層依賴類中間件和代理中間件，無(wú)論哪種均需要修改現(xiàn)有php和JAVA框架，同時(shí)對(duì)DBA管理數(shù)據(jù)也帶來(lái)一定的操作困難。為了降低架構(gòu)復(fù)雜度，架構(gòu)團(tuán)隊(duì)否定了引入DB中間件的方案，還是要求運(yùn)維簡(jiǎn)單、成本低的方案。
2、我們不合適—TiDB
TiDB也曾一度進(jìn)入了我們重點(diǎn)調(diào)研對(duì)象，只是由于目前公司的DB生態(tài)主要還是在MGR、MongoDB、MySQL上，在可預(yù)見(jiàn)的需求中，也沒(méi)有能充分發(fā)揮TiDB的場(chǎng)景，所以就暫時(shí)擱置了。
3、我們不合適—ElasticSearch
ELK-stack提供的套件確實(shí)讓ES很有吸引力，公司用ES集群也有較長(zhǎng)時(shí)間了。ES優(yōu)勢(shì)在于檢索和數(shù)據(jù)分析領(lǐng)域，也正是因?yàn)槠錂z索和分析的功能的強(qiáng)大，無(wú)論寫(xiě)入、查詢和存儲(chǔ)成本都比較高，在日志處理的這個(gè)場(chǎng)景下，性價(jià)比略低，所以也被pass了。
4、適合的選擇—MongoDB
業(yè)務(wù)操作日志讀多寫(xiě)少，很適合文檔型數(shù)據(jù)庫(kù)MongoDB的特點(diǎn)。同時(shí)，MongoDB在業(yè)界得到了廣泛的使用，公司也有很多業(yè)務(wù)在使用，在MongoDB上積累了一定的運(yùn)維經(jīng)驗(yàn)，最終決定選擇MongoDB作為新日志系統(tǒng)存儲(chǔ)方案。
四、性能測(cè)試
為了驗(yàn)證MongoDB的性能能否達(dá)到要求，我們搭建了MongoDB集群，機(jī)器配置、架構(gòu)圖和測(cè)試結(jié)果如下：
1、機(jī)器配置
MongoDB集群3臺(tái)機(jī)器配置如下：
2、架構(gòu)圖
3、測(cè)試場(chǎng)景
本次MongoDB測(cè)試采用YCSB（
https://github.com/brianfrankcooper/YCSB）性能測(cè)試工具，ycsb的workloads目錄下保存了6種不同的workload類型，代表了不同的壓測(cè)負(fù)載類型，本次我們只用到了其中5種，具體場(chǎng)景和測(cè)試結(jié)果如下。
1) 插入平均文檔大小為5K，數(shù)據(jù)量為100萬(wàn)，并發(fā)100，數(shù)據(jù)量總共5.265G 左右，執(zhí)行的時(shí)間以及磁盤壓力
結(jié)論：插入100w數(shù)據(jù)，總耗時(shí)219s,平均 insert 耗時(shí)21.8ms，吞吐量 4568/s
2) 測(cè)試90%讀，10%更新，并發(fā)100的場(chǎng)景
結(jié)論：總耗時(shí)236s，read 平均耗時(shí)23.6ms， update 平均耗時(shí)23.56ms,吞吐量達(dá)到 4225/s
3) 測(cè)試讀多寫(xiě)少，100%讀 ，并發(fā)100的場(chǎng)景
結(jié)論：總耗時(shí)123s，平均read 耗時(shí)12.3ms，吞吐量達(dá)到8090/s
4) 測(cè)試讀多寫(xiě)少，90%讀，10%插入，并發(fā)100的場(chǎng)景
結(jié)論：總耗時(shí)220s，read 平均耗時(shí) 21.9ms，insert 平均耗時(shí)21.9ms，吞吐量達(dá)到4541/s
5) 測(cè)試混合讀寫(xiě)，50%讀，25%插入、25%更新，并發(fā)100的場(chǎng)景
結(jié)論：總耗時(shí)267s，read 平均耗時(shí)26.7ms，update 平均耗時(shí)26.7ms，insert 平均耗時(shí)26.6ms ,吞吐量 為3739/s
4、測(cè)試結(jié)果對(duì)比
可以看出mongodb適合讀多寫(xiě)少的時(shí)候，性能最好，讀寫(xiě)速率能滿足生產(chǎn)需求。
五、無(wú)縫遷移實(shí)踐
為了保障業(yè)務(wù)的無(wú)縫遷移，也為了最大化降低業(yè)務(wù)研發(fā)同學(xué)的投入成本，我們決定采用分階段切換的方案。
1、系統(tǒng)應(yīng)用層改造+LogStore系統(tǒng)搭建
首先，在S3系統(tǒng)中內(nèi)置讀開(kāi)關(guān)和寫(xiě)開(kāi)關(guān)，可將讀寫(xiě)流量分別引入到LogStore系統(tǒng)中，而新應(yīng)用的接入可以直接調(diào)用LogStore系統(tǒng)，此時(shí)結(jié)構(gòu)示意圖如下：
2、增量數(shù)據(jù)同步
為了讓S3系統(tǒng)和LogStore系統(tǒng)中新增數(shù)據(jù)達(dá)到一致，在底層數(shù)據(jù)庫(kù)采用Maxwell訂閱MySQL Binlog的方式同步到MongoDB中，示意圖如下：
Maxwell(http://maxwells-daemon.io)實(shí)時(shí)讀取MySQL二進(jìn)制日志binlog，并生成 JSON 格式的消息，作為生產(chǎn)者發(fā)送給 Kafka，Logstore系統(tǒng)消費(fèi)Kafka中的數(shù)據(jù)寫(xiě)入到mongodb數(shù)據(jù)庫(kù)中。
至此，對(duì)于業(yè)務(wù)方現(xiàn)有日志類型，新增數(shù)據(jù)在底層達(dá)到雙寫(xiě)目的，S3系統(tǒng)和LogStore系統(tǒng)存儲(chǔ)兩份數(shù)據(jù)；如果業(yè)務(wù)方新增日志類型，則直接調(diào)用LogStore系統(tǒng)接口即可。接下來(lái)，我們將對(duì)已有日志類型老數(shù)據(jù)進(jìn)行遷移。
3、存量數(shù)據(jù)遷移
此次遷移S3老數(shù)據(jù)采用php定時(shí)任務(wù)腳本(多個(gè))查詢數(shù)據(jù)，將數(shù)據(jù)投遞到RabbitMQ隊(duì)列中，LogStore系統(tǒng)從RabbitMQ隊(duì)列拉取消息進(jìn)行消費(fèi)存儲(chǔ)到MongoDB中，示意圖如下：
- 由于原mysql表中id為varchar類型并且非主鍵索引，只能利用ctime索引分批次進(jìn)行查詢，數(shù)據(jù)密集處進(jìn)行chunk投遞到mq隊(duì)列中。
- 數(shù)據(jù)無(wú)法一天就遷移完，遷移過(guò)程中可能存在中斷的情況。腳本采用定時(shí)任務(wù)每天執(zhí)行20h, 在上線時(shí)間停止執(zhí)行，同時(shí)將停止時(shí)間記錄到redis中。
- 由于需要遷移數(shù)據(jù)量較大，在mq和消費(fèi)者能承受的情況下，盡可能多地增加腳本數(shù)量，縮短導(dǎo)數(shù)據(jù)的時(shí)間。
- 腳本執(zhí)行期間，觀察業(yè)務(wù)延時(shí)情況和MySQL監(jiān)控情況，發(fā)現(xiàn)有影響立即進(jìn)行調(diào)整，以保障不影響正常業(yè)務(wù)。
4、檢驗(yàn)數(shù)據(jù)
老數(shù)據(jù)導(dǎo)入完成后，下面就要對(duì)老數(shù)據(jù)進(jìn)行校驗(yàn)，校驗(yàn)從兩個(gè)方面進(jìn)行: 數(shù)據(jù)量和數(shù)據(jù)完整性。
1）數(shù)據(jù)量
基于S3系統(tǒng)老數(shù)據(jù)的id, 查詢?cè)贛ongoDB中是否存在，如果不存在則進(jìn)行補(bǔ)償重發(fā)。
2）數(shù)據(jù)完整性
對(duì)于S3和MongoDB中的數(shù)據(jù)按照相同規(guī)則進(jìn)行md5校驗(yàn)，校驗(yàn)不通過(guò)則進(jìn)行補(bǔ)償重發(fā)。
5、數(shù)據(jù)雙寫(xiě)
將應(yīng)用層預(yù)制的寫(xiě)開(kāi)關(guān)打開(kāi)，將流量導(dǎo)入到LogStore中，此時(shí)mysql的流量并沒(méi)有停掉，繼續(xù)執(zhí)行binlog同步。結(jié)構(gòu)如下：
從圖中可以看到，從S3調(diào)用點(diǎn)的寫(xiě)接口的流量都寫(xiě)入到MongoDB數(shù)據(jù)庫(kù)backuplogs集合中，為什么不直接寫(xiě)入到logs表中呢？留個(gè)小懸念，在后文中有解釋。
6、灰度切換S3讀到LogStore系統(tǒng)
上文我們提到，對(duì)于S3系統(tǒng)應(yīng)用層讀寫(xiě)調(diào)用點(diǎn)均分別內(nèi)置了切換開(kāi)關(guān)，打開(kāi)應(yīng)用層讀開(kāi)關(guān)，所有的讀操作全部走LogStore, 切換后示意圖如下所示：
7、灰度切換寫(xiě)接口到LogStore系統(tǒng)
打開(kāi)應(yīng)用層寫(xiě)開(kāi)關(guān)，所有寫(xiě)操作會(huì)通過(guò)mq異步寫(xiě)到MongoDB中，那如何證明應(yīng)用層寫(xiě)調(diào)用點(diǎn)修改完全了呢？
上文中雙寫(xiě)數(shù)據(jù)一份到logs表中，一份到backuplogs表中，通過(guò)Maxwell的Binlog同步的數(shù)據(jù)肯定是最全的，數(shù)據(jù)量上按理來(lái)說(shuō) count( logs) >= count(backuplogs), 如果兩個(gè)集合一段時(shí)間內(nèi)的數(shù)據(jù)增量相同，則證明寫(xiě)調(diào)用點(diǎn)修改完全，可以去掉雙寫(xiě)，只保留LogStore這條線，反之需要檢查修改再次驗(yàn)證。切換寫(xiě)完成后，示意圖如下：
六、MongoDB與故障演練
故障演練能夠檢測(cè)服務(wù)是否真正高可用，及時(shí)發(fā)現(xiàn)系統(tǒng)薄弱的環(huán)節(jié)，提前準(zhǔn)備好預(yù)案減少故障恢復(fù)時(shí)間。為了驗(yàn)證MongoDB是否真正高可用，我們?cè)诰€下搭建了MongoDB集群：
同時(shí)，我們編寫(xiě)腳本模擬用戶MongoDB數(shù)據(jù)插入和讀取，基于好大夫在線自研故障演練平臺(tái)，對(duì)機(jī)器進(jìn)行故障注入，查看各種故障對(duì)用戶的影響。故障演練內(nèi)容CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)和進(jìn)程Kill等操作，詳情如下圖所示：
實(shí)驗(yàn)結(jié)果：
- CPU、磁盤填充和磁盤負(fù)載對(duì)MongoDB集群影響較小。
- 內(nèi)存滿載可能會(huì)發(fā)生系統(tǒng)OOM，導(dǎo)致MongoDB進(jìn)程被操作系統(tǒng)Kill，由于MongoDB存在數(shù)據(jù)副本和自動(dòng)主從切換，對(duì)用戶影響較小。
- 網(wǎng)絡(luò)抖動(dòng)、延遲和丟包會(huì)導(dǎo)致mongos連接服務(wù)器時(shí)間變長(zhǎng)，客戶端卡頓的現(xiàn)象發(fā)生，可通過(guò)網(wǎng)絡(luò)監(jiān)控的手段監(jiān)測(cè)。
- 分別主動(dòng)Kill掉MongoDB的主節(jié)點(diǎn)、從節(jié)點(diǎn)、仲裁節(jié)點(diǎn)、mongos、config節(jié)點(diǎn)，對(duì)整個(gè)集群影響較小。
整體而言，MongoDB存在副本和自動(dòng)主從切換，客戶端存在自動(dòng)檢測(cè)重連機(jī)制，單個(gè)機(jī)器發(fā)生故障時(shí)對(duì)整體集群可用性影響較小。同時(shí)，可增加對(duì)單機(jī)器的資源進(jìn)行監(jiān)控，達(dá)到閾值進(jìn)行報(bào)警，減小故障發(fā)現(xiàn)和恢復(fù)時(shí)間。
七、總結(jié)
1、MongoDB的使用
MongoDB數(shù)據(jù)寫(xiě)入可能各個(gè)分片不均勻，此時(shí)可以開(kāi)啟塊均衡策略；由于均衡器會(huì)增加系統(tǒng)負(fù)載，最好選擇在業(yè)務(wù)量較小的時(shí)候進(jìn)行；
合理選擇分片鍵和建立索引，會(huì)使你的查詢速度更快，這個(gè)要具體場(chǎng)景具體分析。
2、遷移數(shù)據(jù)
必須保留唯一標(biāo)識(shí)數(shù)據(jù)的字段，最好是主鍵id，方便校驗(yàn)數(shù)據(jù)；
一定要考慮多進(jìn)程，腳本要自動(dòng)化，縮短遷移時(shí)間和減小人工介入；
遷移過(guò)程中，要時(shí)刻關(guān)注數(shù)據(jù)庫(kù)、中間件及應(yīng)用相關(guān)指標(biāo)，防止導(dǎo)出導(dǎo)入數(shù)據(jù)影響正常業(yè)務(wù)；
要在同樣配置的環(huán)境下充分演練，提前制定數(shù)據(jù)比對(duì)測(cè)試用例，以防止數(shù)據(jù)丟失；
每一步線上操作（如切換讀寫(xiě)），都要有對(duì)應(yīng)的回滾計(jì)劃，最大限度降低對(duì)業(yè)務(wù)的影響。
作者丨孫文華
來(lái)源丨公眾號(hào)：HaoDF技術(shù)團(tuán)隊(duì)（ID：haodf_tech）
dbaplus社群歡迎廣大技術(shù)人員投稿，投稿郵箱：editor@dbaplus.cn
關(guān)于我們
dbaplus社群是圍繞Database、BigData、AIOps的企業(yè)級(jí)專業(yè)社群。資深大咖、技術(shù)干貨，每天精品原創(chuàng)文章推送，每周線上技術(shù)分享，每月線下技術(shù)沙龍，每季度Gdevops&DAMS行業(yè)大會(huì)。
關(guān)注公眾號(hào)【dbaplus社群】，獲取更多原創(chuàng)技術(shù)文章和精選工具下載
