海量數(shù)據(jù)存儲基礎(chǔ)

2018-02-24 15:46 更新

原文出處:http://weibo.com/p/1001643874615465508614
作者:畢建坤@bijiankun

document/2015-09-14/55f667eec97d8

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

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

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

課程大綱:

一、課程目標(biāo)

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

2. ?理解MySQL、Redis、HBase基本實現(xiàn)機制、特性、適用場景

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

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

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

6. ?了解平臺幾種典型案例

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

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

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

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

  • 查詢語言SQL,insert delete update select

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

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

    • MySQL

    • Oracle

    • DB2

    • SQL Server
  • 性能

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

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

    • 常見的SSD磁盤服務(wù)器,單機讀取性能可達萬級/s

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

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

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

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

  • 性能

? ? 業(yè)界使用的NoSQL多為內(nèi)存集中型服務(wù),受限于I/O及網(wǎng)絡(luò),通常請求響應(yīng)時間在毫秒級別,單機QPS在10萬級別(與數(shù)據(jù)大小及存儲復(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)存存儲;而Redis提供支持復(fù)雜結(jié)構(gòu)(List、Hash等)的內(nèi)存及持久化存儲

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

  • Document(MongoDb)

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

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

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

三、MySQL與MySQL分布式架構(gòu)設(shè)計

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

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

1. ?MySQL簡介

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

  • 使用SQL作為查詢語言

  • 開源

  • 存儲引擎

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

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

  • 滿足ACID特性

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

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

  • 服務(wù)、端口、實例,都是指 服務(wù)端啟動的一個MySQL數(shù)據(jù)庫

  • 性能

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

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

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

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

    • 引入NoSQL

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

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

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

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

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

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

  • 當(dāng)用戶增多,數(shù)據(jù)量、訪問量升高(2倍以下),數(shù)據(jù)庫壓力較大,怎樣在有限程度提高MySQL吞吐量呢?

    • SQL優(yōu)化

    • 硬件升級

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

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

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

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

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

  • 讀寫分離,寫入僅寫master,master與slave自動同步;讀取僅以slave作為來源

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

  • 一臺/一對M-S服務(wù)器性能終歸是很有限的,當(dāng)單實例服務(wù)性能無法承載線上的請求量時,如何進行優(yōu)化?

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

    • 一個master承載所有寫入請求,理論上master性能不變

    • 多個slave分擔(dān)讀取請求,讀取性能提升n倍

  • 隨著業(yè)務(wù)量的增長,服務(wù)出現(xiàn)如下變化:

  • 數(shù)據(jù)量增長,意味著原本的存儲空間不足

  • 寫入量增長,意味著master寫入性能存在瓶頸

  • 讀取量增長,意味著slave讀取性能也存在瓶頸,但通過擴充slave是有限制的:一方面M-S replication性能有風(fēng)險;另一方面擴充slave的成本較高

如何優(yōu)化以解決上述問題?

  • 水平拆分

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

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

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

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

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

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

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

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

在一個數(shù)據(jù)庫實例上,建立的多個數(shù)據(jù)庫,稱為邏輯庫。

  • 邏輯庫設(shè)計

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

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

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

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

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

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

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

    • 根據(jù)uid hash到uid所在到數(shù)據(jù)庫,然后再hash到數(shù)據(jù)庫_1下的tb_5表
  • 按時間拆分方式,按時間規(guī)則將同一時段的數(shù)據(jù)存儲在一張表,多個時段時間存儲在多張表。例如按月劃分,每個月表存儲一個月的數(shù)據(jù),如果需要獲取全部數(shù)據(jù)需要跨越多個月表

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

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

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

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

    思考一個問題:如何能夠快速定位,一個人的第1000條到1100條數(shù)據(jù)呢?

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

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

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

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

?? 5. ?當(dāng)一臺服務(wù)器宕機怎么辦?

  • Slave(一主多從)宕機?

    • 剩余健康Slave無風(fēng)險,則無需緊急操作,例行修復(fù)

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

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

    • 有損降級部分請求
  • Master宕機?

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

    • 快速下線master

    • 下線一臺salve的讀服務(wù)(如果slave性能有風(fēng)險,則同時快速擴容)

    • 提升slave為master

    • 生效新master與slave的同步機制

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

??多數(shù)使用分布式數(shù)據(jù)庫服務(wù)的團隊,都有各自實現(xiàn)的數(shù)據(jù)庫Client組件,微博平臺采用如下幾個層級的組建來進行分布式數(shù)據(jù)庫操作

? ?

  • 獲取TableContainer,獲取所有表定義規(guī)則
  • 通過table name從TableContainer中獲取指定的TableItem
  • TableItem關(guān)聯(lián)多個JdbcTeplate-DataSource
  • 通過TableItem結(jié)合uid、id、date獲取經(jīng)過hash計算得到正確的JdbcTemplate及SQL
  • 使用JdbcTemplate進行SQL操作

7. ?注意事項

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

    • 表字符集選擇UTF8

    • 存儲引擎使用InnoDB

    • 使用Varchar/Varbinary存儲變長字符串

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

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

    • 提前對業(yè)務(wù)做好垂直拆分
  • MySQL查詢應(yīng)該遇到的問題

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

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

      • 降低業(yè)務(wù)耦合度避開服務(wù)端BUG
    • 避免使用大表的JOIN

      • MySQL最擅長的是單表的主鍵/索引查詢

      • JOIN消耗較多內(nèi)存,產(chǎn)生臨時表
    • 避免在數(shù)據(jù)庫中進行數(shù)學(xué)運算

      • MySQL不擅長數(shù)學(xué)運算

      • 無法使用索引
    • 減少與數(shù)據(jù)庫的交互次數(shù)

      • select條件查詢要利用索引

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

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

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

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

  • 給定2個mysql實例,每個實例創(chuàng)建2個數(shù)據(jù)庫

  • 每個數(shù)據(jù)庫創(chuàng)建2長表

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

四、Redis與Redis分布式架構(gòu)設(shè)計

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

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

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

1. ?Redis簡介

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

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

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

    • list:存儲列表數(shù)據(jù)
  • 單線程

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

  • 數(shù)據(jù)一致性好,例如對一個計數(shù)的并發(fā)操作,不會有‘讀者寫者’問題

  • 單線程無法利用多核,單可以通過啟動多個實例方式,充分利用多核

  • 原生支持Master-Slave

  • 過期機制

  • 被動過期——client訪問key時,判斷過期時間選擇是否過期

  • 主動過期——默認使用valatile-lru

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

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

    • volatile-random:從已設(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)就意味著需要按需進行rehash,rehash的時間段內(nèi),對內(nèi)存是有成倍開銷的

    • Value結(jié)構(gòu),存儲Key對應(yīng)的value

    • Expire表結(jié)構(gòu),存儲key的過期時間

    • 額外開銷60B+

    • 持久化方式

      • AOF

      • Snapshot——RDB文件快照
  • 與MC的差異

  • 平臺的定制CounterService

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

    • 廢棄expire,Redis的主動過期策略無法像MC的LRU策略確保熱數(shù)據(jù)留存在內(nèi)存中,冷數(shù)據(jù)從緩存剔除,我們多數(shù)場景需要控制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)

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

  • 主從——HA、讀寫分離

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

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

  • 常用的分布式部署方案

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

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

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

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

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

  • 訪問量=服務(wù)訪問量*單次訪問對資源的hit量 微博計數(shù)器Feed訪問量=10000/s * 20 = 20萬/s

6. ?CounterService

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

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

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

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

  • 采用分段哈希桶的形式,進行存儲,避免rehash (分段存儲要求key為遞增序)

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

  • key:8B

  • value:自定義

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

  • Reids具有多個開源的client支持,我們所使用的是Jedis

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

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

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

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

  • 使用測試環(huán)境,啟動兩個Redis實例

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

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

五、思考與討論

1. ?Memcache當(dāng)容量到達瓶頸會 截取LRU鏈以釋放空間。上文介紹過Redis的key過期機制,思考以下幾個問題:

  • Redis滿了會發(fā)生什么?如何避免發(fā)生上述問題呢?

  • 為什么我們的定制Redis會廢棄expire表?

2. ?MySQL與Redis各自適合什么樣的場景?

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

  • 數(shù)據(jù)大???

  • 數(shù)據(jù)量級?

  • 數(shù)據(jù)增長速度?

  • 是否持久化?

  • 訪問量(read/write)?

  • 請求性能要求?


新兵訓(xùn)練營簡介

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

微博平臺是非常注重團隊成員融入與成長的團隊,在這里有人幫你融入,有人和你一起成長,也歡迎小伙伴們加入微博平臺,歡迎私信咨詢。

講師簡介

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

以上內(nèi)容是否對您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號
微信公眾號

編程獅公眾號