1.停电事故后电力恢复的方式1.1.停电后常见的情形是，送电几秒钟后又再次断电1.2.数百万台空调和冰箱的用电需求，使刚刚恢复的电力供应发生过载1.3.当电力供应不足时，增加的电流很快就到达满负荷，导致过载，触发断路器跳闸，灯再次熄灭2.经验教训2.1.系统规模相对较小的组件子集上永远不会出现这种情况2.2.系统达到稳态时的负载，会与系统启动或周期性运行的负载存在明显不同2.3.示例2.3.1.一个应用程序服务器农场的启动过程2.3.2.每台服务器都需要连接到数据库，并加载一定数量的参考数据或种子数据2.3.3.每台服务器的缓存都从空闲状态开始，逐渐形成一个有用的工作集2.3.4.大多数HTTP请求会转换为一个或多个数据库查询2.3.5.当应用程序启动时，数据库上的瞬时负载要比运行一段时间后的负载高得多3.一窝蜂3.1.一堆服务器一同对数据库施加瞬时负载3.2.是对系统的集中使用，相比将峰值流量分散开后所需的系统能力，一窝蜂需要一个更高的系统容量峰值3.3.一窝蜂所需系统成本过高，高峰需求无法处理3.4.引发一窝蜂现象的情况3.4.1.在代码升级和重新运行之后，启动多台服务器3.4.2.午夜（或任何一个整点时间）触发cron作业3.4.3.配置管理系统推出变更3.4.4.当一些外部现象引起流量的同步“脉冲”时3.4.5.阻塞许多线程的所有地方，它们在等待某个线程完成工作3.4.5.1.这个状态打破时，新释放的线程就会对任何接收数据包的下游系统施加一窝蜂3.4.6.虚拟用户的脚本存在固定等待时间，则在进行负载测试时，就会产生流量脉冲3.4.6.1.脚本中的每个等待时间都应该附带一个小的随机时间增量3.5.解决方案3.5.1.使用增加的退避时间避免脉冲3.5.1.1.固定的重试时间间隔，会集中那段时间的调用方需求3.5.1.2.使用退避算法，不同调用方在经过自己的退避时间后，在不同的时间点发起调用3.5.2.使用随机时钟摆动以分散需求3.5.2.1.不要将所有cron作业都设置在午夜或其他任何整点时间执行3.5.2.2.混合的方式设置时间，分散负载4.系统容量4.1.无论系统资源是需要数月、数周还是数秒才能完成整备，最终都可能导致不同层级之间的处理速率不匹配4.2.由于容量不对等，前端总是有能力来压倒后端4.3.将系统容量均匀地进行匹配，是不切实际的4.3.1.除了某一天会派上用场，其他时间99%的基础设施将处于闲置状态4.4.对于服务的构建，如果不能使之全部满足前端潜在的压倒性需求，那么就必须构建服务调用方和服务提供方的韧性，从而能够应对海啸般袭来的请求4.5.对服务调用方来说，当响应获取速度变慢或连接被拒绝时，使用断路器模式有助于缓解下游服务的压力4.6.对服务提供方来说，可以使用握手和背压通知调用方，限制调用方发送请求的速度4.7.使用舱壁模式，为关键服务的高优先级调用方预留系统容量5.系统容量失衡5.1.放大效应的特例5.2.在QA环境中很少能观察到的问题5.2.1.主要原因是每个系统的QA环境通常会缩小到只有两台服务器5.2.2.检查服务器和线程的数量5.2.3.实现QA环境虚拟化并实现扩展5.2.4.重视接口的两侧5.3.考验机能帮助验证前端系统能否良好地实现降级5.4.关系中一方的增幅变化大大超过另一方5.5.宣传带来的流量高峰，就更难以预测了5.5.1.自黑式5.5.2.季节性、市场驱动或宣传驱动等流量模式的变化，会导致前端系统的大量请求涌向后端系统（通常是良性的），就像热门的社交媒体帖子导致网站流量剧增5.6.要为出现任何状况做好准备5.6.1.可以使用系统容量建模的方法，确保系统能力至少在可变范围之内5.6.2.如果系统具有韧性，那么它可能会减慢处理速度，甚至当无法在允许的时间内处理事务时，就开始出现“快速失败”5.6.2.1.当负载压力减弱后，系统应该还能够恢复回来5.6.3.使用自动扩展应对激增的访问请求5.6.3.1.存在时间相对滞后的问题，并且还会将问题向下转移到超载的平台服务上