事务一致性解决方案汇总

2PC理论

应用场景

  • 主要应用于两个数据库或者系统之间的同步

操作阶段

  • 准备阶段: 协调者向所有参与者发起执行一个事务的询问。
  • 提交阶段或者回滚阶段:如果索引参与者都回答YES,那么将执行commit提交任务。如果有任意一个没有返回YES那么将发起callback回滚命令。

2PC缺陷

  • 在提交阶段服务出问题了

最终一致性

rabbitMQ(业务方自己实现)

思路

  • 业务方准备一个消息表,将操作的事务在本地做强一致性.然后再准备一个定时任务,定时的去扫描消息表,将其推送给RabbitMQ

遇到的问题

  • 如果推送失败怎么办?
推送失败重试推送,一般3次.再失败将报警,进行人工介入.

rocketMQ(MQ支持)

思路

  • 依赖rocketMQ把消息发送两个阶段,一个是prepare阶段与一个是comfirm阶段.第一步系统A调用prepare方法,将消息暂存起来.第二步去操作业务表成功后,第三步将调用comfirm方法.确认将消息发送出去.

遇到的问题

  • 如果第一成功二三失败,如果第一二成功第三失败情况怎么办?
利用mq功能,将会默认1min扫描一个预发送没有确认的消费,回调给发送方.由发送方决定是否放弃.

TCC

思路

  • 借助TCC框架

遇到的问题

  • 如果在第二阶段调用方发生服务宕机或者某个服务超时?
不断重试.这样要求comfire与cancel都支持幂等操作.

事务状态表 + 调用者重试 + 接收者幂等

思路

  • 准备一张事务状态表.来标志事务操作阶段.再启动一个任务,定期的来执行为达到最终状态的事务,重新发送.接收方做幂等操作.

遇到的问题

  • 如果后台任务仍不能成功?
事务状态表加上ERROR标志,来人工介入

对账

思路

  • 对理论上最终状态去做对比,不一致的进行补偿操作

遇到的问题

  • 如何补偿?
需要找出其中的规律

弱一致性 + 基于状态补偿

  • 待补充

重试 + 回滚 + 报警 + 人工修复

  • 待补充

参考

  • 软件架构设计书
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
《mysql管理之道:性能调优、高可用与监控》由资深mysql专家撰写,以最新的mysql版本为基础,以构建高性能mysql服务器为核心,从故障诊断、表设计、sql优化、性能参数调优、mydumper逻辑、xtrabackup热备份与恢复、mysql高可用集群搭建与管理、mysql服务器性能和服务监控等方面多角度深入讲解了如何去管理与维护mysql服务器。 书中内容以实战为导向,所有内容均来自于笔者多年实践经验的总结和对新知识的拓展,同时也针对运维人员、dba等相关工作者会遇到的有代表性的疑难问题给出了实用的情景模拟,并给出了解决方案。不论你目前有没有遇到过此类问题,相信对你以后处理相关问题都会有所借鉴。本书适合所有希望构建和管理高性能、高可用性的mysql数据库系统的开发者和dba阅读。 目录 · · · · · · 前言 第一部分 mysql5.5 新特性篇 第1章 mysql5.5介绍 2 1.1 性能上的显著改变 2 1.1.1 mysql5.5默认存储引擎的调整 2 1.1.2 充分利用cpu多核的处理能力 7 1.1.3 提高刷新脏页数量和合并插入数量,改善磁盘i/o处理能力 8 1.1.4 增加自适应刷新脏页功能 9 1.1.5 让innodb_buffer_pool缓冲池中的热数据存活更久 9 1.1.6 innodb的数据恢复时间加快 11 1.1.7 innodb同时支持多个bufferpool实例 15 1.1.8 可关闭自适应哈希索引 17 1.1.9 在innodb中可选择使用内存分配程序 18 1.1.10 提高默认innodb线程并发数 21 1.1.11 预读算法的变化 22 1.1.12 首次在linux上实现了异步i/o 23 1.1.13 恢复组提交 24 1.1.14 innodb使用多个回滚段提升性能 26 1.1.15 改善清除程序进度 26 .1.1.16 添加删除缓冲和清除缓冲 27 1.1.17 控制自旋锁spin lock轮训间隔 28 1.1.18 快速创建、删除、更改索引 29 1.1.19 innodb支持创建压缩数据页 30 1.1.20 可动态关闭innodb更新元数据的统计功能 37 1.2 安全性、稳定性的显著改变 38 1.2.1 复制功能加强 38 1.2.2 中继日志relay-log可自我修复 39 1.2.3 开启innodb严格检查模式 39 1.3 动态更改系统配置参数 39 1.3.1 支持动态更改独立表空间 39 1.3.2 支持动态更改innodb锁超时时间 40 1.4 innodb新参数汇总 40 1.5 同步复制新参数汇总 48 1.6 sql语句写法的改变 53 1.6.1 delete表连接语法改变 53 1.6.2 mysql5.5存储过程支持limit变量 54 1.7 mysql5.1升级为mysql5.5 55 1.7.1 采用mysql_upgrade升级授权表方式升级 55 1.7.2 直接安装mysql5.5,采用数据导出/导入方式升级 59 1.8 性能测试:mysql5.5与mysql5.1 60 第2章 半同步复制 62 2.1 半同步复制简介 62 2.2 半同步复制安装配置 63 2.3 参数说明 63 2.4 功能测试 64 2.4.1 如何验证半同步复制是否正常工作 64 2.4.2 半同步复制与异步复制的切换 65 2.5 性能测试 68 2.6 小结 70 第二部分 故障诊断与性能优化篇 第3章 故障诊断 72 3.1 影响mysql性能的因素 72 3.2 系统性能评估标准 73 3.2.1 影响linux服务器性能的因素 73 3.2.2 系统性能评估指标 74 3.2.3 开源监控和评估工具介绍 76 3.3 故障与处理 79 3.3.1 连接数过多导致程序连接报错的原因 79 3.3.2 记录子查询引起的宕机 84 3.3.3 诊断事务量突高的原因 87 3.3.4 谨慎设置binlog_format=mixed 90 3.3.5 未设置swap分区导致内存耗尽,主机死机 94 3.3.6 mysql故障切换之事件调度器注意事项 95 3.3.7 人工误删除innodb ibdata数据文件,如何恢复 97 3.3.8 update忘加where条件误操作恢复(模拟oracle闪回功能) 99 3.3.9 delete忘加where条件误操作恢复(模拟oracle闪回功能) 108 第4章 同步复制报错故障处理 112 4.1 最常见的3种故障 112 4.1.1 在master上删除一条记录时出现的故障 112 4.1.2 主键重复 114 4.1.3 在master上更新一条记录,而slave上却找不到 115 4.2 特殊情况:slave的中继日志relay-log损坏 116 4.3 人为失误 118 4.4 避免在master上执行大事务 119 4.5 slave_exec_mode参数可自动处理同步复制错误 120 4.6 如何验证主从数据一致 121 4.7 binlog_ignore_db引起的同步复制故障 123 4.8 mysql5.5.19/20同步一个bug 124 4.9 恢复slave从机上的某几张表的简要方法  126 4.10 如何干净地清除slave同步信息 127 第5章 性能调优 129 5.1 表设计 129 5.2 字段类型的选取 133 5.2.1 数值类型 134 5.2.2 字符类型 139 5.2.3 时间类型 141 5.2.4 小技巧:快速修改表结构 148 5.2.5 pt-online-schema-change在线更改表结构 152 5.2.6 mysql5.6在线ddl更改表测试 158 5.3 采用合适的锁机制 161 5.3.1 表锁的演示 161 5.3.2 行锁的演示 164 5.3.3 innodb引擎与myisam引擎的性能对比 166 5.4 选择合适的事务隔离级别 168 5.4.1 事务的概念 168 5.4.2 事务的实现 169 5.4.3 事务隔离级别介绍 171 5.5 sql优化与合理利用索引 177 5.5.1 如何定位执行很慢的sql语句 177 5.5.2 sql优化案例分析 178 5.5.3 合理使用索引 188 5.6 my.cnf配置文件调优 198 5.6.1 per_thread_buffers优化 198 5.6.2 global_buffers优化 200 5.6.3 query cache在不同环境下的使用 201 5.6.4 tuning-primer.sh性能调试工具的使用 205 5.6.5 72 gb内存的my.cnf配置文件 208 5.6.6 谨慎使用分区表功能 211 5.7 mysql5.6同步复制新特性详解 213 第6章 备份与恢复 223 6.1 冷备份 224 6.2 逻辑备份 224 6.2.1 mysqldump增加了一个重要参数 225 6.2.2 取代mysqldump的新工具mydumper 226 6.2.3 逻辑备份全量、增量备份脚本 229 6.3 热备份与恢复 230 第三部分 高可用集群管理篇 第7章 目前流行的4种高可用架构 236 7.1 采用mysql自带的replication架构 237 7.1.1 keepalived+mysql replication架构的搭建演示 237 7.1.2 mmm+mysql replication架构的搭建演示 241 7.2 heartbeat+drbd+mysql架构的搭建演示 249 7.3 红帽rhcs共享存储架构的搭建演示 254 7.3.1 安装过程 257 7.3.2 红帽rhcs集群的维护 265 7.4 mysql高可用集群ha解决方案的测试评估 267 第8章 批量管理服务器 270 8.1 开源工具pssh的使用方法 270 8.2 自己编写的ssh服务器批量管理工具 273 第四部分 监控篇 第9章 性能监控 278 第10章 服务监控 283 10.1 nagios搭建与维护 283 10.2 mysql数据库的监控脚本 288 第五部分 项目案例 第11章 项目案例讲解 292 11.1 数据碎片整理方案 292 11.2 用户信息表水平拆表方案 296 11.3 阿里巴巴中间件cobar水平拆表方案 299
详解数据仓库建模方案方法 最后,我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例,帮助大 家来了解整个数据建模的过程。 一、 什么是数据模型 数据模型是抽象描述现实世界的一种工具和方法,是通过抽象的实体及实体之间 联系的形式,来表示现实世界中事务的相互关系的一种映射。在这里,数据模型表现 的抽象的是实体和实体之间的关系,通过对实体和实体之间关系的定义和描述,来表 达实际的业务中具体的业务关系。 数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型 ,一般的来说,我们数据仓库模型分为几下几个层次,如图 2 所示。 图 2. 数据仓库模型 通过上面的图形,我们能够很容易的看出在整个数据仓库得建模过程中,我们需 要经历一般四个过程: 业务建模,生成业务模型,主要解决业务层面的分解和程序化。 领域建模,生成领域模型,主要是对业务模型进行抽象处理,生成领域概念模型。 逻辑建模,生成逻辑模型,主要是将领域模型的概念实体以及实体之间的关系进行数据 库层次的逻辑化。 物理建模,生成物理模型,主要解决,逻辑模型针对不同关系型数据库的物理化以及性 能等一些具体的技术问题。 因此,在整个数据仓库的模型的设计和架构中,既涉及到业务知识,也涉及到了 具体的技术,我们既需要了解丰富的行业经验,同时,也需要一定的信息技术来帮助 我们实现我们的数据模型,最重要的是,我们还需要一个非常适用的方法论,来指导 我们自己针对我们的业务进行抽象,处理,生成各个阶段的模型。 二、 为什么需要数据模型 在数据仓库的建设中,我们一再强调需要数据模型,那么数据模型究竟为什么这 么重要呢?首先我们需要了解整个数据仓库的建设的发展史。 数据仓库的发展大致经历了这样的三个过程: 简单报表阶段:这个阶段,系统的主要目标是解决一些日常的工作中业务人员需要的报 表,以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部 分表现形式为数据库和前端报表工具。 数据集市阶段:这个阶段,主要是根据某个业务部门的需要,进行一定的数据的采集, 整理,按照业务人员的需要,进行多维报表的展现,能够提供对特定业务指导的数据 ,并且能够提供特定的领导决策数据。 数据仓库阶段:这个阶段,主要是按照一定的数据模型,对整个企业的数据进行采集, 整理,并且能够按照各个业务部门的需要,提供跨部门的,完全一致的业务报表数据 ,能够通过数据仓库生成对对业务具有指导性的数据,同时,为领导决策提供全面的 数据支持。 通过数据仓库建设的发展阶段,我们能够看出,数据仓库的建设和数据集市的建 设的重要区别就在于数据模型的支持。因此,数据模型的建设,对于我们数据仓库的 建设,有着决定性的意义。 一般来说,数据模型的建设主要能够帮助我们解决以下的一些问题: 进行全面的业务梳理,改进业务流程。 在业务模型建设的阶段,能够帮助我们的企业或者是管理机关对本单位的业务进 行全面的梳理。 通过业务模型的建设,我们应该能够全面了解该单位的业务架构图和整个业务的 运行情况,能够将业务按照特定的规律进行分门别类和程序化,同时,帮助我们进一 步的改进业务的流程,提高业务效率,指导我们的业务部门的生产。 建立全方位的数据视角,消灭信息孤岛和数据差异。 通过数据仓库的模型建设,能够为企业提供一个整体的数据视角,不再是各个部 门只是关注自己的数据,而且通过模型的建设,勾勒出了部门之间内在的联系,帮助 消灭各个部门之间的信息孤岛的问题,更为重要的是,通过数据模型的建设,能够保 证整个企业的数据的一致性,各个部门之间数据的差异将会得到有效解决。 解决业务的变动和数据仓库的灵活性。 通过数据模型的建设,能够很好的分离出底层技术的实现和上层业务的展现。 当上层业务发生变化时,通过数据模型,底层的技术实现可以非常轻松的完成业 务的变动,从而达到整个数据仓库系统的灵活性。 帮助数据仓库系统本身的建设。 通过数据仓库的模型建设,开发人员和业务人员能够很容易的达成系统建设范围 的界定,以及期目标的规划,从而能够使整个项目组明确当前的任务,加快整个系 统建设的速度。 三、 如何建设数据模型 建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么 建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何 创建适合自己的数据模型。 1) 数据仓库数据模型架构 数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的,我们首 先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚 地看到,整个数据模型的架构分成 5 大部分,每个部分其实都有其独特的功能。 图 3. 数据仓库数据模型架构 从上图我们可以看出,整个数据仓库的数据模型可以分为大概 5 大部分: 系统记录域(System

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值