唐旺旺-优快云博客

原创中间件部署避坑指南：从零搭建高可用Redis/Kafka/ES集群（含Ansible自动化脚本）

Redis RDB/AOF、Kafka的Log Cleanup Policy、ES的Snapshot。：Prometheus+Grafana监控关键指标（如Redis内存碎片率、Kafka ISR变化）启用Index Lifecycle Management自动管理索引生命周期。”—— 一次血泪教训总结的中间件部署checklist。配置冷热数据分层（如SSD/HDD混合部署）参数导致Redis半夜OOM崩溃；导致集群吞吐量只有预期的1/10；配置（建议设为no）的副本数（建议≥3）限制（避免GC压力）

2025-07-29 19:35:08 485

原创 Elasticsearch深度分页引发的集群雪崩：从“翻页1000页”到零停机优化的终极方案

摘要：电商ES集群因用户翻页到1000页触发OOM崩溃，根源在于from+size深度分页机制导致协调节点需处理10万条数据（10分片×10000条），内存暴增。解决方案包括：1）限制max_result_window；2）改用search_after游标分页（性能恒定，需前端改造）；3）大数据导出用scroll；4）预计算分页索引（牺牲实时性）。最终采用分层策略，关键结论：禁止深度from+size，游标分页是核心方案，预计算适合低频场景，需监控大偏移查询。

2025-07-29 19:26:35 2093

原创 Kafka消费者扩容引发的“数据乱序”灾难：Rebalance机制与顺序性保障的终极博弈

当消费者组内实例数变化（如扩容、缩容、崩溃），Kafka会触发。频繁Rebalance可能意味着消费者不稳定，需优化心跳 (（因Rebalance、重试等机制仍可能导致重复消费）。：手动提交Offset、自定义分配策略、业务幂等。在Rebalance前正在消费分区0的。Rebalance后，分区0被分配给。，重新分配分区给存活的消费者。（如从3个实例扩容到5个）。（3个分区，复制因子=3）。（新消费者可能分不到分区）。，可能中断正在处理的消息。（未提交Offset）。，但仍可能发生分区迁移。

2025-07-05 10:57:59 1534

原创【鬼影缓存之谜】一次跨Redis、MySQL、JVM的诡异数据不一致事故复盘

先更新DB → 再删除Redis → 最后失效本地缓存（通过Redis Pub/Sub通知集群内其他节点）。：即使发生，缓存应很快被纠正（下次更新会删除），但用户看到旧数据持续存在数秒。用户A投诉：明明取消了订单，但在APP订单列表仍能看到，且显示“待支付”。- 第一级：JVM本地缓存（Caffeine，5秒过期）- 第二级：Redis集群（缓存订单数据，10分钟过期）：但其他节点的本地缓存能正常失效，说明通知机制正常。请求1发现缓存空，从DB加载旧数据（未取消）。的情况，但概率极低（<0.1%）。

2025-07-04 23:40:32 900

原创 Spring Cloud Gateway 动态路由翻车实录：从流量洪峰到优雅防护的救赎之路

它站在微服务的最前线，直面所有流量和风险。一次配置失误、一个未处理的异常、一次防护的缺失，都可能成为压垮整个系统的导火索。密切监控Gateway的CPU、内存、线程池、请求量、RT、错误率、熔断器状态。配置重试次数、支持的状态码（如503, 504）和异常类型（如IO异常）。将路由配置存储在配置中心（如Nacos），利用配置中心的监听机制，并结合消息队列（如RabbitMQ, Kafka）实现。在Gateway层实现基于Header、Cookie、权重等的流量染色和路由，是实现全链路灰度发布的关键入口。

2025-07-03 23:30:40 686

原创 RabbitMQ的“幽灵投递”：一次惨烈的重复消费事故与幂等性防御体系搭建实录

希望这篇“血泪实录”能让大家少踩坑，让消息队列真正成为系统解耦、流量削峰、提升弹性的利器，而不是数据混乱的源头。监控显示，RabbitMQ在某个时间点出现了短暂的网络抖动，触发了消息重试机制，而我们的消费端...毫无防备！Broker未收到ACK，认为消息未被成功处理，会将该消息（或该Channel上未ACK的所有消息）重新入队（或投递给其他消费者），导致。如果状态不允许（如订单已是“已支付”，又收到“支付成功”消息），可能是重复或非法消息，记录告警并ACK。获取成功才处理，处理完释放锁。

2025-07-02 10:41:35 973

原创【性能警钟】别让MySQL的“温柔一刀”废了你的索引！—— 记一次隐式编码转换引发的全表扫描

，在进行字符串到数字的转换时，MySQL需要遵循该排序规则定义的比较和转换逻辑。数据库优化，尤其是索引优化，往往就藏在这些细节里。一个不起眼的单引号，可能就是压垮系统的最后一根稻草。记录完毕，归档，继续去守护我的Java江山了！理解索引失效的原理（B+树结构、函数破坏有序性），才能举一反三，避免。： B+树索引的构建是基于列存储的原始值。在测试环境和小数据量下，这查询快得很，完全没问题（埋下了祸根！列使用的是特定的字符集和排序规则（Collation，如。保持警惕，写好每一行SQL，传对每一个参数类型。

2025-07-01 14:42:08 731

原创解决 remote: ERROR: commit c317375: Change-Id must be in message footer 错误

git 推送出错日志：remote:出现此问题的原因是因为 Git 服务器要求每个提交（commit）必须包含一个 Change-Id，并且该字段必须位于提交信息的底部（footer）：如果你使用的是 Gerrit 或类似的代码审查系统，通常会要求安装 commit-msg 钩子来自动添加 Change-Id1，执行一下 gitdir=$(git rev-parse --git-dir);2，然后用 git commit --amend 重新提交一下。

2025-07-01 14:05:07 2600 1

Tsw123151的博客