近些年，由於網際網路的快速發展以及線上需求的爆發，**直播在國內已經成為一個非常成熟的商業模式**。在娛樂、教育、辦公等場景中湧現出許多優秀的影片直播產品。隨著國內市場競爭日益白熱化，加之企業出海漸成趨勢，越來越多的直播公司選擇走出去，尋找新的海外直播市場，借鑑國內成熟的產品、運營以及商業模式，讓全球的使用者都用上中國人創造的產品，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 對於線上大量資料實時聚合查詢的要求。

![20221226-162737.jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/20221226_162737_a33d69ea3a.jpg)

## 如何使用 TiDB 簡化技術架構

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

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

![20221226-162747.jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/20221226_162747_90f8291510.jpg)

<center>Twitter 的技術實現</center>

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

![20221226-162751.jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/20221226_162751_44d420064b.jpg)

<center>Twitter 的解決方案</center>

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

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

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

## 未來規劃

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

LiveMe x TiDB丨單表資料量 39 億條，簡化架構新體驗

相關文章