GitHub爆火项目BrowserAgent深度解析：大模型+Function Calling驱动浏览器自动化操作，4万+星技术揭秘！含OpenAI API配置、代理抓包技巧及Playwright实战，助你掌握AI自动化核心流程。慎跑captcha.py脚本，避免token消耗陷阱！

browser-use 项目核心原理

文章记录了线上数据库连接池打满问题的排查过程，通过分析发现高CPU负载和Minor GC导致线程调度延迟，最终通过降低消息发送速率、优化高频接口和调整定时任务时间解决了问题。

线上问题排查——数据库连接池满了（上）

文章分析了RocketMQ消费问题：全表导出导致消费耗时过长，重试机制下消息被重复消费40多次。通过日志和源码分析，发现rebalance、消费进度更新机制是主因，并提出了分布式锁续约、减少重试次数等优化策略。

花了三天时间，终于看懂了RocketMQ的消费日志

线上巡检发现某服务实例CPU和带宽异常高，通过iftop和tcpdump定位到数据库查询死循环问题，同时用top+jstack和arthas确认是RocketMQ消费线程导致，最终修复分页查询逻辑并引入分页框架避免类似问题。

高cpu使用率和高带宽使用排查思路

文章讲解了MySQL主从复制的两种方式：异步复制和半同步复制，重点分析了半同步复制的演进过程，包括after_commit和after_sync两种模式的区别、幻读问题、等待从库ack数量配置等优化，并详细介绍了半同步相关的监控指标和配置参数。

MySQL异步复制和半同步复制

本文详细解析MySQL主从复制原理及演进历程，从5.6串行复制到5.7基于组提交的并行复制，再到8.0基于WRITESET的并行复制方案，深入剖析各版本优化思路、实现机制及参数配置，帮助理解MySQL复制性能提升的关键技术。

MySQL 并行复制原理及演进

文章介绍了MySQL DDL算法的演进历程，从早期的COPY算法到INPLACE算法，再到8.0引入的INSTANT算法。重点分析了各算法的实现原理、性能差异和应用场景，特别是INSTANT算法如何通过元数据变更实现快速加列，以及8.0.29版本对instant删列的支持。

MySQL OnlineDDL发展历程及各算法介绍

本文深入解析MySQL连接过程中的身份认证机制，详细介绍Handshake流程、三种常用认证插件（mysql_native_password/sha256_password/caching_sha2_password）的工作原理与安全特性，分析Auth Switch切换流程和SSL/TLS加密连接建立过程，并通过抓包实例展示不同认证场景的实际交互。

MySQL 连接阶段

文章分析了Datax连接MySQL报错"Communications link failure"的原因，发现是由于JDK8u291版本移除了TLS1.0/1.1协议，导致与MySQL5.7.31的SSL握手失败。通过抓包对比发现服务端启用了SSL，而客户端因协议不匹配无法建立连接。解决方案包括禁用SSL或显式指定TLS协议版本。

记一次mysql连接问题

文章介绍了数据库批量操作的多种场景及特点，包括multi-value insert、batchUpdate、batchDelete和batchExecute，分析了它们在JDBC规范下的执行模式和优化策略，探讨了返回值处理、事务特性和自增主键获取等关键问题，帮助开发者优化批量操作性能。

一文说透批量SQL

PreparedStatement是Java中预编译SQL的接口，相比Statement能防止SQL注入但性能提升需看实现。MySQL驱动分client/server模式，client模式本地解析SQL，server模式需与数据库交互。测试表明client模式性能反而不如Statement，server模式仅多次执行同一SQL时可能提升性能。不建议开启useServerPrepStmts和cachePrepStmts参数，可能引发内存问题。

你真的懂PreparedStatement吗？

MySQL监控发现IOPS突增，分析发现一条查询语句因回表操作导致大量物理读，读取300多MB数据。通过优化索引和分批处理解决性能问题，并探讨了一键已读功能的同步与异步实现方案，强调缓存和索引优化的重要性。

惊！一条SQL竟有如此威力

通过探究MyBatis动态SQL的实现机制来消除MyBatis不必要的空格和换行

消除MyBatis不必要的空格和换行

服务调用超时和OOM问题分析：排查发现是由于MyBatis拼接大SQL导致内存占用过高，GC频繁STW。优化方案包括减少批次数量、调整线程池大小及优化SQL拼接逻辑。

MyBatis批量插入导致内存溢出问题分析

MySQL 8.0优化了JSON字段的部分更新机制，重点分析了JSON的二进制存储结构、快速定位机制及溢出场景下的更新策略，通过实验验证了非溢出和溢出情况下的空间复用行为差异。

MySQL JSON字段部分更新实验

文章介绍了如何通过解析WPS内嵌图片的Excel文件实现批量导入教师身份证照片功能，分析了因资源未释放导致文件描述符过高的问题，并提出了基于EasyExcel的重构方案，包括优化Zip文件处理、增加注解标注图片列等改进措施，同时记录了测试过程中发现的ZipFile特性问题。

Excel导入需求升级——支持内嵌图片导入

MySQL 8.0.18版本中多值索引虚拟列写入binlog导致解析工具报错，分析发现是canal等工具对MYSQL_TYPE_TYPED_ARRAY类型处理不完善，8.0.25版本已修复该问题。文章详细解析了table_map_event结构、问题定位过程及修复建议。

使用多值索引（Multi-Value Index）导致Canal同步异常

本文深入解析InnoDB数据页结构，详细讲解7大组成部分，重点分析记录存储机制、删除空间复用原理及Page Directory索引优化。通过实验验证删除记录如何形成可重用空间链表，并演示不同场景下空间复用的具体表现，帮助理解InnoDB底层存储机制。

Innodb数据页更新实验

HTTP缓存机制主要涉及存储策略、过期策略和协商策略。存储策略决定是否缓存资源，主要受Cache-Control响应头影响。过期策略判断本地缓存是否过期，结合Expires和Cache-Control响应头。协商策略验证缓存内容是否最新，通过对比两个响应的最后一次修改时间或特征值。此外，启发式缓存和Vary头也影响缓存机制。Cache-Control也可以在请求头中使用，指示客户端的缓存行为。

HTTP缓存机制解析

本篇文章主要探讨了MySQL中大字段的全量更新（full update）实验，揭示了在实验过程中发现的一些有趣的现象和细节。文章首先介绍了一些前置知识点，包括MySQL 8.0对于非压缩溢出页的结构改造，以及全量更新的流程。然后通过实验，详细地展示了更新过程中溢出页的变化，以及更新次数对于溢出页数量的影响。文章还深入分析了溢出页首页的结构，包括索引列表和空闲节点等部分。在实验过程中，文章提出了一些有趣的问题，如在优化表后索引页数量的增加等，这些问题为我们深入理解MySQL的内部机制提供了思考的方向。总的来说，这篇文章通过实验和详细的分析，为我们理解MySQL中大字段的全量更新提供了宝贵的实践视角和深入的理论知识。

MySQL 溢出字段常规更新（full update）实验

MySQL单行记录大小限制详解：Server层65535字节限制与InnoDB层8126字节限制的差异，包括varchar/text字段计算规则、变长编码处理、行溢出机制及定长字段的特殊情况分析。

用几个实验验证char、varchar和text的底层存储

分析SpringBoot gzip压缩失效原因：Tomcat依赖Content-Length判断压缩条件，但MappingJackson2HttpMessageConverter采用流式写入导致无法获取长度。文章探讨了分块传输编码原理，并提出了通过ShallowEtagHeaderFilter或修改Converter的解决方案，权衡性能影响后建议在网关层实现压缩。

SpringBoot开启gzip压缩min-response-size不生效

线上故障分析——数据库连接池满了

文章分析了MySQL连接超时后连接池未校验导致的问题，详细描述了事务内外的4个报错点，并提出了通过tomcat-jdbc异步检查机制优化连接池管理的解决方案，避免关闭连接被重复使用。

tomcat-jdbc连接池对于socketTimeout超时断连的处理BUG

诡异的RocketMQ消费日志分析

本文探讨Spring Cloud Gateway优雅停机问题，分析upstream服务停机时因注册中心下线延迟和本地缓存导致的调用异常，提出通过监听ContextClosedEvent事件优先下线服务，并处理服务列表缓存更新的解决方案，同时指出该方案在注册中心推送延迟时的局限性。

优雅停机之Spring Cloud Gateway

本文深入探讨了Docker端口映射的实现机制，通过分析宿主机和容器内的网络连接情况，揭示了docker-proxy和iptables DNAT两种转发方式的工作原理，并验证了不同场景下的网络通信路径，最后总结了端口映射对性能的影响。

Docker端口映射的实现机制

本文深入分析Dubbo 2.6.5版本的优雅停机实现，探讨其停机流程中的问题及解决方案。通过源码和日志分析，揭示DubboShutdownHook与SpringShutdownHook并行执行的风险，并梳理了Dubbo在后续版本中对优雅停机的持续优化过程，包括多个关键PR和issue的修复历程。

优雅停机之Dubbo

文章介绍了优雅停机的概念及实现方式，重点分析SpringBoot内嵌WebServer的优雅停机机制，包括ShutdownHook原理、Spring容器停机流程、SmartLifecycle实现，以及2.3版本前后的优雅停机方案对比。

优雅停机（上）

本文深入分析Sentinel的计数统计及限流核心逻辑，包括滑动窗口实现、统计节点维护、限流策略分类等关键机制，并探讨了时间回拨处理等细节问题。

Sentinel之计数统计及限流逻辑

本文深入解析Sentinel限流框架的四种限流算法实现：DefaultController直接拒绝、RateLimiterController匀速器、WarmUpController预热及WarmUpLimiterController，重点剖析了预热算法的设计原理与实现细节，并指出其与Guava SmoothWarmingUp的区别，最后提出对WarmUpController设计原理的疑问。

Sentinel之限流算法

本文总结了常见限流算法（固定窗口、滑动日志、滑动窗口、漏桶、令牌桶）及其实现方案，分析了QPS和并发数两种限流维度，详细比较了各算法的优缺点，并提供了Redis、Sentinel等典型实现方式，最后探讨了限流处理策略和长窗口风险防范。

限流算法及常见实现

深入解析Guava RateLimiter源码实现，包括令牌桶算法原理、两种限流策略（平滑爆发SmoothBursty和预热SmoothWarmingUp）的核心设计思想，以及如何处理闲置和大流量场景。通过代码示例展示其工作流程和实际应用中需要注意的问题。

Guava RateLimiter

本文探讨了离线binlog文件解析的多种方法，对比了阿里云DMS、mysqlbinlog、binlog2sql等工具的优缺点，重点介绍了自研工具canal2sql的设计目标与核心改造点，支持离线解析、列还原、回滚SQL生成等功能，为开发人员提供了全面的数据变更追踪解决方案。

如何解析离线binlog文件

生产环境高峰期出现用户请求"死循环"问题，通过分析日志制定限流策略，基于Spring Cloud Gateway的RequestRateLimiter实现同用户、同接口、同入参的限流，并优化了RedisRateLimiter脚本，解决了时间回拨等问题，同时支持开关控制和异常处理。

定制spring-cloud-gateway限流器来解决线上问题

Spring Cloud Gateway处理大文件上传时出现内存溢出问题，排查发现是RetryGatewayFilter导致AdaptCachedBodyGlobalFilter缓存整个请求体。解决方案包括使用unpooled内存分配、增加请求大小限制Filter，并避免在网关直接处理文件上传。

spring-cloud-gateway内存泄漏？

本文深入解析SpringBoot fatJar的实现原理，详细分析jar包结构、自定义jar协议解析器和类加载器机制，揭示优雅型jar包如何通过JarLauncher启动，并探讨三种运行模式及jarMode系统变量的特殊处理方式。

SpringBoot是如何做到一个jar包就可以直接运行的

文章介绍了Spring Cloud Gateway跨域问题的解决方案，包括预检请求处理、响应头重复问题、自定义GlobalFilter、跨域白名单配置等，并探讨了前端代理请求和OPTIONS请求的跨域处理机制。

spring-cloud-gateway跨域配置两三事

MySQL流式查询利用TCP滑动窗口实现数据实时传输，避免大数据量查询OOM，但会独占连接。同时长查询可能因MDL锁阻塞DDL操作，导致系统崩溃，需设置超时或采用无锁变更方案解决。

mysql流式查询下的性能隐患

Canal全量ETL在ShardingSphere-Proxy分库分表场景下出现流式查询异常，原因是连接缓存池设计缺陷导致连接串用，SET命令未正确执行，最终因net_write_timeout超时断开连接。深入分析发现Proxy的流式查询机制与连接模式相关，提供了修复连接串用问题和调整数据源配置两种解决方案。

shardingsphere-proxy和流式查询

本文介绍了生成可执行JAR包的三种方式：暴力型、半优雅型和优雅型，分别对应maven-assembly-plugin、maven-jar-plugin+maven-dependency-plugin组合以及onejar-maven-plugin/spring-boot-maven-plugin等方案，并分析了各方案的优缺点及适用场景。

创建可执行jar包的多种方式

本文详细介绍了在IntelliJ IDEA中创建可执行jar包的步骤，包括两种依赖处理方式：暴力型（解压依赖）和半优雅型（保留原jar包）。通过6个步骤完成配置、构建和验证，最终生成可执行jar包。

通过IntelliJ IDEA 创建可执行jar包

文章分析了一个诡异的ClassNotFound异常问题，发现是由于Maven依赖冲突机制导致json-path包未被正确引入。通过构造最小化场景，深入解析了Maven处理循环依赖的机制，最终提出三种解决方案，并强调遵守开发规范的重要性。

线上问题分析——maven循环依赖导致传递依赖失效问题

本篇文章记录了通过对1个线上问题的排查，引出了好几个次级问题，并一一解决的过程

线上问题分析——canal-adapter数据同步不全问题排查

文章分析了ShardingSphere JDBC在表结构变更后出现的字段映射异常问题，发现是由于内存缓存未及时更新导致字段错位。深入探讨了MyBatis映射机制、ShardingSphere内部实现原理，并提出了避免使用select *、通过Proxy更新表结构等解决方案。

线上问题分析——shardingsphere表结构缓存导致的字段错位

线上问题分析——一次线上OOM问题的分析与解决

摘要：本文深入解析canal-adapter的SPI机制与构建流程。SPI机制包括核心接口设计、类加载流程及自定义类加载器实现；构建流程详细介绍了插件打包、目录编排及两种运行模式（开发/生产）的配置差异，帮助理解canal-adapter的多插件架构实现原理。

canal-adapter插件式架构解析

canal-client-adapter核心代码分析之启动流程

摘要：文章分析了流式查询导出数据时出现的数据库连接复用问题，发现事务中map操作与流式查询共用连接导致冲突，提出通过创建新事务并设置NOT_SUPPORTED传播级别来隔离操作，同时解释了不同环境表现差异的原因。

mysql流式查询中的一个坑

文章详细分析了RocketMQ 4.6.0中Message Trace功能的三个典型问题：测试环境因语言切换报错、生产环境缺少RMQ_SYS_TRACE_TOPIC导致路由失败、开发环境仅显示生产者信息。通过源码分析发现4.6.0版本存在TraceDispatcher启动bug，在4.6.1版本中修复。

RocketMQ 4.6.0 Message Trace 功能异常排查

RocketMQ使用docker启动导致2台消费者实例instanceId相同的原因和解决方案

RocketMQ使用docker启动导致2台消费者实例instanceId相同

解决MacOS下使用docker，宿主机访问volume，提示No sush file or directory

Mac使用docker，volume默认挂载路径/var/lib/docker/volumes不存在问题——多种解决方案

我们的配置中心一直是自研的，并且也用了很久，一直也没出现过什么问题。直到最近这段时间，出了两个同类型的问题，于是乎准备来研究并解决一下。
问题原因都是因为引入了某个新包，并且这个新包的classpath根路径下包含了1个application.properties文件，这个时候Spring会加载这个application.properties配置文件。如果该配置文件里有配置中心里没有配置的key-value，那么该配置就会生效（如果配置中心有，那么还是配置中心的优先级更高）。

带你透过源码理解SpringBoot配置文件加载流程

记刷一张亿级别表产生的线上问题，以及问题分析和思考

刷一张亿级表带来的思考

本文介绍了canal在读取解析binlog文件的过程中的问题和解决方案

Canal解析binlog文件的设计缺陷

本文通过实际场景，用多种方式解析binlog，带你了解MySQL binlog event的组成，以及通过canal同步binlog时kafka里的数据的对应关系。最后再通过生产环境的2个问题给你加深理解。

带你了解MySQL binlog event

本文期望以精炼的语言以及相对清晰的架构图来让你对Canal整体上有一个全面的了解，以及让你知道部署一套Canal的最佳实践

Canal核心各组件介绍及最佳部署实践

关于怎么给blog搞一个自定义的域名：申请域名、配置DNS、配置Vercel

关于怎么给blog搞一个自定义的域名

教你如何搭建一个和本站一样实用的blog

关于怎么搭建一个这样的blog

技术分享

问题排查

友情链接

往期整理

历史归档

文章分类

文章标签

关于我

关于

browser-use

blog

域名申请

excel

在排查高CPU和高带宽使用率的问题时，首先观察到某服务的实例CPU使用率明显偏高，同时带宽使用也高。通过iftop和tcpdump命令分析发现，主要流量来自数据库查询，可能存在死循环。进一步通过top和jstack命令定位到高CPU使用的线程，发现是RocketMQ的消费线程。最终确定问题在于分页查询时未更新最小ID，导致查询效率低下。为避免此类问题，建议使用自定义的分页框架。