第9章高可用性和稳定性“高并发”是为了使系统“高效”，高可用性和稳定性是为了使系统“更稳定”。 9.1多拷贝对于网关和APP应用服务器这样的无状态服务，制作多拷贝比较简单，只需要增加一个机器就可以了，但是对于有缓存和数据库这样的状态的，制作多拷贝就可以了。 1 .本地缓存多拷贝的一种常用方法是利用消息中间件(如kafka )的Pub/Sub机制，使每台机器订阅消息。 发送消息后，每台机器都会接收该消息并更新本地缓存。 2.Redis多副本2.Redis群集提供主标签之间的复制机制，可以在主标签关闭后切换到标签。 当然，切换需要时间间隔(通常为十几秒)，同时由于是异步副本，切换后可能会丢失少量数据。 如果是停机的redis，业务人员需要自己导入两套，自己进行两套的写入和切换。 补充：无论是本地缓存还是redis集中式缓存，既然其自身的定位是“缓存”，那就意味着业务场景并不要求数据完整性。 因此，这里主要考虑“高可用性”，不能保证数据的完整性。 3 .对于MySQL多副本MySQL，master-slave之间使用最多的是异步或半异步复制，同步复制性能较差。 对于异步复制，如果在slave超时后未返回，也会降级为异步复制。 因此，无论是异步复制还是半异步复制，都不能百分之百保证主数据和假数据完全一致。 实际上，为了确保可用性，通常会牺牲一定的数据一致性。 如果少量数据不匹配，并且后续的人工修复无法解决的服务不可用，则损失往往远大于少量数据不一致的损失，尤其是在通信量较大的情况下。 此外，如果发现某个slave延迟太大，还可以直接摘除，并进行监控以防止延迟太大的slave被选为主库。 4 .消息中间件多副本在kafka类消息中间件中，一个交易方通常至少指定三个副本。 为此，kafka设计了一种ISR算法，用于在多个副本之间同步消息。 9.2隔离、限流、熔断和降级1 .隔离隔离隔离是指通过隔离系统或资源，在系统发生故障时，可以限定传播范围和影响范围。 也就是说，故障发生后，不会出现雪人效应，因此将故障的影响限定在一个范围内。 1 .数据隔离从数据重要性的角度来说，一家公司或业务的数据一定非常重要，其次重要，不重要。 数据库存储将这些数据所在的物理库完全隔离。 它还支持业务分割和数据库划分。 从这个角度来说，业务的解体和数据的隔离，其实从不同的角度说的是同一件事。 2 .机器隔离对于一个服务来说，有很多调用者。 这些调用者也有重要性排名。 对于最中心的几个调用方，可以配置一组专用的机器，以防止其他调用方影响该调用方的服务器。 或者，原本是核心服务，但由于某种原因，在此基础上增加了新功能(新接口)。 该新功能只用于某个调用者，可以在不影响现有功能的情况下隔离调用者。 成熟的RPC框架往往具有隔离功能，根据调用方的ID ()，将来自某个调用方的请求全部发送到一组固定的机器上，业务人员不需要编写代码，结构简单。 3 .请注意，线程池隔离首先设置客户端超时时间。 如果超时时间长，某个服务的延迟大，就容易破坏服务。 为此，请使用线程池隔离，为每个rpc调用单独配置线程池。 通常为2到10个线程。 如果线程池中没有可用线程，并且线程池中的队列已满，线程池将直接抛出异常，拒绝新请求，以避免线程阻塞。
如果rpc服务向外部提供了许多接口，并且大多数接口都具有较快的处理速度，而且具有极个别接口的业务逻辑很复杂，处理速度较慢，则也可以在rpc服务内部创建单独的线程池。 这样，这个界面很慢，只是自己慢，对其他没有影响。 4 .信号量隔离信号量隔离是Hystrix提出的另一种隔离方法，比线程池隔离更轻。 一台机器可以运行的线程数量有限，过多的线程池会导致线程过多，从而增加线程切换开销。 使用信号量隔离不会添加线程池，而是仅在调用线程中执行。 信号量本质上是记录当前访问某个资源的同时线程数的数字，线程在访问资源之前获得该信号量，在访问结束时释放信号量。 当信号量达到最大阈值时，线程无法获取该信号量，并放弃请求而不是在那里等待信号量。 2 .限流限流可分为技术级限流和业务级限流。 技术水平的限流比较通用，各种业务场景都可以使用； 业务级流限需要根据具体业务场景进行开发。 1 .技术层面的限制流之一是限制并发次数，另一个是基于系统最大资源进行限制，例如数据库连接池、线程池、nginx的limit_conn模块限制速度的这种方法对于服务的接口调用很有用。 例如，如果在压力测试中发现服务的qps为2000，则该值可被限制为2000qps。 如果调用者超过这个数字，将直接拒绝提供服务。 这样，即使突然进入大量请求，服务器也不会被破坏。 虽然一些请求被拒绝，但可以确保其他服务正常工作。 2 .业务流限比如秒杀系统，一个商品库存只有100件，现在2w人在采购，不用装2w人，前500人装进去，后面的人直接回来卖完就行了。 针对这种情况，门票系统可以设置500张门票，建立每人领取门票的限制系统，或者被称为销售的资格系统(门票系统)。 收票人进入后面的业务系统进行收购； 对于抢不到的人，回到卖完的地方。 在具体实现中，有些人使用redis，有些人使用nginx lua。 3 .限流算法限制并发数的计算原理简单，系统只需在维护中使用的资源数或空闲数，比如数据库的连接数，线程池的线程数。限制速率的算法稍微复杂点，常用的有漏桶算法和令牌桶算法。漏桶算法：1.漏桶的容量是固定的，流出的速率是恒定的；2.流入的速率是任意的；3.如果桶是空的，则不需流出；4.如果流入的数据包超出了桶的容量，则流入的数据包溢出了(被丢弃)，而漏桶的容量不变。令牌桶算法：1.令牌桶的容量也是固定的，向里流入令牌的速率是恒定的；2.当令牌桶满时，新加入的令牌会被丢弃；3.当一个请求达到后，从桶中取出一个令牌。如果能取到令牌，则处理该请求；4.如果取不到令牌，则该请求要么被丢弃，要么排队。区别：对比两个算法会发现，二者的原理刚好相反，一个是流出速率保持恒定，一个是流入速率保持恒定。二者的用途有一定区别，令牌桶限制的是平均流入速率，而不是瞬时速率，因为可能出现一段时间没有请求来，令牌桶塞满了令牌，然后短时间突发流量过来，一瞬时从桶里拿几个令牌出来；漏桶有点类似于消息队列，起到了削峰的作用，平滑了突发流入速率。3.熔断熔断有两种策略：1.一种是根据请求失败率对于客户端调用的某个服务，如果服务在短时间内大量超时或者抛错，则客户端直接开启熔断，也就是不再调用此服务。然后过了一段时间，再把熔断打开，如果还是不行，则继续熔断。这就是 "快速失败(Fail Fast)" 策略。2.一种是根据请求响应时间当资源的平均响应时间超过阈值后，资源进入准降级状态。接下来如果持续进入5个请求，且他们的RT持续超过该阈值，那么在接下来的时间窗口内，对这个方法的调用都会自动的返回。与限流对比：限流是服务端限流，根据其能力上限设置一个过载保护；而熔断是调用端对自己做的一个保护。能熔断的服务肯定不是核心链路上的必选服务。如果是的话，则服务如果超时或者宕机，前端就不能用了，而不是熔断。所以，说熔断其实也是降级的一种方式。4.降级降级是一种兜底的方案，是在系统出故障之后的一个尽力而为的措施。相比限流，熔断两个偏技术的词汇，降级则是一个更加偏业务的词汇。因为在现实中，虽然任何的一个业务或者系统都有很多功能，但并不要求这些功能一定100%可用，或者完全不可用。其中存在一定的灰度空间。比如对于微信或者QQ，有文字通信，语音通信，视频通信，对带宽的要求是从小到大。网络发生故障时，可以优先保证文字通信可用。总之，会尽最大的努力提高服务，哪怕是有损服务，也比完全不提供服务强。还有电商的千人前面，可能靠的是推荐系统。如果推荐系统挂了，可以准备一个静态的商品列表。降级不是一个纯粹的技术手段，而是根据业务场景具体分析，看哪些功能可以降级，降级到什么程度，哪些宁愿不可用也不能降级。9.3 灰度发布与回滚 如果一个系统在线上的代码不动，不更新，理论上可以稳定的一直运行下去。频繁的变更是导致系统不稳定的一个直接因素。既然无法避免系统变更，我们能做的就是让这个过程尽可能的 平滑，受控，这就是灰度与回滚策略。1.新功能上线的灰度当一个新功能上线时，可以先将一部分流量导入这个新的功能，如果验证没有问题，再一点点增加流量，最终让所有流量都切换到这个新功能上。具体办法有很多，比如可以按 user_id 划分流量，按 user_id 的最后几位数字对用户进行分片，一片片的灰度把流量导入到新功能上；或者用户有很多属性，标签，按其中的标签设置用户白名单，再一点点导入流量。2.旧系统重构的灰度同上。3.回滚一种是安装包回滚，这种办法比较简单，不需要额外开发代码，发现线上有问题，统一部署之前的安装版本；另一种是功能回滚，在开发新功能的时候，也开发了相应的配置开关，一旦有问题，则关闭开关，让所有流量都进入老的系统。9.4 监控体系与日志报警 1.监控体系1.资源监控如cpu，内存，磁盘，带宽，端口等。2.系统监控如：1.最前端url访问的失败率以及具体某次访问的失败链路；2.rpc接口的失败率以及具体某次请求的失败链路；3.rpc接口的平均响应时间，最大响应时间，95线，99线；4.db 的 long sql;5.如果使用的是 Java，JVM的 young GC，full GC 的回收频率，回收时间等。3.业务监控根据业务具体分析。把业务系统再扩展一下，就变成了对账系统。2.日志报警如果说业务指标的监控是基于统计数据的一个监控，日志报警则是对某一次具体的请求的处理过程的监控。在输出日志的过程中，最容易出现的问题可能有：1.日志等级不分2.关键日志漏打