如何使用 TiDB 簡化技術(shù)架構(gòu)

LiveMe 有一個(gè)類似朋友圈功能的場景，這個(gè)業(yè)務(wù)中存在兩個(gè)技術(shù)難點(diǎn)：第一是對(duì)于數(shù)據(jù)的無限量增長存儲(chǔ)如何實(shí)現(xiàn)擴(kuò)容；第二是數(shù)據(jù)的冷熱分離，這又涉及到數(shù)據(jù)成本的問題。

以用戶發(fā) Twitter 的場景舉例：如果用戶發(fā)了一條 Twitter，它會(huì)寫入到自己所有的關(guān)注列表，比如有 100 個(gè)粉絲，就寫入 100 條，如果有 10 萬粉絲就需要寫入 10 萬條數(shù)據(jù)，這是一個(gè)典型的寫擴(kuò)散場景。這個(gè)場景帶來的效果是數(shù)據(jù)爆炸半徑非常大，如果某流量網(wǎng)紅發(fā)一條 Twitter ，數(shù)據(jù)寫入量會(huì)非常大，因此需要一個(gè)能夠接近于無限擴(kuò)容的存儲(chǔ)機(jī)制才可以實(shí)現(xiàn)這個(gè)場景。

Twitter 是通過維護(hù)一個(gè) redis-cluster 來解決 feed 分發(fā)的存儲(chǔ)。LiveMe 的技術(shù)團(tuán)隊(duì)也想到使用這種技術(shù)架構(gòu)，技術(shù)團(tuán)隊(duì)經(jīng)過選型考慮使用 codis 集群來做存儲(chǔ)，但通過對(duì)成本的考量，認(rèn)為這個(gè)方案是不可行的，大量的 feed 冷數(shù)據(jù)存儲(chǔ)在 codis 這樣的內(nèi)存密集型數(shù)據(jù)庫中，成本非常高。因此，技術(shù)團(tuán)隊(duì)面臨的挑戰(zhàn)是如何用低成本的方式去實(shí)現(xiàn)一個(gè)寫擴(kuò)散的場景。

基于 TiDB 解決方案，LiveMe 技術(shù)團(tuán)隊(duì)在上述寫擴(kuò)散場景中，把擴(kuò)散寫入的部分替換成了 TiDB，使用一張數(shù)據(jù)庫表來存儲(chǔ)所有 feed 的寫入關(guān)系，比如用戶有 100 萬粉絲，就在數(shù)據(jù)庫里插入 100 萬條數(shù)據(jù)?；?TiDB 的分布式數(shù)據(jù)庫特性，幫助 LiveMe 簡單高效地解決了數(shù)據(jù)增長擴(kuò)容問題。

基于此技術(shù)架構(gòu)，技術(shù)團(tuán)隊(duì)簡化了一個(gè)典型的 redis 緩存設(shè)計(jì)問題，熱數(shù)據(jù)放在 redis 中，用 mget 來獲取。冷數(shù)據(jù)放在 TiDB 中，用 select in 查詢，這樣做數(shù)據(jù)冷熱區(qū)分就非常容易，甚至可以實(shí)現(xiàn)一個(gè)簡單的布隆過濾器來了解哪些數(shù)據(jù)在熱數(shù)據(jù)，哪些數(shù)據(jù)在冷數(shù)據(jù)里。以此減少無效數(shù)據(jù)的回源，更高效獲取數(shù)據(jù)。

LiveMe 的朋友圈功能基于 TiDB 的分布式存儲(chǔ)特性進(jìn)行技術(shù)改造后， feed 表從 2021 年中旬上線至今已經(jīng)達(dá)到數(shù)十億數(shù)據(jù)寫入，現(xiàn)在的數(shù)據(jù)量單表 39 億條。因?yàn)檫@些數(shù)據(jù)是永久保留不會(huì)刪除的，所以該數(shù)據(jù)也會(huì)一直增長。

未來規(guī)劃

未來， LiveMe 將會(huì)繼續(xù)嘗試 TiDB 在更多業(yè)務(wù)中，一方面會(huì)做數(shù)據(jù)庫管理開發(fā)；另一方面將對(duì)于強(qiáng)事務(wù)依賴交易型的業(yè)務(wù)嘗試使用 TiDB，為直播電商場景做技術(shù)儲(chǔ)備。

xiesc