一、前言
在紫微斗数整套系统开发中，排盘、解读规则引擎都封装成后端接口对外提供服务，H5、小程序、网站多端同时调用。随着访问量上涨，短时间大量请求涌入，很容易出现接口超时、数据库压力陡增，甚至规则引擎批量计算拖垮整个服务的情况。
紫微斗数接口和普通业务接口有明显区别，单次请求里面包含农历公历换算、安星计算、规则引擎匹配，CPU 开销远大于简单查库接口，一旦并发失控，故障扩散速度会很快。单纯依靠扩容服务器成本太高，所以必须配套一套稳定的限流方案，保护后端算力资源。
本文结合紫微斗数测算接口的业务特点，分享落地的限流思路、分层防护策略以及踩坑经验。
二、业务特点和限流目标
紫微斗数接口的请求有几个明显特征，很多都是集中在晚间的访问高峰，而且存在批量刷取生辰、爬虫批量调用的风险。单次接口计算耗时不固定，复杂的全量解读请求比单纯排盘请求消耗更多算力。
我们限流的目标，不是简单粗暴拒绝流量，而是区分正常用户和异常流量，优先保障普通用户正常使用，拦截爬虫、高频刷接口的请求，在服务承载上限之内平稳运行，避免雪崩。同时限流逻辑不能影响正常的长尾流量，要给用户友好的提示，而不是直接无响应。
三、分层限流整体思路
采用多层防护的思路，从网关层到应用层依次做控制，层层兜底。第一层在网关做粗粒度限流，拦截大流量攻击；第二层在应用内部做细粒度的业务限流，区分不同接口、不同用户的调用频次。
网关层主要针对 IP 维度做限流，同一个 IP 短时间大量请求直接拦截，用来抵挡爬虫和批量脚本。进入应用之后，再按用户维度、接口类型分开配置阈值，排盘基础接口阈值放宽，带规则引擎全解读的重计算接口阈值收紧。
同时做热点缓存，同一个生辰、同一流派的排盘结果缓存一段时间，减少重复计算，从源头降低并发压力，限流只是兜底手段，缓存优化才是减轻接口压力的核心。
四、限流算法选型
对比几种常用限流算法，固定窗口容易出现临界突刺，滑动窗口实现成本偏高，最终选用令牌桶算法。令牌桶可以控制平均速率，同时允许一定量的突发流量，非常适合这个场景。用户短时间连续测几个盘属于正常突发，令牌桶可以放行，而持续高频的刷取行为会慢慢被限制。
所有限流配置都抽成可配置项，不需要改代码重启服务，后台可以随时调整不同接口的速率上限，高峰期收紧，低峰期放开。
五、核心代码示例
// 令牌桶初始化，重计算解读接口设置速率 private RateLimiter interpretLimiter = RateLimiter.create(20.0); public ResultDTO getInterpretResult(PanQueryDTO query) { if (!interpretLimiter.tryAcquire()) { return ResultDTO.fail("当前访问人数较多，请稍后再尝试测算"); } return ruleEngineService.buildInterpret(query); }
// IP维度限流简易校验 public boolean checkIpLimit(String ip) { String key = "ziwei:ip:limit:" + ip; Long count = redisTemplate.opsForValue().increment(key, 1); if (count == 1) { redisTemplate.expire(key, 60, TimeUnit.SECONDS); } return count <= 30; }
六、业务层面的特殊处理
单纯依靠技术限流还不够，还要结合业务做区分。把接口拆分成两个，基础排盘接口和全解读接口分开，基础排盘算力消耗低，可以给到更高的并发阈值，全解读要跑规则引擎，消耗 CPU 高，严格限制调用频率。
限流之后的返回信息要友好，不要返回 500 错误，统一返回业务提示码，前端收到提示之后展示友好文案，引导用户隔一会再试。另外增加黑名单机制，持续触发限流的 IP，自动加入短时黑名单，减少无效请求持续消耗资源。
还要做好监控，对限流命中次数单独埋点，持续观察哪些接口、哪些 IP 频繁触发限流，方便判断是正常流量上涨还是爬虫攻击，及时调整阈值或者针对性封禁。
七、踩坑总结
前期踩过一个比较大的坑，一开始只做了全局统一限流，没有区分接口，高峰期大量解读请求把配额占满，普通用户简单排盘也被限制，体验很差。分层分接口限流之后这个问题得到解决。
另外不要把限流阈值设置得过于保守，不然很容易误杀正常用户。优先依靠缓存降低计算量，限流作为最后一道防护，而不是主要控流手段。紫微斗数这类算力型接口，缓存命中率提升之后，高并发压力会明显下降。
八、总结
紫微斗数接口属于 CPU 密集型接口，高并发场景下风险比普通查询接口更高。整套方案的核心就是网关粗粒度 IP 限流 + 应用层令牌桶细粒度限流，再配合结果缓存、接口拆分、监控埋点一起使用。
限流不是为了限制用户，而是保护后端排盘和规则引擎服务稳定，避免单点故障。后续还会结合分布式限流改造，多实例部署的时候，保证全集群的调用速率可控。
九、互动
如果你也在做命理测算类后端接口，遇到高并发、算力消耗大的问题，欢迎一起交流限流策略、缓存方案和集群防护的经验。
