Rakuten 乐天积分系统从 Cassandra 到 TiDB 的选型与实战

导读

自 2002 年推出以来，乐天积分系统的流量稳步增长，每天发放的积分从数百万到数千万不等。近年来，不仅仅是展示积分，提升用户体验的重要性也日益增加。

随着数据量的不断增加，挑战在于提供灵活的功能的同时保持成本低廉。本文根据 Rakuten 乐天 INPD 高级软件开发工程师李震在 TiDB 社区活动大连站的分享整理，介绍了乐天选择 TiDB 的思考和实际的应用体验。

---

Rakuten 乐天及其积分系统介绍

Rakuten 乐天是一家成立于 1997 年的日本公司，总部位于东京，员工总数超过 30,000 人，业务遍及 100 多个国家和地区。除了电商业务外，乐天还涉及电信、金融等多个行业。

乐天的积分系统在日本非常普及，用户通过使用乐天的服务，如银行卡、手机卡等，可以获得积分，并在乐天商城中使用这些积分进行购物或抵扣，我们每个季度还会举办促销活动、会有大量用户高频访问积分系统，因此，乐天积分服务平台的性能、延迟和可用性要求极高。

乐天的数据中心主要分布在日本东部和日本西部，东部数据中心大致位于东京地区，而西部数据中心位于大阪地区。目前，我们的主要数据库使用的是 Cassandra，通过批量处理周期性地将主数据库中的数据同步到 TiDB 数据库中。TiDB 目前采用的是主从方案，主数据库位于日本东部，而数据同步则在日本西部进行。

下图展示了乐天正在开发的下一代积分平台的架构图，该平台旨在提供更高性能和低延迟的服务，以满足用户对高可用性的需求。

Cassandra 的限制

过去，积分系统虽然主数据库使用的是 Cassandra，但作为一款 NoSQL 数据库，它存在一些限制。例如，它对事务的支持较弱，也没有传统关系数据库的关系模型。

业务层面 Cassandra 的限制

首先，就开发而言，Cassandra 存在一致性缺失的问题。尽管 Cassandra 宣称其一致性可调，但事实上无法完全确保