佬，下面是我的看法 2.需要使用熔断的场景：1.大量请求到来，调用链比较长且当前业务不是核心业务 需要将当前业务线直接停止 给其它核心业务让资源 2.当前接口在短时间内被多次调用达到自己设定的上限，应该被熔断直至达不到阈值 3.调用不通可能有几点 (1)当前业务没有后续调用链，证明当前业务存在问题，需要维护，因为在微服务中调用远程业务一般使用HTTP请求 既然已经出现bug那就没有必要再次浪费网络资源 (2)当前业务存在调用后续链 问题有两种 当前业务出现问题或者后续业务出现问题 无论是哪一种都会存在大量的资源浪费 比如网络资源 cpu时间片的轮转、线程的阻塞等 3.超时机制，高可用，负载，资源消耗，数据不一致，连接断开等 4.熔断之后，系统会过一会后尝试将服务恢复，检查如果此时的qps没有达到阈值则会放开，否则继续熔断 5.redis超时的应用：分布式锁保证不会一直处在锁阶段，登录服务时token的存储和续约，临时数据的缓存，状态信息的更替 6.分布式锁应该要满足的要求：1.独占性 2.高可用 3.防死锁 4.不乱抢 5.重入性 所以需要设置过期时间，但是如果业务执行时间确实比较长导致锁的释放会造成难以预估的损失，所以权衡时间是一个很重要的点。在官方的RedLock中使用看门狗机制来实现时间的延长。 7.MySQL联合索引注意的点：需要满足最左前缀原则、索引的长度不能太长、应该是索引的那个口诀