Architect's Diary - Revealing the Mystery of E-commerce Promotion Preparation from a Technical Perspective

Yuan Chuanghui, offline restart! July 1, 2023 Shenzhen Station - Basic software technology interview! Early bird tickets are available for a limited time only!

1. Background

This year's 618 promotion has arrived as scheduled. Next, I will talk to you about the underlying logic and actual combat , hoping to answer some doubts in your mind.

First of all, why is the 618 promotion so important? Let’s start with a simple analysis from the perspective of data. The following table lists the GMV transcripts of our major promotions over the years:

years	618 sales (100 million yuan)	Annual sales (100 million yuan)	618 Sales Proportion
2022	3793	33155	11.4%
2021	3439	32970	10.4%
2020	2694	26125	10.3%
2019	2017	20854	9.7%
2018	1592	16769	9.5%

Based on the statistics above, we can draw a conclusion: the annual 618 sales promotion accounts for about 10% of the annual sales. Take the 2022 6.18 sales promotion as an example. During the promotion period, the average sales per minute reached 14.63 million yuan. Therefore, from a technical point of view, it is crucial to ensure the stability of the service. We believe that these data can provide valuable reference for you to prioritize tasks and make decisions during the promotion period.

2. Challenge

The stability of the system during the promotion period is so important to the normal operation of the business, we need to discuss the following issues:

• What are the factors affecting system stability?
• What is the difference between stability requirements and daily high availability requirements for the system?
• In the face of various unstable factors, how should we deal with them?

Let's analyze and discuss these issues together.

1. Factors affecting system stability include the following aspects:

• Traffic size : During the big promotion period, the traffic is often several times or even dozens of times the usual, which puts forward extremely high requirements on the stability of the system. A small problem will often turn into a big problem after the traffic is enlarged;
• Large amount of data : Taking the order in 2022 as an example, the order amount reached 3.4 trillion. In the scenario of massive order data, a simple query will become very challenging;
• The scene is complex : the superposition of various marketing methods such as various promotional offers, platforms, merchants, operations, etc., makes the order production link always in a high-load computing state;
• Long delivery link : Flow distribution at each end, promotion calculation, vehicle addition, settlement, bill of lading, payment, logistics distribution, customer service, after-sales and other process nodes need to be stable. If a service has a 99.9% availability rate, then the combination of 100 related service nodes can only reach 99.5% availability rate, and the unavailability of 0.5% corresponds to a large number of order losses;
• Low tolerance : Consumers require a good user experience, merchants need promotions to take effect quickly, and platforms need to reduce errors and asset losses to protect the interests of consumers and merchants. Higher expectations and concerns lead to lower patience and tolerance;

2. During the promotion period, the requirements for system stability are higher, but it is different from the usual high availability requirements for the system. This is mainly reflected in the following aspects:

• Time is tight : during the promotion period, the stability of the service needs to be guaranteed in a short period of time, and there is usually no time to go into technical details;
• Different perspectives : Stability focuses on the overall business effect, while high availability focuses on service response results;
• Different dimensions : The guarantee of business stability is usually based on the high availability of the system, and cooperates with related service operation strategies to achieve higher-dimensional business stability.

3. Next, we will focus on the relevant ideas and experience of preparing for the big promotion, so as to help you meet the challenges and ensure the stability of the system.

3. Stability Guarantee

Some of the measures to prepare for this year's promotion are listed below:

 The various preparation projects shown in the picture above have directional guidance, process specifications, and implementation-level requirements. Next, I will start from a more fine-grained system execution level and provide some preparation strategies.

 As mentioned above, the stability guarantee during the promotion period is generally an emergency strategy. The purpose is to respond quickly to problems under the premise of ensuring system stability. We will discuss emergency measures to ensure system stability from three perspectives: application, storage, and operation.

3.1 Application Perspective

3.1.1 Unitization

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

• 降低整个应用因某个单元故障而导致服务中断的风险；
• 降低故障排查的难度，因为可以快速定位出问题的单元并进行修复；
• 每个单元都可以独立维护和升级，这样可以降低整个应用因某个单元升级或维护而导致服务中断的风险；
• 每个单元都可以独立扩展和缩减，这样可以根据实际需求动态调整应用的规模。

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

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

3.1.2 监控预警

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

• 监控粒度方面：监控按照层级分为底层中间件监控、依赖RPC监控、方法监控、机器监控、系统监控、业务监控、流程监控、整体的大盘监控；
• 监控的灵敏度问题。灵敏度过低会导致部分问题被延时暴露甚至被隐藏，而灵敏度过高则会造成信息爆炸，难以分辨信息的主次。因此，在实施监控前需要提前做好功课，确定合适的灵敏度；
• 监控的覆盖度方面：关注监控服务单元、监控指标梳理、监控触达方法。比如：监控需要覆盖容器数、资源指标、运行环境（JVM、线程池）、流量大小、限流值、上下游依赖、超时时长、异常日志、数据容量、模型规模、特征数量等，并可以进行时间维度的纵向对比；
• 监控的准确性方面：看可用率，需要看上游调用方的，可能200ms响应时长，对于调用方来说，已经属于不可用的区间了。看CPU繁忙程度，不能只盯着利用率，还要结合容器核数和CPU负载来分析；
• 预警解除方面：接到预警消息，及时排查并处理风险，切不可将小问题演变成大问题。先确认是单机硬件或网络问题，还是集群通用问题，如果是通用问题，能否通过服务调用链追踪技术快速定位问题点，确认好问题原因，才能做好应对预案；

3.1.3 日志打印

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

3.1.4 快速失败

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

• 线程池超时时间的设置，关键系统要拥有动态调整线程池运行参数的能力；
• 利用好工具已有的能力，比如：JSF，JimDB，JMQ等中间件也都支持超时失败的动态调整能力；
• 服务限流也是快速失败的一种实现策略，常见的微服务框架和物理网关一般也都支持类似功能；

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

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 应急预案

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

四、总结

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

-end-

本文分享自微信公众号 - 京东云开发者（JDT_Developers）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

{{o.name}}

{{m.name}}