--- title: '方案精讲丨TiDB 在社交场景的解决方案实践' date: '2023-04-13T00:00:00+08:00' status: publish permalink: /blog/tidb-in-social-application author: - PingCAP - 陈畅亮 excerpt: '本文介绍了 TiDB 数据库在社交应用出海中的应用。文章通过几个社交应用企业的实践案例，具体说明了 TiDB 的优势和应用场景。' type: post id: 3224 category: - 产品技术解读 tag: - 技术出海 post_format: [] profile: - 陈畅亮 algolia_posts_post_records_count: - '8' --- 导读 -- 社交出海已经逐渐成为国内科技企业技术出海的主战地，本文介绍了 TiDB 数据库在社交应用出海中的应用。TiDB 可以解决大规模数据处理、横向扩展、多数据中心部署、强一致性和 SQL 兼容性等技术挑战，帮助社交应用实现稳定高效的全球化发展。文章通过几个社交应用企业的实践案例，具体说明了 TiDB 的优势和应用场景。 在中国互联网高速增长的十几年间，出海应用主要以工具产品为主，随着市场不断拓宽，社交娱乐等也成为互联网公司出海热衷的领域。同时，过去中国出海应用只在边缘市场做探索，而现在则是面向海外主流市场全面探索，从定位于市场的补充产品蜕变为海外应用市场的主流产品。 最新的 data.ai 研究显示，移动生活方式在印尼和新加坡占据主导地位，用户每天使用应用的时间达到了 5.7 小时，有 13 个地区的用户每天使用应用的时间超过了 4 小时。此外，2022 年新加坡和澳大利亚的增长时长比 2020 年增长了 40%，说明社交应用市场正在不断发展。 根据 data.ai 在 2021 年对移动应用使用时长的统计，用户有 70% 的时间花在了社交与照片和视频应用上。这相当于用户在使用移动应用时每 10 分钟中就有 7 分钟花在社交和照片视频上。另外根据 2022 年第二季度的下载量、用户支出和月活跃用户数（MAU）的排名显示，社交媒体和在线视频的应用为主导。从上面几组数据可以看出，社交出海可以为出海企业带来了无限的未来和想象空间，社交出海开始成为出海的主旋律。 社交出海面临的数据库技术挑战 -------------- 作为出海业务，基于社交产生了很多新业务模式，比如社交+直播、社交+游戏、社交+电商，这些都是以社交作为出海业务的基石，那么在社交场景中会面临怎样的挑战呢？在过去，会面临比较多的困难，这里主要讲以下三个挑战： 第一是扩展性挑战。社交应用在海外市场面对的用户量和数据量都会大幅增加，快速扩容升级成为了关键，如果采用传统的对数据库进行分库分表是很难满足业务要求的。因为分库分表也会带来新的问题：第一是业务的改造成本高，业务需要进行额外的开发来适配分库分表的路由规则；第二是多维查询会变得困难，因为分库分表是基于某个维度或者字段进行拆分的，比如一个电商平台，如果按照用户 ID 进行拆分，那么商家维度的查询就会困难；第三是对分布式事务的支持有限；第四是由于业务的发展，数据量在不断的增加，当达到一定容量时就得进行二次拆分，也给运维带来了一个很大的成本开销。 第二个时效性的挑战。在社交场景中，如用户画像、风控、广告投放等业务对于时效性的要求比较高，如果单单采用以前的 kafka+Flink 或者是 Storm 这些流式计算引擎，往往不能很好的满足实时查询分析的要求。比如业务需要对用户画像进行精准的广告投放。业务出海在不同的国家和地区也要符合当地的法律法规的，比如：文化宗教信仰、区域政治动荡，这些都需要依靠于实时的风控来进行保障的。 第三个是成本挑战。海外社交产品从 0 到 1 的冷启动是需要对产品、用户、运营三个基本要素进行快速试错，并验证项目可行性的过程，以低成本不断迭代更新。其中成本可以分为两块：一个是资源成本一个是人力成本。如何在业务规模的不同阶段来控制资源的成本呢？如何让开发人员在更短的时间内迭代新功能并快速上线呢？TiDB 就能很好的帮助企业解决这些问题，比如针对资源成本的考虑，TiDB Cloud 支持集群的 Scale Up 和 Scale Out，Serverless。 TiDB 在社交的应用场景 ------------- 在社交场景中，按照业务模块可以划分为通讯信息层、支付交易层、平台运营管理层。其中通讯信息是基础，包含了社交中的好友关系、通讯数据、包括聊天记录文章、帖子等，这部分数据的特点是数据量大，在对实时性有要求的同时还对大数据的分析查询也有一定的要求。支付交易层是社交软件的变现方式，包括了交易记录、用户钱包、账单管理等核心功能，这部分数据的特点是对数据的高可用要求很高。平台运营管理层更多的是以辅助形式出现，对于数据有比较强的分析和管理要求。对于以上三个模块，TiDB 有哪些功能是可以满足这些要求的呢？ ### TiDB 支撑社交通讯信息场景 ![TiDB 支撑社交通讯信息场景.png](https://img1.pingcap.com/prod/Ti_DB_ff178fe047.png)在通讯信息层的账号中心功能上，对于面向出海的应用来说，用户的分布往往是在不同国家和地区，对此， TiDB 可以支持本地读的跨 Region Global Database，用户可以在本地完成数据身份的验证；对大数据量的通讯来说，TiDB 也提供了弹性的扩容能力，用户不需要分库分表来打散数据，可以针对不同的 TiDB 组件进行扩容，比如在计算能力不足时可以扩容 TiDB Server，存储能力不足时可以扩容 TiKV 节点，AP 能力不足时可以扩容 TiFlash 节点，是非常灵活的。在一些对于消息有时效性要求的场景中，TiDB 也提供了基于 TTL 的行功能，方便对于数据的清理。另外，针对该行业的初创企业，TiDB 提供的 Serverless 可以帮助用户最大化节省成本。 ### TiDB 支撑社交支付交易场景 ![TiDB 支撑社交支付交易场景.png](https://img1.pingcap.com/prod/Ti_DB_64d853d1bd.png)在支付交易场景中，用户钱包和交易流水等关系到公司营收的核心功能，重中之重是如何保证高可用的可靠性。这方面 TiDB Cloud 集群本身就是多副本，每个副本分布在不同的 AZ，这已经是具备了比较高的可用性。此外， TiDB Cloud 还支持跨 region 的多数据中心复制，甚至还可以跨云进行复制，云中立也是 TiDB Cloud 的一个优势。 另外对于数据的恢复能力，TiDB Cloud 提供了 PITR 和 Flashback 两个功能，如果是在 GC 范围内的数据恢复可以基于表、Database、集群这三个维度来进行快速的 Flashback，就再也不用担心数据的误操作。对于超过了 GC 外的恢复，可以通过 PITR 实现任意时间点的恢复。因此，这些功能对高可靠性要求能很好的满足。 ### TiDB 支撑社交平台运营管理场景 ![TiDB 支撑社交平台运营管理场景.png](https://img1.pingcap.com/prod/Ti_DB_4d59399992.png)在平台运营管理层面，用户画像和实时风控是两个重要组成部分。用户画像可以用于基于内容的推送和广告的精准投放以及对人群的划分。在出海场景中，数据合规是一个绕不开的话题，比如文化宗教信仰、区域的政治动荡等，这些都需要依靠实时风控。用户画像和实时风控这两个业务的特点是数据量大的同时对实时性分析有比较高的要求，TiDB HTAP 的特性就能很好的解决这个问题。对于类似广告投放优化的功能，有一个特点就是具有周期性的负载场景，TiDB Cloud Serveless 就非常适合这种场景，可以在高峰时进行弹性扩容，同时也支持 Flink、Spark 接口，可以以大数据技术栈进行很好的集成。 TiDB 在社交应用场景的实践 --------------- ### TiDB 助力 LiveMe 简化架构新体验 LiveMe 是一个全球直播和社交平台，于 2016 年 4 月推出。LiveMe 的产品功能包括 H2H、多人聊天、虚拟形象直播、蹦迪房等，它使用户能够随时随地直播、并观看其他精彩的直播以及与世界各地的朋友进行视频聊天。目前 LiveMe 已在全球积累了超过 1 亿用户和超过 300 万的主播。它已成为美国最受欢迎的社交应用程序之一，并已在 200 多个国家和地区推出。 与其他行业出海一样，直播产品的出海也面临着许多全球化挑战。如各地的合规监管、本地化运营、持续创新、政治文化差异等，都为直播产品出海带来巨大挑战。而在出海的过程中，底层的技术能力帮助 LiveMe 在成本节约、用户增长、金融风控、提升研发效率等方面不断实现精细化运营与业务创新。 经过了多年的沉淀，LiveMe 在业务上已经形成了线上微服务主导，线下计算中心主导的技术架构。线上业务是通过 Go 语言开发的一套微服务架构，每个服务根据不同业务特性具有自己独立的存储。线下业务是由数据研发团队来维护，通过 sqoop 和 MySQL Binlog 同步等方式从数据库层面抓取数据到数据仓库，完成一系列业务相关的支持。 这套业务架构中线上业务主要面临着以下痛点： 第一，虽然完成了微服务分库的设计，每个服务都有自己独立的数据库，但是每个业务中又存在很多业务上的大表，都存在 MySQL 分表的现象。在典型的分表场景中，数据库表会按照用户的 UID 尾号经过 MD5 后分到 256 张表，但是日积月累后又需要再根据时间日期做一个垂直的分表，导致数据库表无法完成聚合查询，再加上跨时间段的分表需求，很多场景无法满足线上需求。 第二，对于分析型业务数据而言，需要保证数据的实时性，并保留数据细节。实时的数据分析，可以在业务上更快做出决策，例如在一些活动运营场景中，业务团队需要快速从各个数据维度来分组统计观察活动效果；在金融相关风控业务中，需要根据各个维度快速聚合来判断各项数据是否达到风控模型的阈值。如果使用离线计算的方式，数据的实时性根本无法得到保证；此外，经过离线计算或者实时计算过的数据，如果用户反馈数据有问题，需要查看数据的细节也很难实现。 第三，各种精细化运营需求，例如推荐、个性化运营等场景不断增加，对于数据的实时要求越来越高。因此，LiveMe 急需一种更简单，同时让线上线下业务做好平衡的方案。 基于以上业务挑战，LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库。TiDB 的以下特性可以帮助 LiveMe 很好的应对挑战： - TiDB 的性能大于等于 MySQL ； - TiDB 的 HTAP 特性能够解决线上大表的问题，在后台或者一些实时分析场景中，其 OLAP 分析能力能够保证实时数据报表； - TiDB 引入的 MPP 架构分析能力，使得 OLAP 查询速度非常快，这也是 OLAP 数据库架构上的技术方向； - TiDB 团队有着完善和专业的技术支持，在过程中可以帮助 LiveMe 解决很多问题，在线上大规模使用后也没有后顾之忧。 ### TiDB 在某知名直播互动应用的实践 某知名直播互动应用是一款倡导健康生活的直播互动应用和健康教育平台，可以发现身边的好友，查看他们的可公开资料、相册和动态，根据自己的兴趣爱好进行多维度匹配。截至 2020 年 3 月, 在全球有超过 4900 万的注册用户，用户已遍布全球超过 210 多个国家和地区，中国大陆以外的国家和地区月活用户数，占全球月活跃总用户数的 49%以上。 在使用 TiDB 之前，该应用的用户关系遇到了如下挑战：随着 业务发展，MySQL 性能容量出现了瓶颈，无法满足日益增长的性能和容量要求，如果把用户关系进行分库分表，业务需要做很大的改动；用户关系本来就是一个读多写少的场景，所以为了扩容补容量，增加只读节点，会存在主从复制的延迟的问题；同时一些分析类 SQL 的执行比较差，无法及时返回，所以业务会把一些数据缓存在 Redis 当中，这就导致了 Redis 的资源成本随之增加。 经过一些调研，用户最终选择了 TiDB，使用 TiDB 后收益也很明显，TiDB 可以针对业务发展的不同阶段进行快速的扩缩容，而且对业务是无感知的，业务不需要做改动，无需担心分库分表。针对读多写少的场景可以直接增加 TiDB Server 节点进行扩容，轻松解决了用户的问题。同时，TiDB 还提供了 HTAP 的混合查询能力，用户也把很多之前存储在 Redis 的查询转移到了 TiDB 集群，从而节省出了 Redis 缓存资源的开销，节约了成本。 总结 -- 除了上述两家企业，还有不少将 TiDB 作为解决方案的社交出海企业，TiDB 在社交应用出海中能够解决大规模数据处理、横向扩展、多数据中心部署、强一致性和 SQL 兼容性等技术挑战，帮助社交应用实现稳定高效的全球化发展。