keepalived 多个应用_网易互娱的数据库选型和 TiDB 应用实践

来源 https://asktug.com/t/tidb/1553

业务架构简介

计费组是为网易互娱产品提供统一登录和支付高效解决方案的公共支持部门，对内是互娱的各个游戏工作室，对外是国内外数百个渠道。

由于业务场景的特殊性，我们为各个游戏产品部署了不同的应用服务，其中大产品环境独立，小产品集中部署。

随着部门业务量的激增，单机 MySQL 在容量、性能、扩展性等方面都遇到了瓶颈，我们开始对其他数据库产品进行调研选型。

本文将详细介绍网易互娱计费组针对自己场景的数据库选型对比方案，以及使用 TiDB 后解决的问题，并分享使用 TiDB 过程中集群管理、监控和数据迁移等方面的最佳实践，以供大家参考和交流。

MySQL 使用架构

网易互娱计费组线上 MySQL 的基本使用架构，如下图所示，其中箭头方向表示数据或请求的指向：

Mysql(主主)+Keepalived实现高可用

• 线上应用 Application 通过 Keepalive + 多机部署，流量经过负载均衡，可以有效保障应用服务的高可用；
• 数据库层架构是 Keepalive + 主从结构，利用半同步复制特性可以有效解决延迟和数据一致性的问题；
• Application 通过 VIP 访问后端数据库，在数据库主节点宕机后通过 VIP 飘移到从节点，保证服务正常对外提供；
• 通过 Slave 节点进行数据备份和线上数据采集，经过全量和增量同步方式导出数据到数据中心，然后进行在线和离线计算任务；
• 类似这样的架构组合线上大概有 50+ 套，涉及服务器 200~400 台，日均新增数据 TB 级。

MySQL 使用的现状与问题

随着业务的发展，部门内各应用服务产生的数据量也在快速增长。业务落地数据量不断激增，导致单机 MySQL 不可避免地会出现性能瓶颈。

主要体现在以下几个方面：

• 容量单机

MySQL 实例存储空间有限，想要维持现有架构就得删除和轮转旧数据，达到释放空间的目的；

网易互娱某些场景单表容量达到 700GB 以上，订单数据需永久保存，同时也需要保持在线实时查询，按照之前的存储设计会出现明显的瓶颈。

• 性能

最大单表 15 亿行，行数过大，导致读写性能受到影响。

• 扩展性

MySQL 无法在线灵活扩展，无法解决存储瓶颈。

• SQL 复杂

大表轮转后出现多个分表，联合查询时需要 join 多个分表，SQL 非常复杂并难以维护；

单机 MySQL 缺乏大规模数据分析的能力。

• 数据壁垒

不同产品的数据库独立部署；数据不互通，导致数据相关隔离，形成数据壁垒；

当进行跨产品计算时，需要维护多个异构数据源，访问方式复杂。数据分散在不同的数据孤岛上会增加数据分析难度，不利于共性价值的挖掘。如下图：

数据库选型

调研目标

针对目前存储架构存在的问题，有需要使用其他存储方案的可能。考虑到目前的业务与 MySQL 高度耦合，

对数据库选型的主要要求有：

• 必须兼容 MySQL 协议；
• 支持事务，保证任务以事务为维度来执行或遇错回滚；
• 支持索引，尤其是二级索引；
• 扩展性，支持灵活在线扩展能力，包括性能扩展和容量扩展。

其他要求：

• 稳定性和可靠性；
• 备份和恢复；
• 容灾等。

可选方案