当前位置：首页 > article >正文

Kafka消息堆积问题排查

article 2024/11/16 9:48:30

背景

业务架构图

根据微服务重构：Mysql+DTS+Kafka+ElasticSearch解决跨表检索难题所描述，我们使用了Es解决微服务重构中遇到的Mysql库拆分问题，业务架构图如下所示：

Kakfa消息堆积导致的数据一致性问题

在下午14:15左右，收到用户反馈，短暂时间内，出现了业务数据一致性问题

具体表现是：用户提交了一个页面操作，但是在查询接口里，没有返回最新的操作结果

具体校验是：通过问题反馈，我们直接对比DB和Es的具体索引，确实发现es的索引数据没有更新到

binLog/redoLog/undoLog对比

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会记录所有涉及更新数据的逻辑规则，并且按顺序写。
redo log 和undo log的核心是为了保证innodb事务机制中的持久性和原子性，事务提交成功由redo log保证数据持久性，而事务可以进行回滚从而保证事务操作原子性则是通过undo log 来保证的。

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来保障的。