在使用 RabbitMQ Java 客户端的生产环境中，网络波动、服务端重启、节点切换是常见问题。如果没有可靠的重连机制，轻则消息丢失，重则导致服务雪崩。自动恢复（Automatic Recovery）是 RabbitMQ 官方客户端提供的核心高可用能力，本文将从基础概念、触发机制、场景适配、使用限制到生产实践，全面解析自动恢复机制。

本文全面解析 RabbitMQ Java 客户端Connection 与 Topology 自动恢复机制，清晰阐述 Connection（TCP 物理连接）与 Channel（逻辑信道）核心概念，明确两种自动恢复的触发条件、适用场景及客户端版本差异。结合生产实践，详细说明自动恢复的关键限制，并提供可直接落地的标准配置与生产者高可用代码示例，帮助开发者解决网络抖动、服务端重启导致的断连问题，实现客户端无感重连，保障消息业务稳定运行。

通过对默认模式、同步确认、异步监听三种方案的横向对比，文章详述了各自的性能损耗与风险点，并重点讲解了在高性能异步模式下，如何结合 ConfirmListener 与 ReturnListener 实现消息投递成败的精准判定。最后，文章总结了一套“异步确认 + 强制路由 + 持久化”的生产级可靠投递方案，是开发者优化消息中间件稳定性必备的实战指南。

深度拆解 RabbitMQ 消费者的底层运行逻辑。从 Push/Pull 模式的选择出发，详细分析了如何通过 QoS Prefetch 建立系统背压保护，并针对 Manual ACK 模式下的不同确认指令（Ack/Nack/Reject）给出了明确的业务适用场景。此外，文章重点探讨了分布式环境下的消费幂等性解决方案及**死信队列（DLX）**的补偿架构设计，旨在帮助开发者构建一个无畏网络抖动、逻辑异常的鲁棒消费系统。

主流关系数据库对大小写问题的处理各不相同，本文对Mysql，pg和oracale对大小问题进行总结

总结一些跨数据中心同步缓慢的排查方法

整理一些mysql常用到的用户管理命令

binlog记录了描述数据库变化的“事件”， 例如表创建操作，表修改操作等。如果不是基于row的日志方式，binlog还会记录可能潜在修改数据库的statement（例如一条没有匹配到行的delete语句）。binlog日志还包含了每条语句更新数据所花费的时间。

mysql binlog事件类型简介

mongo用户管理介绍