准实时对账流程图：
说明：
准实时对账监控和报警可以及时发现是否异常入账情况，如果报警发现会有紧急预案处理。
5. 通用模式抽象在经历过春节超大流量活动后的设计与实现后，有一些总结和经验与大家一起分享一下。
5.1 容灾降级层面大流量场景，为了保证活动最终上线效果，容灾是一定要做好的。参考业界通用实现方案，如降级、限流、熔断、资源隔离，根据预估活动参与人数和效果进行使用存储预估等。
5.1.1 限流层面（1）限流方面应用了 api 层 nginx 入流量限流，分布式入流量限流，分布式出流量限流。这几个限流器都是字节跳动公司层面公共的中间件，经过大流量的验证。
（2）首先进行了实际单实例压测，根据单实例扛住的流量与本次春节活动预估流量打到该服务的流量进行扩容，并结合下游能抗住的情况，在 tlb 入流量、入流量限流以及出流量限流分别做好了详细完整的配置并同。
限流目标：
保证自身服务稳定性，防止外部预期外流量把本身服务打垮，防止造成雪崩效应，保证核心业务和用户核心体验。
简单集群限流是实例维度的限流，每个实例限流的 QPS=总配置限流 QPS/实例数，对于多机器低 QPS 可能会有不准的情况，要经过实际压测并且及时调整配置值。
对于分布式入流量和出流量限流，两种使用方式如下，每种方式都支持高低 QPS，区别只是 SDK 使用方式和功能不同。一般低 QPS 精度要求高，采用 redis 计数方式，使用方提供自己的 redis 集群。高 QPS 精度要求低，退化为总 QPS/tce 实例数的单实例限流。
5.1.2 降级层面对于高流量场景，每个核心功能都要有对应的降级方案来保证突发情况核心链路的稳定性。
（1）本次春节奖励入账与活动活动钱包页方向做好了充分的操作预案，一共有 26 个降级开关，关键时刻弃车保帅，防止有单点问题影响核心链路。
（2）以发现金红包链路举例，钱包方向最后完全降级的方案是只依赖 docker 和 MySQL，其他依赖都是可以降级掉的，MySQL 主有问题可以紧急联系切主，虽说最后一个都没用上，但是前提要设计好保证活动的万无一失。
5.1.3 资源隔离层面（1）提升开发效率不重复造轮子。因为钱包资产中台也日常支持抖音资产发放的需求，本次春节活动也复用了现有的接口和代码流程支持发奖。
（2）同时针对本次春节活动，服务层面做了集群隔离，创建专用活动集群，底层存储资源隔离，活动流量和常规流量互不影响。
5.1.4 存储预估（1）不但要考虑和验证了 Redis 或者 MySQL 存储能抗住对应的流量，同时也要按照实际的获取参与和发放数据等预估存储资源是否足够。
（2）对于字节跳动公司的 Redis 组件来讲，可以进行垂直扩容（每个实例增加存储，最大 10G），也可以进行水平扩容（单机房上限是 500 个实例），因为 Redis 是三机房同步的，所以计算存储时只考虑一个机房的存储上限即可。要留足 buffer，因为水平扩容是很慢的一个过程，突发情况遇到存储资源不足只能通过配置开关提前下掉依赖存储，需要提前设计好。
5.1.5 压测层面本次春节活动，钱包奖励入账和活动钱包页做了充分的全链路压测验证，下面是一些经验总结。
- 在压测前要建立好压测整条链路的监控大盘，在压测过程当中及时和方便的发现问题。
- 对于 MySQL 数据库，在红包雨等大流量正式活动开始前，进行小流量压测预热数据库，峰值流量前提前建链，减少正式活动时的大量建链耗时，保证发红包链路数据库层面的稳定性。
- 压测过程当中一定要传压测标，支持全链路识别压测流量做特殊逻辑处理，与线上正常业务互不干扰。
- 压测中要验证计算资源与存储资源是否能抗住预估流量
- 梳理好压测计划，基于历史经验，设置合理初始流量，渐进提升压测流量，实时观察各项压测指标。
- 存储资源压测数据要与线上数据隔离，对于 MySQL 和 Bytekv 这种来讲是建压测表，对于 Redis 和 Abase 这种来讲是压测 key 在线上 key 基础加一下压测前缀标识 。
- 压测数据要及时清理，Redis 和 Abase 这种加短时间的过期时间，过期机制处理比较方便，如果忘记设置过期时间，可以根据写脚本识别压测标前缀去删除。
5. 压测后也要关注存储资源各项指标是否符合预期。
5.2 微服务思考在日常技术设计中，大家都会遵守微服务设计原则和规范，根据系统职责和核心数据模型拆分不同模块，提升开发迭代效率并不互相影响。但是微服务也有它的弊端，对于超大流量的场景功能也比较复杂，会经过多个链路，这样是极其消耗计算资源的。本次春节活动资产中台提供了 sdk 包代替 rpc 进行微服务链路聚合对外提供基础能力，如查询余额、判断用户是否获取过奖励，强制入账等功能。访问流量最高上千万，与使用微服务架构对比节约了上万核 CPU 的计算资源。
6. 系统的未来演进方向（1）梳理上下游需求和痛点，优化资产中台设计实现，完善基础能力，优化服务架构，提供一站式服务，让接入活动方可以更专注进行活动业务逻辑的研发工作。
（2）加强实时和离线数据看板能力建设，让奖励发放数据展示的更清晰更准确。
（3）加强配置化和文档建设，对内减少对接活动的对接成本，对外提升活动业务方接入效率。
