<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>lua-script on </title>
    <link>/tags/lua-script/</link>
    <description>Recent content in lua-script on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sat, 11 Apr 2026 10:00:00 +0800</lastBuildDate><atom:link href="/tags/lua-script/index.xml" rel="self" type="application/rss+xml" />
    <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>
    
    <item>
      <title>Spring Boot 3.5 &#43; Java 25 &#43; Cloud Native 系列（六）：插件化活动引擎</title>
      <link>/posts/shop-platform-activity-engine/</link>
      <pubDate>Sun, 05 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/shop-platform-activity-engine/</guid>
      <description>在之前的文章中，我们看了 API Gateway、BFF 聚合、领域服务和事件驱动架构。本文继续整理 Shop Platform 里我觉得比较有意思的一块——activity-service 的插件化游戏引擎。
📦 本文基于的完整项目源码：https://github.com/meirongdev/shop
上一篇：（五）事件驱动架构
2026-04 实践更新 当前主线代码里，RedEnvelopePlugin 和 AntiCheatGuard 都已经从 StringRedisTemplate 统一迁到 RedissonClient；本文讨论的 Lua 原子性和反作弊思路不变，但 Redis 客户端层已经与早期版本不同。
为什么需要活动引擎 电商平台经常需要举办营销活动来吸引用户：
砸金蛋/抽奖：用户消耗次数参与，随机获得奖品 抢红包：限时限量，用户拼手速抢金额 集卡：集齐一套卡片兑换大奖 虚拟养成：每天浇水/喂养，成熟后收获奖品 如果每个活动都独立开发一个新服务：
代码大量重复（参与记录、奖品发放、反作弊逻辑） 每次上线新活动都要走完整的发版流程 活动下线后代码变成死代码 这次项目里我更倾向用插件化引擎：一个服务、一套运行框架，新增活动时先实现一个插件接口，再让 Spring 负责发现和注册。
GamePlugin SPI 接口设计 核心接口 public interface GamePlugin { /** 声明支持的游戏类型 */ GameType supportedType(); /** 游戏激活时的初始化（如生成红包金额） */ default void initialize(ActivityGame game) {} /** 核心玩法：参与一次 */ ParticipateResult participate(ParticipateContext ctx); /** 游戏结束时的清理（如 Redis 数据回收） */ default void settle(ActivityGame game) {} /** 扩展表前缀（插件自带数据表时使用） */ default Optional&amp;lt;String&amp;gt; extensionTablePrefix() { return Optional.</description>
    </item>
    
  </channel>
</rss>
