大家好，我是小富～有次上线监控告警突然炸了，Kafka 订单 Topic 消息积压量突破 10 万条，下游支付服务拿不到数据，部分用户付款后一直显示处理中。紧急登录集群排查，发现消费者组明明有 3 个节点，却只有 1 个在正常消费，原来 10 分钟前触发了 Rebalance，另外两个节点还卡在分区重新分配的状态，导致消费能力直接砍半。所以我的经验是：Kafka出现消息积压、重复、丢失这类问题，直接看是否有Rebalance，能解决大部分问题。什么时候会触发 Rebalance？Rebalance 本质是消费者组内分区与消费者的重新分配，只有当消费者、分区的对应关系被打破时才会触发，下边咱们看...

节前上线出问题，线上灰度发布后部分用户反馈付款后订单状态不更新，支付服务的失败率飙升。一顿排查后发现致命配置错误。小可爱上线时，将payment-service服务的 Nacos 注册类型改成了ephemeral=false（持久化实例）。当时其中一台服务节点因内存泄漏频繁 GC，心跳线程被阻塞超过 30 秒，但是由于持久化实例没被 Nacos 剔除，导致调用方持续往这台异常节点发请求，最终拖垮整个支付链路。这个面试场景题总问，不过很多同学对 Nacos 临时、持久实例的认知，只停留在服务会不会消失的表面，什么时候该用临时，什么时候该用持久，适用场景是什么，没太明白。注册中心和配置中心本质区别...

大家好，我是小富～面试都背过道八股题：Redis 的内存淘汰策略 LRU 和 LFU 是什么？怎么选好？很多同学对这两个算法的理解，只停留在都是缓存淘汰，但说不清它们具体区别，概念混淆，更不知道实际场景该怎么选？而且 Redis 的 key 淘汰算法其实还不是正统的 LRU 和 LFU 算法，而是基于 LRU/LFU 的一个变种。所以我们先了解下 LRU/LFU 基础算法，再看看它和变种的 Redis LRU 算法有何不同。一、什么是 LRU 算法？LRU 的全称是 Least Recently Used（最近最少使用），核心逻辑特别好记：最近没被用过的，下次也大概率用不上。举个例子：你电脑桌...

大家好，我是小富～最近团队迭代频繁，连续几周都在做新功能上线，从测试环境验证到生产环境放量，全程谨小慎微没出一次故障，主要是用好了 Spring Cloud Gateway 的 流量染色 和 灰度发布。很多同学面试时被问用过 SpringCloud Gateway 吗？，只会说做限流、鉴权，但这些都是网关的基础操作。要想出去吹，得说用网关解决线上新版本平稳上线的问题。比如今天要分享的流量染色 + 灰度发布，就是我司每次上线必用的核心方案。什么是流量染色？为什么需要它？很多同学听流量染色觉得抽象，其实一句话就能说透：给请求打身份标签，让链路中所有服务都能认得出它。比如我们做电商 APP 的新功能...

大家好，我是小富～最近同事找我帮忙排查一个"诡异"的 Bug，说困扰了他们一年多一直没解决。我接手后花了一些时间定位到了问题根源，今天就来跟大家分享一下这个问题的排查过程和解决方案。问题描述同事使用的是 SpringCloud Gateway 3.0.1 + JDK8，整合了 Nacos 做动态路由配置。问题是：每次修改 Nacos 的路由配置后，网关的 API 请求就会出现 404 错误，但重启网关后又能恢复正常。听到这个问题，我的第一反应是：Nacos 配置更新后，网关的缓存数据可能没有及时更新。带着这个猜想，我开始深入排查。环境准备首先准备了 3 个后端服务实例，端口...

大家好，我是小富～面试官：OOM类型有哪些？你：就是老年代放不下了嘛！面试官：等消息吧！OOM（Out Of Memory） 错误有多种类型，每种类型对应不同的内存区域或触发场景。以下是常见的 OOM 类型及其产生原因：1. java.lang.OutOfMemoryError: Java heap space触发原因：堆内存（存放对象实例）不足，无法分配新对象。典型场景：内存泄漏：对象被无意长期引用（如静态集合、未关闭的资源），无法被 GC 回收。堆大小不足：JVM 堆参数（-Xmx）设置过小，或程序需要处理的数据量超出预期。大对象分配：一次性申请超大对象（如大数组）。示例： // 不断向集...

大家好，我是小富～有个兄弟私下跟我说，他在面试狗东时，有一道面试题没回答上来：Redis 的Bitmap和布隆过滤器啥区别与关系？其实就是考小老弟对这两种工具的底层数据结构是否了解，不算太难的题。不过，bitmap和布隆过滤器在大数据量和高并发业务的使用频率不低，知识点应该掌握下，既然问了那咱们简单的梳理下它们的底层原理、应用场景以及它们之间的关联。BitmapRedis中的Bitmap（位图）是一种较为特殊数据类型，它以最小单位bit来存储数据，我们知道一个字节由 8个 bit 组成，和传统数据结构用字节存储相比，这使得它在处理大量二值状态（true、false 或 0、1等只有两种状态）数...

大家好，我是小富～ 如何处理比较耗时的接口？ 这题我熟，直接上异步接口，使用 Callable、WebAsyncTask 和 DeferredResult、CompletableFuture等均可实现。 但这些方法有局限性，处理结果仅返回单个值。在某些场景下，如果需要接口异步处理的同时，还持续不断地向客户端响应处理结果，这些方法就不够看了。 Spring 框架提供了多种工具支持异步流式接口，如 ResponseBodyEmitter、SseEmitter 和 StreamingResponseBody。这些工具的用法简单，接口中直接返回相应的对象或泛型响应实体 ResponseEntity&l...

接手新项目一言难尽，别的不说单单就一个 @Transactional 注解用的一塌糊涂，五花八门的用法，很大部分还失效无法回滚。  有意识的在涉及事务相关方法上加@Transactional注解，是个好习惯。不过，很多同学只是下意识地添加这个注解，一旦功能正常运行，很少有人会深入验证异常情况下事务是否能正确回滚。@Transactional 注解虽然用起来简单，但这货总是能在一些你意想不到的情况下失效，防不胜防！ 我把这些事务问题归结成了三类：不必要、不生效、不回滚，接下用一些demo演示下各自的场景。 不必要 1. 无需事务的业务 在没有事务操作的业务方法上使用 @Transactional...

大家好，我是小富～本文是《ShardingSphere5.x分库分表原理与实战》系列的第七篇，目前系列的前几篇制作成了PDF，需要的可以在文末获取下载方式，持续更新中。今天咱们继续一起来探究下，分布式ID在分库分表中起到的作用以及如何使用，ShardingSphere-jdbc中已经为我们提供了多种分布式主键ID生成策略。接下来将分别介绍这些策略的优缺点，看看它们在实际应用中的场景和效果。 小富的技术站：*********************** 为什么用分布式主键ID在传统的单库单表结构时，通常可以使用自增主键来保证数据的唯一性。但在分库分表的情况下，每个表的默认自增步长为1，这导致了各...

大家好，我是小富～ 前言 本文是《ShardingSphere5.x分库分表原理与实战》系列的第六篇，书接上文实现三种自定义分片算法。通过自定义算法，可以根据特定业务需求定制分片策略，以满足不同场景下的性能、扩展性或数据处理需求。同时，可以优化分片算法以提升系统性能，规避数据倾斜等问题。 在这里，自定义分片算法的类型（Type）统一为CLASS_BASED，包含两个属性：strategy 表示分片策略类型，目前支持三种：STANDARD、COMPLEX、HINT；algorithmClassName 表示自定义分片算法的实现类路径。此外，还可以向算法类内传入自定义属性。  自定义 STANDA...

大家好，我是小富～好久没发这种实用贴了，最近用到了一些能提升工作效率的IDEA插件，给小伙伴们分享一下。相信我，我分享的这些插件，都是实实在在能解决实际开发场景中痛处的。以往的两篇IDEA插件分享：10个 解放双手的 IDEA 插件，少些冤枉代码10个解放双手的 IDEA 插件，这些代码真不用手写（第二弹）1、POJO to JSON开发工作中，常常在设计完API后，会使用如GsonFormat工具来将设计文档上的JSON格式数据生成Java实体类，这可以节省很多时间。不过，在某些情况下，我们需要将已有实体类转换为JSON格式数据，那我通常不得不依赖于手动执行单元测试或在main方法中，使用J...

大家好，我是小富～ShardingSphere实现分库分表，如何管理分布在不同数据库实例中的成千上万张分片表？上边的问题是之前有个小伙伴看了我的分库分表的文章，私下咨询我的，看到他的提问我第一感觉就是这老铁没用过ShardingSphere，因为这个问题在ShardingSphere中已经有了很好的解决方案，接下来看看怎么实现。本文案例代码GitHub地址：https://github.com/chengxy-nds/Springboot-Notebook/tree/master/shardingsphere101/shardingsphere-autocreate-table系列往期往期系列...

大家好，我是小富～ 说个事吧！最近公司发生了一个事故，有同事不小心把敏感数据上传到了GitHub上，结果被安全部门扫描出来了。这件事导致公司对所有员工进行了一次数据安全的培训。对于这个事我相信，有点工作经验的人都不会故意去上传这些敏感文件，多数应该是误操作导致的。 这个事件也给了提了个醒，我平时会写博客用GitHub比较多，吓得我赶紧对自己所有的GitHub仓库进行了排查，庆幸没有提交过敏感信息的记录。但我注意到在过往的提交记录中，有使用公司的Git账号信息提交过代码，***这就很难受了。  避免后续产生不必要的麻烦，我决定修改一下提交记录中涉及公司的信息。  注意：以下操作只限于用在自己的G...