TiDB x Ninja Van | TiDB on Kubernetes 助力成就精彩未来

业务挑战

Ninja Van 每天会派送约 150 万个包裹，特别在双 11 和双 12 购物节期间，在极短时间内就会产生成百上千个订单，给平台带来巨大的工作量，其原有数据库面临着巨大挑战：

• OLTP 工作负载在峰值期间需要进行弹性计算，面对如此庞大的数据量，分片成为 Ninja Van 不得不面临的选择，但是应用层分片需要进行大量的重构；
• Ninja Van 选择使用 Galera 集群，其本质是一个 MySQL 二进制文件和一个 Glaera 插件。但 Galera 集群操作繁琐，并且不具备扩展性；
• OLAP 工作负载方面，Ninja Van 选择前端工具 Redash 作为 UI，用来查询副本数据库阵列，却没有针对这种需求的任何数据转换，所有的表设计和数据只是 OLTP 导向的生产数据的简单复制，导致糟糕的性能表现。

解决方案

在综合考虑技术架构的生态系统、社区支持、以及服务本身与 MySQL 的兼容性等因素后，Ninja Van 决定选用兼容 MySQL 并具有高可用性的云原生数据库方案 TiDB 。TiDB 具有丰富的生态系统， TiCDC 可以支持 Ninja Van 的 CDC 需求，并且有工具使 Ninja Van 数据从 MySQL 同步到 TiDB, 甚至从 TiDB 同步到其他数据库，保证迁移顺利完成。目前， Ninja Van 每个月都会进行一项迁移服务，稳中有进，现在已经有十几个数据库转移到 TiDB 。

迁移计划

Ninja Van 在 Kubernetes 集群上有一个运行的应用，这个应用对应一个运行在虚拟机上的 MySQL 实例。应用程序最初连接到 MySQL，Ninja Van 首先在 Kubernetes 中部署 TiDB,然后使用由 PingCAP 提供的 DM / TiDB Lightning 工具，将数据从 MySQL 同步到 TiDB，在数据迁移完成后，应用程序将连接到 TiDB,最后 TiDB 使用 TiCDC 将数据再次同步回 MySQL 。

在这个过程中，TiCDC 扮演着三个重要的角色：

第一，先同步到 MySQL 副本，并由 Maxwell 订阅，然后发布到 Kafka, 供数据湖使用；

第二， TiCDC 会直接发布 Maxwell 格式消息，这些消息会被其他消费者接受，比如同步数据到 Elasticsearch 的消费者;

第三， TiCDC 发布多源副本到 TiDB。

业务收益

• Ninja Van 所有应用程序都基于 MySQL，TiDB 完美兼容 MySQL，使得整个迁移过程十分便捷，无需进行业务改造；
• TiDB 具备读写可扩展性，可以应对业务的快速增长；
• TiDB 具有高可用性，即使集群出现部分故障，依然可以正常工作；
• 可以通过 CDC 将数据变更发布到其他系统，如数据湖和 Elasticsearch 进行监测；
• TiDB 支持 Kubernetes 原生部署，保障 Ninja Van 的所有工作负载都在 Kubernetes 上良好运行。