Kafka消息堆积题目排查

  

  背景

  业务架构图

  根据 微服务重构：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应用体系
  一文带你看懂：亿级大表垂直拆分的工程实践
  亿级大表冷热分级的工程实践

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。