网易互娱的数据库选型和 TiDB 应用实践
共 6640字,需浏览 14分钟
· 2021-05-29
点击上方蓝色字体,选择“设为星标”
回复”资源“获取更多资源
一、业务架构简介
1.1 MySQL 使用架构
![](https://filescdn.proginn.com/3f0c8bf4442e51611395ced9d1680574/da366bc21fc67088b8f3b440d964771d.webp)
线上应用 Application 通过 Keepalive + 多机部署,流量经过负载均衡,可以有效保障应用服务的高可用; 数据库层架构是 Keepalive + 主从结构,利用半同步复制特性可以有效解决延迟和数据一致性的问题; Application 通过 VIP 访问后端数据库,在数据库主节点宕机后通过 VIP 飘移到从节点,保证服务正常对外提供; 通过 Slave 节点进行数据备份和线上数据采集,经过全量和增量同步方式导出数据到数据中心,然后进行在线和离线计算任务; 类似这样的架构组合线上大概有 50+ 套,涉及服务器 200~400 台,日均新增数据 TB 级。
1.2 MySQL 使用的现状与问题
容量 单机 MySQL 实例存储空间有限,想要维持现有架构就得删除和轮转旧数据,达到释放空间的目的; 网易互娱某些场景单表容量达到 700GB 以上,订单数据需永久保存,同时也需要保持在线实时查询,按照之前的存储设计会出现明显的瓶颈。 性能 最大单表 15 亿行,行数过大,导致读写性能受到影响。 扩展性 MySQL 无法在线灵活扩展,无法解决存储瓶颈。 SQL 复杂 大表轮转后出现多个分表,联合查询时需要 join 多个分表,SQL 非常复杂并难以维护; 单机 MySQL 缺乏大规模数据分析的能力。 数据壁垒 不同产品的数据库独立部署; 数据不互通,导致数据相关隔离,形成数据壁垒; 当进行跨产品计算时,需要维护多个异构数据源,访问方式复杂。数据分散在不同的数据孤岛上会增加数据分析难度,不利于共性价值的挖掘。如下图:
![](https://filescdn.proginn.com/b079acf489b87797b46308a4218c3caf/837cd7f33c33d52673ba4ef2a2848cb8.webp)
二、数据库选型
2.1 调研目标
必须兼容 MySQL 协议;
支持事务,保证任务以事务为维度来执行或遇错回滚;
支持索引,尤其是二级索引;
扩展性,支持灵活在线扩展能力,包括性能扩展和容量扩展。
稳定性和可靠性; 备份和恢复; 容灾等。
2.2 可选方案
![](https://filescdn.proginn.com/095d5a9b04f05177340e6913e60b637e/3d23e7f52b8279b5c8f0778b1eff9131.webp)
2.3 测试
![](https://filescdn.proginn.com/c250fa28ea7c7cf0806f57b4a6fa960b/5c880bd864e0fdfe8d006cd12dc43ac7.webp)
方案过于复杂
需要改业务代码
2.3.2 CockroachDB VS TiDB
TiDB 天然兼容 MySQL 协议,而 CRDB 兼容 PostgreSQL ; 如果业务以 MySQL 为主,那 TiDB 可能是比较好的选择;如果是 PostgreSQL,那CRDB 可能是优先的选择。
![](https://filescdn.proginn.com/897a5f8949023b90b6ec9562e6ed276c/6a5b273f447b9720da28ca04480bbc54.webp)
![](https://filescdn.proginn.com/b5e8121e9eb88c5075fd890b7d76d04d/f66834eedf916e5748b287c0d806fcde.webp)
范围查询: SELECT c FROM sbtest%u WHERE id BETWEEN ? AND ?
SELECT SUM(k) FROM sbtest%u WHERE id BETWEEN ? AND ?
SELECT c FROM sbtest WHERE id BETWEEN ? AND ? ORDER BY c
SELECT DISTINCT c FROM sbtest%u WHERE id BETWEEN ? AND ? ORDER BY c随机 IN 查询: SELECT id, k, c, pad FROM sbtest1 WHERE k IN (?)
随机范围查询: SELECT count(k) FROM sbtest1 WHERE k BETWEEN ? AND ? OR k BETWEEN ? AND ?
更新索引列: UPDATE sbtest%u SET k=k+1 WHERE id=?
更新非索引列: UPDATE sbtest%u SET c=? WHERE id=?
读写混合:范围查询 + 更删改混合
![](https://filescdn.proginn.com/23fea985b95151811bca8178a66a3b04/2b03ed050ce22ab324615a13167551e3.webp)
![](https://filescdn.proginn.com/73d8e73d033dd352e6b13f82543e2b63/c617fd4503224665f46a4b42cffdd5ba.webp)
![](https://filescdn.proginn.com/16be3cd5d731e164fb4ecf9f375b75c1/188ae8b2f9de17f379644485998d82be.webp)
![](https://filescdn.proginn.com/1b855676c20932f1ec101ff8d08cca57/504d253c5785d29381a265af58599cc5.webp)
![](https://filescdn.proginn.com/58343a72ed2b7453dd827fee43735ca5/8e564eed52bbea66500e76c068023013.webp)
三、TiDB 在网易互娱计费组的使用
3.1 TiDB 使用架构
![](https://filescdn.proginn.com/f1415340593c1d2d9ebce0fcf41bb0d2/fe94ca6a944f0fdf12a707a7166a6e0d.webp)
整个集群分为 TiDB、TiKV 和 PD 3 个模块分层部署; 使用 Nginx 作为前端负载均衡。
3.2 TiDB 解决了哪些需求
![](https://filescdn.proginn.com/8038428a7fb9f8f002ea6598e5aa4c56/897fb91818a14cf41d194f681a6ab479.webp)
3.3 TiDB 使用现状
业务
TiDB 作为线上 MySQL 数据镜像,负责线上数据的收集和集中管理,形成数据湖泊;
应用于数据平台服务,包括报表、监控、运营、用户画像、大数据计算等场景;
HTAP:OLTP + OLAP。
集群
测试集群:v2.1.15,用于功能测试、特性尝鲜;
线上集群:v2.1.15,80% 离线大数据计算任务 + 20% 线上业务。
规模
41 台服务器,88 个实例节点,38 个 Syncer 实时同步流(将升级为 DM);
存储:20TB/总 50TB,230 万个 Region;
QPS 均值 4k/s,高峰期万级 QPS,读写比约 1:5;
延迟时间:80% 在 8ms 以内,95% 在 125ms 以下,99.9% 在 500ms 以下。
四、最佳实践分享
4.1 集群管理
Ansible(推荐) 一键部署弹性伸缩,可在线灵活扩缩容; 升级,单节点轮转平滑升级; 集群启停和下线; Prometheus 监控。 Docker K8s 使用 TiDB Operator 可以在私有云和公有云上一键管理。
4.2 运维实践
4.2.1 Prometheus 监控
服务器基础资源的监控:内存、CPU、存储空间、IO 等;
集群组件的监控:TiDB、PD、TiKV 等;
数据监控:实时同步流、上下游数据一致性检验等。
![](https://filescdn.proginn.com/32f0f8452a663dc0aa0292cd3ef9369e/03439f0f99b4e465057fe724ce8dcd53.webp)
![](https://filescdn.proginn.com/7460f9c61575c768db322a42c8b1a32f/c2349511605387dcf57befc4b0259b18.webp)
Region 数量过多,Raft Store 还要处理 heartbeat message。 Raft Store 单线程处理速度跟不上集群写入速度。
![](https://filescdn.proginn.com/665159a5d9e6064181c2a9a8a3c76a09/6c2870f65d4340e157112ea6b94463c0.webp)
4.3 全网数据库遍历
![](https://filescdn.proginn.com/281917985132e6ba8463d67792b6be2f/896c63a623aeeef6509864b3044f0517.webp)
4.4 数据迁移
4.4.1 MySQL 到 TiDB
![](https://filescdn.proginn.com/f837fa38ed253e549d032c27bc66333e/2553e47037ad98fb76e22f58236ec2f9.webp)
图 14 数据从 MySQL 迁移到 TiDB
全量 使用工具 (Mydumper 或 MySQL Dump 等)从 MySQL 导出数据,并且记录当前数据的 binlog 位置; 使用工具(Loader 或 Lightning 等)将数据导入到 TiDB 集群; 可以用作数据的备份和恢复操作。 增量 TiDB 伪装成为上游 MySQL 的一个 Slave,通过工具(Syncer 或 DM)实时同步 binlog 到 TiDB 集群; 通常情况上游一旦有数据更新,下游就会实时同步过来。同步速度受网络和数据量大小的影响。
![](https://filescdn.proginn.com/527f8d47ed66faa2184956bd8d037029/57a867d7085d39d4d4a88fba2088fb22.webp)
图 15 数据迁出 TiDB
数据同步:同步 TiDB 集群数据到其他数据库; 实时备份和恢复:备份 TiDB 集群数据,同时可以用于 TiDB 集群故障时恢复。
全量:TiDB 兼容 MySQL 协议,在 MySQL 容量足够大的情况下,也可用工具将数据从 TiDB 导出后再导入 MySQL。 增量:打开 TiDB 的 binlog 开关,部署 binlog 收集组件(Pump+Drainer),可以将 binlog 数据同步到下游存储架构(MySQL、TiDB、Kafka、S3 等)。
4.5 优雅地「去分库分表」
![](https://filescdn.proginn.com/3ad2cc4c7801756d109a0042c4fd8327/2583dca5974db3e5e574ab1180180315.webp)
图 16 去分库分表举例
SELECT xx FROM HFeeall join HFee20190101 join ... join ...join ... join HFee20190917 WHERE xx;
SELECT xx FROM SuperHfeeall WHERE xx ;
4.6 业务迁移
数据完整和准确:数据很重要,保证数据不错、不丢; 迁移平滑和迅速:服务敏感度高,停服时间要短; 可回滚:遇到问题可随时切回到 MySQL。
![](https://filescdn.proginn.com/f5f8aef130bb0cdaab1cc5dde6e152a4/66a9e2723b523373a3443511049fd674.webp)
![](https://filescdn.proginn.com/917d01e4514bb44ae781b19fa6519b2d/b61b25abfa1d046ae6bd5e88fd8c2928.webp)
![](https://filescdn.proginn.com/4e95c70fbc32ebe51f83ded8e61d2731/75616861acffeef163cd1547b3f894d5.webp)
![](https://filescdn.proginn.com/9481c2d4352af140dab0c1f21806dcb1/596e7057f304aa298d33cd060b65e8b1.webp)
五、总结与展望
集群数据备份:希望提供集群更高效地备份和恢复 SST 文件的方式; 事务限制:希望可以放宽大事务的限制,现在仍需要人工切分大事务,比较复杂; 同步:希望 DM 支持上下游表结构不一致的同步; 数据热点问题:建议加强自动检测和清除热点功能; 客户端重试:目前客户端代码需要封装重试逻辑,对用户不友好,希望可以改进。
![](https://filescdn.proginn.com/8913302224f8ddb4644216bdd86a0aed/9356eaa15ac2bb5f10e81a21b639a025.webp)