如何使用 TiDB 簡化技術架構
LiveMe 有一個類似朋友圈功能的場景，這個業(yè)務中存在兩個技術難點：第一是對于數據的無限量增長存儲如何實現擴容；第二是數據的冷熱分離，這又涉及到數據成本的問題。
以用戶發(fā) Twitter 的場景舉例：如果用戶發(fā)了一條 Twitter，它會寫入到自己所有的關注列表，比如有 100 個粉絲，就寫入 100 條，如果有 10 萬粉絲就需要寫入 10 萬條數據，這是一個典型的寫擴散場景。這個場景帶來的效果是數據爆炸半徑非常大，如果某流量網紅發(fā)一條 Twitter ，數據寫入量會非常大，因此需要一個能夠接近于無限擴容的存儲機制才可以實現這個場景。
Twitter 是通過維護一個 redis-cluster 來解決 feed 分發(fā)的存儲。LiveMe 的技術團隊也想到使用這種技術架構，技術團隊經過選型考慮使用 codis 集群來做存儲，但通過對成本的考量，認為這個方案是不可行的，大量的 feed 冷數據存儲在 codis 這樣的內存密集型數據庫中，成本非常高。因此，技術團隊面臨的挑戰(zhàn)是如何用低成本的方式去實現一個寫擴散的場景。
基于 TiDB 解決方案，LiveMe 技術團隊在上述寫擴散場景中，把擴散寫入的部分替換成了 TiDB，使用一張數據庫表來存儲所有 feed 的寫入關系，比如用戶有 100 萬粉絲，就在數據庫里插入 100 萬條數據?；?TiDB 的分布式數據庫特性，幫助 LiveMe 簡單高效地解決了數據增長擴容問題。
基于此技術架構，技術團隊簡化了一個典型的 redis 緩存設計問題，熱數據放在 redis 中，用 mget 來獲取。冷數據放在 TiDB 中，用 select in 查詢，這樣做數據冷熱區(qū)分就非常容易，甚至可以實現一個簡單的布隆過濾器來了解哪些數據在熱數據，哪些數據在冷數據里。以此減少無效數據的回源，更高效獲取數據。
LiveMe 的朋友圈功能基于 TiDB 的分布式存儲特性進行技術改造后， feed 表從 2021 年中旬上線至今已經達到數十億數據寫入，現在的數據量單表 39 億條。因為這些數據是永久保留不會刪除的，所以該數據也會一直增長。
未來規(guī)劃
未來， LiveMe 將會繼續(xù)嘗試 TiDB 在更多業(yè)務中，一方面會做數據庫管理開發(fā)；另一方面將對于強事務依賴交易型的業(yè)務嘗試使用 TiDB，為直播電商場景做技術儲備。
