导读
跨境电商进入多模式并行阶段，海量数据增长下，数据技术栈面临重重考验，实时、全量兼得至关重要。
在跨境电商领域中，TiDB 得到了广泛的应用。本文作者李坤，PingCAP 中国出海事业部技术总监，分析了电商出海的现状与挑战，同时介绍了 TiDB 的产品能力，并结合实际案例介绍了对应的解决方案。
背景
近年来，随着国内电商行业发展见顶和国家政策的支持，出海电商成为一个快速发展的行业，2021 年虽然跨境电商经历了各类风险考验，但是在这些重重考验下我国跨境电商出口额达 1.44 万亿元，同比增长 24.5%，仍处于高速发展区间，显示出了我国出海电商发展的韧性和强大的动能。
在独立站、直播短视频、社交媒体的带动下，跨境电商 DTC 模式出现爆发式增长，为出海企业创造了全新链路，跨境电商进入多模式并行阶段，同时形成全新的跨境电商产业生态。
现状与挑战
跨境电商企业在业务扩张时通常会遇到海量数据增长的数据存储问题，技术栈也随之越来越复杂，包含数据库、ETL、分析引擎等；同时，出海业务通常分布在多个地区或国家，因此普遍比较青睐公有云、多云部署，以及全球部署；相较国内，由于能提供更高的效率，出海企业对 SaaS 服务的接受度也比较高。
在出海过程中，每个企业都会有对自身业务增长的预期，通常会从两方面考虑：第一，随着业务的增长，希望可以实现数据平滑扩展。数据库都是以单节点的（DBMS）为主要基础，常见的限制是当数据量增长达到容量瓶颈时，性能便会出现急剧下降；第二，随着业务的增长，希望可以持续进行数据分析。尤其是在电商行业，数据分析作用非常突出。虽然以数据湖和数仓为代表的技术栈可以承担更大数据量，但处理数据的延迟将其功能限制在离线分析，而无法用于实时分析场景。
TiDB 的定位恰好可以帮助企业跨越上述数据鸿沟。TiDB 是一个高度兼容 MySQL 的分布式数据库产品。在架构上，TiDB 采用了计算存储分离的典型架构，它为 TiDB 的长期演进带来了很多好处，如 serverless 架构演进，更好的资源管控等等。在计算部分，TiDB 提供了一个 SQL 的统一入口，它是无状态的服务，可以随时在线扩展；存储部分通过 Raft 使用通用型硬件实现多台节点横向部署，可以跨多节点实现高可用。当数据规模增长时，可以通过增加节点来扩展性能。用户不需要对表提前进行分区设计的划分，一切由 TiDB 内部独立完成。
TiDB 存储部分包含 TiKV 和 TiFlash 两个存储引擎，这也是 TiDB HTAP 主要能力所在。TiKV 是行存引擎，可以承担在线交易型业务，同时把数据实时同步给列存 TiFlash。列存由于能够拿到实时数据，可以进行高速分析，例如重型查询、大表之间的 join 等操作。TiKV 与 TiFlash 之间实现了物理隔离，不会互相干扰。
过去，当电商平台业务快速发展时，为了解决海量数据增长，通常需要分库分表，但这样会使业务逻辑变得更加复杂。为了提升读取性能，用户可能会选择增加只读节点，但写入能力仍然是单点。这时为了扩展性，有些业务就会选择 NoSQL，但这也意味着不得不放弃 SQL 和事务性。这些问题都可以使用新一代 HTAP 数据库 TiDB 来解决。
作为一款企业级数据库产品，TiDB 提供了多种部署形态。在云上提供了托管服务 TiDB Cloud ，用户可以从 Web 控制台一键部署，自助完成所有运维操作。同时，TiDB Cloud 还入驻了 AWS 和 GCP 的 marketplace；用户也可以私有部署，通过 TiDB Operaor 部署在 K8s 中。去年年底，PingCAP 发布了第一款 Serverless 架构的 HTAP 数据库 TiDB Cloud Serverless Tier 测试版，这是一个划时代的产品，它可以为所有开发者秒级提供一套 HTAP 数据库，根据真实的 workload 负载实现弹性扩缩容，帮助客户节省部署成本和服务成本。
电商行业解决方案
TiDB 可以结合标准的 SQL 入口以及弹性扩展能力、HTAP 一体化能力，向电商提供敏捷开发、持续交付的能力。下面通过面向商家、最终用户和运营分析几个维度介绍 TiDB 在电商业务中的主要应用场景：
商品中心
商品中心是电商平台提供服务的具体内容，大量商品和内容信息会在平台进行曝光展示，用户看到商品信息后产生消费意愿，最终完成下单。商品内容在电商整个业务链条中会被多次依赖，在特定的时间或者特定的活动下（如购物节），会产生爆发式的流量增长。此时，商品内容模块的流量可能达到平时数倍以上。所以，在面向 C 端平台的这些核心模块必须保证数据服务的可靠性及稳定性，通常对 SLA 的要求是非常高的，数据量也非常大。
TiDB 基于原生的分布式架构，可以根据业务的实际情况灵活扩展计算及存储节点。同时，TiDB 也具有数据强一致性能力，可以做到故障自动恢复，为商品中心提供可靠的数据存储，应对大促带来的流量高峰。
订单中心
订单中心在电商交易的链路中扮演着一个非常重要的角色。它向上对接用户信息，将用户订单信息转化为订单数据，并且管理并追踪整个订单过程，是整个公司在线交易中不可或缺的一个环节。同时，订单中心还承接了其他系统的功能，如促销、仓储、会员和支付等，扮演着关键的承上启下的作用。
订单中心对 SLA 有很高的要求，同时订单的数据规模非常大，订单状态还要保持持续跟踪，这就造成订单中心的吞吐量也相当大。
与传统解决方案和基于 MySQL 的分布式解决方案相比，TiDB 在吞吐量、数据处理和查询能力、可扩展性等方面具有显著优势。过去，为了解决查询问题，传统解决方案必须扩展大量的读写节点，导致系统数据冗余，同时又只能扩展读能力，写能力无法得到扩展。而 TiDB 提供了一种高效的解决方案，可以同时扩展读写能力，是管理大量订单的最佳选择。
IM 场景
IM 类型的场景在电商中也非常典型。其中一个显著的特点是数据量大，但往往 SQL 模型比较简单。过去有很多产品承载着 IM 这种系统，例如 HBase、Redis、MySQL 和 TiDB。HBase 存储成本很低，但作为一种老牌存储，其运维较为复杂且不太稳定。Redis 运维简单、灵活性好、性能非常好，但是对于一些消息来说，它无法持久化，存在丢失消息的风险。MySQL 使用 SQL 的成本较低，但由于其单机数据库的设计，其容量限制和吞吐能力受限，这导致业务在数据量变大时无法再扩展。
TiDB 可以很好地解决这些问题。当然，这里也有一个缺点，即初期成本相比 Redis 和 MySQL 略高。除此之外，TiDB 也即将支持 TTL。老的 IM 数据可能会被归档，从而避免了归档后需要运维或业务手动删除的任务，节省了工作量。
促销中心
很多电商服务都是 SaaS 类的服务，第三方公司很难提前预见未来的促销活动何时发生。促销活动可能会导致整体负载的大幅变化。过去，TiDB 尽管已经具备弹性水平扩展的能力，但有时候还是会显得有些来不及。当 TiDB Cloud 提供了 Serverless 能力后发生了变化，电商企业可以根据实际负载情况，无需人为干预就能完成在线弹性扩缩容。这大大降低了用户的 TCO 和运维成本，使得 TiDB 在这个场景下具有非常优越的竞争力。
实时风控
风控系统的职责之一是防止营销活动中的作弊行为，例如羊毛党、虚拟用户裂变、刷榜单等，甚至还包括一些内容违规情况。因此，过去的风控系统通常关注哪些用户在何时对什么商品或事情进行了什么操作。一般的实现方式是对业务订单、支付订单、抽奖活动、秒杀活动等系统的记录或日志进行收集、分析和处理。由于这些数据记录和数据源非常多，因此风控系统的数据量通常很大。在关键的操作前，业务会调用风控服务接口进行分析。数据的实时性越高，就越能及时感知到风险并处理掉风险问题或访问。因此，实时性对于风控系统非常重要。
借助 TiFlash 一体化的 HTAP 能力，TiDB 可以很好地处理需要实时性非常高的风控业务。与此同时，风控业务中也有一类负载比较重的 SQL 查询，但执行时间很难预测，这些查询可能是突发性流量或有周期性的，而不是持续存在的。如果计算资源始终按照最高需求或峰值提供，将会造成极大的浪费。因此，TiFlash 的 Serverless 可以很好地为这类负载降低总体拥有成本（TCO）。
跨境电商行业解决方案
除了传统经典的亚马逊、eBay 等老牌第三方电商平台，近年来，独立站逐渐在跨境电商中流行起来。其趋势正不断增长，其中包括 DTC 自建、SaaS 建站和开源建站等多种方式。
提到独立站，就不得不提 SaaS 平台。SaaS 平台中有大量租户数据需要管理，这些数据要怎样才能更好地进行管理呢？通常这些数据需要满足以下需求：如隔离性，即多个租户之间的隔离；敏捷性，即数据需要能够快速创建；可扩展性，面对未来的业务增长需求，数据可以快速扩缩；性能方面希望每个租户都能够拥有比较隔离的资源，以避免邻居争用，也就是所谓的“吵闹的邻居”，这可能会导致性能争用等问题。另外，希望 SaaS 用户的数据能够合法合规，并且存储在他们所要求的地区内。
过去常见的部署方式可能有以下几种：一、每个租户都有独立的数据库实例部署；二、将所有租户共享在一张表中。但这些方式有各自的优点和问题。例如，共享方式的隔离性较低，但独立实例的成本又相对较高。
TiDB 可以通过一套集群解决以上问题：首先，TiDB 提供了 PlacementRule 特性，可以在不同的维度上为各个租户设置数据分布策略，以保证数据合规要求；第二，TiDB 提供并行 DDL，由于租户的数据可能经常调整，并行 DDL 可以直接从 TiDB 的小表缓存中查询，效率更高；第三，由于 TiDB 本身具有弹性扩展能力，无需为大型租户进行特别改造，保证小租户和大租户在整个业务逻辑上保持统一；第四，在 SaaS 的电商系统中，一定会有一些租户需要的资源相对较高，TiDB 可以自动将数据打散分布在所有的计算、存储节点上。
应用案例
Shopee
Shopee 是东南亚领先的电商平台之一。目前在订单等核心子系统上都采用了 TiDB。在 2018 年引入 TiDB 之前，Shopee 面临着以下两个挑战：首先，自建的 MySQL 已成为严重的瓶颈；其次，虽然考虑过 MySQL 分库分表方案，但发现挑战非常大。基于上述问题，Shopee 团队开始寻找适合的技术方案。经过充分的技术调研和测试，TiDB 最终在 Shopee 内部被广泛使用。下面是两个典型场景：
第一个场景是 Shopee 的 Chat 系统。2019 年，客户尝试将 Chat 从 MySQL 迁移到 TiDB，成功支撑了平台的大促。Chat 是聊天服务，如买家和卖家之间的问询等，该系统分为两个部分：MySQL 存放消息元数据，消息的内容存储在消息服务中，这部分使用了自研的文件系统。在迁移前，MySQL 的稳定性和运维性都面临挑战。
消息服务是单点服务，其数据冗余和机制不健全，导致可能会丢失最近的聊天记录。Shopee 也考虑过持续使用 Redis，但其成本过高，也有丢失数据的风险。为满足业务要求，最终选择了 TiKV 集群，它可以保证业务在容量上在线扩展，从而保证高可用性。
另外一个系统是 Shopee 的风控系统，最初他们将风控系统也放在 MySQL 上，并且按照 user ID 将数据分成上百张表。随着用户量的增长，在 2018 年的一次促销活动中订单量达到了前一年的 4.5 倍，所以数据体积开始疯狂增长，急需解决数据存储容量的问题，从长期考虑，Shopee 没考虑使用分库分表，切换到 TiDB 业务已经平稳运行了四年时间，在上线的早期阶段 6 个月内数据增长了 8 倍。
小红书
小红书在业务快速发展的过程中，也同样希望保持数据的多样性、实时性与更强的扩展性。使用 TiDB 之前，他们在如实时数据视图、反欺诈分析和实时报表等业务中主要采用了 MySQL、Hadoop 和 Hive 的架构，并且使用了 MySQL 的分库分表。该架构的实时性比较差，很多数据要等到 T+1 才能获取，而且数据源也很多，这三个业务要分别访问不同的数据源，因此业务复杂度比较高。采用 TiDB 后，小红书将 T+1 的提交方式改为实时写入 TiDB 数据库，查询更加方便。此外，TiDB 作为数据服务层，通过 Flink 将其中聚合的结果再次返回 TiDB，最终结果可供业务直接在这一套系统上使用。这三个业务的数据源得以统一，业务的实时性从过去的 T+1 变成了实时，同时还简化了运维的复杂度和架构。
转转
转转是一家电商公司，在很多业务中也广泛使用 TiDB 系统，例如 IM 交易、用户和商品等。转转是一个重度使用 TiDB 的客户，可以从世界杯促销等方面看到他们对于数据容量的增长有着良好的承担能力。当然，在许多泛电商领域中，TiDB 也得到了广泛的应用。
总结
外贸数字化所导致的全球贸易新格局正在形成。在浪潮之下，已经有相当多的企业正在尝试拥抱于 此。跨境电商成为一个高速发展的行业，但快速增长的用户量与流量也对电商平台的技术架构带来 冲击，TiDB 新一代分布式数据库的水平扩展架构可轻松应对节日大促与秒杀带来的数据量激增问题。同时，作为一个开源数据库，TiDB 的系统和生态非常开放。它可以连接到各种应用程序和大数据生态系统，同时还可以与私有云、公有云集成。其 HTAP 一栈式实时数据分析能力，也让数据实时分析成为可能，帮助企业提升运营效率，赢得市场先机。
目录