目標(biāo)

數(shù)據(jù)存儲(chǔ)資源是系統(tǒng)中最重要的組成部分，數(shù)據(jù)即一切，尤其分布式領(lǐng)域，主要關(guān)注以下幾點(diǎn)：

• 高可用性，當(dāng)遇到網(wǎng)絡(luò)或者系統(tǒng)故障時(shí)，系統(tǒng)仍然保持可用
• 高擴(kuò)展，當(dāng)數(shù)據(jù)規(guī)模變大時(shí)，數(shù)據(jù)存儲(chǔ)系統(tǒng)能夠自動(dòng)適應(yīng)這種變化
• 高性能，當(dāng)數(shù)據(jù)規(guī)模和訪問(wèn)規(guī)模變大時(shí)，性能不受大的影響
• 成本，通過(guò)成本反映出系統(tǒng)設(shè)計(jì)是合理的
• 安全，遇到各種系統(tǒng)和人為故障時(shí)，數(shù)據(jù)不丟失

MySQL

MySQL是OLTP關(guān)系型數(shù)據(jù)庫(kù)，支持ACID事務(wù)，是最主要的存儲(chǔ)系統(tǒng)，目前使用的版本是5.7。

MySQL本身不是分布式系統(tǒng)，其支持的數(shù)據(jù)復(fù)制技術(shù)，本質(zhì)上是為了數(shù)據(jù)容災(zāi)使用，但目前基于主從復(fù)制進(jìn)行讀寫分離，減少單機(jī)的讀壓力。

MySQL服務(wù)如果托管在阿里云，可以使用高可用版本，秒級(jí)的主從切換，基于云盤的磁盤擴(kuò)容技術(shù)，能夠快速?gòu)?fù)制一個(gè)只讀節(jié)點(diǎn)，減少了很多自建MySQL遇到的各種問(wèn)題，另外其還提供了很多額外的功能，比如索引分析、SQL審查、慢查詢分析、動(dòng)態(tài)擴(kuò)容。

雖然云托管RDS，但本質(zhì)上還是MySQL，仍然會(huì)遇到很多問(wèn)題，比如：

• 數(shù)據(jù)存儲(chǔ)不支持分片，只能通過(guò)分庫(kù)分表的方式進(jìn)行橫向擴(kuò)展，目前應(yīng)用層也不支持分庫(kù)分表的路由，即使分表，拆分表的時(shí)候還是會(huì)遇到很多問(wèn)題
• 如果表設(shè)計(jì)和索引設(shè)計(jì)不合理，大量的更新，仍然會(huì)遇到主從延遲的問(wèn)題，從應(yīng)用層面是很難徹底解決的
• 阿里云RDS只支持一個(gè)負(fù)載均衡主從分離，所以后臺(tái)、隊(duì)列應(yīng)用使用360 Atlas讀寫分離服務(wù)，目前是一個(gè)單點(diǎn)，且也會(huì)影響讀寫性能。
• MySQL應(yīng)用規(guī)范目前還沒有建立，比如什么樣的應(yīng)用應(yīng)該選擇MySQL，使用MySQL很大程度是為了事務(wù)，如果沒有事務(wù)的場(chǎng)景是否可以選擇其他的數(shù)據(jù)庫(kù)？
• 阿里云官方提到，單表記錄數(shù)超過(guò)500w，性能會(huì)極具下降
• DDL操作，尤其對(duì)于大表操作，會(huì)引起很大的同步延遲問(wèn)題

云托管的RDS本質(zhì)上還是基于ECS+云盤搭建的，數(shù)據(jù)的增長(zhǎng)、備份、性能、遷移、升級(jí)、只讀實(shí)例、磁盤容量、Binlog延遲還是會(huì)顯露出來(lái)。

那未來(lái)如何？其實(shí)云廠商也在探索，提出了云原生數(shù)據(jù)庫(kù)、云原生分布式數(shù)據(jù)的概念，比如阿里云的PolarDB、PolarDB-X。

云原生數(shù)據(jù)庫(kù)關(guān)注成本、性能、在線業(yè)務(wù)擴(kuò)展、數(shù)據(jù)安全，它的核心技術(shù)包括計(jì)算和存儲(chǔ)分離，物理復(fù)制Binlog行復(fù)制模式，共享存儲(chǔ)設(shè)備，存儲(chǔ)之間通過(guò)RDMA高速網(wǎng)絡(luò)協(xié)議傳輸，同時(shí)PolarDB-X支持分區(qū)模式，解決了分庫(kù)分表的問(wèn)題。

經(jīng)過(guò)這些創(chuàng)新，傳統(tǒng)MySQL的弊端被解決了，比如同步延遲、備份、成本、分庫(kù)分表、性能。

未來(lái)，可以將核心數(shù)據(jù)庫(kù)遷移至云原生數(shù)據(jù)庫(kù)，保障核心業(yè)務(wù)的穩(wěn)定性和擴(kuò)展性，而對(duì)于非OLTP業(yè)務(wù)可以選擇其他數(shù)據(jù)庫(kù)，且制定MySQL應(yīng)用規(guī)范，明確哪些業(yè)務(wù)模式使用MySQL，索引正確設(shè)計(jì)、容量規(guī)劃、SQL語(yǔ)句使用規(guī)范等等。

Redis

Redis是K/V數(shù)據(jù)庫(kù)，它基于單線程、內(nèi)存操作，所以性能非常高。另外支持豐富的數(shù)據(jù)結(jié)構(gòu)，比如字符串、Hash、List、集合，應(yīng)用場(chǎng)景非常廣泛。

它通過(guò)AOF和RDB保障數(shù)據(jù)持久化，通過(guò)復(fù)制技術(shù)進(jìn)行數(shù)據(jù)備份，也支持通過(guò)哨兵和分區(qū)提供高可用性和容量伸縮，通過(guò)LUA腳本支持多條命令的事務(wù)操作。

Redis雖然是一個(gè)單機(jī)系統(tǒng)，但通過(guò)復(fù)制、集群技術(shù)也可以認(rèn)為是一個(gè)分布式存儲(chǔ)系統(tǒng)，目前西五街在大量使用，主要分為三類應(yīng)用：

• 存儲(chǔ)，比如用戶積分、文章數(shù)等數(shù)據(jù)，這些數(shù)據(jù)不能丟
• 緩存，比如用戶文章列表數(shù)據(jù)，需要考慮緩存穿透和雪崩等問(wèn)題
• 消息隊(duì)列，目前逐步替換為Kafka等純消息系統(tǒng)

阿里云云托管Redis社區(qū)版5.0服務(wù)集群版。

在應(yīng)用設(shè)計(jì)上存在以下幾個(gè)問(wèn)題：

• 存儲(chǔ)和緩存混合使用，無(wú)法拆分，對(duì)于容量估算不透明
• 應(yīng)用模式上，沒有很好的規(guī)范，比如緩存更新機(jī)制標(biāo)準(zhǔn)、統(tǒng)一Lib應(yīng)用包

通過(guò)阿里云Redis提供的部署架構(gòu)，可以很好的理解它的應(yīng)用場(chǎng)景：

• 標(biāo)準(zhǔn)版-雙副本：服務(wù)可靠，數(shù)據(jù)可靠，比較標(biāo)準(zhǔn)的使用模式，不管是存儲(chǔ)還是緩存服務(wù)都可用
• 集群版：通過(guò)代理模式和分片可以構(gòu)建出一個(gè)可伸縮的集群模式，解決Redis自身單線程瓶頸，滿足大容量、高性能的業(yè)務(wù)需求，而且副本集主要做恢復(fù)用，很適合存儲(chǔ)場(chǎng)景，不存在同步延遲的問(wèn)題
• 讀寫分離架構(gòu)：對(duì)于不關(guān)注同步延時(shí)的問(wèn)題，比如緩存場(chǎng)景，可以選擇這種模式，當(dāng)容量不夠的適合，通過(guò)客戶端的一致性Hash技術(shù)擴(kuò)容多個(gè)Redis實(shí)例就可以

后續(xù)確定Redis使用規(guī)范，拆分存儲(chǔ)和緩存場(chǎng)景，基于統(tǒng)一Lib包，就能解決大部分問(wèn)題。

Elasticseach

Elasticseach是一個(gè)近實(shí)時(shí)的分布式搜索引擎和分析引擎。

作為一個(gè)搜索引擎，目前在開源領(lǐng)域已經(jīng)是排名第一的數(shù)據(jù)庫(kù)了；基于倒排索引，具有很強(qiáng)的檢索能力，所以不管是應(yīng)用還是在大數(shù)據(jù)領(lǐng)域，它都是一個(gè)非常通用的分析引擎。

近實(shí)時(shí)表示Elasticseach應(yīng)用場(chǎng)景必須要有所了解，它不支持ACID，所以無(wú)法是一個(gè)OLTP數(shù)據(jù)庫(kù)，但使用壓力小了很多，在做策略分析、后臺(tái)應(yīng)用、即時(shí)查詢上有很廣泛的場(chǎng)景。

作為一個(gè)分布式應(yīng)用，通過(guò)副本集機(jī)制解決高可用的問(wèn)題，能夠解決單機(jī)故障的問(wèn)題，但如果數(shù)據(jù)被誤刪除，還是需要有備份機(jī)制，比如Elasticseach的快照機(jī)制。

副本集的同步最終達(dá)到一致性，為了寫入性能，也可以配置主節(jié)點(diǎn)寫入完成即返回給客戶端。

在容量可擴(kuò)展方面，可以采用分片機(jī)制解決容量橫向伸縮的問(wèn)題，將數(shù)據(jù)分到不同節(jié)點(diǎn)的不同分片上，如果要調(diào)整分片，需要reindex。

在性能方面，通過(guò)多副本集節(jié)點(diǎn)分擔(dān)查詢壓力。也可以使用專門的Transport節(jié)點(diǎn)分擔(dān)date Node節(jié)點(diǎn)的壓力，將分片查詢，副本查詢等路由和合并動(dòng)作的結(jié)果匯總起來(lái)。

Elasticseach是ELK解決方案的一部分，其還包括很多服務(wù)，包括Filebat，Kibana，Logstash，在大數(shù)據(jù)領(lǐng)域也是很好的一個(gè)方向。

Elasticseach是在ELK上搭建的三節(jié)點(diǎn)服務(wù)，由于規(guī)模問(wèn)題，目前也很少使用分片技術(shù)。核心是文章大寬表，用戶大寬表。

結(jié)合了搜索場(chǎng)景和分析場(chǎng)景，通過(guò)Binlog+Canal+Kafka+Go服務(wù)將MySQL多個(gè)表匯總到一個(gè)大寬表，主要是文章信息的大寬表，一方面是滿足搜索場(chǎng)景，另外滿足策略和應(yīng)用場(chǎng)景。

現(xiàn)在大寬表的應(yīng)用模式非常多，基于Free Schema模式，查詢模式非常靈活，通過(guò)訂閱方式同步數(shù)據(jù)，也減輕了應(yīng)用層的負(fù)擔(dān)，數(shù)據(jù)正確性有很大的保障。

未來(lái)，對(duì)于Elasticseach的應(yīng)用，一方面要加強(qiáng)性能調(diào)優(yōu)，比如分片數(shù)據(jù)的不均勻，查詢性能的優(yōu)化，同時(shí)要提升可維護(hù)性，比如挖掘reindex、alias等功能，充分理解Elasticseach。

而在國(guó)內(nèi)的云廠商中，都沒有對(duì)Elasticseach做太大的升級(jí)，基本上就是將Elasticseach服務(wù)托管到云中。

Kakfa

Kakfa是一個(gè)分布式的高吞吐消息隊(duì)列，訂閱/消費(fèi)模式追求的是高性能，而非存儲(chǔ)容量。但其日志本身具有重放功能，也可以理解為一個(gè)分布式存儲(chǔ)系統(tǒng)。

Kafka的核心功能包括：解耦、消峰、緩存，應(yīng)用場(chǎng)景極為廣泛，是系統(tǒng)不可缺少的一個(gè)組件。

作為分布式系統(tǒng)，它也有副本和分區(qū)機(jī)制，從而保障高可用和高吞吐。通過(guò)segment順序?qū)?，保障了寫性能非常高，而基于消費(fèi)組組的概念，消費(fèi)者吞吐能力也能橫向擴(kuò)展。同時(shí)每個(gè)broker都能負(fù)責(zé)查詢，提升了吞吐能力

Kafka基于Zookeeper做很多分布式管理功能，包括Leader選舉，負(fù)載均衡，Meta存儲(chǔ)。

目前Kafka三節(jié)點(diǎn)集群是通過(guò)ECS自行搭建的，運(yùn)行近一年，服務(wù)相對(duì)穩(wěn)定，可維護(hù)性也較好，沒有太多的管理工作，很多核心服務(wù)都已經(jīng)使用了Kafka隊(duì)列，后續(xù)原有基于Redis的隊(duì)列也可以盡快遷移。

MongoDB

MongoDB是一個(gè)分布式的文檔數(shù)據(jù)庫(kù)，其目標(biāo)是一個(gè)支持ACID事務(wù)的分布式數(shù)據(jù)庫(kù)，因?yàn)槭敲嫦蛭臋n，所以模式非常靈活，結(jié)構(gòu)松散，使用場(chǎng)景很規(guī)范，相比MySQL，其二進(jìn)制的存儲(chǔ)模式，壓縮比非常高，存儲(chǔ)成本會(huì)大幅減少，同時(shí)基于WiredTiger引擎，能夠創(chuàng)建各種類型的索引，甚至子文檔也能創(chuàng)建索引，從而提升查詢性能

MongoDB通過(guò)oplog技術(shù)支持副本集，也支持分區(qū)，分區(qū)鍵可以自定義，因?yàn)橛辛朔謪^(qū)，所以額外有了mongos路由服務(wù)器，config服務(wù)器，mongos路由服務(wù)器通過(guò)查詢config服務(wù)器，向節(jié)點(diǎn)和分區(qū)發(fā)送服務(wù)。

MongoDB將一致性和性能訴求交給了客戶端，通過(guò)read concern、write concern、read perference技術(shù)提供多種靈活性，比如你要求強(qiáng)一致性，那么就采用majority，你要求數(shù)據(jù)永遠(yuǎn)不丟失就配置journal為真。

MongoDB 4.0和MongoDB 4.2支持多文檔的事務(wù)，分別支持復(fù)制集、分區(qū)維度的事務(wù)性，但使用和理解非常復(fù)雜，可能是分布式系統(tǒng)中最難學(xué)習(xí)的部分。

這樣說(shuō)明，不用刻意使用事務(wù)，對(duì)MongoDB進(jìn)行良好的建模，做OLTP關(guān)系數(shù)據(jù)的補(bǔ)充，其在性能、成本、高可用、伸縮性方面是有優(yōu)勢(shì)的。其實(shí)在MySQL中，目前我們也很少使用跨表，跨語(yǔ)句的事務(wù)，所以不要太迷信事務(wù)，選擇好應(yīng)用場(chǎng)景。

除了查詢，MongoDB也支持各種聚合操作，在分析領(lǐng)域也很有廣泛的使用場(chǎng)景，這一點(diǎn)和Elasticseach很類似。

目前MongoDB三節(jié)點(diǎn)集群是通過(guò)ECS自行搭建的，存儲(chǔ)規(guī)模較小，使用場(chǎng)景較少。

對(duì)比MySQL和Elasticseach，MongoDB還是有很廣泛的應(yīng)用場(chǎng)景，比如分析場(chǎng)景，對(duì)事務(wù)要求不高的場(chǎng)景，數(shù)據(jù)增長(zhǎng)比較大的場(chǎng)景（比如私信數(shù)據(jù)），業(yè)務(wù)模式比較靈活的場(chǎng)景（比如各種條件的查詢，聚合操作）。

不過(guò)和Elasticseach一樣，各大云廠商一樣，只是將這個(gè)服務(wù)托管到云，并沒有做太多的優(yōu)化。