近些年，由于互聯網的快速發展以及線上需求的爆發，直播在國內已經成為一個非常成熟的商業模式。在娛樂、教育、辦公等場景中涌現出許多優秀的視頻直播產品。隨著國內市場競爭日益白熱化，加之企業出海漸成趨勢，越來越多的直播公司選擇走出去，尋找新的海外直播市場，借鑒國內成熟的產品、運營以及商業模式，讓全球的用戶都用上中國人創造的產品，LiveMe 便是成功的出海直播產品之一。

(資料圖)

LiveMe 是一個全球直播和社交平臺,于 2016 年 4 月推出。LiveMe 的產品功能包括 H2H、多人聊天、虛擬形象直播、蹦迪房等，它使用戶能夠隨時隨地直播、并觀看其他精彩的直播以及與世界各地的朋友進行視頻聊天。目前 LiveMe 已在全球積累了超過 1 億用戶和超過 300 萬的主播。它已成為美國最受歡迎的社交應用程序之一，并已在 200 多個國家和地區推出。

業務痛點

與其他行業出海一樣，直播產品的出海也面臨著許多全球化挑戰。如各地的合規監管、本地化運營、持續創新、政治文化差異等，都為直播產品出海帶來巨大挑戰。而在出海的過程中，底層的技術能力幫助 LiveMe 在成本節約、用戶增長、金融風控、提升研發效率等方面不斷實現精細化運營與業務創新。

經過了多年的沉淀，LiveMe 在業務上已經形成了線上微服務主導，線下計算中心主導的技術架構。線上業務是通過 Go 語言開發的一套微服務架構，每個服務根據不同業務特性具有自己獨立的存儲。線下業務是由數據研發團隊來維護，通過 sqoop 和 MySQL Binlog 同步等方式從數據庫層面抓取數據到數據倉庫，完成一系列業務相關的支持。

這套業務架構中線上業務主要面臨著以下痛點：

第一，雖然完成了微服務分庫的設計，每個服務都有自己獨立的數據庫，但是每個業務中又存在很多業務上的大表，都存在 MySQL 分表的現象。在典型的分表場景中，數據庫表會按照用戶的 UID 尾號經過 MD5 后分到 256 張表，但是日積月累后又需要再根據時間日期做一個垂直的分表，導致數據庫表無法完成聚合查詢，再加上跨時間段的分表需求，很多場景無法滿足線上需求。

第二，對于分析型業務數據而言，需要保證數據的實時性，并保留數據細節。實時的數據分析，可以在業務上更快做出決策，例如在一些活動運營場景中，業務團隊需要快速從各個數據維度來分組統計觀察活動效果；在金融相關風控業務中，需要根據各個維度快速聚合來判斷各項數據是否達到風控模型的閾值。如果使用離線計算的方式，數據的實時性根本無法得到保證；此外，經過離線計算或者實時計算過的數據，如果用戶反饋數據有問題，需要查看數據的細節也很難實現。

第三，各種精細化運營需求，例如推薦、個性化運營等場景不斷增加，對于數據的實時要求越來越高。因此，LiveMe 急需一種更簡單，同時讓線上線下業務做好平衡的方案。

此時，如果 LiveMe 繼續選擇大數據技術棧解決痛點就會面臨以下挑戰：1）大數據技術棧的架構非常復雜，中間件過多；2）需要額外的技術棧學習成本，比如如果使用數據同步，就需要 sqoop、scala、kafka 等中間件，會大幅增加整個業務的復雜性；3）希望線上業務以及架構非常簡單，能夠簡化到普通開發人員只要能夠 CRUD（增加(Create)、讀取(Read)、更新(Update)和刪除(Delete)） 數據庫就可以上手開發。

為什么選擇 TiDB ？

基于以上業務挑戰，LiveMe 經過一系列技術選型后最終選擇了 TiDB 數據庫。 TiDB 的以下特性可以幫助 LiveMe 很好的應對挑戰：

1）TiDB 的性能大于等于 MySQL ；

2）TiDB 的 HTAP 特性能夠解決線上大表的問題，在后臺或者一些實時分析場景中，其 OLAP 分析能力能夠保證實時數據報表；

3）TiDB 引入的 MPP 架構分析能力，使得 OLAP 查詢速度非常快，這也是 OLAP 數據庫架構上的技術方向；

4）TiDB 團隊有著完善和專業的技術支持，在過程中可以幫助 LiveMe 解決很多問題，在線上大規模使用后也沒有后顧之憂。

如何利用 TiDB 實現實時聚合查詢

鑒于 LiveMe 的微服務架構，如果將數據源全部替換，工程量大且不能一蹴而就，因此就需要一種兼容性的方案，在保證線上業務不受影響的同時也能使用 TiDB 的特性來解決 LiveMe 的業務痛點。因此，對于需要聚合查詢的業務， LiveMe 通過消息隊列廣播的方式，在業務層訂閱相關事件再補充業務側需要的寬表信息寫入 TiDB，基于 TiFlash 就可以做到實時的運營報表。業務開發人員只需要編寫對應的 SQL 查詢，就可以輕松完成需求。 沒有了復雜的 ETL 過程，大大簡化了開發流程。

對于業務數據， LiveMe 使用 AWS SQS 消息隊列，相比 Kafka 的優勢在于每條數據都是原子性的，每條數據都可以用來做冪等重試，來保證數據的最終一致性。目前，這套技術方案已經支撐了 LiveMe 的活動運營和金融風控等多個業務場景，滿足了 LiveMe 對于線上大量數據實時聚合查詢的要求。

如何使用 TiDB 簡化技術架構

LiveMe 有一個類似朋友圈功能的場景，這個業務中存在兩個技術難點：第一是對于數據的無限量增長存儲如何實現擴容；第二是數據的冷熱分離，這又涉及到數據成本的問題。

以用戶發 Twitter 的場景舉例：如果用戶發了一條 Twitter，它會寫入到自己所有的關注列表，比如有 100 個粉絲，就寫入 100 條，如果有 10 萬粉絲就需要寫入 10 萬條數據，這是一個典型的寫擴散場景。這個場景帶來的效果是數據爆炸半徑非常大，如果某流量網紅發一條 Twitter ，數據寫入量會非常大，因此需要一個能夠接近于無限擴容的存儲機制才可以實現這個場景。

Twitter 是通過維護一個 redis-cluster 來解決 feed 分發的存儲。LiveMe 的技術團隊也想到使用這種技術架構，技術團隊經過選型考慮使用 codis 集群來做存儲，但通過對成本的考量，認為這個方案是不可行的，大量的 feed 冷數據存儲在 codis 這樣的內存密集型數據庫中，成本非常高。因此，技術團隊面臨的挑戰是如何用低成本的方式去實現一個寫擴散的場景。

基于 TiDB 解決方案，LiveMe 技術團隊在上述寫擴散場景中，把擴散寫入的部分替換成了 TiDB，使用一張數據庫表來存儲所有 feed 的寫入關系，比如用戶有 100 萬粉絲，就在數據庫里插入 100 萬條數據。基于 TiDB 的分布式數據庫特性，幫助 LiveMe 簡單高效地解決了數據增長擴容問題。

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

LiveMe 的朋友圈功能基于 TiDB 的分布式存儲特性進行技術改造后， feed 表從 2021 年中旬上線至今已經達到數十億數據寫入，現在的數據量單表 39 億條。因為這些數據是永久保留不會刪除的，所以該數據也會一直增長。

未來規劃

未來， LiveMe 將會繼續嘗試 TiDB 在更多業務中，一方面會做數據庫管理開發；另一方面將對于強事務依賴交易型的業務嘗試使用 TiDB，為直播電商場景做技術儲備。

關鍵詞： 新聞資訊