背景
业务架构图
根据 微服务重构：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来保障的。
排查流程
流程步骤如下所示：
1、Kafka消费者组-监控
通过云组件监控，可以得到：
从14:00起，kafka不断有待消费数据的毛刺点出现，同时kafka的具体topic消费速度也随着毛刺点出现而升高
在15:15前后有一个未消费消息数的峰值接近 4w条/分钟
结论：
某个group对topic进行的消费，出现了大量消息堆积，导致了下游业务的数据一致性问题
虽然产生了消费的波峰，但远未达到ckafka的消费瓶颈，因为Kafka是号称百万吞吐量的中间件
方向：
需要定位消息产生方，为什么会出现瞬时流量顶点
2、Kafka的topic分区消息堆积情况-监控
分析：
topic级别监控，知道某一分区，存在大量被写入和被消费的情况
3、kakfa实例监控
分析：
kafka实例监控，各类指标挺多的，但都属于正常的范围
不存在以下情况：
某个生产者环境阻塞，导致的消费瓶颈
也不存在带宽到了瓶颈，阻塞了消息生产和消费
实例的流量读入、读出都符合正常的云组件性能要求
4、生产者和消费者能力监控
Kafka 实例监控的指标有很多，我们主要关注下面几个：
实例生产消息总数：
实例消费消息总数：
结论是：
最大生成消息数量是473w，最大消息消费速度是472w，Kakfa的生产和消费都很正常。
kafka实例的吞吐量没有太大问题，kafka不是瓶颈
5、运维SQL变更
通过数据库变更追溯，发现业务库的一张千万级数据量大表，执行了一次业务变更（执行了一个ALTER的DDL），导致了大量binlog产生。
6、提高消费者能力
当下Kafka的生产速率略大于消费速率，导致了部分数据滞后消费，要解决
瓶颈是业务消费逻辑（数据落库到ES）。
因此，从消费端入手，提高消费能力（业务消费瓶颈-落库到ES），将客户端限流的令牌数量提高，可以参考我公众号写的另外文章：源码解析：Guava客户端限流
7、其他原因
从生产端入手，后续运维变更，减少突发峰值可能性：
运维执行，建议后续放到业务低峰期执行SQL变更
对于部分大表进行性能优化，可以参考我公众号写的另外文章大表拆分方案：亿级大表冷热分级的工程实践、亿级大表冷热分级的工程实践
8、验证问题
通过对消费能力提升，我们通过对kafka的监控，找了一个业务低峰期执行SQL变更的时机，观察到topic分区消息堆积情况不再出现，说明问题得到了解决。
总结
在分布式系统下，业务链路往往一环扣一环，如果某个环节出现了性能卡点，可能会在其他环节暴露出问题。因此我们分析问题时，往往要结合上下游的来分析链路。
参考
https://cloud.tencent.com/developer/article/2197101
其他文章
微服务重构：Mysql+DTS+Kafka+ElasticSearch解决跨表检索难题
基于SpringMVC的API灰度方案
SQL治理经验谈：索引覆盖
Mybatis链路分析：JDK动态代理和责任链模式的应用
大模型安装部署、测试、接入SpringCloud应用体系
一文带你看懂：亿级大表垂直拆分的工程实践
亿级大表冷热分级的工程实践
