# 《Seckill秒杀系统》第95章：服务降级核心原理与落地方案
作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)
源码获取地址：https://t.zsxq.com/0dhvFs5oR (opens new window)
沉淀，成长，突破，帮助他人，成就自我。
- 本章难度：★★☆☆☆
- 本章重点：了解服务降级解决的核心问题与使用场景，重点掌握服务降级的核心原理与落地实现方案，并能够灵活将实现方案应用到自身实际项目中。
大家好，我是冰河~~
从本质上讲，与流量削峰一样，服务降级解决的也是在有限的系统资源下，需要承载超高流量的需求问题。像秒杀系统这种瞬时超高并发流量的场景，即使我们对系统做了流控措施，在整场秒杀活动下，如果系统持续处于高并发流量的压力下，秒杀链路上部分服务就可能会出现问题，所以，除了流控以外，我们对秒杀系统也要增加其他的容错方案。
# 一、前言
在前面的文章中，我们对秒杀系统进行了一系列的优化措施。同时，对秒杀系统实现了分布式流控、单机限流的流控措施。引入了业务网关，能够在业务网关层面实现分布式流控和单机流控。为了尽可能的将流控和数据校验前置化，引入了流量网关。为了进一步保证秒杀系统整个交易链路上服务的稳定性，我们还需要对秒杀系统进行容错处理，其中，服务降级就是秒杀系统中非常重要的一环。
# 二、本章诉求
讲述服务降级的核心原理与落地实现方案，不只是秒杀系统适用，任何互联网项目甚至传统IT项目，在系统资源有限的情况下，需要支持高并发流量访问。此时，都需要对系统进行降级处理，使系统能够在资源有限的环境中，平稳运行。
# 三、服务降级
从本质上讲，与流量削峰一样，服务降级解决的也是在有限的系统资源下，需要承载超高流量的需求问题。像秒杀系统这种瞬时超高并发流量的场景，即使我们对系统做了流控措施，在整场秒杀活动下，如果系统持续处于高并发流量的压力下，秒杀链路上部分服务就可能会出现问题，所以，除了流控以外，我们对秒杀系统也要增加其他的容错方案。
当然，如果你的系统资源充足，或者访问流量根本不高，此时可以不考虑服务降级。反之，如果系统资源有限，并且访问系统的流量比较高，系统资源不足以支撑这么高的并发访问流量时，就需要考虑服务降级了。
服务降级一般都是有损的，常见的服务降级方案有：写服务降级、读服务降级和精简系统流程。
# 四、写服务降级
学到这里，小伙伴们应该比较清楚了，在秒杀系统中，不可能是一个单体系统或者单个微服务在运行，往往是各个微服务组成了整个秒杀的交易链路，此时，就会涉及到多数据源的问题。
其实，尽管有数据一致性理论和分布式事务落地方案的指导，在多数据源场景下，数据的强一致性其实也是比较难以保证的，这不仅仅是分布式事务在高并发场景下实现比较困难，更是由于在高并发场景下，需要对强一致性和高可用性做出权衡和取舍。
因此，一般在涉及金融资产类对一致性要求比较高的场景时，才会使用强一致性分布式事务解决方案，其他场景下，会采用弱一致性或者最终一致性分布式事务方案来解决数据一致性的问题。
在访问流量不高时，可以将写请求直接路由到MySQL数据库，再通过Canal监听MySQL数据库BinLog的变化，将变化的数据更新到Redis缓存，如图95-1所示。
这种设计下，缓存与数据库的数据就是最终一致的，通过将数据库中的增量变化数据同步到缓存中，通过缓存可以抗更高的并发读操作。但是，此时系统的写操作会受限于数据库磁盘的IO操作。
当访问系统的流量激增时，就需要对写操作进行降级，由先写MySQL数据库，再同步Redis缓存，降级为先写Redis缓存，再异步写MySQL数据库。由Redis的强大读写能力来抗更高的并发流量，如图95-2所示。
# 查看完整文章
加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码
