这么感觉学的时候太肤浅全是漏洞，  问了个BeanPostProcessor，去实现加了一个注解的bean，打印日志，记录bean的名称，和初始化时间，我都没听过后来又问bean的生命周期，回答的很浅我，鸡了

讲的数据库底层，挺好的，不用直接干巴巴的背mysql，深刻理解了！安利！！

    Hystrix 官方在 2018 年宣布进入维护模式，不再开发新特性，仅修复严重安全与 BUG 问题。官方推荐替代方案：Resilience4j，轻量级、函数式编程，适配 Java8+，完全兼容 Spring Boot/Cloud 生态。国内主流替代方案：阿里 Sentinel，除了熔断降级，还提供了流量控制、系统自适应保护、网关流控等更全面的微服务流量治理能力。讲的太清晰了！！！强力安利！

#前面讲得夯爆了，后面讲得有一般，但是也是收获满满

以前只会无脑拉去，现在系统学了下，挺好的！！！

1安全，前端token不变，但是相当于token后端有状态2aecsstoken和refash token设计access_token和refresh_token就是为了提高安全性，但是安全这个问题没有绝对安全，只是提高。access_token用于业务，频繁api请求使用，容易被劫持泄漏，有效期一般比较短，失效了就要用户重新认证，用户体验太差，又不能把用户账号和密码保存本地，并且现在很多业务系统使用outh2，这个账号及密码会关联很多其他业务系统，一旦泄露安全问题就更严重了。refresh_token有效期一般比较长时间，在access_token失效时客户端做失效异常拦截自动使用refresh_token和认证服务器发送请求获取最新access_token，由于使用频率低，在网络泄漏劫持的概率就低了。app等应用中用户主动点击退出，也会将refresh_token在服务端做失效处理。当然认为当前项目系统安全不重要的，完全可以把用户敏感信息和密码保存到客户端本地，刷新令牌随着业务请求一起使用。

一、四种限流算法1. 固定窗口计数器◦ 单位时间内计数，超过就拒◦ 优点：简单◦ 缺点：临界突刺2. 滑动窗口◦ 把时间分片，滑动统计◦ 优点：更平滑，无突刺3. 漏桶算法◦ 请求入桶，固定速率流出◦ 优点：保护下游，匀速处理◦ 缺点：不支持突发流量4. 令牌桶算法◦ 固定速率放令牌，请求拿令牌◦ 优点：支持突发流量，生产最常用二、单机限流• Semaphore：控制并发数• 线程池 + 队列：利用拒绝策略限流• Guava RateLimiter：单机首选，令牌桶实现三、分布式限流• Redis + Lua：最常用，保证原子性• Redisson RRateLimiter：开箱即用分布式限流• 网关限流：Nginx、Spring Cloud Gateway四、主流限流框架• Sentinel：阿里出品，限流、降级、熔断• Resilience4j：轻量级，替代 Hystrix五、一句话总结• 单机：Guava• 微服务：Sentinel• 分布式：Redis + Lua• 算法首选：令牌桶

有写的Frp配置感觉一会一变，没法调试，用的时间反而变多了，也没学到东西，还是去老实学习原理去了。

CAP 理论是分布式系统的核心理论之一1. CAP 的三个特性一致性（Consistency）：所有节点同时看到相同的数据，即更新操作后，所有节点的数据是一致的。可用性（Availability）：任何合法请求都能在合理时间内得到响应（不保证数据最新，但服务必须可用）。分区容错性（Partition Tolerance）：当网络分区（部分节点之间通信中断）发生时，系统仍能继续运行。2. CAP 的核心结论在分布式系统中，网络分区是无法避免的（必须满足 P），因此只能在 “C” 和 “A” 中二选一：CP 模式：优先保证一致性和分区容错性，牺牲可用性。例：ZooKeeper（分布式协调场景，需强...

Redis 中一种非常高效的二进制数据结构。核心是通过位（bit）来存储和操作数据，特别适合处理海量的布尔型（是 / 否）数据场景。Bitmap 本质上是 Redis 的 String 类型 的「特殊使用方式」—— String 类型最大能存储 512MB 数据，对应可以存储 512MB * 8 = 4294967296 个位（约 43 亿位）。Redis 的 String 类型 是二进制安全的字节序列，官方规定其最大存储容量为 512MB（字节）；而 Bitmap 本质上是对 String 字节的「位级操作」—— 把每个字节（Byte）拆成 8 个位（Bit）来使用，因此 Bitmap 的最大可用位数 = 512MB × 8 = 4294967296 位（约 43 亿位）。每个位只有 0 或 1 两种状态；通过「偏移量（offset）」定位具体的位（偏移量从 0 开始，无上限，只要内存足够）；核心价值：用极少的内存存储海量的布尔型数据。512MB 限制的底层原因Redis 对 String 设 512MB 上限，并非技术上无法突破，而是基于「性能 + 设计定位」的权衡：内存与性能平衡：String 是 Redis 最基础、使用最频繁的类型，若允许无限制存储大字符串，会导致：单 key 占用过多内存。读写大 String 时（如 GET/SET 512MB 数据），网络传输、内存拷贝耗时过长，阻塞 Redis 主线程；符合 Redis 设计定位：Redis 是「内存数据库」，核心优势是「高速读写」，适合存储小而高频访问的数据（如缓存、计数器），而非大文件 / 大 blob 数据；底层编码适配：Redis String 会根据长度自动切换编码（int→embstr→raw），超过 44 字节用 raw 编码，512MB 是 raw 编码的安全上限，避免编码切换或内存管理异常。bitmap直观理解比如用 Bitmap 记录「用户是否登录」：offset = 用户 ID，value = 1（登录）/ 0（未登录）；记录 1 亿用户的登录状态，仅需 1亿 / 8 = 12.5MB 内存，远低于用 Hash/Set 等结构的内存消耗。实际操作所有命令都有 BIT1. 设置指定偏移量的位值：SETBIT key offset value（重要）作用：给 key 的第 offset 位设置值（0 或 1）示例：记录用户 ID=10086 的用户今天（20260106）登录了（设为 1）：SETBIT login:20260106 10086 1(integer) 0  # 返回值：该位原来的值（首次设置为0）2 获取指定偏移量的位值：GETBIT key offset（重）查询 key 的第 offset 位的值；示例：查询用户 10086 20260106 是否登录：GETBIT login:20260106 100863. 统计指定范围内值为 1 的位数量：（重）BITCOUNT key [start end]统计 key 中值为 1 的位的总数（可选指定字节范围，默认全部）BITCOUNT login:202601064位运算（与 / 或 / 异或 / 非）：BITOP operation destkey key1 [key2 ...]作用：对多个 Bitmap 执行位运算，结果存入 destkey；常用运算：AND：与（都为 1 才为 1）；OR：或（任意一个为 1 则为 1）；XOR：异或（不同为 1，相同为 0）；示例：统计用户「20260105 和 20260106 两天都登录」的数量：SETBIT login:20260105 10086 1SETBIT login:20260105 10000 1SETBIT login:20260106 10086 1SETBIT login:20260106 10001 1执行AND运算，结果存入 login:20260105_06_bothBITOP AND login:20260105_06_both login:20260105 login:20260106统计结果（只有10086两天都登录）BITCOUNT login:20260105_06_both

什么是缓存穿透客户端请求一个「数据库里根本不存在」的数据，导致请求既查不到 Redis 缓存、又查不到数据库，每次请求都会直接穿透缓存打到数据库，疯狂消耗数据库性能。解决方法：1，**缓存空对象：**在第一次未命中时，将该请求对象的value设置为null存储在redis中，并且设置TTL，这样在短期再次请求该数据时则不会出现缓存穿透。优点：实现简单，维护方便缺点：：Redis 会存一堆「空值 key」，占用少量内存（可忽略，设置短过期即可）。2, 布隆过滤器【进阶方案，高并发场景用】在 Redis / 缓存前加一层「布隆过滤器」，里面提前存入所有数据库中存在的 ID，请求过来先过过滤器：✅ 过滤器里有这个 ID → 放行，走正常缓存流程；❌ 过滤器里没有这个 ID → 直接返回空，连 Redis 都不查。✅ 优点：性能极致，拦截效率 100%；❌ 缺点：实现稍复杂，适合百万 / 千万级数据的高并发项目，新手前期不用学。

考虑一种场景，我们的短信发送接口被同一个人使用不同的手机号多次恶意调用，那么同样会导致之前说过的问题。要实现 IP 地址黑名单功能，核心是基于 IP 标识请求方，并通过 Redis 维护黑名单列表，结合拦截器在请求入口处校验。在redisconstants中// ========== 新增【登录IP管控】核心配置 ==========// IP 1分钟限流Key（格式：verify:ip:limit:xxx.xxx.xxx.xxx）：1IP1分钟仅能发1次验证码public static final String VERIFY_IP_LIMIT_KEY = "verify:ip:limit:";// IP请求次数统计Key（格式：verify:ip:count:xxx.xxx.xxx.xxx）：统计短时间内IP总请求数public static final String VERIFY_IP_COUNT_KEY = "verify:ip:count:";// IP黑名单Key（格式：verify:ip:black:xxx.xxx.xxx.xxx）：IP被封禁的标识public static final String VERIFY_IP_BLACK_KEY = "verify:ip:black:";// 通用过期时间（复用原有，无需新增）：限流60s、统计1h、黑名单24h在usersericeimpl中//ip黑名单检测// 从session中获取HttpServletRequest对象HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();// ====== 第一步：获取客户端真实IP（必须！适配本地/服务器/代理环境） ======String clientIp = getRealIp(request);// ====== 第二步：校验黑名单【优先级最高】 ======// 1. 校验IP是否在黑名单 → IP拉黑直接拒绝String ipBlackKey = RedisConstants.VERIFY_IP_BLACK_KEY + clientIp;if (Boolean.TRUE.equals(stringRedisTemplate.hasKey(ipBlackKey))) {return Result.fail("ip在黑名单中!!");}// ====== 第三步：校验1分钟限流【防高频请求】 ======// 1. 校验IP：同一个IP，1分钟内仅能请求1次String ipLimitKey = RedisConstants.VERIFY_IP_LIMIT_KEY + clientIp;if (Boolean.TRUE.equals(stringRedisTemplate.hasKey(ipLimitKey))) {return Result.fail("同一个IP，1分钟内仅能请求1次");}// 1. IP请求次数统计：短时间内超3次 → 拉黑IPString ipCountKey = RedisConstants.VERIFY_IP_COUNT_KEY + clientIp;Long ipCount = stringRedisTemplate.opsForValue().increment(ipCountKey);if (ipCount == 1) { // 首次请求，设置1小时过期stringRedisTemplate.expire(ipCountKey, RedisConstants.VERIFY_COUNT_TTL, TimeUnit.SECONDS);}// IP超3次 → 封禁IP（24小时）if (ipCount > 2) {stringRedisTemplate.opsForValue().set(ipBlackKey, "1", RedisConstants.VERIFY_BLACK_TTL, TimeUnit.SECONDS);}// ========== 工具方法1：获取客户端真实IP（关键！适配所有环境） ==========private String getRealIp(HttpServletRequest request) {String ip = request.getHeader("X-Forwarded-For");if (ip == null || ip.isEmpty() || "unknown".equalsIgnoreCase(ip)) {ip = request.getHeader("Proxy-Client-IP");}if (ip == null || ip.isEmpty() || "unknown".equalsIgnoreCase(ip)) {ip = request.getHeader("WL-Proxy-Client-IP");}if (ip == null || ip.isEmpty() || "unknown".equalsIgnoreCase(ip)) {ip = request.getRemoteAddr();}// 处理多代理场景，取第一个有效IPif (ip != null && ip.contains(",")) {ip = ip.split(",")[0].trim();}return ip;}// ========== 工具方法2：超阈值时，清理无用的限流/统计Key ==========private void cleanLimitKey(String... keys) {for (String key : keys) {stringRedisTemplate.delete(key);}}