大型电商网站分布式秒杀系统设计三种姿势( 六 ) _分布式

读缓存：对读请求做数据缓存，将重复的请求过滤掉。

写限流：对写请求做限流保护，将超出系统承载能力的请求过滤掉。

写校验：对写请求做一致性校验，只保留最终的有效数据。

过滤的核心目的是通过减少无效请求的数据 IO 保障有效请求的 IO 性能。
小结：系统可以通过入口层的答题、业务层的排队、数据层的过滤达到流量削峰的目的，本质是在寻求商业诉求与架构性能之间的平衡。
另外，新的削峰手段也层出不穷，以业务切入居多，比如零点大促时同步发放优惠券或发起抽奖活动，将一部分流量分散到其他系统，这样也能起到削峰的作用。
Plan B当一个系统面临持续的高峰流量时，其实是很难单靠自身调整来恢复状态的，日常运维没有人能够预估所有情况，意外总是无法避免。
尤其在秒杀这一场景下，为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底。
高可用建设，其实是一个系统工程，贯穿在系统建设的整个生命周期。

文章插图
具体来说，系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段，以及故障发生时，逐一进行分析：

架构阶段：考虑系统的可扩展性和容错性，避免出现单点问题。例如多地单元化部署，即使某个 IDC 甚至地市出现故障，仍不会影响系统运转。
编码阶段：保证代码的健壮性，例如 RPC 调用时，设置合理的超时退出机制，防止被其他系统拖垮，同时也要对无法预料的返回错误进行默认的处理。
测试阶段：保证 CI 的覆盖度以及 Sonar 的容错率，对基础质量进行二次校验，并定期产出整体质量的趋势报告。
发布阶段：系统部署最容易暴露错误，因此要有前置的 Checklist 模版、中置的上下游周知机制以及后置的回滚机制。
运行阶段：系统多数时间处于运行态，最重要的是运行时的实时监控，及时发现问题、准确报警并能提供详细数据，以便排查问题。
故障发生：首要目标是及时止损，防止影响面扩大，然后定位原因、解决问题，最后恢复服务。

对于日常运维而言，高可用更多是针对运行阶段而言的，此阶段需要额外进行加强建设。
主要有以下几种手段：

预防：建立常态压测体系，定期对服务进行单点压测以及全链路压测，摸排水位。
管控：做好线上运行的降级、限流和熔断保护。需要注意的是，无论是限流、降级还是熔断，对业务都是有损的，所以在进行操作前，一定要和上下游业务确认好再进行。就拿限流来说，哪些业务可以限、什么情况下限、限流时间多长、什么情况下进行恢复，都要和业务方反复确认。
监控：建立性能基线，记录性能的变化趋势；建立报警体系，发现问题及时预警。
恢复：遇到故障能够及时止损，并提供快速的数据订正工具，不一定要好，但一定要有。

在系统建设的整个生命周期中，每个环节中都可能犯错，甚至有些环节犯的错，后面是无法弥补的或者成本极高的。
所以高可用是一个系统工程，必须放到整个生命周期中进行全面考虑。同时，考虑到服务的增长性，高可用更需要长期规划并进行体系化建设。
总结一下高可用其实是在说 “稳定性”，稳定性是一个平时不重要，但出了问题就要命的事情，然而它的落地又是一个问题——平时业务发展良好，稳定性建设就会降级给业务让路。
解决这个问题必须在组织上有所保障，比如让业务负责人背上稳定性绩效指标，同时在部门中建立稳定性建设小组，小组成员由每条线的核心力量兼任，绩效由稳定性负责人来打分，这样就可以把体系化的建设任务落实到具体的业务系统中了。