🎬 -> 📝 ocztBxbnaQIp7ZIB724myvZZeCqAkDfQeg63IA.txt

[leeguooooo]

https://v26-web.douyinvod.com/f6c2fa017ff1e0d0dc6018f4449ca2d6/6475cf0f/video/tos/cn/tos-cn-ve-15c001-alinc2/ocztBxbnaQIp7ZIB724myvZZeCqAkDfQeg63IA/?a=6383&ch=0&cr=0&dr=0&er=0&cd=0%7C0%7C0%7C0&cv=1&br=440&bt=440&cs=0&ds=4&ft=GN7rKGVVywIiRZm8Zmo~xj7ScoApZ8ai6vrKHcqRcto0g3&mime_type=video_mp4&qs=0&rc=NTQ7ZWg4NzdmMztlODlkaUBpamY1dzc6ZndmazMzNGkzM0A2YGFjYzNeNS8xYWMvYDA2YSNtbWticjRvc2NgLS1kLWFzcw%3D%3D&l=20230530171617758CA2B60B9F29046BF3&btag=e00030000

[github-actions[bot]]

Hi! 👋

Thanks for using my services! ❤️! 🤖 I've received your request and currently working on it.

⚙️ It might take a few minutes 🙏 You can check the progress here

In the meantime, feel free to chat with me ! 😊 I'll notify you as soon as I'm done! 😊

If you find my services helpful, you can support me by buying me a coffee ☕️

[github-actions[bot]]

Mission accomplished! 🥳🥳🥳 Here's the result:

[github-actions[bot]]

ocztBxbnaQIp7ZIB724myvZZeCqAkDfQeg63IA

Summary Text

Original text

ocztBxbnaQIp7ZIB724myvZZeCqAkDfQeg63IA: 當年我還在某個遊戲項目著作開發的時候 從企鵝那邊挖來的遊戲策劃信誓旦旦的說 我們接下來要做的這款遊戲《老少皆宜》 肯定是爆款,要做成全球同服 上線至少過億註冊,十萬人同時在線 要好好規劃設計,當年過億註冊什麼概念 要是放在今天也是個可以媲美原神的存在 我們當時算了下,信它能有一個億的註冊量 考慮到單表放這麼多數據,性能肯定會很慢 於是分了四張表,搞得我熱血沸騰 那天晚上下班,夏天的慘叫的都比平時還要更大聲 我聽著《折葉紅枝》的歌,就算是開著電瓶車 我都感覺自己像是在開高達 一年後,遊戲上線前一天通知運回家機器 怕頂不住,要整夜關注 後來上線了,全球最高在線人數58人 其中有7個是項目組成員 還是夏天,還是同樣的下班路 想哭,但我不能哭 因為騎電瓶車的時候擦眼淚不安全 你幹嘛 今天這個視頻就聊聊數據庫分庫分表 相信在接下來的開發生涯中,你一定會有機會遇到 現在我們假設我們做的就是《原神》這款遊戲 需要對它的數據庫表進行設計 我們通常會在數據表裡記錄玩家角色信息 假設有張user表,一行記錄就是一個玩家 一開始做遊戲demo的時候,通常會先用一張數據表跑就行 老闆看到遊戲demo效果還行,就會考慮立項 對於一款商業級的遊戲來說 一旦項目立項,就需要考慮上線後的玩家人數 假設上線註冊玩家人數過億,全都塞在一張user表裡 MySQL底層B加速的層級結構就可能會變得很高 不同層級的數據頁一般都放在磁盤裡不同的地方 也就是說磁盤IO會變多,查詢性能就會變差 於是我們不得不考慮數據庫分表 這裡的分表分為垂直分表和水平分表兩種 垂直分表的原理比較簡單 一般就是把某幾列拆成一個新表 這樣原來的表就小了,查詢性能就快了 是不是懵了 雖然好像很符合常理 但為什麼拆幾列出去,表查詢就變快了 絕大部分資料說到這裡就結束了 完全不提為什麼 我來告訴你 MySQL底層用的是B加速 而B加速本質上是一個個16K的數據頁實現的 表裡的一行行數據其實是放在數據頁裡 當要查詢數據表裡的某行數據時 就可能要將數據頁從磁盤加載到內存中 也就產生了磁盤IO 這是個很慢的操作 拆幾列出去 那數據表裡的每行數據就會變少 單個16K數據頁就能放入越多的行數 這樣發生查詢時需要的數據頁就會越少 那磁盤IO也會越少 所以性能就會越快 到這裡垂直分表就講完了 下面我們重點說說最常見的水平分表 水平分表有好幾種做法 但不管是哪種 本質上都是將原來的user表 變成user0到userN這樣的N張小表 每一張小表裡只保存了一部分數據 一般是500萬到2000萬 那分表具體怎麼做呢 最常見的就是根據ID取模分表 這是個比較簡單直接的做法 假設我們一共分了兩張表 分別是user0和user1 此時模等於2 我們將輸入的ID與模進行求余數操作 比如ID等於246的時候 2取模得到0 會被寫到user0這張表裡 ID等於135和2取模得到1 於是就能知道 應該寫到user1這張表裡 根據ID取模分表這個方案的優點 是比較簡單 而且讀寫數據都可以很均勻的 分攤到每個分表上 但缺點也比較明顯 如果想要擴展表的個數 比如從兩張表變成三張表 那同樣還是ID等於3的數據 以前3和2取模得到1 所以ID等於3的數據會放在user1表裡 現在3和3取模得到0 那就要放在user0這張表裡 跟原來的user1就對不上了 這就需要考慮數據遷移的問題了 就很頭突 為了避免後續擴展的問題 我見過一些業務 一開始就將數據預估的很大 然後一狠心一跺腳 分成100張表 一張表如果存個2000萬條數據 那100張表就能存20個億的數據了 也不是說這樣不行 就是這個業務直到最後放棄的時候 也就存了幾百條數據 每次打開數據庫表 都能看到茫茫多的user0xx表 就是不太舒服 專業點叫增加了程序員的心智負擔 那有沒有更好的方案 有 根據ID範圍分表 假設我們每張分表都能存放2000萬條數據 那user0xx就存放ID為1到2000萬的數據 user1xx就存放ID在2000萬到4000萬之間的數據 以此類推 假設現在有條數據ID等於3000萬 要讀寫這條數據 就需要將3000萬除以2000萬得到1.5 向下取整得到1 那就可以知道這條數據屬於user1xx表 於是就去讀寫user1xx表就行了 根據ID範圍去分表 就能很好的解決 ID取模時數據表的擴展問題 數據少的時候表也少 隨著數據增多 表會慢慢變多 這樣數據表就可以無限擴展了 但根據ID範圍去分表就沒有缺點嗎 也不是 舉個例子 假設原神新註冊玩家的ID是不斷加1的 那麼在某段時間內 ID會集中在某個分片範圍內 比如在4000萬到6000萬的範圍裡 數據會不斷寫入這個特定的分表中 這樣雖然你有很多個分表 但大部分時候可能只有那麼一兩張分表 會被頻繁的讀寫 其他表都很空閒 像這樣一表有難八方圍觀的情況 就沒有起到分攤數據讀寫壓力的效果 這就是所謂的讀寫熱點問題 解決讀寫熱點問題 最簡單的方案就是讓ID變成隨機 這樣ID就能隨機分散到所有表上 分攤讀寫壓力 除此之外 還可以用我接下來要介紹的第三種分表方法 同時結合ID取模分表和ID範圍分表的方案 我們可以先用ID範圍去分表 然後在某個ID範圍內引入取模的功能 比如以前2000萬到4000萬是user1表 現在可以在這個範圍裡再分成多個表 比如引入user1-0 user1-1 在這兩個表裡進行取模操作 一個例子還是ID等於3000萬的這條數據 根據ID範圍分表會被分到user1表裡 然後再進行取模 3000萬和2取模得到0 也就是說讀寫user1-0這張表 這樣就可以將讀寫單表分攤為讀寫多表 這還只是在一個數據庫裡做分表 如果範圍再搞大點 還能在多個數據庫裡做分表 也就是所謂的分庫分表 如果我們將不同的庫部署到不同的機器上 就能充分利用各個機器的性能 不管是單庫分表還是分庫分表 都需要通過一個中間層邏輯做路由 我們把這部分邏輯封裝起來 放在數據庫和業務代碼之間 這樣對於業務代碼來說 他只知道自己在讀寫一張user表 根本不知道底下還分了那麼多張小表 對於數據庫來說 他並不知道自己被分表了 他只知道有那麼幾張表 只是正好名字長得比較像而已 還真的就應了那句話 沒有什麼是加中間層不能解決的 如果有就多加一層 至於這個中間層的實現方式就更靈活了 它可以像第三方ORM庫那樣加在業務代碼中 但這樣就需要根據不同語言 實現不同的代碼庫比較繁瑣 所以不少大廠都選擇在mySQL和業務代碼之間 加個Proxy服務去做這個中間層分表路由邏輯 這樣就不需要關心上游服務用的是什麼語言了 你學廢了嗎 但光講這些其實我覺得沒什麼意思 還不夠硬還不夠傑克 你聽說過讀擴散問題嗎 你知道分庫分表為什麼會引發讀擴散問題嗎 怎麼解決讀擴散問題呢 點贊破500馬上燃燒生命為大家安排一下 算了算了我現在就燃燒生命 我們上面提到的好幾種分表方式 都用了ID這一列作為分表的依據 這其實就是所謂的分片鍵 實際上我們一般也是用的數據庫組件作為分片鍵 這樣理想情況下我們已知一個ID 不管是根據哪種規則 我們都能很快定位到該讀哪個分表 但很多情況下我們的查詢又不是只查組件 比如原神數據庫表裡有那麼一列 是用來保存用戶名字的 並且加了個普通索引 假設我現在需要查詢名字叫小白的用戶有哪些 我需要執行上面的sql語句 主語Name並不是分片鍵 我們沒法定位到具體要到哪個分表去執行這條sql 於是就會對所有的分表都並發執行上面的sql語句 假設我有100張分表 就執行100次sql查詢 如果我有200張表 就執行200次sql查詢 隨著我的表越來越多 查詢的次數也會越來越多 這就是所謂的讀擴散問題 這是個比較有趣的問題 它確實是個問題 但大部分的業務不會去處理它 讀100次怎麼了 業務不賺錢 人和代碼有一個能跑就行 話是這麼說沒錯 該面試官問你的時候 你得知道怎麼說 這個問題的核心在於 組件是分片鍵 而普通索引列並不分片 那好辦 我們再單獨建個新的分片表 這個新表裡的列 就只有舊表的組件ID和普通索引列 重點來了 這次換普通索引列來做分片鍵 這樣當我們要查詢普通索引列時 先到這個新的分片表裡做一次查詢 就能迅速定位到對應的組件ID 然後再拿組件ID去舊的分片表裡 再查一次數據 這樣就從漫無目的的全表擴散查詢 縮減為只查固定幾個表了 但這個做法的缺點也比較明顯 你需要維護兩套表 並且普通索引列更新時 要兩張表同時進行更改 有一定的開發量 那麼有沒有更簡單的方案呢 歡迎留言討論 點贊破500 答案就發到評論區 能看到這裡 我猜你肯定是一個 有技術追求的程序員 雖然天天寫代碼 跟前後端打交道 都用到網絡通信 但遇到問題的時候 你是不是也會感到束手無策 比如502問題怎麼排查 連一個不存在的IP地址 內核到底會發生什麼 如果你對這些感興趣 又對厚厚的網絡黑皮書束手無策 那一定要看看左下角的教程 你是一個有判斷力的人 你應該知道你的時間很寶貴 與其花時間自己摸索 不如直接看一下 過來人的經驗總結 如果他能在面試或工作中幫到你 那我覺得 這件事情 太酷了 我是小白 下期會講一個很特別的話題 先賣個關子 我們下期見

[github-actions[bot]]

🙌

If you find my services helpful, you can support me by buying me a coffee ☕️ Thanks for using my services! ❤️