高可用异常
　　系统中某个服务高可用，当其中部分高可用节点因为某种原因挂掉时，能否保证整个服务可用。高可用又有主从和双主两种形式，需要区别对待。主从情况下，从节点一般不提供服务，只有在主节点挂掉时才会切换到服务状态；双主情况下，所有节点的地位是平等的，请求一般会负载均衡到所有节点。出现节点异常时不同的高可用类型会表现出各自的行为。
　　我们在模拟节点不可用时主要采用下文中提到的进程挂和主机宕机两种手段。
　　多副本异常
　　多副本在分布式存储系统中十分常见，是一种从数据安全角度考虑所做的数据冗余。和高可用中的双主形式比较类似，各副本地位平等，但对读写操作有不同的行为，视具体的系统策略而定。比如在某些系统中，所有副本写操作都正确返回才表示写成功，而只要一个副本读操作成功表示读成功了，因此副本异常时我们对读写操作的预期也不同。
　　模拟副本不可用的场景，同样也是采用进程挂和主机宕机两种手段。
　　缓存失效
　　缓存是提高服务响应、提升终用户体验的重要手段。如果缓存失效了，请求是否能正确到达后端，是否会对后端造成很大影响。
　　这种情况可以通过限制缓存大小，改变其命中率来模拟。
　　进程挂
　　进程挂主要通过kill掉进程来模拟，同时要注意不同的信号会产生不同的实际效果。
　　主机宕机
　　主机宕机在物理机环境下可以通过拔掉网线来模拟，但通常这种方式对测试的服务器可行性不高。我们可以通过在虚拟机内启动服务，然后kill掉虚拟机进程来模拟这种情况。
　　分析的困境
　　执行完测试，需要对测试结果进行分析。在验证应用服务行为的时候，我们主要通过其输出的日志来分析。当异常发生时，应用日志会被异常堆栈淹没，这些异常信息大部分是合理的，但我们需要从中挖掘出那些不合理的部分，或者说是异常中的异常。这时候人肉检查势必遗漏很多问题，即使借助Linux下的grep、awk等工具，其效率也十分有限，一个日志自动化分析工具才是解决问题的关键。在实践中我们基于Hadoop Hive定制了分析应用日志的工具，收到了不错的效果。
　　佳实践
　　过载异常测试是对系统中异常处理和过载保护的有效性检验，在此总结一下几种实践经验：
　　服务隔离：服务隔离可以按业务类型和核心程度进行划分。按业务类型隔离，如存储系统中读写业务分离、多媒体处理中图片视频模块分离、同步异步服务分离等等，把不同的业务分隔到不同的处理路径上，保证在某个路径上出现的异常不会波及到其他路径，使影响控制在有限的范围内。 根据业务的核心程度进行隔离，能够在异常情况下保证核心业务继续服务，把非核心业务部分或完全关闭。服务隔离又可以从物理和逻辑上进行具体实施。物理隔离，即把不同业务分隔到不同的磁盘、进程、机器甚至机房里。逻辑隔离，即对提供服务的逻辑单元进行隔离。
　　设置超时：经实践证明，超时是简单而行之有效的保护手段。建立TCP连接、数据传输需要设置超时，HTTP客户端发送请求也需要超时。在进行开发时我们应该明确这些超时配置，使其可配，而不是写死或者使用其默认值。超时参数需要根据依赖服务进行合理设置，太大相当于没有超时，过小则会导致过多超时错误，使后端做了无用功。
　　结语
　　随着业务的发展，我们的系统经历着用户量和请求量的增长，系统的各种异常处理和过载保护措施能够为这种增长保驾护航吗？让我们一起通过过载异常测试的实践来回答吧。