Redis 限流与计数器设计：零售 POS 系统优化

Redis 限流与计数器设计：零售 POS 系统优化

一、POS 场景的特殊挑战

零售 POS（Point of Sale）系统与常规互联网应用有本质差异：

核心痛点：

1. 扫码枪连扫：收银员快速扫描商品，100ms 内可能触发 5-10 次请求
2. 支付重试：POS 端网络抖动导致支付请求重复提交
3. 离线同步：断网期间数据本地缓存，恢复后批量上传需防重复
4. 金额精度：分位计算不能有任何累积误差

二、限流算法选型：为什么不用令牌桶？

2.1 四种算法对比

POS 不选令牌桶的原因：

• 令牌桶允许突发流量，但 POS 需要严格平滑（不能让扫码枪 1 秒内突刺 50 次）
• 漏桶输出速率恒定，会拖慢正常收银速度
• 滑动窗口能精确控制任意时间段的请求数，最适合收银节奏控制

2.2 滑动窗口的 Redis 实现

使用 RedisZSet（Sorted Set）存储请求时间戳，Score 和 Member 均为毫秒时间戳（比 UUID 节省 70% 内存）：

-- sliding_window.lua-- KEYS[1]: 限流key (如: rate:pos:store:001:terminal:003)-- ARGV[1]: 限制次数-- ARGV[2]: 窗口大小(秒)-- ARGV[3]: 当前时间戳(毫秒)localkey=KEYS[1]locallimit=tonumber(ARGV[1])localwindow=tonumber(ARGV[2])*1000-- 转为毫秒localnow=tonumber(ARGV[3])-- 1. 清理窗口外的旧数据（O(logN)）redis.call('ZREMRANGEBYSCORE',key,0,now-window)-- 2. 统计当前窗口内请求数localcount=redis.call('ZCARD',key)ifcount<limitthen-- 3. 记录本次请求（使用当前时间戳+微秒级随机数防重复）localmember=now..'-'..redis.call('INCR',key..':seq')redis.call('ZADD',key,now,member)-- 4. 设置过期时间（窗口+1秒冗余）redis.call('EXPIRE',key,math.ceil(window/1000)+1)-- 5. 返回剩余配额（便于前端展示）return{1,limit-count-1}else-- 返回拒绝标识和最早过期时间localoldest=redis.call('ZRANGE',key,0,0,'WITHSCORES')[2]localretryAfter=math.ceil((oldest+window-now)/1000)return{0,retryAfter}end

Java 封装层：

@ComponentpublicclassPosRateLimiter{@AutowiredprivateStringRedisTemplateredisTemplate;privatestaticfinalRedisScript<List<Long>>SLIDING_WINDOW_SCRIPT=newDefaultRedisScript<>(newClassPathResource("lua/sliding_window.lua"),List.class);/** * POS 收银限流 * @param storeId 门店ID * @param terminalId 收银机ID * @param action 动作类型(scan/pay/refund) * @param limit 限制次数 * @param windowSeconds 窗口大小(秒) */publicRateLimitResulttryAcquire(StringstoreId,StringterminalId,Stringaction,intlimit,intwindowSeconds){Stringkey=String.format("rate:pos:%s:%s:%s",storeId,terminalId,action);longnow=System.currentTimeMillis();List<Long>result=redisTemplate.execute(SLIDING_WINDOW_SCRIPT,Collections.singletonList(key),String.valueOf(limit),String.valueOf(windowSeconds),String.valueOf(now));booleanallowed=result.get(0)==1;longremaining=result.get(1);// 剩余配额低于 20% 时预警if(allowed&&remaining<limit*0.2){log.warn("POS限流预警: store={}, terminal={}, action={}, 剩余配额={}",storeId,terminalId,action,remaining);}returnnewRateLimitResult(allowed,remaining,allowed?0:result.get(1));}}

三、POS 专用限流策略设计

3.1 分层限流架构

┌─────────────────────────────────────────┐ │ 网关层 (Nginx) │ │ 粗限流: 1000 req/s per store │ ├─────────────────────────────────────────┤ │ 应用层 (Spring Gateway) │ │ 细限流: 100 req/s per terminal │ ├─────────────────────────────────────────┤ │ 业务层 (POS Service) │ │ 精准限流: 10 req/s per action │ │ scan: 20/s | pay: 5/s | refund: 3/s │ └─────────────────────────────────────────┘

策略配置表：

3.2 自适应限流（应对促销高峰）

@ServicepublicclassAdaptiveRateLimiter{@AutowiredprivatePosRateLimiterrateLimiter;@AutowiredprivateRedisTemplate<String,String>redisTemplate;// 促销期间动态调整系数privatestaticfinalStringPROMO_COEFFICIENT_KEY="config:rate:promo:coeff";publicRateLimitResulttryAcquireWithAdaptation(StringstoreId,StringterminalId,Stringaction,intbaseLimit){// 1. 获取当前促销系数（默认1.0）StringcoeffStr=redisTemplate.opsForValue().get(PROMO_COEFFICIENT_KEY);doublecoeff=coeffStr!=null?Double.parseDouble(coeffStr):1.0;// 2. 计算动态阈值（促销期间放宽 50%）intadjustedLimit=(int)(baseLimit*coeff);// 3. 执行限流检查RateLimitResultresult=rateLimiter.tryAcquire(storeId,terminalId,action,adjustedLimit,1);// 4. 记录限流指标用于监控if(!result.isAllowed()){Metrics.counter("pos.rate_limit.blocked","store",storeId,"action",action).increment();}returnresult;}// 运营后台动态调整接口@PostMapping("/admin/rate/adjust")publicvoidadjustRateLimit(@RequestParamdoublecoefficient){redisTemplate.opsForValue().set(PROMO_COEFFICIENT_KEY,String.valueOf(coefficient),Duration.ofHours(2)// 2小时后自动恢复);}}

四、精准计数器设计：金额计算 0 误差

4.1 为什么不用 INCRBYFLOAT？

RedisINCRBYFLOAT使用 IEEE 754 double 精度，存在浮点误差：

127.0.0.1:6379>INCRBYFLOAT amount0.01"0.010000000000000000208"

POS 解决方案：整数分存储（1元 = 100分）

4.2 交易计数器架构

Redis Key 设计: ├─ txn:daily:{storeId}:{yyyyMMdd} Hash {terminalId -> 交易笔数} ├─ txn:amount:daily:{storeId}:{yyyyMMdd} Hash {terminalId -> 交易金额(分)} ├─ txn:hourly:{storeId}:{yyyyMMddHH} Hash {terminalId -> 交易笔数} ├─ txn:realtime:{storeId} String 当前门店实时流水号（原子递增） └─ txn:terminal:{terminalId}:seq String 单收银机流水号（防断网重号）

原子扣减库存 + 记录交易（Lua 脚本）：

-- pos_transaction.lua-- 保证库存扣减、金额累加、流水号生成三者原子性localstockKey=KEYS[1]-- 库存keylocaltxnCountKey=KEYS[2]-- 交易计数keylocaltxnAmountKey=KEYS[3]-- 交易金额keylocalseqKey=KEYS[4]-- 流水号keylocalproductId=ARGV[1]localquantity=tonumber(ARGV[2])localamountFen=tonumber(ARGV[3])-- 金额（分）localterminalId=ARGV[4]-- 1. 检查并扣减库存（使用 HINCRBY 原子操作）localstock=redis.call('HGET',stockKey,productId)ifnotstockortonumber(stock)<quantitythenreturn{-1,"库存不足"}-- 错误码-1end-- 2. 扣减库存redis.call('HINCRBY',stockKey,productId,-quantity)-- 3. 生成全局唯一流水号（时间戳+自增）localtimestamp=redis.call('TIME')[1]localseq=redis.call('INCR',seqKey)localflowNo=timestamp..string.format("%06d",seq%1000000)-- 4. 累加交易统计（整数分，零误差）redis.call('HINCRBY',txnCountKey,terminalId,1)redis.call('HINCRBY',txnAmountKey,terminalId,amountFen)-- 5. 记录交易明细（5分钟后过期，用于对账缓冲）localtxnDetailKey="txn:detail:"..flowNo redis.call('HMSET',txnDetailKey,"terminal",terminalId,"product",productId,"qty",quantity,"amount",amountFen,"time",timestamp)redis.call('EXPIRE',txnDetailKey,300)return{1,flowNo,redis.call('HGET',stockKey,productId)}

Java 调用封装：

@ServicepublicclassPosTransactionService{@AutowiredprivateStringRedisTemplateredisTemplate;privatestaticfinalRedisScript<List<Object>>TXN_SCRIPT=newDefaultRedisScript<>(newClassPathResource("lua/pos_transaction.lua"),List.class);/** * 执行交易（原子性保证） * @return 交易流水号 */publicStringexecuteTransaction(StringstoreId,StringterminalId,StringproductId,intquantity,BigDecimalamount){// 金额转为分（彻底避免浮点误差）longamountFen=amount.movePointRight(2).setScale(0,RoundingMode.UNNECESSARY).longValue();Stringtoday=LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE);List<Object>result=redisTemplate.execute(TXN_SCRIPT,Arrays.asList("stock:store:"+storeId,"txn:daily:"+storeId+":"+today,"txn:amount:daily:"+storeId+":"+today,"txn:realtime:"+storeId),productId,String.valueOf(quantity),String.valueOf(amountFen),terminalId);Longcode=(Long)result.get(0);if(code==-1){thrownewInsufficientStockException((String)result.get(1));}return(String)result.get(1);// 返回流水号}}

五、幂等性设计：防重复支付

POS 场景重复提交的主要来源：

1. 网络抖动：支付请求已发出，但响应丢失，POS 端自动重试
2. 收银误操作：收银员误以为支付失败，手动点击"重新支付"
3. 离线同步：断网期间缓存多笔交易，联网后批量上传

5.1 Token 机制 + 去重表双保险

第一层：客户端 Token（防误操作）

@RestController@RequestMapping("/pos/pay")publicclassPosPaymentController{@AutowiredprivateIdempotentTokenServicetokenService;@AutowiredprivatePaymentServicepaymentService;// 1. 预生成支付 Token（收银台初始化时获取）@GetMapping("/token")publicStringgenerateToken(@RequestParamStringterminalId){returntokenService.generateToken(terminalId,Duration.ofMinutes(5));}// 2. 执行支付（携带 Token）@PostMapping("/execute")publicPaymentResultpay(@RequestBodyPaymentRequestrequest){// 校验并消费 Token（原子操作，仅第一次有效）if(!tokenService.checkAndConsumeToken(request.getTerminalId(),request.getToken())){thrownewDuplicateRequestException("该支付请求已处理，请勿重复提交");}// 执行支付...returnpaymentService.process(request);}}

第二层：服务端去重表（防网络重试）

-- 支付去重表（唯一索引保证幂等）CREATETABLEt_payment_idempotent(idempotent_keyVARCHAR(64)PRIMARYKEYCOMMENT'幂等键: terminalId:flowNo',terminal_idVARCHAR(32)NOTNULL,flow_noVARCHAR(32)NOTNULL,amountDECIMAL(10,2)NOTNULL,statusTINYINTDEFAULT0COMMENT'0-处理中 1-成功 2-失败',create_timeTIMESTAMPDEFAULTCURRENT_TIMESTAMP,UNIQUEKEYuk_flow(terminal_id,flow_no))ENGINE=InnoDB;-- 插入即锁定（利用唯一索引冲突防并发）INSERTINTOt_payment_idempotent(idempotent_key,terminal_id,flow_no,amount)VALUES(?,?,?,?)ONDUPLICATEKEYUPDATEstatus=IF(status=0,status,status),-- 处理中状态不覆盖id=LAST_INSERT_ID(id);-- 返回已存在记录的ID

Token 服务 Redis 实现：

@ServicepublicclassIdempotentTokenService{@AutowiredprivateStringRedisTemplateredisTemplate;privatestaticfinalStringTOKEN_PREFIX="pos:token:";/** * 生成预支付 Token */publicStringgenerateToken(StringterminalId,Durationttl){Stringtoken=UUID.randomUUID().toString().replace("-","");Stringkey=TOKEN_PREFIX+terminalId+":"+token;// 使用 SET NX EX 原子操作redisTemplate.opsForValue().set(key,"PENDING",// 状态: PENDING -> PROCESSING -> COMPLETEDttl);returntoken;}/** * 校验并消费 Token（Lua 保证原子性） */publicbooleancheckAndConsumeToken(StringterminalId,Stringtoken){Stringkey=TOKEN_PREFIX+terminalId+":"+token;Stringlua="if redis.call('get', KEYS[1]) == 'PENDING' then "+" redis.call('set', KEYS[1], 'PROCESSING') "+" return 1 "+"else "+" return 0 "+"end";Longresult=redisTemplate.execute(newDefaultRedisScript<>(lua,Long.class),Collections.singletonList(key));returnresult!=null&&result==1;}/** * 完成支付后标记（用于查询重复提交时的结果） */publicvoidcompleteToken(StringterminalId,Stringtoken,StringresultJson){Stringkey=TOKEN_PREFIX+terminalId+":"+token;redisTemplate.opsForValue().set(key,"COMPLETED:"+resultJson,Duration.ofMinutes(10)// 保留10分钟供查询);}}

六、完整架构与部署建议

6.1 部署拓扑

门店网络 ├─ POS 终端 x N (Android/Windows) │ └─ 本地 SQLite (离线缓存) + 断网队列 │ ├─ 门店路由器 │ └─ 本地 Redis 哨兵 (1主2从，自动切换) │ └─ VPN/专线 ──────► 总部数据中心 └─ Redis Cluster (6主6从) ├─ 限流数据 (过期快) ├─ 计数器数据 (持久化) └─ 对账数据 (AOF每秒刷盘)

6.2 关键配置参数

# Redis 配置（针对 POS 场景优化）redis:# 限流数据使用 LRU 淘汰（不重要）maxmemory-policy:allkeys-lru# 计数器数据必须持久化appendonly:yesappendfsync:everysec# 每秒刷盘，平衡性能与安全# 避免 OOM 导致限流失效maxmemory:2gb# 监控告警slowlog-log-slower-than:10000# 10ms 慢查询记录

6.3 监控指标

七、总结：POS 限流设计 checklist

• 限流算法：选择滑动窗口，拒绝令牌桶（突发风险）
• 金额存储：全部使用整数分，禁止浮点运算
• 原子操作：库存 + 金额 + 流水号必须 Lua 脚本原子化
• 幂等设计：Token 预生成 + 去重表双保险
• 降级策略：Redis 故障时切换本地限流（保守模式）
• 对账机制：Redis 计数器与数据库每日对账校验

这套方案核心思想是：用 Redis 做高性能临时计算，用关系型数据库做最终持久化，用 Lua 脚本保证中间状态的原子性。