根据 微服务重构:Mysql+DTS+Kafka+ElasticSearch解决跨表检索难题所描述,我们使用了Es解决微服务重构中遇到的Mysql库拆分问题,业务架构图如下所示:
在下午14:15左右,收到用户反馈,短暂时间内,出现了业务数据一致性问题
具体表现是:用户提交了一个页面操作,但是在查询接口里,没有返回最新的操作结果
具体校验是:通过问题反馈,我们直接对比DB和Es的具体索引,确实发现es的索引数据没有更新到
log类型 | 日志类型 | 作用 | 数据类型 | 用法 | 支持级别 |
---|---|---|---|---|---|
redo log | 物理日志 - 在xx数据页做了xx修改” | 称为重做日志,当MySQL服务器意外崩溃或者宕机后,保证已经提交的事务持久化到磁盘中(持久性) | redo log 数据主要分为两类:- 内存中的日志缓冲(redo log buffer)- 磁盘上的日志文件(redo logfile) | - 崩溃恢复 | Innodb存储引擎 |
undo log | 物理日志 - 在xx数据页做了xx修改” | 事务可以进行回滚从而保证事务操作原子性则是通过undo log 来保证的 | undo log 数据主要分两类:- insert undo log- update undo log | - 事务回滚- MVCC | Innodb存储引擎 |
bin log | 逻辑日志 -记录内容是语句的原始逻辑 | 记录了对MySQL数据库执行更改的所有的写操作,包括所有对数据库的数据、表结构、索引等等变更的操作。 | 三种格式,分别为 STATMENT 、 ROW 和 MIXED | - 数据恢复- 主从复制 | MySQL Server层 |
分析:
redo log
和undo log
都是物理日志,记录的是“在某个数据页做了什么修改”,属于Innodb
存储引擎,如果换了一个存储引擎,这俩能力都将不复存在,它们分别是用来。binlog
日志是逻辑日志,记录内容是语句的原始逻辑,属于MySQL Server
层。所有的存储引擎只要发生了数据更新,都会产生binlog
日志,binlog
会记录所有涉及更新数据的逻辑规则,并且按顺序写。能力 | 优点 | 不足 | 备注 | |
---|---|---|---|---|
ROW | 基于行的复制(row-based replication, RBR),不记录每条SQL语句的上下文信息,仅需记录哪条数据被修改了 | 稳定性较好,不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题; | 会产生大量的日志,尤其是 alter table 的时候会让日志暴涨。 | MySQL 5.7.7 之后,默认值是 ROW |
STATMENT | 基于SQL语句的复制( statement-based replication, SBR ),每一条会修改数据的SQL语句会记录到 binlog 中 | 不需要记录每一行的变化,减少了 binlog 日志量,节约了 IO , 从而提高了性能; | 在某些情况下会导致主从数据不一致,比如执行sysdate() 、 slepp() 等 | MySQL 5.7.7 之前,默认的格式是 STATEMENT |
MIXED | 基于 STATMENT 和 ROW 两种模式的混合复制(mixed-based replication, MBR),一般的复制使用 STATEMENT 模式保存 binlog ,对于一些函数,STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog。 |
binlog 是MySQL server层的日志,而redo log 和undo log都是引擎层(InnoDB)的日志,要换其他数据引擎那么就未必有redo log和undo log了。
它的设计目标是支持innodb的“事务”的特性,事务ACID特性分别是原子性、一致性、隔离性、持久性, 一致性是事务的最终追求的目标,隔离性、原子性、持久性是达成一致性目标的手段,根据的之前的介绍我们已经知道隔离性是通过锁机制来实现的,而事务的原子性和持久性则是通过redo log 和undo log来保障的。
流程步骤如下所示:
通过云组件监控,可以得到:
结论:
方向:
分析:
分析:
Kafka 实例监控的指标有很多,我们主要关注下面几个:
结论是:
通过数据库变更追溯,发现业务库的一张千万级数据量大表,执行了一次业务变更(执行了一个ALTER的DDL),导致了大量binlog产生。
当下Kafka的生产速率略大于消费速率,导致了部分数据滞后消费,要解决
瓶颈是业务消费逻辑(数据落库到ES)。
因此,从消费端入手,提高消费能力(业务消费瓶颈-落库到ES),将客户端限流的令牌数量提高,可以参考我公众号写的另外文章:源码解析:Guava客户端限流
从生产端入手,后续运维变更,减少突发峰值可能性:
通过对消费能力提升,我们通过对kafka的监控,找了一个业务低峰期执行SQL变更的时机,观察到topic分区消息堆积情况不再出现,说明问题得到了解决。
在分布式系统下,业务链路往往一环扣一环,如果某个环节出现了性能卡点,可能会在其他环节暴露出问题。因此我们分析问题时,往往要结合上下游的来分析链路。
其他文章
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。