Spring Boot项目实战:短信功能分布式限流

项目背景与需求

  • 项目名称:充电桩项目
  • 升级:进行微服务架构升级
  • 关键功能:短信服务,用于用户登录、注册等

短信功能设计考虑

  • 短信模板存储:需考虑存储方式
  • 发送次数限制:防止恶意攻击,设计60秒内只能发送一次短信
  • 成本问题:短信成本累积,需考虑限制发送次数以控制成本

分布式限流技术概述

  • 目的:防止恶意用户频繁发送短信导致成本上升
  • 限流方案:列举了五种不同的限流技术及其适用场景

限流方案详解

  1. 基于令牌桶算法:简单,平滑限流,但不适合瞬时流量突增
  2. 基于漏桶算法:简单,平滑限流,但粒度较粗
  3. 基于计数器的限流:控制请求速率,但可能因流量突增导致系统压力
  4. 基于分布式缓存的限流:适用于大规模分布式系统,但依赖缓存系统
  5. 基于流量控制网关的限流:集中管理流量,适用于大规模系统,但增加系统复杂性

限流算法比较

  • 固定速率(Fixed):简单,预测性强,但不灵活,无法应对突发流量
  • 滑动窗口速率(Sliding Window):灵活,资源利用率高,但实现复杂,性能开销大

限流算法选择建议

  • 根据业务需求和系统架构选择适合的限流算法
  • 举例:每小时用户最多发送6次短信,使用滑动窗口限流

实现示例

  • 技术选型:使用Redisson实现滑动窗口限流
  • 方法介绍 :limitBySlidingWindow 方法及其参数
    • key:限流的键
    • rate:每秒允许的请求数量
    • rateInterval:滑动窗口的时间长度
    • rateIntervalUnit:时间长度单位

短信模块设计

  • 设计模式:模板方法模式、工厂模式、策略模式
  • 限流处理:短信发送前进行图片验证码校验
相关推荐
子兮曰4 天前
jev-ultrafast 深度解析:7 秒订机票的浏览器 Agent 是如何炼成的
前端·后端·agent
子兮曰4 天前
Jev 爆发一周:7 秒 Agent 背后的 System One 生态与三场争议
前端·后端·ai编程
爱勇宝4 天前
ZCode 开源 24 小时:一份没有历史的账本,回答不了"有没有偷代码"
前端·后端·chatglm (智谱)
胡写代码4 天前
别再前后端各写一套表单校验了
java·后端
大勇前进4 天前
原生 PHP 还是 Laravel?小项目到底要不要上框架
后端
vipxieliang4 天前
ValidX 在 DDD 领域驱动设计中的实践
java·spring boot
yuzhi_liu4 天前
我用 LangGraph4j 实现 Multi-Agent Supervisor
后端
alsmile4 天前
Node-RED 之外,国产规则引擎的新方案:基于标准语法,Go 先行实现
后端·开源·go
大白804 天前
PHP 内存溢出排查思路:看懂报错日志,精准定位问题
后端
二月龙4 天前
PHP 接口返回统一响应封装,让前后端对接更省心
后端