1、Cache住所有查询，两层cache
除了使用ckv做全量缓存，还在数据访问层dao中增加本机内存cache做二级缓存，cache住所有读哀求。
查询失败或者查询不存在时，降级内存cache；内存cache查询失败或纪录不存在时降级DB。
DB自己不做读写分离。
2、DB写同步cache，容忍少量不一致， DB写使用完成后，dao中同步内存cache，业务服务层同步ckv，失败由异队伍列补偿，
定时的ckv与DB备机对账，保证终极数据一致。
高并发
微信红包的并发挑战，紧张在于微信大群，多人同时抢同一个红包。
以上这种情况，存在竞争MySQL行锁。为了控制这种并发，团队做了以下一些事变：
1、哀求按红包订单路由，逻辑块垂直sticky，事件隔离
按红包订单分别逻辑单位，单位内业务闭环。服务rpc调用时，使用红包订单号的hash值为key探求下一跳地址。对同一个红包的所有拆哀求、查询哀求，都路由到同一台逻辑呆板、同一台DB中处理。
2、Dao搭建本机Memcache内存cache，控制同一红包并发个数
在DB的接入机dao中，搭建本机内存cache。以红包订单号为key，对同一个红包的拆哀求做原子计数，控制同一时候能进DB中拆红包的并发哀求数。
这个计谋的实施，依赖于哀求路由按红包订单hash值走，确保同一红包的所有哀求路由到同一逻辑层呆板。
3、多层级并发量控制
1）发红包控制
发红包是业务流程的入口，控制了这里的并发量，代表着控制了红包业务整体的并发量。在发红包的业务链路里，做了多层的流量控制，确保产生的有用红包量级在可控范围。
2）抢红包控制
微信红包领取时分为两个步骤，抢和拆。
抢红包这个动作自己就有控制拆并发的作用。因为抢红包时，只必要查cache中的数据，不必要哀求DB。
对于红包已经领完、用户已经领过、红包已颠末期等流量可以直接拦截。而对于有资格进入拆红包的哀求量，也做流量控制。通过这些处理，最后可进入拆环节的流量大大减少，并且都是有用哀求。
3）拆时内存cache控制
针对同一个红包并发拆的控制，上面的文章已介绍。
4、DB简化和拆分
DB的并发本领，有很多影响因素。红包体系结合红包使用情境，举行了一些优化。比较有借鉴意义的，紧张有以下两点：
1）订单表只存关键字段，其他字段只在cache中存储，可柔性。
红包详情的展示中，除了订单关键信息（用户、单号、金额、时间、状态）外，还有用户头像、昵称、祝福语等字段。这些字段对交易来说不是关键信息，却占据大量的存储空间。
将这些非关键信息拆出来，只存在cache，用户查询展示，而订单中不落地。
如许可以维持订单的轻量高效，同时cache不命中时，又可从实时接口中查询补偿，达到优化订单DB容量的效果。
2）DB双重纬度分库表，冷热分离
使用订单hash、订单日期，两个纬度分库表，也即db_xxx.t_x_dd如许的格式。
此中，x表示订单hash值，dd表示01-31循环日。
订单hash纬度，是为了将订单打散到差别的DB服务器中，均衡压力。
订单日期循环日纬度，是为了避免单表数据无穷扩张，使每天都是一张空表。
别的，红包的订单访问热度，是非常典范的冷热型。
热数据集中在一两天内，且随时间急剧消减。
线上热数据库只必要存几天的数据，其他数据可以定时移到本钱低的冷数据库中。
循环日表也使得汗青数据的迁徙变得方便。
红包算法
首先，如果红包只有一个，本轮直接使用全部金额，确保红包发完。
然后，盘算出本轮红包最少要领取多少，才华保证红包领完，即本轮下水位；轮最多领取多少，才华保证每个人都领到，即本轮上水位。紧张方式如下：
盘算本轮红包金额下水位：假设本轮领到最小值1分，那接下来每次都领到200元红包能领完，那下水位为1分；如果不能领完，那按接下来每次都领200元，剩下的本轮应全部领走，是本轮的下水位。
盘算本轮红包上水位：假设本轮领200元，剩下的钱还足够接下来每轮领1分钱，那本轮上水位为200元；如果已经不敷领，那按接下来每轮领1分，盘算本轮的上水位。
为了使红包金额不要太悬殊，使用红包均值调整上水位。如果上水位金额大于两倍红包均值，那么使用两倍红包均值作为上水位。换句话说，每一轮抢到的红包金额，最高为两倍剩下红包的均值。
最后，获取随机数并用上水位取余，如果结果比下水位还小，则直接使用下水位，否则使用随机金额为本轮拆到金额。
柔性降级方案
体系到处存在发生异常的可能，必要对所有的环节做好应对的预案。
下面列举微信红包对体系异常的紧张降级考虑。
1、 下单cache故障降级DB
下单cache有两个作用，生成红包订单与订单缓存。
缓存故障情况下，降级为直接落地DB，并使用id生成器独立生成订单号。
2、 抢时cache故障降级DB
抢红包时，查询cache，拦截红包已经抢完、用户已经抢过、红包已颠末期等无效哀求。当cache故障时，降级DB查询，同时打开DB限流保护开关，防止DB压力过大导致服务不可用。
别的，cache故障降级DB时，DB不存储用户头像、用户昵称等（上文提到的优化），此时一并降级为实时接口查询。查询失败，继承降级为展示默认头像与昵称。
3、 拆时资金入账多级柔性
拆红包时，DB纪录拆红包单据，然后执行资金转账。单据必要实时落地，而资金转账，这里做了多个层级的柔性降级方案：
大额红包实时转账，小额红包入队列异步转账 所有红包进队列异步转账 实时流程不执行转账，事后凭单据批量入账。
总之，单据落地后，真实入账可实时、可异步，终极保证一致即可。
4、 用户列表降级
用户列表数据在微信红包体系中，属于非关键路径信息，属于可被降级部分。
首先，写入时通过MQ异步写，通过定时对账保证一致性。
其次，cache中只缓存两屏，用户查询凌驾两屏则查用户列表DB。在体系压力大的情况下，可以限制用户只查两屏。
调整后的体系颠末了2016年春节的实践检验，平稳地度过了除夕业务高峰，保障了红包用户的体验。
上文参考泉源：架构说公众号，作者：方乐明
方乐明，2011年结业于华南理工大学通讯与信息体系专业，结业后就职于财付通科技有限公司。微信付出团队组建后，紧张负责微信红包、微信转账、AA收款等付出应用产品的后台架构。
360w QPS 100亿级 字节红包 体系架构
1. 背景&挑战&目标
1.1 业务背景
（1）支持八端：
2022 年字节系产品春节活动必要支持八端 APP 产品（包罗抖音/抖音火山/抖音极速版/西瓜/头条/头条极速版/番茄小说/番茄畅听）的嘉奖互通。用户在上述恣意一端都可以参与活动，得到的嘉奖在其他端都可以提现与使用。
（2）玩法多变：
紧张有集卡、朋友页红包雨、红包雨、集卡开奖与烟火大会等。
（3）多种嘉奖：
嘉奖范例包罗现金红包、补贴视频红包、商业化广告券、电商券、付出券、消费金融券、保险券、信用卡优惠券、喜茶券、影戏票券、dou+券、抖音文创券、头像挂件等。
1.2 焦点挑战
（1）超高吞吐，超大并发，最高预估 360w QPS 发奖。
（2）嘉奖范例多，共 10 余种嘉奖。多种发嘉奖的场景，玩法多变；
（3）从嘉奖体系稳定性、用户体验、资金安全与运营基础本领全方位保障，确保活动顺遂举行 。
1.3 终极目标
（1）嘉奖入账：数据高可靠。提供统一的错误处理机制，入账幂等本领和嘉奖预算控制。
（2）**嘉奖展示/使用：**支持用户查看、提现（现金），使用卡券/挂件等本领。
（3）稳定性保障：在大流量的入账场景下，保证钱包焦点路径稳定性与美满，通过常用稳定性保障手段如资源扩容、限流、熔断、降级、兜底、资源隔离等方式保证用户嘉奖方向的焦点体验。
（4）资金安全：通过幂等、对账、监控与报警等机制，保证资金安全，保证用户资产应发尽发，不少发。
（5）活动隔离：实现内部测试、灰度放量和正式春节活动三个阶段的嘉奖入账与展示的数据隔离，不互相影响。
2. 产品需求介绍
用户可以在恣意一端参与字节的春节活动获取嘉奖，以抖音红包雨现金红包入账场景为例，具体的业务流程如下：
登录抖音 → 参与活动 → 活动钱包页 → 点击提现按钮 → 进入提现页面 → 举行提现 → 提现结果页，
别的从钱包页也可以进入活动钱包页。
嘉奖发放焦点场景：
- 集卡：集卡抽卡时发放各类卡券，集卡锦鲤还会发放大额现金红包，集卡开奖时发放瓜分奖金和优惠券；
- 红包雨：发红包、卡券以及视频补贴红包，此中红包和卡券最高分别 180w QPS；
3. 钱包资产中台设计与实现
在 2022 年春节活动中，业务方分为：
UG、激励中台、视频红包、钱包方向、资产中台等
此中，UG 紧张负责活动的玩法实现，包罗集卡、红包雨以及烟火大会等具体的活动相干业务逻辑和稳定性保障。
而钱包方向定位是大流量场景下实现嘉奖入账、嘉奖展示、嘉奖使用与资金安全保障的相干任务。
此中资产中台负责嘉奖发放与嘉奖展示部分。
3.1 春节资产资产中台总体架构图如下：
钱包资产中台焦点体系分别如下：
收敛八端嘉奖入账链路，
提供统一的接口协议，对接上游活动业务方的嘉奖发放功能，
同时，支持预算控制、补偿、订单号幂等。
2. 活动钱包 api 层：
统一嘉奖展示链路，同时支持大流量场景
3.2 资产订单中心设计
焦点发放模型：
说明：
活动 ID 唯一区分一个活动，
本次春节分配了一个单独的母活动 ID
场景 ID 和具体的一种嘉奖范例一一对应，
定义该场景下发嘉奖的唯一配置，
场景 ID 可以配置的本领有：
- 发嘉奖账单文案；
- 是否必要补偿；
- 限流配置；
- 是否举行库存控制；
- 是否要举行对账。
- 提供可插拔的本领，供业务可选接入。
订单号设计：
资产订单层支持订单号维度的发奖幂等，订单号设计逻辑为
${actID}_${scene_id}_${rain_id}_${award_type}_${statge}
从单号设计层面保证不超发，每个场景的嘉奖用户最多只领一次。
4. 焦点难点问题解决
4.1 难点一：支持八端嘉奖数据互通
有八个产品端，必要统一对接，
此中抖音系和头条系 APP 是差别的账号体系，所以不能通过用户 ID 打通嘉奖互通。
具体解决方案是：
- 给每个用户生成唯一的 actID
- 手机号优先级最高，如果差别端登录的手机号一样，在差别端的 actID 是一致的。
在唯一 actID 基础上，每个用户的嘉奖数据是绑定在 actID 上的，入账和查询是通过 actID 维度实现的，即可实现八端嘉奖互通。
示意图如下：
4.2 难点二：高场景下的嘉奖入账实现
超高并发场景，发现金红包都是最关键的一环。有几个缘故原由如下：
- 预估发现金红包最大流量有 180w TPS。
- 现金红包自己价值高，必要保证资金安全。
- 用户对现金的敏感度很高，在保证用户体验与功能完整性同时也要考虑本钱问题。
终上所述，发现金红包面对比较大的技术挑战。
发红包其实是一种交易举动，资金流走向是从公司本钱出然后进入个人账户。
（1）从技术方案上是要支持订单号维度的幂等，同一订单号多次哀求只入账一次。订单号生成逻辑为
${actID}_${scene_id}_${rain_id}_${award_type}_${statge}
从单号设计层面保证不超发。
（2）支持高并发，有以下 2 个传统方案：
具体方案范例实现思路优点缺点同步入账申请和预估流量类似的盘算和存储资源1.开发简单； 2.不轻易堕落；浪费存储本钱。 拿账户数据库举例，经实际压测结果：支持 30w 发红包必要 152 个数据库实例，如果支持 180w 发红包，至少必要 1152 个数据库实例，还没有算上 tce 和 redis 等其他盘算和存储资源。异步入账申请部分盘算和存储资源资源，实际入账本领与预估有肯定差值1.开发简单； 2.不轻易堕落； 3.不浪费资源；用户体验受到很大影响。 入账延迟较大，以本年活动举例会有十几分钟延迟。用户参与玩法得到嘉奖后在活动钱包页看不到嘉奖，也无法举行提现，会有大量客诉，影响抖音活动的效果。 以上两种传统意义上的技术方案都有显着的缺点，
那么举行思考，既能相对节省资源又能保证用户体验的方案是什么？
终极采用的是红包雨 token 方案，具体方案是：
使用异步入账加较少量分布式存储和较复杂方案来实现，
下面具体介绍一下。
4.2.1 红包雨 token 方案：
根据预估发放红包估算，红包雨 token 方案, 盘算实际入账最低要支持的 TPS 为 30w，所以实际发放中有压单的过程。
设计目标：
在活动预估给用户发放（180w）与实际入账（30w）有很大 gap 的情况下，保证用户的焦点体验。
用户在前端页面查看与使用过当中不能感知压单的过程，即查看与使用体验不能受到影响，相干展示的数据包罗余额，累计收入与红包流水，使用包罗提现等。
具体设计方案：
我们在大流量场景下每次给用户发红包会生成一个加密 token（使用非对称加密，包罗发红包的元信息：红包金额，actID，与发放时间等），
分别存储在客户端和服务端（容灾互备），每个用户有个 token 列表。
每次发红包的时间会在 Redis 里纪录该 token 的入账状态，
然后用户在活动钱包页看到的现金红包流水、余额等数据，是归并已入账红包列表+token 列表-已入账/入账中 token 列表的结果。
同时为保证用户提现体验不感知红包压单流程，
在进入提现页或者点击提现时，将未入账的 token 列表举行强制入账，
保证用户提现时账户的余额为应入账总金额，不 block 用户提现流程。
示意图如下：
token 数据结构：
token 使用的是 protobuf 格式，
经单测验证存储斲丧实际比使用 json 少了一倍，节省哀求网络的带宽和存储本钱；
同时序列化与反序列化斲丧 cpu 也有低沉。
- // 红包雨token结构
- type RedPacketToken struct {
- AppID int64 `protobuf: varint,1,opt json: AppID,omitempty ` // 端ID
- ActID int64 `protobuf: varint,2,opt json: UserID,omitempty ` // ActID
- ActivityID string `protobuf: bytes,3,opt json: ActivityID,omitempty ` // 活动ID
- SceneID string `protobuf: bytes,4,opt json: SceneID,omitempty ` // 场景ID
- Amount int64 `protobuf: varint,5,opt json: Amount,omitempty ` // 红包金额
- OutTradeNo string `protobuf: bytes,6,opt json: OutTradeNo,omitempty ` // 订单号
- OpenTime int64 `protobuf: varint,7,opt json: OpenTime,omitempty ` // 开奖时间
- RainID int32 `protobuf: varint,8,opt,name=rainID json: rainID,omitempty ` // 红包雨ID
- Status int64 `protobuf: varint,9,opt,name=status json: status,omitempty ` //入账状态
- }
采用非对称加密算法，保障存储在的客户端尽可能不被破解。
如果 token 加密算法被黑产破译，可监控报警发现，可降级。
4.3 难点三：发嘉奖链路依赖多的稳定性保障
发红包流程降级示意图如下：
根据汗青经验，实现的功能越复杂，依赖会变多，对应的稳定性风险就越高，那么怎样保证高依赖的体系稳定性呢？
解决方案：
现金红包入账最基础要保障的功能，
是将用户得到的红包举行入账，
焦点的功能，必要支持幂等与预算控制（避免超发），
红包账户的幂等设计强依赖数据库保持事件一致性。
但是如果非常情况发生，中间的链路可能会出现问题，如果是弱依赖，必要支持降级掉，不影响发放主流程。
钱包方向发红包最短路径为依赖服务实例盘算资源和 MySQL 存储资源实现现金红包入账。
发红包强弱依赖梳理图示：
psm依赖服务是否强依赖降级方案降级后影响资产中台tcc是降级读本地缓存无bytkekv否主动降级开关，跳过 bytekv，依赖下游做幂等无资金交易层分布式锁 Redis否被动降级，调用失败，直接跳过根本无token Redis否主动降级开关，不调用 Redis用户能感知到入账有延迟，会有很多客诉MySQL是主有问题，联系 dba 切主故障期间发红包不可用 4.4 难点四：大流量发卡券预算控制
大流量集中发券的一个场景，钱包侧与算法计谋配合举行卡券发放库存控制，防止超发。
具体实现：
（1）钱包资产中台维护每个卡券模板 ID 的斲丧发放量。
（2）每次卡券发放前，读取该卡券模板 ID 的斲丧量以及总库存数。同时会设置一个阈值，如果卡券剩余量小于 10%后不发这个券（使用兜底券或者祝福语举行兜底）。
（3） 发券流程 累计每个券模板 ID 的斲丧量（使用 Redis incr 命令原子累加斲丧量），然后与总活动库存举行比对，如果斲丧量大于总库存数则拒绝掉，防止超发，也是一个兜底流程。
具体流程图：
优化方向：
（1）大流量下使用 Redis 计数，单 key 会存在热 key 问题，必要拆分 key 来解决。
（2）大流量场景下，使用 Redis 会存在超时问题，返回上游处理中，上游继承重试发券，会多斲丧库存少发，本次春节活动实际活动库存在预估库存基础上加了 5%的量级来缓解超时带来的少发问题。
4.5 难点五：高 QPS 场景下的热 key 的读取和写入稳定性保障
最大流量预估读取有 180wQPS，写入 30wQPS。
这是典范的超大流量，热门 key、更新延迟不敏感，非数据强一致性场景（数字是一直累加），
同时要做好容灾降级处理，最后实际活动展示的金额与产品预计发放数值误差小于 1%。
4.5.1 方案一
高 QPS 下的读取和写入单 key，比较轻易想到的是使用 Redis 分布式缓存来举行实现，但是单 key 读取和写入的会打到一个实例上，压测过单实例的瓶颈为 3w QPS。
所以做的一个优化是拆分多个 key，然后用本地缓存兜底。
具体写入流程：
设计拆分 100 个 key，每次发红包根据哀求的 actID%100 使用 incr 命令累加该数字，因为不能保证幂等性，所以超时不重试。
读取流程：
与写入流程类似，优先读取本地缓存，
如果本地缓存值为为 0，那么去读取各个 Redis 的 key 值累加到一起，举行返回。
问题：
（1）拆分 100 个 key 会出现读扩散的问题，必要申请较多 Redis 资源，存储本钱比较高。
而且可能存在读取超时问题，不能保证一次读取所有 key 都读取成功，故返回的结果可能会较上一次有减少。
（2）容灾方案方面，如果申请备份 Redis，也必要较多的存储资源，必要的额外存储本钱。
4.5.2 方案二
设计思路：
在方案一实现的基础上举行优化，
在写场景，通过本地缓存举行归并写哀求，举行原子性累加，
读场景返回本地缓存的值，减少额外的存储资源占用。
使用 Redis 实现中心化存储，终极大家读到的值都是一样的。
具体设计方案：
每个 docker 实例启动时都会执行定时任务，分为读 Redis 任务和写 Redis 任务。
读取流程：
读取 Redis 单 key 的值，如果获取到的值大于本地缓存那么更新本地缓存的值。
2. 对外袒露的 sdk 直接返回本地缓存的值即可。
3. 有个问题必要留意下，每次实例启动第一秒内是没有数据的，所以会壅闭读，等有数据再返回。
写入流程：
- 因为读取都是读取本地缓存（本地缓存不过期），所以处理好并发情况下的写即可。
- 本地缓存写变量使用 go 的 atomic.AddInt64 支持原子性累加本地写缓存的值。
- 每次执行更新 Redis 的定时任务，
先将本地写缓存复制到 amount 变量，最后将 amount 的值 incr 到 Redis 单 key 上，实现 Redis 的单 key 的值一直累加。
4. 容灾方案是使用备份 Redis 集群，写入时举行双写，
一旦主机群挂掉，设计了一个配置开关支持读取备份 Redis。两个 Redis 集群的数据一致性，通过定时任务兜底实现。
具体写入流程图如下：
本方案调用 Redis 的流量是跟实例数成正比，
经调研读取侧的服务为主会场实例数 2 万个，写入侧服务为资产中台实例数 8 千个，
所以实际 Redis 要支持的 QPS 为 2.8 万/定时任务执行间隔（单位为 s），
经压测验证 Redis 单实例可以支持单 key2 万 get，8k incr 的使用，
所以设置定时任务的执行时间间隔是 1s，如果实例数更多可以考虑延伸执行时间间隔。
4.5.3 方案对比
优点缺点方案一1. 实现本钱简单1. 浪费存储资源； 2. 难以做容灾； 3. 不能做到一直累加；方案二1. 节省资源； 2. 容灾方案比较简单，同时也节省资源本钱；1. 实现稍复杂，必要考虑好并发原子性累加问题 结论：
从实现效果，资源本钱和容灾等方面考虑，终极选择了方案二上线。
4.6 难点六：大流量场景下资金安全保障
钱包方向在本次春节活动期间做了三件事变来保障大流量大预算的现金红包发放的资金安全：
- 现金红包发放整体预算控制的拦截
- 单笔现金红包发放金额上限的拦截
- 大流量发红包场景的资金对账
- 小时级别对账：支持红包雨/集卡/烟火红包发放 h+1 小时级对账，并针对部分场景设置兜底 h+2 核对。
- 准实时对账：红包雨已入账的红包数据反查钱包资产中台和活动侧做准实时对账
多维度核对示意图：
准实时对账流程图：
说明：
准实时对账监控和报警可以及时发现是否异常入账情况，如果报警发现会有告急预案处理。
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.2 微服务思考
在日常技术设计中，大家都会服从微服务设计原则和规范，根据体系职责和焦点数据模型拆分差别模块，提拔开发迭代效率并不互相影响。
但是微服务也有它的弊端，对于超大流量的场景功能也比较复杂，会颠末多个链路，如许是极其斲丧盘算资源的。
本次春节活动资产中台提供了 sdk 包取代 rpc 举行微服务链路聚合对外提供基础本领，如查询余额、判定用户是否获取过嘉奖，强制入账等功能。访问流量最高上万万，与使用微服务架构对比节省了上万核 CPU 的盘算资源。
6. 体系的未来演进方向
（1）梳理上下游需求和痛点，优化资产中台设计实现，美满基础本领，优化服务架构，提供一站式服务，让接入活动方可以更专注举行活动业务逻辑的研发工作。
（2）加强实时和离线数据看板本领建立，让嘉奖发放数据展示的更清楚更准确。
（3）加强配置化和文档建立，对内减少对接活动的对接本钱，对外提拔活动业务方接入效率。
上文参考泉源：字节跳动技术团队：春节钱包大流量嘉奖体系入账及展示的设计与实现
保举阅读：
《Docker面试题（史上最全 + 连续更新）》
《 场景题：假设10W人突访，你的体系怎样做到不 雪崩？》
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
