字節面試:百億級存儲,怎麼設計?只是分庫分表?

文章很長,且持續更新,建議收藏起來,慢慢讀!瘋狂創客圈總目錄 博客園版 爲您奉上珍貴的學習資源 :

免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ,幫你 實現技術自由,完成職業升級, 薪酬猛漲!加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷1)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷2)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷3)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

免費贈送 資源寶庫: Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取


字節面試:百億級存儲,怎麼設計?只是分庫分表?

尼恩特別說明: 尼恩的文章,都會在 《技術自由圈》 公號 發佈, 並且維護最新版本。 如果發現圖片 不可見, 請去 《技術自由圈》 公號 查找

尼恩:百億級數據存儲架構起源

在40歲老架構師 尼恩的讀者交流羣(50+)中,經常性的指導小夥伴們改造簡歷。

經過尼恩的改造之後,很多小夥伴拿到了一線互聯網企業如得物、阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試機會,拿到了大廠機會。

這些機會的來源,主要是尼恩給小夥伴 改造了簡歷,植入了亮點項目、黃金項目。

尼恩的 亮點項目、黃金項目 需要持續迭代。

下一個亮點項目、黃金項目是:百億級數據存儲架構。

同時,小夥伴在面試時,經常遇到這個面試難題。比如,前幾天一個小夥伴面試字節,就遇到了這道題

字節面試:百億級數據存儲,怎麼設計?只是分庫分表嗎?

於是,尼恩組織小夥伴開始研究和 設計 《百億級數據存儲架構》,幫助大家打造一個新的黃金項目,實現大廠的夢想。

百億級數據存儲架構,只有分庫分表嗎?

很多的小夥伴來諮詢尼恩, 百億級數據存儲怎麼架構,說他們的面試中,都遇到的。

比如,前幾天一個小夥伴面試字節,就遇到了這道題

字節面試:百億級數據存儲,怎麼設計?

他們回答了分庫分表。

大家都知道,當一個表(比如t_order) 達到500萬條或2GB時,需要考慮水平分表。

這個雖然是常識了,但是面試官不滿意。

很多的小夥伴來諮詢尼恩,爲什麼?

這裏,尼恩用20年的技術功力,給大家做一個徹底性、系統化梳理,幫助大家吊打面試。

從0到1, 百億級數據存儲架構,怎麼設計?

咱們的生產需求上,百億級數據存儲架構, 一般來說,需要具備以下四個能力:

  • 高併發的在線ACID事務 (分庫分表)
  • 高併發的在線搜索 (倒排表副本)
  • 海量數據的離線處理 (高可用+全量副本)
  • 冗餘表雙寫能力 (不同業務維度的副本)

其中,上面的冗餘表雙寫能力, 也就是 高併發的 多業務維度 在線ACID 事務處理能力

比如在海量訂單場景,

  • 用戶維度的在線ACID 事務訂單處理能力,需要進行用戶維度的分庫分表。
  • 商家維度的在線ACID 事務訂單處理能力,需要進行商家維度的分庫分表。

如果不需要 不同業務維度的 在線ACID 事務訂單處理能力,那麼冗餘表雙寫能力 這個是可選項。

這是引入這麼多的副本,有好處,也有壞處:

  • 好處是滿足各種各樣的處理要求
  • 壞處是我們要維護多個副本之間的數據一致。

百億級數據存儲架構,多副本之間的數據一致如何實現?

便於商品的聚合搜索,高速搜索,採用兩大優化方案:

  • 把商品數據冗餘存儲在Elasticsearch中,實現高速搜索
  • 把商品數據冗餘存儲在redis 中,實現高速緩存

在這裏插入圖片描述

很多的時候,要求保持很高的數據一致性。

比如:

  • 要求 mysql 與 es 做到秒級別的數據同步。
  • 要求 mysql 與 redis 做到秒級別的數據同步。
  • 要求 mysql 與 hbase 做到秒級別的數據同步。

接下來,以 mysql 與 es 的數據一致,作爲業務場景進行分析, 其他的場景比如mysql 與 redis 的數據一致性方案,都是差不多的。

只要大家能把下面的 5大數據一致性方案, 滔滔不絕的說出來,面試官一定會愛到 “不能自已、口水直流”。

方案一:同步雙寫

同步雙寫是一種最爲簡單的方式,在將數據寫到 MySQL 時,同時將數據寫到 ES。

在這裏插入圖片描述

同步雙寫優點:

這種方式簡單粗暴,實時寫入能做到秒級。

同步雙寫缺點:

  • 業務耦合,這種方式代碼侵入性強,商品的管理中耦合大量數據同步代碼,要在之前寫 mysql 的地方加寫 es 的代碼。以後寫 mysql 的地方也要加寫 es 的代碼。
  • 影響性能,寫入兩個存儲,響應時間變長,本來 MySQL 的性能不是很高,再加一個 ES,系統的性能必然會下降。
  • 不便擴展:搜索可能有一些個性化需求,需要對數據進行聚合,這種方式不便實現
  • 高風險:存在雙寫失敗丟數據風險

方案2:異步雙寫

同步操作性能低,異步性能高。

異步雙寫,分爲兩種:

  • 使用內存隊列(如阻塞隊列)異步
  • 使用消息隊列進行異步

方案2.1 使用內存隊列(如阻塞隊列)異步

先把商品數據寫入DB後,然後把 數據寫入 BlockingQueue 阻塞隊列

消費線程異步從 drain 數據,batch 寫入 ElasticSearch, 保證數據一致性

在這裏插入圖片描述

方案2.2 使用消息隊列(如阻塞隊列)異步

如果內存隊列裏邊數據丟失,那麼es 當中的數據和DB就不一致了

如何解決呢?

  • 方式1:定期同步 db數據到 es ,同步週期一般比較長,這裏有比較長時間的不一致
  • 方式2: 保證隊列的可靠性,使用高可靠消息隊列

生產場景中,一般會有一個搜索服務,由搜索服務去訂閱商品變動的消息,來完成同步。

在這裏插入圖片描述

異步雙寫優點:

  • 性能高;
  • 不易出現數據丟失問題,主要基於 MQ 消息的消費保障機制,比如 ES 宕機或者寫入失敗,還能重新消費 MQ 消息;
  • 多源寫入之間相互隔離,便於擴展更多的數據源寫入。

異步雙寫缺點:

  • 硬編碼問題,接入新的數據源需要實現新的消費者代碼;
  • 系統複雜度增加,引入了消息中間件;
  • MQ是異步消費模型,用戶寫入的數據不一定可以馬上看到,造成延時。

方案三:定期同步

爲了保證 DB和ES /HBase 數據一致性,包括兩個方面:

  • 增量數據一致性
  • 全量數據一致性

在這裏插入圖片描述

爲了保證 DB和ES /HBase 的全量數據一致性, 往往需要進行定期的全量數據同步

在這裏插入圖片描述

數據增量數據,很少,並且,一致性要求不高,那麼可以把增量數據一致性行的 同步雙寫、異步雙寫去掉。

在這裏插入圖片描述

定期同步優點:

實現比較簡單

定期同步缺點:

  • 實時性難以保證
  • 對存儲壓力較大

當然,增量數據,可以考慮用定時任務來處理:

  1. 數據庫的相關表中增加一個字段爲 timestamp 的字段,任何 CURD 操作都會導致該字段的時間發生變化;
  2. 原來程序中的 CURD 操作不做任何變化;
  3. 增加一個定時器程序,讓該程序按一定的時間週期掃描指定的表,把該時間段內發生變化的數據提取出來;
  4. 逐條寫入到 ES 中。

方案四:數據訂閱

如果要提高實時性,又要低入侵, 可以利用 MySQL 的 Binlog 來進行同步。

MySQL通過binlog訂閱實現主從同步,canal Server 是一個僞裝的slave節點,接收到binlog日誌後,發送到MQ, 其他的 存儲消費 MQ裏邊 的binlog日誌,實現數據訂閱。

架構圖如下

在這裏插入圖片描述

這種方式和異步雙寫比較像,但是有兩個優點:

  • 第一降低了商品服務的入侵性,
  • 第二數據的實時性更好。

所以使用數據訂閱:

  • 優點:
    • 業務入侵較少
    • 實時性較好

至於數據訂閱框架的選型,主流的大體上是這些:

Cancal Maxwell Python-Mysql-Rplication
開源方 阿里巴巴 Zendesk 社區
開發語言 Java Java Python
活躍度 活躍 活躍 活躍
高可用 支持 支持 不支持
客戶端 Java/Go/PHP/Python/Rust Python
消息落地 Kafka/RocketMQ 等 Kafka/RabbitNQ/Redis 等 自定義
消息格式 自定義 JSON 自定義
文檔詳略 詳細 詳細 詳細
Boostrap 不支持 支持 不支持

注意,尼恩的100Wqps三級緩存組件架構實操中,也介紹了,這種架構,存在秒級延遲。

如果不允許有秒級延遲的場景,不能使用這種架構。

具體請參見 尼恩的100Wqps三級緩存組件架構實操。

方案五:冗餘表的同步雙寫/異步雙寫

爲什麼要有冗餘表

當t_order表達到500萬條或2GB時需要考慮水平分表,進行水平分表需要根據某個列進行分割,假設根據userId分割。用戶查詢自己的訂單攜帶着userId,因此能夠定位到具體哪張表。

而商家查詢者自己店鋪的訂單,沒辦法確定userId,只能訪問一遍所有的分表再合併結果,效率非常低。

爲了加快商家端的查詢,可以冗餘一份訂單表,這份冗餘表根據merchantId切分,商家訪問冗餘表,效率就很好。

這是引入冗餘表的好處,壞處是我們要維護普通表和冗餘表的數據一致。

冗餘表的同步雙寫實現方案

在這裏插入圖片描述

更新t_order的操作要執行兩次,一次更新普通表,一次更新冗餘表,寫兩次。
優點:

  • 實現簡單,由一次寫變爲兩次寫
  • 容易維護數據的一致性

缺點:

  • 代碼冗餘,第二次寫跟第一次寫的代碼類似,而且每個更新的地方都要寫兩次
  • 請求處理時間變長

冗餘表的異步雙寫實現方案:

在這裏插入圖片描述

更新請求過來,寫一次數據庫,再發送一條消息到消息中間件,返回響應。消費者拉取消息進行寫操作。
優點:

  • 處理時間是單次寫

缺點

  • 較複雜,引入了消息中間件
  • 不容易維護數據的一致性

方案六: ETL數據同步

在這裏插入圖片描述

一致性分爲兩種:

  • 增量一致性: 前面的的雙寫方案,主要是保持增量數據的一致性。

  • 全量一致性: ETL數據同步主要用於同步全量數據。

MySQL數據全量同步到Redis、MySQL同步到hbase、MySQL同步到es、或機房同步、主從同步等,都可以考慮使用elt工具。

什麼是etl 工具呢?

ETL,是英文 Extract-Transform-Load 的縮寫,用來描述將數據從來源端經過抽取(extract)、轉換(transform)、加載(load)至目的端的過程。ETL一詞較常用在數據倉庫,但其對象並不限於數據倉庫。

ETL是構建數據倉庫的重要一環,用戶從數據源抽取出所需的數據,經過數據清洗,最終按照預先定義好的數據倉庫模型,將數據加載到數據倉庫中去。

常用的etl工具有: databus、canal (方案四用了這個組件,有etl 的部分功能)、otter 、kettle 等

下面以 databus爲例,介紹一下。

Databus 是一個低延遲、可靠的、支持事務的、保持一致性的數據變更抓取系統。由 LinkedIn 於 2013 年開源。

Databus 通過挖掘數據庫日誌的方式,將數據庫變更實時、可靠的從數據庫拉取出來,業務可以通過定製化 client 實時獲取變更並進行其他業務邏輯。

特點:

  • 多數據源:Databus 支持多種數據來源的變更抓取,包括 Oracle 和 MySQL。
  • 可擴展、高度可用:Databus 能擴展到支持數千消費者和事務數據來源,同時保持高度可用性。
  • 事務按序提交:Databus 能保持來源數據庫中的事務完整性,並按照事務分組和來源的提交順尋交付變更事件。
  • 低延遲、支持多種訂閱機制:數據源變更完成後,Databus 能在毫秒級內將事務提交給消費者。同時,消費者使用D atabus 中的服務器端過濾功能,可以只獲取自己需要的特定數據。
  • 無限回溯:對消費者支持無限回溯能力,例如當消費者需要產生數據的完整拷貝時,它不會對數據庫產生任何額外負擔。當消費者的數據大大落後於來源數據庫時,也可以使用該功能。

再看看 Databus 的系統架構。

Databus 由 Relays、bootstrap 服務和 Client lib 等組成,Bootstrap 服務中包括 Bootstrap Producer 和 Bootstrap Server。
在這裏插入圖片描述

  • 快速變化的消費者直接從 Relay 中取事件;
  • 如果一個消費者的數據更新大幅落後,它要的數據就不在 Relay 的日誌中,而是需要請求 Bootstrap 服務,返回的將會是自消費者上次處理變更之後的所有數據變更快照。

開源地址:https://github.com/linkedin/databus

從0到1, 百億級數據存儲架構,怎麼設計?

從0到1, 百億級數據存儲架構,40歲老架構尼恩團隊,計劃用一個系列的文章幫大家實現這個架構難題,這個系列還會錄成視頻,並輔導大家寫入簡歷。

這個系列包括:

  • 高併發搜索篇:從0到1, 從入門到 ElasticSearch 工業級使用
  • 100億級任務調度篇:從0到1, 從入門到 XXLJOB 工業級使用
  • 100億級海量存儲篇:從0到1, 從入門到 HABSE 工業級使用
  • 100億級離線計算篇:從0到1, 從入門到 Flink 工業級使用

已經發布的文章包括:

100億級任務調度篇:從0到1, 從入門到 XXLJOB 工業級使用

說在最後:有問題找老架構取經

百億級數據存儲架構,一定是一個超級牛掰的簡歷亮點項目,黃金項目,稍微晚點把全量的架構方案和視頻進行發佈。

這個項目寫入簡歷,面試的時候如果大家能對答如流,如數家珍,基本上 面試官會被你 震驚到、吸引到。

最終,讓面試官愛到 “不能自已、口水直流”。offer, 也就來了。

在面試之前,建議大家系統化的刷一波 5000頁《尼恩Java面試寶典》V174,在刷題過程中,如果有啥問題,大家可以來 找 40歲老架構師尼恩交流。

另外,如果沒有面試機會,可以找尼恩來幫扶、領路。

  • 大齡男的最佳出路是 架構+ 管理
  • 大齡女的最佳出路是 DPM,

圖片

女程序員如何成爲DPM,請參見:

DPM (雙棲)陪跑,助力小白一步登天,升格 產品經理+研發經理

領跑模式,尼恩已經指導了大量的就業困難的小夥伴上岸。

前段時間,領跑一個40歲+就業困難小夥伴拿到了一個年薪100W的offer,小夥伴實現了 逆天改命

技術自由的實現路徑:

實現你的 架構自由:

喫透8圖1模板,人人可以做架構

10Wqps評論中臺,如何架構?B站是這麼做的!!!

阿里二面:千萬級、億級數據,如何性能優化? 教科書級 答案來了

峯值21WQps、億級DAU,小遊戲《羊了個羊》是怎麼架構的?

100億級訂單怎麼調度,來一個大廠的極品方案

2個大廠 100億級 超大流量 紅包 架構方案

… 更多架構文章,正在添加中

實現你的 響應式 自由:

響應式聖經:10W字,實現Spring響應式編程自由

這是老版本 《Flux、Mono、Reactor 實戰(史上最全)

實現你的 spring cloud 自由:

Spring cloud Alibaba 學習聖經》 PDF

分庫分表 Sharding-JDBC 底層原理、核心實戰(史上最全)

一文搞定:SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關係(史上最全)

實現你的 linux 自由:

Linux命令大全:2W多字,一次實現Linux自由

實現你的 網絡 自由:

TCP協議詳解 (史上最全)

網絡三張表:ARP表, MAC表, 路由表,實現你的網絡自由!!

實現你的 分佈式鎖 自由:

Redis分佈式鎖(圖解 - 秒懂 - 史上最全)

Zookeeper 分佈式鎖 - 圖解 - 秒懂

實現你的 王者組件 自由:

隊列之王: Disruptor 原理、架構、源碼 一文穿透

緩存之王:Caffeine 源碼、架構、原理(史上最全,10W字 超級長文)

緩存之王:Caffeine 的使用(史上最全)

Java Agent 探針、字節碼增強 ByteBuddy(史上最全)

實現你的 面試題 自由:

4800頁《尼恩Java面試寶典 》 40個專題

免費獲取11個技術聖經PDF:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章