小小默：进无止境

日志中 TID 显示为 N/A 的根本原因是 SkyWalking 的 trace 上下文依赖 ThreadLocal，异步线程池工作线程无法继承。通过在自定义线程池上配置 setTaskDecorator(RunnableWrapper::of)，可自动捕获并恢复 trace 上下文，一行代码即可修复 8 处线程池的 TID 丢失问题，实现全链路追踪闭环。

本文详述CHEN网关接入Sentinel网关限流的实战经验，揭示三大核心坑点：① Dashboard UI的“前缀”匹配实际对应ANT模式（非字面意义前缀），导致规则误配；② gw-api数据源JSON格式错误时静默失败，5秒重试机制掩盖问题；③ 自转发架构下全量分组规则导致配额双重消耗。基于1.8.9版本，提供经字节码验证的matchStrategy真实语义表及生产可用配置，强调排障需按“定义加载→路径匹配→规则转换”链路逐层定位。

Spring Cloud Gateway 4.3 与 Nacos 集成实现动态路由热更新，通过桥接类 GatewayRouteRefreshBridge 监听 EnvironmentChangeEvent，基于前缀过滤触发 RefreshRoutesEvent，确保配置变更秒级生效。解决 2025 版本属性前缀迁移（如 spring.cloud.gateway.routes → spring.cloud.gateway.server.webflux.routes）导致的路由未更新问题，提升可观测性与可靠性，

Route ID 限流（服务级别）API 类型选择Route ID，填入目标路由 ID（下文以demo-route为例）。阈值类型选 QPS，单机阈值设为1，间隔5秒（即 5 秒内只允许 1 次请求）。这种配置对应底层，等价于服务级别的整体限流。API 分组限流（接口级别）在API 管理中创建分组，匹配模式选精确，匹配串填入目标接口路径（如在流控规则中选择API 分组进行限流。同样会转换为。热点参数限流（精细化）勾选“针对请求属性”，参数属性选择Header，填入。

本文详解xxl-job在Spring Boot中两种接入方式：手动装配（官方推荐）与自动装配（社区starter）。核心要点为：避免在@Bean中配置initMethod = "start"，否则会导致EmbedServer双启动，引发BindException: Address already in use。正确做法是通过XxlJobSpringExecutor的SmartInitializingSingleton机制自动启动，确保执行器仅启动一次。文中结合天宫首次部署踩坑实录，强调配置一致性与启动逻辑理

本文探讨了多实例并发处理数据库任务表的四种方案。核心问题在于如何避免任务重复处理，同时兼顾吞吐和实现复杂度。四种方案包括： 逐条CAS UPDATE（乐观锁） SELECT FOR UPDATE + 批量UPDATE（悲观锁） 批量UPDATE + 回查 SELECT FOR UPDATE SKIP LOCKED（MySQL 8.0+） 分析表明，当任务处理耗时远大于数据库操作时（如HTTP调用100-200ms vs DB操作1-3ms），简单的逐条CAS UPDATE（方案A）在MySQL 5.7环境下

本文探讨了定时任务系统设计中吞吐量、延迟、超时和积压四个核心矛盾的平衡方案。以50万设备、100万任务的节假日补偿场景为例，通过对比单次拉取（batchSize=500）和循环拉取（maxProcessPerRun=1000）两种模式，分析得出循环拉取能在5分钟调度间隔下将吞吐量提升至400条/分钟（双Pod），接近470条/分钟的峰值需求。方案在单任务耗时≤200ms时完全安全，300ms时处于临界状态。建议保持当前循环拉取设计，通过监控任务耗时和积压情况，灵活选择增加Pod数量或引入线程池来应对未来需求

本文探讨了延时任务实现方案在JANUS XX-YC定时开关项目中的应用选型，重点分析了"节假日不生效"功能的延时任务调度需求。通过对比各类延时队列方案（如Kafka时间轮、RabbitMQ死信队列、Redis ZSET等），指出这些方案在长延时（数月）、频繁取消和状态追踪场景下的局限性。最终推荐采用MySQL任务表结合XXL-Job轮询的方案，并详细阐述了其设计原理、性能考量及实现路径。 核心结论： 传统延时队列方案（内存/消息队列）不适合超长延时+频繁取消场景 MySQL+XXL-Job方案通过磁盘存储和

Spring Boot对接Prometheus监控指南 本文详细介绍了Spring Boot应用接入Prometheus监控的两种方案：无认证和Basic Auth认证。核心内容包括： 通用配置：引入Micrometer和Actuator依赖，配置管理端口和监控端点暴露 无认证方案：适用于内网/测试环境，通过K8s注解直接暴露Prometheus端点 Basic Auth方案：适用于生产环境，集成Spring Security保护监控端点 K8s部署配置：包含两种场景下的Deployment注解配置差异 验

Redis分布式限流方案对比：固定窗口、滑动窗口与令牌桶 本文对比了三种基于Redis的分布式限流方案： 固定窗口：实现简单高效，适合API防刷、登录限流等场景，但存在边界突发问题。 滑动窗口：通过ZSET精确控制流量，解决边界问题，但内存消耗较大，适用于需要严格QPS控制的金融交易等场景。 令牌桶：允许突发流量，通过HASH结构实现，适用于需要弹性限流的网关和系统保护场景。 每种方案各有优劣，选择时需权衡实现复杂度、性能要求和流量控制精度。固定窗口适合简单场景，滑动窗口提供精确控制，令牌桶则支持流量突发。

摘要 本文提出一种基于Redis+Lua的分布式IP限流方案，用于微服务网关防护。方案采用固定窗口算法，通过原子性Lua脚本实现单次Redis操作完成计数和过期设置，确保高并发下的精确控制。核心设计包括：按IP维度限流、自然过期的Key结构、Redis异常时自动降级放行，并提供详细日志用于观测攻击情况。压测显示该方案能准确限制每秒请求数（如30次/秒），在保证系统安全的同时兼具高性能和可靠性，有效防御接口刷取等恶意行为。

OSS文件下载方案对比摘要 本文对比了三种OSS文件下载方案： 内网直连方案（推荐）： 网关302重定向到OBS内网地址 优点：网关压力小、性能最佳、支持浏览器缓存 前提：需配置OBS Bucket内网访问策略 网关代理方案（当前方案）： 网关通过janus-service1中转文件流 优点：安全性最高，无需额外配置 缺点：网关压力大，性能较差 预签名URL+Nginx方案： 通过Nginx代理和公网域名访问 优点：权限控制灵活 缺点：架构复杂，需维护Nginx 综合推荐内网直连方案，在满足内网安全要求的前

本文档详细介绍了在SpringBoot应用中实现全链路追踪的traceId技术方案，重点覆盖Nginx→Gateway→微服务的请求追踪场景。主要内容包括： SkyWalking Agent工作机制：自动生成traceId并通过MDC、线程上下文和sw8请求头三种方式传播，其运行不依赖OAP服务端。 sw8请求头解析：详细说明SkyWalking跨进程传播协议格式，以及与自定义X-Trace-Id头的区别。 全场景分析：对比了挂载/未挂载Agent的三种典型场景，展示了traceId在不同组件间的传递机制，

实现的复杂性或者难度角度：Zookeeper > redis > 数据库实际性能角度：redis > Zookeeper > 数据库可靠性角度：Zookeeper > redis = 数据库这三种方式都不是尽善尽美，我们可以根据实际业务情况选择最适合的方案：如果追求极致性能可以选择：reds方案如果追求可靠性可以选择：zk。

本文接讲解Redisson在分布式锁的应用实践。Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。

本文从一个经典的库存超卖问题分析说明常见锁的应用，假设库存资源存储在Redis里面。此时方法操作是先读后写，非原子性操作，是存在并发问题的。JVM本地锁的实现与优缺点在已经分析过了，这里不再赘述。

本文从一个经典的库存超卖问题分析说明常见锁的应用。

C(Consistency)强一致性、A(Availability)高可用性和P(Partitiontolerance)分区容错性。单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。满足一致性、分区容错性的系统，通常性能不是特别高。满足可用性、分区容错性的系统，通常可能对一致性要求低一些。......

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要通过一些互斥手段来防止彼此之间的干扰，以保证一致性，在这种情况下，就需要使用分布式锁了。简而言之，分布式锁就是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。分布式锁要满足哪些要求呢？1、互斥性–在分布式系统环境下，一.........

实现分布式锁目前有三种流行方案，分别为基于数据库、Redis、Zookeeper的方案。这里主要介绍基于zk怎么实现分布式锁。由于zookeeper获取链接是一个耗时过程，这里可以在项目启动时，初始化链接，并且只初始化一次。

TCC适用于公司内部对一致性、实时性要求较高的业务场景，而本文我们讲解的“最大努力通知型事务”是为解决跨网络、跨服务之间的柔性事务的另一种解决方案。首先看一下最大努力通知型的流程图，如下图：...

【1】微服务是什么提到微服务，就没法不提到这位“大神”——马丁·福勒，他没有直接给微服务下一个精准的定义，而是给出了微服务特点的描述：根据业务模块划分服务种类。 每个服务可以独立部署并且互相隔离。 通过轻量的 API 调用服务。 服务需要保证良好的高可用性。就目前而言，对于微服务业界并没有一个统一的、标准的定义。但通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用...

分布式架构与Dubbo基础入门与实践一文中初步介绍了分布式架构并使用xml配置方式进行了Dubbo和Zookeeper实践。分布式应用简单入门及SpringBoot整合Dubbo+Zookeeper一文中使用SpringBoot整合了Dubbo和Zookeeper但是并未抽取公共API项目。本文是上述两个项目的升级版。【1】创建SpringBoot项目① 使用Spring starter pp...

【1】分布式系统① 什么是分布式系统《分布式系统原理与范型》定义：“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”。分布式系统（distributed system）是建立在网络之上的软件系统。随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。② 架构发展演...

查看Dubbo完整配置示例，参考官方文档。【1】启动时检查Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check=“true”。可以通过 check=“false” 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。另外，如果你的 Spring 容器是懒加载的，或者通过 ...

SpringBoot与Dubbo整合有几种方式，通常需要根据项目实际情况来进行选择。SpringBoot与dubbo整合的三种方式：1）导入dubbo-starter，在application.properties配置属性，使用@Service【暴露服务】使用@Reference【引用服务】，使用@EnableDubbo注解。2）保留dubbo xml配置文件，导入dubbo-starter...

【1】Zookeeper宕机与dubbo直连① zookeeper注册中心宕机，还可以消费dubbo暴露的服务注意，这里是注册中心全部宕机(比如做了Zookeeper集群配置)。那么消费者还是可以消费提供者暴露的服务的。因为消费者消费服务，其实就是从注册中心拿到服务地址(URL)，这个URL消费者是有本地缓存的。② 不使用注册中心，能否消费服务？当然也是可以的！使用Dubbo直连— @Re...

【1】RPC原理首先看个图：一次完整的RPC调用流程（同步调用，异步另说）如下：1）服务消费方（client）调用以本地调用方式调用服务；2）client stub(可以理解为代理)接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；3）client stub找到服务地址，并将消息发送到服务端；4）server stub收到消息后进行解码；5）server stub根据解...

[认真学习分布式应用的分布式事务2PC/3PC](https://blog.youkuaiyun.com/J080624/article/details/86538135)[聊聊分布式应用的分布式事务TCC](https://blog.youkuaiyun.com/J080624/article/details/86542491)[聊聊分布式应用的分布式事务之最大努力通知型事务](https://blog.youkuaiyun.com/J080624/article/details/86542689)[聊聊分布式应用的分布式事务之消息最

TCC是try-confirm-cancel的单词首字母缩写，是一个类2PC的柔性事务解决方案，由支付宝提出后得到广泛的实践。补偿事务（TCC）有三个阶段：Try 阶段，对业务系统做检测和资源预留Confirm 阶段对业务系统做确认提交，默认：Try执行成功，Confirm一定成功Cancel 阶段在业务执行失败，需要回滚的情况下执行的业务取消，预留资源释放。首先我们看它的一个原理图.........

在分布式系统中，国内常用zookeeper+dubbo组合，而Spring Boot推荐使用全栈的Spring，Spring Boot+Spring Cloud。一个有意思的示例图：单一应用架构当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。垂直应用架构当访问量逐渐增大，单一应用增...

聊聊分布式应用的分布式事务2PC/3PC聊聊分布式应用的分布式事务TCC聊聊分布式应用的分布式事务之最大努力通知型事务本文我们将学习到另一种常见的柔性事务解决方案：消息一致性事务方案。对于TCC型事务，跨系统的调用均是基于服务间的直接调用，即很大程度上是同步调用。基于TCC方案能够保证主子事务同时成功，同时失败。但实际开发中，由于多方面的考虑，我们会将服务拆分为异步方式，一般是基于MQ进......

秒杀场景需要考虑这些关键词：高并发、响应时效性、流程削峰、恶意流量攻击、秒杀原子操作与数据安全、服务高可用(应对雪崩)等。【1】秒杀业务场景分析① 秒杀/抢购业务场景比如商品秒杀、商品抢购、群红包、抢优惠券、抽奖等等。② 秒杀/抢购业务特点秒杀商品价格低廉、抢购商品很好|抢手、---------------------

并发量、吞吐量、并发用户数据、pv、 uv、平均停留时长、跳出率、 平均响应时间、QPS、RPS、TPS。。。① 并发量即系统同时处理事务的能力，通常我们用QPS(query per second 每秒查询)来表示,也有地方用RPS(request per second 每秒请求),TPS(吞吐量，准确来说应该是吞吐率)来表示.但其实我们拿到的qps/tps/rps等大多都是1s内的处理能力...

MySQL的单表达到多少量级时性能会下降？宽表在千万量级，窄表要好一点在1200W左右。但是MySQL单表达到1500W时性能开始急剧下降！这里先抛出一道面试题：Q1：一亿的用户表，怎么做优化？Q2：两个实体，用户和订单，数据量都过亿要求：1.从用户角度快速查询订单2.从订单角度快速查用户怎么设计表？【1】常见数据库中间件分布式数据库中间件有TDDL、Sharding-JDBC...

面试题：高并发场景/接口被刷怎么办？【1】架构和细节首先参考上篇博文：聊聊高并发应用中秒杀场景的方案实现，其中限流，缓存等思想是一致的。这里需要注意的是，如果在现有集群环境下，负载压力仍然很大怎么办？观察上图最后一步—容器化技术。使用Docker+K8s(Kubernetes)构建Docker集群环境。当QPS超过阈值后，自动扩容。比如扩容两个虚拟机，将登录子系统从四节点扩容到6节点，然后...

【1】本地缓存本地缓存即缓存和应用在同一个进程里，是基于JVM的缓存，应用生则生，应用死则亡。常见产品有Guava、Caffeine和Ehcache。三者对比如下：对比项GuavaCaffeineEhcache是否开源Y(Google)Y(apache)Y(Terracotta)级别轻量轻量重量级知名度Java开发者必备Spring5Hi...

不仅包含负载均衡还包括应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙过滤等功能。参考Tomcat官网：http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html。

当查询一个不存在的数据时，如果每次都去查询数据库，而数据库中确实没有该数据，这就会导致每次请求都直接打到数据库上，这种现象被称为缓存穿透。