一 背景

今年的618大促已经如期而至，接下来我会从技术的角度，跟大家聊聊大促备战的底层逻辑和实战方案，希望能够解答大家心中的一些疑惑。

首先，618大促为什么如此重要呢？先从数据的角度简单做一下分析，以下表格罗列了我们历年大促GMV成绩单：

根据以上数据统计，我们可以得出结论：每年的618大促销售额约占全年销售额的10%左右。以2022年618大促销售额为例，大促期间，每分钟的销售额平均高达1463万元。因此，从技术角度来看，保证服务的稳定性是至关重要的。相信这些数据可以为您在大促期间制定任务优先级和做出决策提供有价值的参考。

二 挑战

大促期间系统的稳定性对于业务的正常运营如此重要，我们需要探讨以下问题：

下面我们一起来分析和探讨这些问题。

1. 影响系统稳定性的因素有以下几个方面：

2. 在大促期间，对系统的稳定性要求更高，但与平常对系统的高可用性要求不同。这主要体现在以下几个方面：

3. 接下来将重点围绕备战大促的相关思路和经验进行展开，以帮助您应对挑战并确保系统的稳定性。

三 稳定性保障

以下罗列了今年大促备战的部分措施：





 

上图里展示的各种备战项目，有方向性的指导，有流程上的规范，有落地层面的要求。下面我将从更细粒度的系统执行层面出发，提供一些备战策略。





 

正如前文提到的，大促期间的稳定性保障一般属于应急策略。目的是在保证系统稳定性的前提下，对问题的快速响应。我们将从应用、存储、运营三个视角，来探讨系统稳定性保障的应急措施。

3.1 应用视角

3.1.1 单元化

单元化部署是将应用拆分成多个独立的单元进行独立部署，有以下好处：

为了保证服务的可靠性，我们需要在备战层面实现异地多活的能力，即要求服务进行异地多机房部署。考虑到异地跨机房调用的网络延时问题（例如北京到上海的往返网络延时大约为12毫秒），黄金交易链路的所有服务都需要本地单元化部署。因此，建议采用本地单元化优先的部署架构，并与其他异地单元化互为灾备。

另外，也要注意流量负载均衡策略，防止出现分组的调用流量不均衡，造成部分分组因流量倾斜，导致性能表现不佳的情况出现；

3.1.2 监控预警

预防和发现问题的最直接方式，需要关注以下几个方面：

3.1.3 日志打印

日志格式、日志级别、输出方式，归档策略，序列化方式，traceId策略等都需要进行合理设置，特别要限制重复日志和无效日志的输出，减少日志对机器资源的占用。比如：业务异常堆栈日志不建议直接打印，通过状态码统计结果就可以了；

3.1.4 快速失败

能够快速地检测和响应故障，帮助服务更快地恢复正常状态，从而提高系统的可用性和稳定性。实现快速失败，常见的技术手段如下：

总之，快速失败可以保护系统资源的合理分配，避免出现资源调度阻塞甚至全盘崩溃情况发生，是稳定性保证的重要手段。

3.1.5 服务限流

限流一定是基于系统的承载能力来进行的，整个服务调用链路上，遵循木桶原理，下面给出一些建议：

3.1.6 业务降级

通常情况下，降级策略是一种防御性的应对措施，用于应对可预见的风险。这种策略可能会牺牲部分非核心能力，以确保业务的基本可用性。随着业务不断迭代，需要时刻关注之前的降级策略是否仍然适用，特别是在多人协作的系统中。

3.2 存储视角

下面从存储视角来看看稳定性保障方面的一些思路。

3.2.1 数据库

主从架构：这是最常见的数据库实例部署架构模式，目的是保证核心数据的高可用，防止出现单机故障，导致数据丢失的情况发生；

读写分离：对于大部分实时性要求不高的场景，可以将从库资源充分利用起来的，按照业务场景，实现写主库，读从库的架构模式；

事务隔离：MySQL默认的事务隔离级别是RR，但对于大部分应用场景，特别实在写频繁的场景，将隔离级别设置为RC级别，也能够提高数据库吞吐量；

分库分表：这里不是要求大促前进行数据库架构升级，而是说在大促期间，可以进一步将数据进行更细粒度的迁移，比如启动冷热数据的迁移任务；

慢查询：提前做好索引优化，比较重的查询，提前进行降级屏蔽，做好监控预警；

3.2.2 缓存

一主多从：核心数据需要关注部署架构的合理性，目的是保证核心数据的高可用，防止出现单机故障，导致数据丢失的情况发生；

能力扩容：缓存是否需要扩容，主要考虑两个因素，存储空间上限和IO流量上限。在达到上限之前，及时增加分片来提高容量上限；

主从双读：缓存主从部署架构的模式下，从分片也可以用来承接部分业务压力；

热点数据：热点数据需要及时消灭，否则容易引起节点性能的急剧下降，高版本的缓存客户端已经支持了热点数据的识别，并实现了热点数据进行本地缓存的优化；

大key问题：大key同样会导致集群性能的稳定性问题，核心业务需要考虑风险隔离，避免多条业务线公用一个缓存集群，尽量做到集群隔离；

3.2.3 Elasticsearch

双集群：ES虽然拥有数据容灾的能力，但在压力大的情况下，能够优化的空间有限，另一方面，集群节点故障的时候，分片再平衡也可能会影响可用率，所以重要的业务建议做双集群进行能力冗余互备；

慢请求：有时候慢请求会导致整个集群卡住，类似关系型数据库中出现锁库的场景。那么我们可以通过查询集群中的慢请求任务，若有必要可取消，以释放资源；

写控速：大量的写请求会比较影响查询性能，有时候可以适当的限制写速度，来保证集群查询的稳定性；

存储容量：集群对存储容量默认有根据不同的水位线进行保护，若超过水位线则无法再提供写入特性。需要监视集群存储占用情况，亦可根据实际服务器存储配置调高水位线；

3.3 运营视角

千里之行始于足下，再好的预案都需要贯彻执行到位，否则只能事倍功半。下面给出一些运营保障措施。

3.3.1 备战小组

站在系统或团队内看问题往往是有视野盲区的，还需要有站在更高维度看问题的视角，这就是备战小组。准则就是：及时响应、效率第一。从问题的发现、影响范围的控制、解决方案的推进到流程规范的执行，备战小组都扮演着不可或缺的角色。

3.3.2 军演压测

这需要协调上下游相关部门，组织协调成本很高，旨在模拟真实线上流量，以进行系统稳定性的压力测试。这是应用维度，稳定性保障预案的数据指标基础，如：监控指标，熔点阈值、限流阈值和机器扩容数等。

3.3.3 技术封版

上线封版，听起来往往让人难以理解，难道大促期间我们就不上线了吗？据统计，70%的线上问题是由于改动发版导致，大促期间，业务需求让步于系统稳定性保障，也是再三权衡的结果。

3.3.4 每日巡检/假期值班

作为系统自动巡检的补充，对系统定时定点的进行可用性检查。其目的是及时发现问题，降低异常影响范围。

3.3.5 应急预案

这是出现问题后的备用计划，备战是为了避免问题的发生，但如果问题真的出现了，应急预案将成为我们最后一道防线。关于应急预案相关的要求和操作，参照下图：



四 总结

本文从技术角度深入分析了大促备战的背景和重要性，重点介绍了备战期间稳定性保障的相关措施，包括具体的指导方向和落地细节。本文旨在回顾和梳理备战期间的关键步骤，以帮助我们更加从容的应对系统稳定性的挑战。虽然大促备战是一场紧急行动，但备战的效果离不开平时的协作共识和技术积累，过往的经验和教训，在此刻将得到充分验证。

 

作者：京东零售  刘慧卿

内容来源：京东云开发者社区