背景说明

在国产化迁移的浪潮中，各行各业都开始进行相关的国产数据库替换操作。信创产业包括基础硬件、基础软件、应用软件、信息安全这四大类别。国产化的适配，是涉及全产业链的全栈适配。

（图片来源：百度百科）

某业务系统是企业应用中的核心系统，也是业务上下游最关键的应用系统之一，其承担着海量用户的实时账务处理、账单生成和支付处理等重要功能内容。该业务系统的稳定性和安全运行，直接影响对外用户的使用满意度和业务的收益，任何系统或者数据库问题都可能导致对外服务的可用性，从而引发较大经济损失和社会影响。

在国产化迁移的大背景需求下，原部署在Intel x86环境下的业务系统，需要迁移到国产化环境中，以实现信创替代。本文重点分享数据库层面的国产化替代经验。

业务场景及诉求

该业务系统不仅要处理大量的在线事务，即OLTP业务，同时还要实时分析部分复杂查询，即OLAP业务。是一个经典的HTAP混合事务/分析处理的应用场景

该业务系统对稳定性和数据安全有极高的要求，核心数据库系统必须具备高稳定性、高可靠性、高安全性和性能，同时拥有全面的容灾能力，确保数据零丢失。随着数字化转型的深入， 业务系统要实施核心系统数据库的分布式改造，实现从依赖 MySQL 分库分表技术栈，全面向国产分布式数据库的自主可控转型 。

数据库选型评估维度

在国产数据库百花齐放的情况下，出现了多种多样的数据库，包括：

• 非关系型数据库
• 关系型数据库 OLAP、OLTP
• 时序数据库
• 文档数据库
• 分布式数据库等多种类型。

在选择国产数据库时，企业应根据自身的业务需求和技术特点进行综合考虑。业务要结合应用系统的数据量规模、延时容忍度和混合负载率，分别做好评估。在TiDB社区上有一个图能非常生动地说明这个问题，如下图所示：

这个图的核心意思，大致是对于不同体量下的业务应用，其关注的侧重点明显不同，对应的数据库选型偏向也会明显不一样。

从数据量规模的角度分析：

• 当业务的数据量处于一个比较小的规模是，比如MB级别、GB 级别时，单机内存或单机数据库就能满足需求。这个时候没必要硬要上分布式数据库。
• 但当业务应用的数据量规模达到 10 TB、百 TB 级别、甚至 PB 级别时，需要选择更具扩展性的数据库了。此时单机数据库明显不太合适，而应该选择具备良好扩展性的分布式数据库。

从访问负载类型的角度分析：

• 对于在线交易系统等对延时敏感的业务，即OLTP负载，数据库的响应速度至关重要。
• 对于在线实时分析复杂查询，即OLAP分析负载，数据库的计算效率和吞吐量则为更加关注。
• 而混合负载率则决定了在线实时业务和统计分析报表类业务能否在同一数据库中高效执行，即更加依赖HTAP特性。

TiDB高可用方案

TiDB作为一款优秀的国产分布式数据库，具备下面优秀的特点：

• TiDB内核架构支持金融级高可用 架构不存在单点瓶颈 多副本存储，数据副本通过 Multi-Raft 协议同步，保证数据实时强一致性
• 高性能实时HTAP TiKV采用行存，支持高并发交易业务 TiFlash采用列存，支持复杂分析查询
• 灵活弹性伸缩 一键水平扩缩容，操作对业务透明
• 兼容MySQL协议和生态

灵活且优秀的高可用架构

个人之前总结过下面高可用架构图，这可以很好地说明TiDB高可用方案的优越性。

在计算层不仅可以实现域名独享，还可以隔离 不同类型的负载流量，且还支持计算层跨机房容灾。

在存储层也有类似的优点，不仅可以实现行、列存隔离，还可以让 OLAP业务独享列存 存储和计算资源，做到存储层的行、列存储物理隔离，此外存储层还支持跨机房容灾，这个点非常重要。

TiDB选型 技术优势

站在一个系统架构师的视角，TiDB的核心选型优势，要点如下：

• 良好的扩展性：

  • 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容。

• 安全高可用：

  • 支持强一致性和高可用。天然支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明。

• 对开发友好：

  • 支持 MySQL 协议，业务代码几乎不用修改直接就能使用。

• 对运维友好

  • 有丰富的工具生态，覆盖数据迁移、同步、备份等多种场景。对DBA非常友好。

TiDB 适用场景

总结来说，TiDB适用的场景大致如下：

• 替换分库分表的业务场景
• 业务增长较快，数据量大（500GB~500TB）
• 普遍性场景，综合类业务（TP和AP均有，以TP为主）
• 降本增效的要求背景下，将多个业务进行融合，把上游多套小数据规模的MySQL（1GB~100GB）合并到一套TiDB集群。提高资源利用率，同时释放运维管理压力。

国产化改造-两地三中心方案

我们在设计存储方案的时候，考虑到异地数据灾备的要求，充分利用了TiDB的存算分离的特点，实施了两地三中心的部署方案。我们对存储层设置了5副本，在北京的两个机房利用Placement Rule 放置策略分别设置2个TiKV副本，且具有Vote的权限，即北京的这两个机房可以被选举为Leader。另外1个Folloer 副本放置在天津的机房，只承担数据副本的异地灾备，不做选主。

对于TiPD节点，我们通过设置选举权重，将PD的Leader也限制在北京的两个机房内。

TiDB计算层节点只在北京的两个机房部署，在天津的机房部署tidb-server节点，同时分别在北京机房设置两个不同的域名对外服务，计算层面也实现了跨机房的容灾。

由于北京的两个机房之间距离较短而且有专线，业务应用也部署在北京机房内，这样就实现了数据就近存储和服务，不仅实现了两地三中心的数据库高可用，还满足了异地数据安全容灾的要求，还可以保证高性能访问，可以说该方案非常优秀。

如果硬要说该方案的缺点的话，那就是硬件成本比较高，业务需要有三个机房+网络专线的硬件条件来满足，也不是一般业务可以承受得起的这个苛刻的硬件要求的。

业务系统国产化迁移

该业务系统应用侧采用双机房双活的容灾策略，数据库内核使用TiDB，实施了两地三数据中心的高可用部署，完全满足金融级别的高标准要求。系统支持交易和大型数据分析型应用的需求，能够在任意数据中心出现故障时，确保数据不丢失，并实现秒级业务切换。在前期演练中表明，数据零丢失（RPO=0）和故障秒级自动切换（RTO<60 s），

• 割接前

  • 兼容性验证：TiDB 与 MySQL 高度兼容，应用适配过程几乎无缝迁移，极大降低了迁移成本。
  • 分区键设计：不需要分区键，region自动分布，避免侵入应用代码，也解决了数据倾斜问题。

• 割接中

  • 提前迁移历史基量数据，大大减少割接当晚的风险。
  • 最终，整个割接窗口控制在4小时内，迁移过程很高效和平稳。

• 割接后

  • 系统访问延迟大幅降低，平均处理性能提升约30%。
  • 数据总存储空间由40TB缩减至10TB，节约了75% 存储成本。

迁移采坑经验

TiDB几乎兼容MySQL5.7协议，所以应用系统在语法兼容性这块几乎没什么问题。但是在应用实践过程中，由于分布式架构不同于集中式数据库，所以业务系统从集中式数据库迁移到分布式数据库后，也遇到下面常见的问题。这些问题在官网或者社区里都有很成熟的解决方案。

• 基量数据大，迁移耗时久。操作中出现误操作后，重试代价很高。

  • 注意操作准确性，提前准备好各个要执行的步骤，要具体的命令细节。
  • 同时，在系统进行割接前要提前迁移，并且在增量同步时 定期校验上下游数据的一致性情况。

• 热点问题处理。分布式数据库某些节点存在数据倾斜，或访问负载倾斜，导致出现热点问题。

  • 针对热点问题，通过Dashboard的热力图分析热点产生原因，在前期做兼容性验证时协助业务重新设计表结构，避免连续自增整形字段。同时引入随机 ID，在业务层面避免大范围数据扫描来解决。

• 大SQL改造。业务大SQL访问导致扫描大量数据，易出现OOM等问题。

  • 对于业务的OLAP处理，出现扫描效率低、OOM的问题，针对性改写大SQL，进行针对性优化。
  • 必要的地方，可以引入中间表的方式减少一次性的内存消耗，缓解OOM现象。

• DDL元数据锁问题，导致业务长时间无响应。

  • 通过官方指引定位到元数据锁的问题后，与业务评估后提前关闭元数据锁的功能，业务完善重试机制。

总结与建议

本文以一个迁移案例探讨了业务应用选用TiDB构建数据库国产化高可用部署的方案，希望能为正在或计划进行数据库国产化改造的企业提供有价值的参考。

• 业务匹配

  • 业务要结合应用系统的数据量规模、延时容忍度和混合负载率，分别做好评估。
  • 适配自身业务需求，包括数据的存储、查询、分析等要求。根据业务的实际需求选择适合的数据库

• 技术评估

  • 选择数据库产品时，对其性能、稳定性、安全性等进行全面技术评估。
  • 通过技术比对、测试验证等方式，综合评估产品实际表现。

• 生态系统

  • 考虑数据库的生态系统完善情况，包括社区支持、第三方工具支持等。完善的生态系统能帮助企业更好地使用和维护数据库。

• 成本效益

  • 成本效益问题，不仅需要考虑硬件、软件的成本，还要考虑运维成本以及未来的升级和维护等成本。

一言以蔽之，在国产数据库选型时，应根据自身的业务需求和技术特点进行综合考虑。

TiDB就是一个非常值得推荐的选项！