分库分表后,数据库数据一致性问题如何解决? 上

简介: 分库分表后,数据库数据一致性问题如何解决? 上


前言

通过对数据的垂直拆分或水平拆分后,我们解决了数据库容量、性能等问题,但是将会面临数据迁移和数据一致性的问题。

在数据迁移方面,需要考虑如何快速迁移、平滑迁移、不停机的迁移等。待数据迁移完毕后,还需要校验数据的完整性。

数据一致性方面,要根据的业务来判断是否要必要引入分布式事务,如果需要引入分布式事务,需要斟酌是采用XA,还是基于BASE的柔性事务。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

数据迁移

数据迁移是很容易出故障的一个环节,需要考虑怎么更加平滑的迁移旧数据到新的数据库和系统,以及达到数据准确、快速迁移、减少停机、对业务的影响小等,特别是异构的数据结构情况下,难度更大。

全量

全量迁移的过程如下:

  • 业务系统停机。
  • 数据库迁移,校验数据一致性。
  • 然后业务系统升级,接入新的数据库。

缺点:

  • 需要业务系统停机
  • 迁移时间较长,对业务影响较大。如果是异构数据的话,需要使用程序来处理,迁移时间更长。

全量+增量

全量+增量迁移的方式,需要依赖数据本身的创建时间,步骤如下:

  • 先同步数据到最近的某个时间戳(创建时间)。
  • 然后发布系统升级维护的通知。
  • 然后同步最近一段时间变化的数据。
  • 最后升级系统,接入新的数据库。

全量+增量的同步相比全量同步的方式,大大的减少了系统停机的时间,对业务影响较小。

binlog+全量+增量

binlog+全量+增量是通过从数据库的主库或者从库解析和重新构造数据,实现复制。

通常情况下都需要中间件等工具的支持,一般需要中间件等工具的支持。可以实现多线程、断点续传、全量和增量数据的同步,还可以实现自动扩容和缩容。

常见的工具有:Canal、ShardingSphere-scaling等

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

分布式事务

XA分布式事务

XA分布式事务,是数据库本身支持的协议,具备强一致性。

XA分布式事务的组件:

  • 应用程序(Application Program, 简称AP): 用于定义事务边界,即事务的开始和结束,并且在事务边界内对资源进行操作。
  • 资源管理器(Resource Manager, 简称RM): 如数据库、文件系统,并且提供访问资源的方式。
  • 事务管理器(Transaction Manager, 简称TM): 负责分配事务唯一标识,监控事务的执行进度,并且负责事务的提交、回滚等。

XA接口:

  • xa_start 负责开启或者恢复一个事务分支
  • xa_end 负责取消当前线程与事务分支的关联
  • xa_prepare 询问RM是否准备好提交事务分支
  • xa_commit 通知RM提交事务分支
  • xa_rollback 通知RM回滚事务分支
  • xa_recover 需要恢复的XA事务

MySQL从5.0.3开始支持InnoDB引擎的XA分布式事务。

完整的XA事务处理流程如下:

主流的XA框架有:Atomikos、Narayana、Seata

XA分布式事务存在的问题:

  • 同步阻塞:全局事务包含了多个独立的事务分支,这一组事务分支要么都不成功,要不都失败,各个分支的ACID特性共同构成了全局事务的ACID特性。如果对读操作很敏感,需要将数据库的隔离级别设置为SERIALIZABLE,性能特别的差。
  • 单点故障:TM存在单点故障,需要考虑TM高可用性。
  • 数据不一致:极端情况下,会出现事务失败问题,需要监控和人工处理。即二阶段commit请求后,发送网络故障,只有一部分RM收到请求,其他节点没有收到Commit请求的情况。
柔性事务

BASE的核心在于,保证系统基本可用的前提下,通过利用柔性状态(支付操作后不是支付成功,而是支付中状态),实现数据的最终一致性,如下:

  • 基本可用(Basically available),分布式事务参与方不一定同时在线。
  • 柔性状态(Soft state), 允许系统状态更新有一定的延迟,出现一些中间状态,这个延迟对客户来说不一定能够察觉。
  • 最终一致性(Eventually consistent),通常是通过消息传递的方式保证系统的最终一致性。

柔性事务核心理念是通过业务逻辑将互斥锁操作从RM层上升到业务层,通过放宽对强一致性的要求,来换取系统吞吐量的提升。

BASE柔性事务常见模式

  • TCC: 通过手动补偿处理
  • AT: 通过自动补偿处理
相关文章
|
5月前
|
存储 缓存 负载均衡
数据库分库分表:提升系统性能的必由之路
数据库分库分表:提升系统性能的必由之路
180 1
|
1月前
|
存储 缓存 数据库
解决缓存与数据库的数据一致性问题的终极指南
解决缓存与数据库的数据一致性问题的终极指南
131 63
|
2月前
|
消息中间件 canal 缓存
项目实战:一步步实现高效缓存与数据库的数据一致性方案
Hello,大家好!我是热爱分享技术的小米。今天探讨在个人项目中如何保证数据一致性,尤其是在缓存与数据库同步时面临的挑战。文中介绍了常见的CacheAside模式,以及结合消息队列和请求串行化的方法,确保数据一致性。通过不同方案的分析,希望能给大家带来启发。如果你对这些技术感兴趣,欢迎关注我的微信公众号“软件求生”,获取更多技术干货!
134 6
项目实战:一步步实现高效缓存与数据库的数据一致性方案
|
2月前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
327 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
6月前
|
Oracle 关系型数据库 MySQL
实时计算 Flink版操作报错合集之采集oracle的时候报ORA-65040:不允许从可插入数据库内部执行该操作如何解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
243 3
|
2月前
|
消息中间件 缓存 NoSQL
15)如何保证缓存和数据库之间的数据一致性
15)如何保证缓存和数据库之间的数据一致性
54 1
|
6月前
|
缓存 关系型数据库 Java
不要将数据库中的“分库分表”理论盲目应用到 Elasticsearch
不要将数据库中的“分库分表”理论盲目应用到 Elasticsearch
47 0
|
3月前
|
消息中间件 Kafka 数据库
深入理解Kafka的数据一致性原理及其与传统数据库的对比
【8月更文挑战第24天】在分布式系统中,确保数据一致性至关重要。传统数据库利用ACID原则保障事务完整性;相比之下,Kafka作为高性能消息队列,采用副本机制与日志结构确保数据一致性。通过同步所有副本上的数据、维护消息顺序以及支持生产者的幂等性操作,Kafka在不牺牲性能的前提下实现了高可用性和数据可靠性。这些特性使Kafka成为处理大规模数据流的理想工具。
71 6
|
4月前
|
关系型数据库 分布式数据库 数据库
PolarDB产品使用问题之是否支持分库分表创建数据库
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
5月前
|
关系型数据库 MySQL 分布式数据库
PolarDB产品使用问题之要验证MySQL迁移后的数据库数据与迁移前的数据一致性,该怎么办
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
PolarDB产品使用问题之要验证MySQL迁移后的数据库数据与迁移前的数据一致性,该怎么办