原文:?http://weibo.com/p/1001643874615465508614

?

微博平臺(tái)研發(fā)作為微博的底層數(shù)據(jù)及業(yè)務(wù)支撐部門，已經(jīng)經(jīng)歷了5年的發(fā)展歷程。伴隨著從數(shù)據(jù)及業(yè)務(wù)暴發(fā)式增長(zhǎng)，我們?cè)诤Ａ繑?shù)據(jù)存儲(chǔ)方面遭遇了諸多挑戰(zhàn)，與此同時(shí)也伴隨著豐富經(jīng)驗(yàn)的積累。

? ?本次新兵訓(xùn)練營(yíng)，受眾在于應(yīng)屆畢業(yè)生，目的在于讓新同學(xué)系統(tǒng)化并且有針對(duì)性的了解平臺(tái)的核心技術(shù)及核心業(yè)務(wù)，以使新同學(xué)在新兵訓(xùn)練營(yíng)結(jié)束后，能夠?qū)ζ脚_(tái)的底層架構(gòu)與業(yè)務(wù)有一定的了解。

? ?本文主要面向新同學(xué)介紹平臺(tái)的核心技術(shù)之一——海量數(shù)據(jù)存儲(chǔ)，主要介紹在海量數(shù)據(jù)存儲(chǔ)在大規(guī)模分布式系統(tǒng)下的架構(gòu)變遷與設(shè)計(jì)。

課程大綱：

1. ?課程目標(biāo)

2. ?存儲(chǔ)服務(wù)概述

3. ?MySQL與MySQL分布式架構(gòu)設(shè)計(jì)

4. ?Redis與Redis分布式架構(gòu)設(shè)計(jì)

5. ?思考與討論

一、課程目標(biāo)

1. ?了解存儲(chǔ)服務(wù)概況，以及RDBMS及NoSQL的差異

2. ?理解MySQL、Redis、HBase基本實(shí)現(xiàn)機(jī)制、特性、適用場(chǎng)景

3. ?理解幾種存儲(chǔ)產(chǎn)品的大規(guī)模分布式服務(wù)方案

4. ?學(xué)會(huì)使用平臺(tái)的MySQL、Redis?client組件

5. ?理解對(duì)于MySQL、Redis分布式系統(tǒng)設(shè)計(jì)想要注意的問(wèn)題

6. ?了解平臺(tái)幾種典型案例

7. ?理解幾種存儲(chǔ)產(chǎn)品在平臺(tái)的定制修改與名詞術(shù)語(yǔ)

二、存儲(chǔ)服務(wù)概述

1. ?關(guān)系型數(shù)據(jù)庫(kù)是基于實(shí)體關(guān)系模型（Entity-Relationship Model）的數(shù)據(jù)服務(wù)，具備以下特點(diǎn)。

• 適合存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)

• 查詢語(yǔ)言SQL，insert delete update select

• 主流關(guān)系型數(shù)據(jù)庫(kù)多是持久化存儲(chǔ)系統(tǒng)，系統(tǒng)性能與機(jī)器性能相關(guān)性較大

• 幾類主流的 關(guān)系型數(shù)據(jù)庫(kù)

• • MySQL

  • Oracle

  • DB2

  • SQL Server

• 性能

• • 局限于服務(wù)器性能，與其是磁盤性能

  • 局限于數(shù)據(jù)復(fù)雜度

  • 常見的SSD磁盤服務(wù)器，單機(jī)讀取性能可達(dá)萬(wàn)級(jí)/s

? ? 大型互聯(lián)網(wǎng)服務(wù)大多采用MySQL進(jìn)行作為關(guān)系型數(shù)據(jù)庫(kù)，微博平臺(tái)的核心業(yè)務(wù)(如微博內(nèi)容用戶微博列表)也同樣如此

?? ? ? ?本次培訓(xùn)也會(huì)著重介紹MySQL及其分布式架構(gòu)方案。

2. ?NoSQL(Not only SQL)數(shù)據(jù)庫(kù)，泛指非關(guān)系型的數(shù)據(jù)庫(kù)，興起的契機(jī)在于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)應(yīng)對(duì)大規(guī)模、高并發(fā)的能力有限，而NoSQL的普遍性能優(yōu)勢(shì)能夠彌補(bǔ)關(guān)系型數(shù)據(jù)庫(kù)在這方面的不足

• 存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)

• 性能

? ? 業(yè)界使用的NoSQL多為內(nèi)存集中型服務(wù)，受限于I/O及網(wǎng)絡(luò)，通常請(qǐng)求響應(yīng)時(shí)間在毫秒級(jí)別，單機(jī)QPS在10萬(wàn)級(jí)別(與數(shù)據(jù)大小及存儲(chǔ)復(fù)雜度相關(guān))

• 常見的幾類NoSQL產(chǎn)品

• K-V(Memcached、Redis)，這類NoSQL產(chǎn)品在互聯(lián)網(wǎng)業(yè)內(nèi)應(yīng)用范圍最廣。Memcached提供具備LRU淘汰策略的K-V內(nèi)存存儲(chǔ)；而Redis提供支持復(fù)雜結(jié)構(gòu)(List、Hash等)的內(nèi)存及持久化存儲(chǔ)

• Column(HBase、Cassandra)，HBase是基于列式存儲(chǔ)的分布式數(shù)據(jù)庫(kù)集群系統(tǒng)

• Document(MongoDb)

• Graph(Neo4J)，最龐大、最復(fù)雜的Graph模型是人的關(guān)系，理論上用圖描述并且用Graph數(shù)據(jù)庫(kù)存儲(chǔ)最合適不過(guò)，不過(guò)目前的數(shù)據(jù)規(guī)模、系統(tǒng)性能仍然有待優(yōu)化

? ?web2.0時(shí)代，NoSQL產(chǎn)品在互聯(lián)網(wǎng)行業(yè)中的重要性隨著互聯(lián)網(wǎng)及移動(dòng)互聯(lián)網(wǎng)的發(fā)展而與日劇增?? ? ??大型互聯(lián)網(wǎng)應(yīng)用，為應(yīng)對(duì)大規(guī)模、高并發(fā)訪問(wèn)，大多都引入了NoSQL產(chǎn)品，其中Memcached、Redis以其高成熟度、高性能、高穩(wěn)定性而被廣泛使用。微博平臺(tái)也具備千臺(tái)規(guī)模的NoSQL集群，微博核心的Feed業(yè)務(wù)、關(guān)系業(yè)務(wù)也都依賴Memcached及Redis提供高性能服務(wù)

??本次培訓(xùn)，會(huì)著重介紹Redis及其分布式架構(gòu)

三、MySQL

微博平臺(tái)核心業(yè)務(wù)的數(shù)據(jù)都存儲(chǔ)在MySQL上，目前具備千臺(tái)規(guī)模的集群，單個(gè)核心業(yè)務(wù)數(shù)據(jù)突破千億級(jí)，單個(gè)核心業(yè)務(wù)QPS峰值可達(dá)10萬(wàn)級(jí)每秒，寫入也是萬(wàn)級(jí)每秒。

在海量數(shù)據(jù)并且數(shù)據(jù)量持續(xù)增長(zhǎng)的景下，在如何設(shè)計(jì)滿足 高并發(fā)(w/r)、低延時(shí)(10ms級(jí)別)、高可用性(99.99％)的分布式MySQL系統(tǒng)方面，我們已經(jīng)具備充足的經(jīng)驗(yàn)并且依然在持續(xù)攻堅(jiān)這一問(wèn)題，而我們的課程也會(huì)著重介紹海量數(shù)據(jù)存儲(chǔ)之MySQL。

1. ?MySQL簡(jiǎn)介

• MySQL是一個(gè)關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)RDBMS

• 使用SQL作為查詢語(yǔ)言

• 開源

• 存儲(chǔ)引擎

• Innodb?支持事務(wù)、行鎖，寫入性能稍差

• MyIsam?不支持事務(wù)，讀寫性能略好

• 滿足ACID特性

• 主鍵、唯一鍵、外鍵(大規(guī)模系統(tǒng)一般不用)

• Transaction，事務(wù)即一系列操作，要么完全地執(zhí)行，要么完全地不執(zhí)行

• 服務(wù)、端口、實(shí)例，都是指 服務(wù)端啟動(dòng)的一個(gè)MySQL數(shù)據(jù)庫(kù)

• 性能

• 隨著磁盤性能升高，讀寫性能也逐步升高，但成本也隨之增加

• 數(shù)據(jù)庫(kù)的寫入性能：寫入tps隨著并發(fā)量增加而增加，但上升到一定瓶頸，增速放緩至并發(fā)數(shù)臨界點(diǎn)后 tps會(huì)急劇下滑

• 思考：如果對(duì)性能有更高(超出上述三種存儲(chǔ)介質(zhì)并發(fā)量級(jí))的要求怎么辦？

  • 定制存儲(chǔ)：針對(duì)服務(wù)特點(diǎn)，定制存儲(chǔ)，定制更適合自己業(yè)務(wù)場(chǎng)景的存儲(chǔ)產(chǎn)品。然而一般業(yè)界成熟產(chǎn)品為考慮通用性而會(huì)犧牲部分性能

  • 引入NoSQL

2. ?從單機(jī)到集群的架構(gòu)變遷

• 業(yè)務(wù)上線初期，web服務(wù)規(guī)模較小，一般具備以下特點(diǎn)

• • 服務(wù)原型時(shí)期,用戶基數(shù)小,多種業(yè)務(wù)公用資源,日均寫入百萬(wàn)級(jí)別,讀取千萬(wàn)級(jí)別

  • 數(shù)據(jù)規(guī)模小，單機(jī)性能能夠滿足需求

  • 用戶規(guī)模小，開發(fā)重心偏向迭代速度

    考慮到上述小型業(yè)務(wù)特點(diǎn)，為節(jié)約資源成本及開發(fā)成本，可以采用多個(gè)業(yè)務(wù)混合部署形式

• 當(dāng)用戶增多，數(shù)據(jù)量、訪問(wèn)量升高(2倍以下)，數(shù)據(jù)庫(kù)壓力較大，怎樣在有限程度提高M(jìn)ySQL吞吐量呢？

• • SQL優(yōu)化

  • 硬件升級(jí)

  壓力還在有限的范圍內(nèi)增長(zhǎng)，通過(guò)簡(jiǎn)單、低成本優(yōu)化，可以一定成都上提高有限的服務(wù)性能

• 業(yè)務(wù)持續(xù)發(fā)展，讀取性能出現(xiàn)瓶頸&&各業(yè)務(wù)互相影響，多個(gè)業(yè)務(wù)出 ? ? ?現(xiàn)資源搶占，如何快速解決業(yè)務(wù)搶占問(wèn)題以提高服務(wù)性能？

• • 垂直拆分——按業(yè)務(wù)進(jìn)行數(shù)據(jù)拆分

  ?? ? ? ?按業(yè)務(wù)進(jìn)行拆分，以使業(yè)務(wù)隔離，timeline的壓力增加，不會(huì)影響content數(shù)據(jù)庫(kù)服務(wù)性能；進(jìn)行拆分后，資源增加，服務(wù)性能也相應(yīng)提升。

• 隨著業(yè)務(wù)的繼續(xù)發(fā)展，讀取性能出現(xiàn)瓶頸,讀寫互相影響，如何確保讀請(qǐng)求量的增加，不要影響寫入性能？相反寫入請(qǐng)求量增加如何確保不影響讀取性能？(寫入性能出現(xiàn)問(wèn)題會(huì)造成數(shù)據(jù)丟失)

• 讀寫分離，寫入僅寫master，master與slave自動(dòng)同步；讀取僅以slave作為來(lái)源

?? ? ? ?讀寫分離后，slave僅專注于承擔(dān)讀請(qǐng)求，讀取性能得到優(yōu)化；同里獨(dú)立的master服務(wù)的寫入性能也得到優(yōu)化。

• 一臺(tái)/一對(duì)M-S服務(wù)器性能終歸是很有限的，當(dāng)單實(shí)例服務(wù)性能無(wú)法承載線上的請(qǐng)求量時(shí)，如何進(jìn)行優(yōu)化？

• • 升級(jí)為一主多從架構(gòu)

  • 一個(gè)master承載所有寫入請(qǐng)求，理論上master性能不變

  • 多個(gè)slave分擔(dān)讀取請(qǐng)求，讀取性能提升n倍

• 隨著業(yè)務(wù)量的增長(zhǎng)，服務(wù)出現(xiàn)如下變化：

• 數(shù)據(jù)量增長(zhǎng)，意味著原本的存儲(chǔ)空間不足

• 寫入量增長(zhǎng)，意味著master寫入性能存在瓶頸

• 讀取量增長(zhǎng)，意味著slave讀取性能也存在瓶頸，但通過(guò)擴(kuò)充slave是有限制的：一方面M-S replication性能有風(fēng)險(xiǎn)；另一方面擴(kuò)充slave的成本較高

如何優(yōu)化以解決上述問(wèn)題？

• 水平拆分

?? ? ? ?業(yè)務(wù)經(jīng)歷數(shù)據(jù)量的增長(zhǎng)、讀寫請(qǐng)求量的增長(zhǎng)，數(shù)據(jù)庫(kù)服務(wù)已經(jīng)演進(jìn)為分布式架構(gòu)，一個(gè)業(yè)務(wù)的數(shù)據(jù)，怎樣合理的分布到上述復(fù)雜的分布式數(shù)據(jù)庫(kù)是下一個(gè)需要解決的問(wèn)題

3. ?如何基于上述演進(jìn)到最后的架構(gòu)進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)呢？

• 分布式數(shù)據(jù)庫(kù)設(shè)計(jì)

• hash拆分方式，既按hash規(guī)則，將數(shù)據(jù)讀寫請(qǐng)求分散到多個(gè)實(shí)例上，見上述水平拆分示意圖

• 時(shí)間拆分方式，基于確定好的時(shí)間劃分規(guī)則，將數(shù)據(jù)按時(shí)間段分散存儲(chǔ)再多個(gè)實(shí)例中

數(shù)據(jù)分布到一個(gè)分布式數(shù)據(jù)庫(kù)內(nèi)，一個(gè)實(shí)例存儲(chǔ)1/n的數(shù)據(jù)，一個(gè)實(shí)例只需要一個(gè)數(shù)據(jù)庫(kù)就能夠滿足功能需求。

經(jīng)歷幾年的發(fā)展，數(shù)據(jù)規(guī)模會(huì)成倍增長(zhǎng)，當(dāng)需要再次水平擴(kuò)容(4太→8臺(tái))，需要通過(guò)程序，將數(shù)據(jù)一分為二，數(shù)據(jù)遷移成本較高，需要開發(fā)人員介入。

如果在數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)，一個(gè)就預(yù)先建好2個(gè)數(shù)據(jù)庫(kù) ，每個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)1/n/2的數(shù)據(jù)，需要水平擴(kuò)容時(shí)，即可完整遷移一個(gè)數(shù)據(jù)庫(kù)，而無(wú)需開發(fā)人員干預(yù)。

在一個(gè)數(shù)據(jù)庫(kù)實(shí)例上，建立的多個(gè)數(shù)據(jù)庫(kù)，稱為邏輯庫(kù)。

• 邏輯庫(kù)設(shè)計(jì)

• • 邏輯庫(kù)是相對(duì)與物理庫(kù)而言的概念：物理庫(kù)只數(shù)據(jù)庫(kù)服務(wù)的實(shí)例；邏輯庫(kù)指在一個(gè)數(shù)據(jù)庫(kù)實(shí)例上創(chuàng)建的多個(gè)database

  • 定義邏輯庫(kù)的目的是便于擴(kuò)容。假如4臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，每臺(tái)上的物理庫(kù)包含8個(gè)邏輯庫(kù)，當(dāng)系統(tǒng)出現(xiàn)容量、寫入量瓶頸時(shí)，可以新增一倍即4臺(tái)服務(wù)器，直接以同步方式同步數(shù)據(jù)庫(kù)，而不需要單獨(dú)編寫應(yīng)用程序利用進(jìn)行導(dǎo)入

4. ?基于上述分布式數(shù)據(jù)庫(kù)下的表拆分設(shè)計(jì)方式

• hash拆分方式：按hash規(guī)則將一個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)，分散hash到多張表中

• • 適合數(shù)據(jù)規(guī)模有限的數(shù)據(jù)集

  • 適合增長(zhǎng)速度可控的數(shù)據(jù)集

  結(jié)合數(shù)據(jù)庫(kù)的hash模型如圖：

  • 根據(jù)uid hash到uid所在到數(shù)據(jù)庫(kù)，然后再hash到數(shù)據(jù)庫(kù)_1下的tb_5表

• 按時(shí)間拆分方式，按時(shí)間規(guī)則將同一時(shí)段的數(shù)據(jù)存儲(chǔ)在一張表，多個(gè)時(shí)段時(shí)間存儲(chǔ)在多張表。例如按月劃分，每個(gè)月表存儲(chǔ)一個(gè)月的數(shù)據(jù)，如果需要獲取全部數(shù)據(jù)需要跨越多個(gè)月表

• • 適合存儲(chǔ)增速較快的數(shù)據(jù)集

  • 但查詢數(shù)據(jù)需要跨越多個(gè)時(shí)間段的表

  結(jié)合數(shù)據(jù)庫(kù)的hash模型如圖：

  • 根據(jù)uid hash到所在的數(shù)據(jù)庫(kù)db_1，然后再查找201507 201506獲取兩個(gè)月的數(shù)據(jù)

  思考一個(gè)問(wèn)題：如何能夠快速定位，一個(gè)人的第1000條到1100條數(shù)據(jù)呢？

• 二級(jí)索引快速定位(一級(jí))索引位置

• • 描述數(shù)據(jù)在以及索引中的分布狀況

  • 用于快速定位/縮小查詢范圍

  • 一般情況字段列表：uid, date_time, min_id, count

?? 5. ?當(dāng)一臺(tái)服務(wù)器宕機(jī)怎么辦？

• Slave(一主多從)宕機(jī)？

  • 剩余健康Slave無(wú)風(fēng)險(xiǎn)，則無(wú)需緊急操作，例行修復(fù)

  • 切換流量到容災(zāi)機(jī)房(如果具備容災(zāi)機(jī)房)

  • 緊急擴(kuò)容[優(yōu)先]、重啟、替換

  • 有損降級(jí)部分請(qǐng)求

• Master宕機(jī)？

• 由于master數(shù)據(jù)的唯一性，致使master出現(xiàn)異常會(huì)直接造成數(shù)據(jù)寫入失敗

• • 快速下線master

  • 下線一臺(tái)salve的讀服務(wù)(如果slave性能有風(fēng)險(xiǎn)，則同時(shí)快速擴(kuò)容)

  • 提升slave為master

  • 生效新master與slave的同步機(jī)制

?? 6. ?如此復(fù)雜的分布式數(shù)據(jù)庫(kù)＋數(shù)據(jù)庫(kù)拆分＋數(shù)據(jù)表拆分，client端如何便捷操作呢？

??多數(shù)使用分布式數(shù)據(jù)庫(kù)服務(wù)的團(tuán)隊(duì)，都有各自實(shí)現(xiàn)的數(shù)據(jù)庫(kù)Client組件，微博平臺(tái)采用如下幾個(gè)層級(jí)的組建來(lái)進(jìn)行分布式數(shù)據(jù)庫(kù)操作

? ?

• 獲取TableContainer，獲取所有表定義規(guī)則

• 通過(guò)table name從TableContainer中獲取指定的TableItem

• TableItem關(guān)聯(lián)多個(gè)JdbcTeplate－DataSource

• 通過(guò)TableItem結(jié)合uid、id、date獲取經(jīng)過(guò)hash計(jì)算得到正確的JdbcTemplate及SQL

• 使用JdbcTemplate進(jìn)行SQL操作

7. ?注意事項(xiàng)

• MySQL設(shè)計(jì)應(yīng)該注意的問(wèn)題

  • 表字符集選擇UTF8

  • 存儲(chǔ)引擎使用InnoDB

  • 使用Varchar/Varbinary存儲(chǔ)變長(zhǎng)字符串

  • 不在數(shù)據(jù)庫(kù)中存儲(chǔ)圖片、文件等

  • 每張表數(shù)據(jù)量控制在20000W以下

  • 提前對(duì)業(yè)務(wù)做好垂直拆分

• MySQL查詢應(yīng)該遇到的問(wèn)題

• • 避免使用存儲(chǔ)過(guò)程、觸發(fā)器、函數(shù)等

  • • 讓數(shù)據(jù)庫(kù)做最擅長(zhǎng)的事

    • 降低業(yè)務(wù)耦合度避開服務(wù)端BUG

  • 避免使用大表的JOIN

  • • MySQL最擅長(zhǎng)的是單表的主鍵/索引查詢

    • JOIN消耗較多內(nèi)存,產(chǎn)生臨時(shí)表

  • 避免在數(shù)據(jù)庫(kù)中進(jìn)行數(shù)學(xué)運(yùn)算

  • • MySQL不擅長(zhǎng)數(shù)學(xué)運(yùn)算

    • 無(wú)法使用索引

  • 減少與數(shù)據(jù)庫(kù)的交互次數(shù)

  • • select條件查詢要利用索引

    • 同一字段的條件判定要用in而不要用or

?? 8. ?MySQL練習(xí)題

• 設(shè)計(jì)一個(gè)每秒2000qps，1億條數(shù)據(jù)的用戶基本信息存儲(chǔ)數(shù)據(jù)庫(kù)。完成數(shù)據(jù)庫(kù)設(shè)計(jì)，數(shù)據(jù)庫(kù)搭建，web寫入查詢服務(wù)搭建。

• 定義用戶信息結(jié)構(gòu)：uid，name，age，gender

• 給定2個(gè)mysql實(shí)例，每個(gè)實(shí)例創(chuàng)建2個(gè)數(shù)據(jù)庫(kù)

• 每個(gè)數(shù)據(jù)庫(kù)創(chuàng)建2長(zhǎng)表

• 編寫代碼，以hash形式，實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)、表的數(shù)據(jù)操作

四、Redis

??微博作為web2.0時(shí)代具備代表性的SNS服務(wù)，具備龐大的用戶群體和億級(jí)的活躍用戶，同時(shí)也承擔(dān)著高并發(fā)、低延遲的服務(wù)性能壓力。

??Redis作為NoSQL系列的一個(gè)典型應(yīng)用，以其高成熟度、高可用性、高性能而被用來(lái)解決web2.0時(shí)代關(guān)系型數(shù)據(jù)庫(kù)性能瓶頸問(wèn)題。例如微博的計(jì)數(shù)服務(wù)的請(qǐng)求量以達(dá)到百萬(wàn)級(jí)/s，數(shù)以百計(jì)的關(guān)系型數(shù)據(jù)庫(kù)才能應(yīng)對(duì)如此高的QPS，而且請(qǐng)求耗時(shí)較高且波動(dòng)較大；然而使用Redis這種NoSQL產(chǎn)品，僅僅需要10臺(tái)級(jí)別的集群即可應(yīng)對(duì)，平均請(qǐng)求耗時(shí)5ms以下。

??這一章節(jié)，為大家介紹Redis以及其大規(guī)模集群架構(gòu)。

1. ?Redis簡(jiǎn)介

• Redis是一個(gè)支持內(nèi)存存儲(chǔ)及持久化存儲(chǔ)的K-V存儲(chǔ)系統(tǒng)

• 支持復(fù)雜數(shù)據(jù)結(jié)構(gòu)，相比與Memcached僅支持簡(jiǎn)單的key-value存儲(chǔ)，Redis原生支持幾類常用的存儲(chǔ)結(jié)構(gòu)，例如

• • hash：存儲(chǔ)哈希結(jié)構(gòu)數(shù)據(jù)

  • list：存儲(chǔ)列表數(shù)據(jù)

• 單線程

• 高性能，避免過(guò)多考慮并發(fā)、鎖、上下文切換

• 數(shù)據(jù)一致性好，例如對(duì)一個(gè)計(jì)數(shù)的并發(fā)操作，不會(huì)有‘讀者寫者’問(wèn)題

• 單線程無(wú)法利用多核，單可以通過(guò)啟動(dòng)多個(gè)實(shí)例方式，充分利用多核

• 原生支持Master-Slave

• 過(guò)期機(jī)制

• 被動(dòng)過(guò)期——client訪問(wèn)key時(shí)，判斷過(guò)期時(shí)間選擇是否過(guò)期

• 主動(dòng)過(guò)期——默認(rèn)使用valatile-lru

• • volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

  • volatile-ttl：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選將要過(guò)期的數(shù)據(jù)淘汰

  • volatile-random：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰

  • allkeys-lru：從全部數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰

  • allkeys-random：從全部數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)

• Redis的字典表結(jié)構(gòu)

• • Key字典表hash table結(jié)構(gòu)，有hash結(jié)構(gòu)就意味著需要按需進(jìn)行rehash，rehash的時(shí)間段內(nèi)，對(duì)內(nèi)存是有成倍開銷的

  • Value結(jié)構(gòu)，存儲(chǔ)Key對(duì)應(yīng)的value

  • Expire表結(jié)構(gòu)，存儲(chǔ)key的過(guò)期時(shí)間

  • 額外開銷60B+

  • 持久化方式

  • • AOF

    • Snapshot——RDB文件快照

• 與MC的差異

• 平臺(tái)的定制CounterService

• • 修改hash table為，增量擴(kuò)展式的hash tables，例如每1億個(gè)key存儲(chǔ)在一個(gè)table中，數(shù)據(jù)超過(guò)1億(或者一個(gè)臨界比例)則開辟下一個(gè)1億空間的table

  • 廢棄expire，Redis的主動(dòng)過(guò)期策略無(wú)法像MC的LRU策略確保熱數(shù)據(jù)留存在內(nèi)存中，冷數(shù)據(jù)從緩存剔除，我們多數(shù)場(chǎng)景需要控制Redis中的數(shù)據(jù)量不突破內(nèi)存限制

2. ?Redis的主要數(shù)據(jù)結(jié)構(gòu)

• String (key－value)

• Hash (key－field－value)

• List(key－values)

• Set(key－members)

• SortedSet(key－member－score)

3. ?Redis的分布式部署方案是怎樣的？與MySQL有什么異同

• Reids由于其M-S特性與MySQL類似，因此分布式部署方案同MySQL相當(dāng)

• 單實(shí)例——小型業(yè)務(wù) or 業(yè)務(wù)初期

• 主從——HA、讀寫分離

• 一主多從——讀取性能出現(xiàn)瓶頸

• 數(shù)據(jù)水平拆分——容量不足｜寫入性能瓶頸

• 常用的分布式部署方案

?? 4. ?分布式Redis架構(gòu)如何實(shí)現(xiàn)高可用(HA)？

• 采用M-S高可用方案，原因也式由于其Master-Slave的特性

• 服務(wù)域名化是必要的，目前大型的Redis集群應(yīng)用大多采用域名方式

5. ?基本容量規(guī)劃

• 空間＝key數(shù)量＊單條占用(K-V占用＋額外空間) 用戶空間＝5億用戶＊200B(平均)＝100G 微博計(jì)數(shù)器＝(500億+預(yù)期2年新增300億)＊10B＝800G

• 訪問(wèn)量＝服務(wù)訪問(wèn)量＊單次訪問(wèn)對(duì)資源的hit量 微博計(jì)數(shù)器Feed訪問(wèn)量＝10000/s * 20 ＝ 20萬(wàn)/s

6. ?CounterService

????微博具備龐大的數(shù)據(jù)基數(shù)，因此所需要存儲(chǔ)的數(shù)據(jù)量級(jí)也極其龐大

??例如微博計(jì)數(shù)器，具有百億條紀(jì)錄，全部存儲(chǔ)在Redis中，需要T級(jí)別的空間，成本過(guò)高

因此我們對(duì)Redis進(jìn)行定制化改造，以使其適合多數(shù)數(shù)據(jù)小，大小有固定限制的數(shù)據(jù)

• 優(yōu)化存儲(chǔ)空間

• 采用分段哈希桶的形式，進(jìn)行存儲(chǔ)，避免rehash (分段存儲(chǔ)要求key為遞增序)

• 空間占用優(yōu)化效果

• key：8B

• value：自定義

7. ?如何支持上述分布式架構(gòu)下的client訪問(wèn)？(redis3.0+支持Redis Cluster)

• Reids具有多個(gè)開源的client支持，我們所使用的是Jedis

• Jedis除了提供client外，還提供了操作封裝以及M-S組件

• 我們所使用的Redis系列組件如下：

?? 8. ?Redis練習(xí)題

• 使用Redis，實(shí)現(xiàn)用戶受到的贊列表及贊計(jì)數(shù)功能

• 使用測(cè)試環(huán)境，啟動(dòng)兩個(gè)Redis實(shí)例

• 使用Redis存儲(chǔ)用戶受到的贊列表[{uid, time}..]及贊計(jì)數(shù)uid-count

• 完成贊操作業(yè)務(wù)邏輯，包括贊、取消贊、查看贊列表、查看贊計(jì)數(shù)

五、思考與討論

1. ?Memcache當(dāng)容量到達(dá)瓶頸會(huì) 截取LRU鏈以釋放空間。上文介紹過(guò)Redis的key過(guò)期機(jī)制，思考以下幾個(gè)問(wèn)題：

• Redis滿了會(huì)發(fā)生什么？如何避免發(fā)生上述問(wèn)題呢？

• 為什么我們的定制Redis會(huì)廢棄expire表？

2. ?MySQL與Redis各自適合什么樣的場(chǎng)景？

• 數(shù)據(jù)冷熱？

• 數(shù)據(jù)大小？

• 數(shù)據(jù)量級(jí)？

• 數(shù)據(jù)增長(zhǎng)速度？

• 是否持久化？

• 訪問(wèn)量(read/write)？

• 請(qǐng)求性能要求？

------------------新兵訓(xùn)練營(yíng)簡(jiǎn)介------------------

微博平臺(tái)新兵訓(xùn)練營(yíng)活動(dòng)是微博平臺(tái)內(nèi)部組織的針對(duì)新入職同學(xué)的團(tuán)隊(duì)融入培訓(xùn)課程，目標(biāo)是團(tuán)隊(duì)融入，包括人的融入，氛圍融入，技術(shù)融入。當(dāng)前已經(jīng)進(jìn)行4期活動(dòng)，很多學(xué)員迅速成長(zhǎng)為平臺(tái)技術(shù)骨干。

微博平臺(tái)是非常注重團(tuán)隊(duì)成員融入與成長(zhǎng)的團(tuán)隊(duì)，在這里有人幫你融入，有人和你一起成長(zhǎng)，也歡迎小伙伴們加入微博平臺(tái)，歡迎私信咨詢。

------------------講師簡(jiǎn)介------------------

畢建坤，@bijiankun?微博平臺(tái)及大數(shù)據(jù)部——平臺(tái)研發(fā)系統(tǒng)研發(fā)工程師，2012年7月畢業(yè)于哈爾濱理工大學(xué)，校招入職微博工作至今，先后負(fù)責(zé)微博Feed、贊、評(píng)論等底層服務(wù)研發(fā)以及方案評(píng)審等工作。聚焦大規(guī)模系統(tǒng)的架構(gòu)設(shè)計(jì)與優(yōu)化，以及大規(guī)模系統(tǒng)下的服務(wù)穩(wěn)定性保障。新兵訓(xùn)練營(yíng)第一期學(xué)員。

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

總結(jié)

以上是生活随笔為你收集整理的[转载] 新兵训练营系列课程——海量数据存储基础的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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