悟了！！！！太爽了算算法不仅不痛苦还有点小爽怎么回事每天不刷点还有点难受哈哈哈开玩笑的真的强，灵加卡加豆

灵神太强了，写力扣没这么爽过

，有没有什么老主神学，祝我一臂之力

这么感觉学的时候太肤浅全是漏洞，  问了个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（分布式协调场景，需强...