<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>redisson on </title>
    <link>/tags/redisson/</link>
    <description>Recent content in redisson on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Tue, 14 Apr 2026 10:00:00 +0800</lastBuildDate><atom:link href="/tags/redisson/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>没有 Service Mesh，用 API Gateway 做用户级灰度</title>
      <link>/posts/spring-cloud-gateway-canary-release/</link>
      <pubDate>Tue, 14 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/spring-cloud-gateway-canary-release/</guid>
      <description>本文基于的项目：https://github.com/meirongdev/shop（私有）。相关实现主要在 services/api-gateway。
从一个具体问题开始 buyer-bff 要升级一版，改动涉及订单接口的返回结构。上线前我们想让两三个内部测试账号先跑一段时间，其他人继续走旧版。出问题时能立刻回切，整个过程不要重启任何服务。
前提：环境里没有 Istio、没有 Linkerd，也没有 Argo Rollouts。Kubernetes 只有原生的 Service 和 Ingress。
在这种约束下，灰度发布能放在哪一层？
Kubernetes Service 权重：原生 Service 不支持按权重或按用户分流，它只是 round-robin。 应用内开关：让每个服务各自根据用户属性判断走新旧逻辑。问题是&amp;quot;谁是灰度用户&amp;quot;的判断会散落到每个服务里重复实现，也没法在入口做统一观测。代码层面的 feature flag 不是不能用，它和 Gateway 路由解的是不同层次的问题——本文末尾会讨论两者如何互补。 Service Mesh：能干净地做这件事，但引入一整套 sidecar/control plane，对这个项目太重。 API Gateway：请求进入系统的第一跳，比较自然地成为流量决策点。只要 Gateway 能按请求属性选择 upstream，就够了。 这个项目选了第四条。下面把每一个设计选择拆开讲。
Spring Cloud Gateway 在这里担任什么角色 Shop Platform 的 api-gateway 是 Spring Cloud Gateway Server MVC（不是 WebFlux 那套），运行在虚拟线程上。它在系统里承担的事情是常规的那几件：
路径路由（/api/buyer/** → buyer-bff，/auth/** → auth-server……） 鉴权（解析 JWT、注入 X-Buyer-Id 等可信 Header） 限流（基于 Redis 的令牌桶） CORS、OpenAPI 聚合 按用户做灰度路由 ← 本文主题 灰度在这里不是外挂的新组件，而是复用 Gateway 的路由匹配能力加一个自定义谓词。</description>
    </item>
    
    <item>
      <title>Spring Boot 3.5 下 Redis 实战记录：从连接池调优到 Bloom Filter 自动配置</title>
      <link>/posts/spring-boot-redis-best-practices/</link>
      <pubDate>Sat, 11 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/spring-boot-redis-best-practices/</guid>
      <description>📦 本文基于的完整项目源码：https://github.com/meirongdev/shop
2026-04 实践更新 当前主线代码已经把 buyer-bff / auth-server / activity-service / api-gateway 的 Redis 访问统一切到 RedissonClient；其中网关限流仍然保留 Lua 原子脚本，但执行器也已经从 StringRedisTemplate 切到 RScript。本文下面的示例已按仓库当前实现同步。
Redis 在 Shop Platform 中承担的角色远不止&amp;quot;缓存&amp;quot;——它是限流的令牌桶状态（Gateway Lua + RScript）、抢红包的原子存储（activity-service Redis List）、反作弊的状态机（Anti-CheatGuard）、幂等检查的 Bloom Filter（shop-starter-idempotency），以及游客购物车的存储（buyer-bff）。
本文从五个维度整理 Spring Boot 3.5 下 Redis 的一些实践记录。
Lettuce 连接池调优 Spring Boot 3.5 默认使用 Lettuce 作为 Redis 客户端。Lettuce 基于 Netty，连接本身是线程安全的；对大多数普通 GET / SET / HSET / EVAL 场景来说，共享连接就已经够用。连接池更适合拿来解决阻塞命令、事务、Pub/Sub 或需要 dedicated connection 的场景，而不是“高并发就一定要开池”。
什么时候才需要连接池 如果你确实要跑阻塞命令、事务，或者要为特定操作准备专用连接，可以再启用连接池：
spring: data: redis: host: ${REDIS_HOST:redis} port: ${REDIS_PORT:6379} lettuce: pool: max-active: 20 # 最大连接数 max-idle: 10 # 最大空闲连接 min-idle: 5 # 最小空闲连接 max-wait: 2000ms # 获取连接最大等待时间 参数 说明 常见起点 max-active 连接池最大连接数 CPU 核心数 × 2 ~ × 4 max-idle 最大空闲连接数 max-active 的 50%-80% min-idle 最小空闲连接数 max-active 的 20%-30% max-wait 获取连接超时 1-3 秒（过长说明连接池不够） 连接池依赖 Spring Boot 不会自动引入连接池，需要手动添加 commons-pool2：</description>
    </item>
    
  </channel>
</rss>
