rac数据库架构分析与实战攻略-【选型实践】58集团的数据库技术选型思路
本文是TUG在北京举办的《不同业务场景下的数据库技术选型思路》实战记录整理。 作者：58团DBA宣凯
大家好，我是58集团DBA宣凯，今天为大家带来的分享题目是《58集团数据库技术选型思路》。
首先，让我向您介绍一下我们集团的业务概况。 我们的业务范围包括58同城、赶集网、安居客、58金融、中国人才、驾校一点通等公司。 我们使用的数据库有MySQL、Redis、ES、TiDB等，日访问量约8000亿，4000+集群，1500+物理服务器。
TiDB 在 58 群的使用
我们目前线上生产环境有11套TiDB集群，版本3.0.3，物理机数量80台，数据总量40T，日访问量10亿左右。 我们总共有2300套MySQL集群和11套TiDB集群，占比大概是0.47%，访问比例是2%。
在响应时间上，TiDB 是一个分布式数据库，其响应时间高于单机的 MySQL。 我们之前做过的测试表明，TiDB 和 MySQL 的响应时间比在 1.2 到 1.5 左右，可以接受，所以我们正在逐步用 TiDB 替换 MySQL。
TiDB 在 58 集团的使用场景包括交易账务流转（也是最大的库）、金融数据仓库、私有云监控、用户行为日志、语音机器人、客服系统、广告投放系统、交友系统、帖子信息， ETC。
TiDB 的选型流程
我们在2018年Q1开始研究TiDB 2.0，当时遇到的问题是私有云监控的数据存储在MySQL中。 由于数据量巨大，需要定期清理表，给DBA带来了很大的工作量。
我们知道 TiDB 之后就开始研究，终于在 2018 年 4 月推出了第一个 TiDB，迁移了公司内部系统的一个监控日志。 第一套的体量很小，大约每秒2000次访问，整体数据量在7T到8T之间。 2018年12月，我们开始测试2.1 GA版本。 此时大约有4套集群在线，存放着内部私有云的所有日志系统。 到 2019 年 9 月，我们的线上和测试环境已经全部接入 TiDB 3.0.2。
我们使用 TiDB 来解决几个 MySQL 问题：
这就引出了我们选择数据库的一些思考维度：
所以我们选择了具有代表性的数据库 TiDB 来解决这些问题。
前面我们提到了我们在使用 MySQL 时遇到的一些问题，那么 TiDB 是如何解决的呢？
58 群 TiDB 的使用结构
我们的 TiDB 架构比较简单。 应用方面，第一步是分别读写域名，后端使用Load。 默认情况下，我们在一个集群上有 4 个 TiDB 节点，一个用于写入，三个用于读取。 如果写入达到瓶颈，可以扩容 TiDB 节点。
58集团TiDB系统建设
首先，我们建立了工单系统。 开发者需要使用私有云平台进行日常的数据库操作，如DDL、DML等，不能直接连接数据库。
第二，我们搭建了一个监控系统，将TiDB的监控数据同步到我们的网站，然后根据我们的数据模型展示在私有云平台上。
三是搭建了自助查询系统，可以快速生成SQL，SQL可以直接导出数据，提高了RD使用平台的效率。
第四，我们建立了报表系统，方便集群的管理。 通过抓取报表中的数据，将报表展示在运维平台上，日常值班的DBA可以通过报表掌握各个集群的状态：是否出错，容量是否充足，是否需要展开等
第五，我们建立了每日巡检制度，每天早上九点和晚上六点对TiDB集群进行巡检。 目前检查的项目比较简单，大概十几个项目，可以帮助我们及时发现一些隐患，比如某个时间点慢日志突然爆发rac数据库架构分析与实战攻略，某个表缺少索引，或者异常在错误日志中。
第六，最近我们开发了运维工具和备份系统，使数据库能够满足审计的需要。
TiDB工单系统介绍
我们的 TiDB 工单系统支持建表、改表、数据导出、数据变更、账号授权等工单，可以满足大部分 RD 的日常需求。 后端进行校验，提交给 TiDB 执行，与 MySQL 同路。 但是我们对MySQL的规则做了一些区分。 比如TiDB目前不支持自增主键，而MySQL需要自增主键。
监控系统
首先会从云DB平台拉取TiDB的硬件信息，然后比较同步更新的配置文件是否一致，不一致则更新。 它会从网站上拉取监控数据，然后将数据发送到网站。 如果发现异常，后台会通过微信、短信、邮件、IM发送告警。
TiDB 运维
我们在运维工具方面做了几件事情：我们有集群拓扑查询工具，集群状态检查，慢日志分析，TiDB监控巡检，自动部署，会话管理工具。
58 Group 使用 TiDB 的经验
我们刚开始使用 TiDB 的时候，因为机器上有 4 个磁盘，我们在一台机器上部署了 4 个 TiKV，但是造成了宕机时间特别长的问题。 最长的一次是一次 TiKV 机器宕机之后大概两个半小时没起床，解决办法就是打标签。 标注后发现使用3.0.1后宕机时间还是比较长，于是向TiDB官方求助，升级到3.0.2后宕机时间缩短到一分钟左右。
二是SQL语法错误。 让我举一个例子。 在3.0.1中，当left join超过4个时，可能会报语法错误。 for的执行也有问题，新版本已经解决了。
三是我们之前选机的时候，我们是基于磁盘部署TiKV的。 后来发现是 CPU 资源不够用，TiKV 越升级越占用 CPU。 跟官方沟通后，我们换了一个新的模型，增加了 CPU 核数，然后减少了 TiKV 的数量。 所以我们得出一个结论：用最好的机器，用最新的版本，一切问题都会迎刃而解。
后续规划
这部分主要分为四个方向。
首先，我们将优化监控模型。 现在我们只需从中提取数据并将其发送给警报。 平台再对数据进行聚合展示，不如MySQL的监控那么完善。
其次，我们会把 TiDB 和 TiKV 的自动伸缩放在我们的运维平台上。
接下来我们将搭建一个慢日志系统。 目前 MySQL 有慢速日志系统，包括日报和类似实时流的日志，但 TiDB 的日志格式与 MySQL 不同。 目前只能在文件系统中实时读取，在未来TiDB的慢日志系统中我们会单独做一套。
最后是实时数据恢复，因为TiDB没有一个理想的备份系统，我们只是简单的用它来做备份，然后我们也会用它来做实时备份，把两块数据联系起来。
问答
Q1：您好，请问58集团的TiDB备份恢复系统是如何实现的？ 是物理备份还是逻辑备份？ 备份之后，这些文件有没有压缩等优化？
答：是的。 官方物理备份尚未发布。 我们只是将其用于简单的逻辑备份。 如果数据库比较小，我们会备份整个数据库。 如果比较大，我们会优先对一些重要的表进行单表备份。 这是一个逻辑备份。 备份完成后，我们会放在专门的存储机器上。 也会实时备份到存储机上。 我们可以手动查找文件和备份文件，必要时进行相应的恢复。
Q2：请问一下，目前58群的TiDB选机大概用的是什么机器？
A：我们刚开始引入 TiDB 的时候，并没有把它当成一个核心数据库，所以我们从 DBA 的角度使用了一台低端的机器。 当时是32核的CPUrac数据库架构分析与实战攻略，型号是E5 2630，主频是2.1，磁盘是一块1.7T的PCIE卡，不过这个卡比较老，是Intel的4530，装上2.1后，我们发现CPU不够用。 当时看了一下，生意没那么大，就忍了。 3.0之后，对CPU核心数的需求增加了，然后我们开始改变选机。 现在我们使用与MySQL相同的配置机器。 单核数没有变化，依然是32核。 CPU的主频是2.4。 磁盘1.7T/盘，内存128，今年三季度新进了一批机器。 内存为256，CPU主频降为2.1，核心数为48。
Q3：现在一台物理机上有多少个实例？
A: 使用 3.0 版本的机器现在在一台机器上使用一个 TiKV。 我们的后续型号之一是 48 核机器，增加了内存和三个 SSD 磁盘。
Q4：请问您刚才提到有一个for，这种悲观锁的场景，TiDB之前是不支持的。 请问你这里是怎么解决的？
A：我们较少使用悲观锁。 之前我们金融数仓的同事反馈说它的执行没有达到预期，但是DBA没有办法解决这个问题，所以我们暂时让他使用乐观锁。 我认为正式版3.0.3也解决了这个问题，但还需要进一步测试。
有什么想和宣凯先生交流的吗？ 欢迎在评论区留言告诉我们！
以上就是关于：rac数据库架构分析与实战攻略-【选型实践】58集团的数据库技术选型思路的相关内容，更多精彩请继续关注玩手游。
