文章目录

- 服务稳定性
- - 82原则
  - 如何衡量系统稳定性？
  - 事故按影响程度不同划分等级
- 如何提高服务稳定性？
- - 一、系统设计规范
  - 二、单服务稳定性
  - 三、集群稳定性
  - 四、稳定性专项
二、场景设计
- 2.1 微博热搜数据设计
- - 2.1.1 Hot Key问题怎么应对？
  - - Hot Key可能引发的问题
    - 极热 key 解决方案
  - 2.1.2 限流问题
  - - 设计一个限流器，满足100w QPS 的限流。
- 2.2 帖子（post）的设计实现与优化
- 2.3 点赞业务如何落地
- 订单表的分库分表方案设计(大数据)
- - b2c平台。订单的卖家就一个，就是平台自己。
  - c2b2c 平台的订单分卖家和买家的时候，选择什么字段来分库分表呢？
  - 微博百亿数据-粉丝关系链如何分库分表
- 冷热数据
- 数据库缓存一致性问题
- 如何设计低延时服务
- 如何在备库（读库）读到最新数据？
- 数据库主从延时问题
- 秒杀架构的思考
- - 常用技术手段
  - 高性能热点优化
  - 服务性能优化
  - 一致性性能优化
  - 高可用
  - 秒杀架构
  - - - 库存服务被调用超时怎么办？
    - 缓存数据一致性
    - 缓存命中率问题
    - binlog延迟、并行问题
  - http接口何如防篡改、防重放
  - - 防重放
    - - 阿里云api网关的解决方案
  - 如何在短时间内在一个接口中并发请求多个http链接
  - 10亿个KEY判断某KEY是否存在
- 分布式限流
字节跳动团队：春节钱包大流量奖励系统入账及展示的设计与实现
- 4.4 难点四：大流量发卡券预算控制
- 4.5 难点五：高 QPS 场景下的热 key 的读取和写入稳定性保障
通用场景
- 商品服务多级缓存
- - 本地缓存策略
  - 热点问题
  - 缓存击穿
微博场景
- 大V发动态
- - 读扩散、写扩散优化
B站
- 视频显示在线观看人数是怎么做的？

服务稳定性

82原则

如何衡量系统稳定性？

事故按影响程度不同划分等级

如何提高服务稳定性？

一、系统设计规范

业内喜欢用SLA （服务等级协议，全称：service level agreement）来衡量系统的稳定性，对互联网公司来说就是网站服务可用性的一个保证。9越多代表全年服务可用时间越长服务越可靠，停机时间越短。就以一个标准99.99%为例，停机时间52.6分钟，平均到每周也就是只能有差不多1分钟的停机时间，也就是说网络抖动这个时间可能就没了。保证一个系统四个9或者更高的五个9，需要一套全体共识严格标准的规章制度，没有规矩不成方圆。创建的规范有如下几种：
1、研发规范、自身稳定；

2、事务中不能包含远程调用；

3、超时时间和重试次数要合理；

4、表数据操作必须double check，合理利用索引，避免出现慢查询、分库分表不走分表键；

5、没有有效的资源隔离，避免不同业务共用一个线程池或连接池；

6、合理的系统拓扑，禁止不合理服务依赖，能依赖就依赖，否则同步尽量改成异步弱依赖；

7、精简的代码逻辑；

8、核心路径流程必须进行资源隔离，确保任何突发情况主流程不能受影响。

二、单服务稳定性

关键字：开关可控、单一职责、服务隔离、异常兜底、监控发现！

对于稳定性来说，抛开整体系统架构设计，单就每个业务域服务的稳定性也是非常的重要。只有每个业务环节都稳如泰山，才能保障整个稳定性。单服务稳定可以从以下几个方面来进行：

1、禁用设计：应该提供控制具体功能是否开启可用的配置，在相应的功能服务出现故障时，快速下线局部功能，以保证整体服务的可用性；

2、必要的缓存：缓存是解决并发的利器，可以有效的提高系统的吞吐量。按照业务以及技术的纬度必要时可以增加多级缓存来保证其命中率；

3、接口无状态性：服务接口应是无状态的，当前接口访问不应该依赖上层接口的状态逻辑；

4、接口单一职责性：对于核心功能的接口，不应该过多的耦合不属于它的功能。如果一个接口做的事情太多应做拆分，保证单接口的稳定性和快速响应；

5、第三方服务隔离性：任何依赖于第三方的服务（不论接口还是中间件等），都应该做到熔断和降级，不能有强耦合的依赖；

6、业务场景兜底方案：核心业务场景要做到完整兜底方法，从前端到后端都应有兜底措施；

7、服务监控与及时响应：每个服务应做好对应监控工作，如有异常应及时响应，不应累积。

三、集群稳定性

关键字：系统架构、部署发布、限流熔断、监控体系、压测机制！

对于集群维度的稳定性来说，稳定性保障会更加复杂。单服务是局部，集群是全局。一个见微知著，一个高瞻远瞩。

1、合理的系统架构：合理的系统架构是稳定的基石；

2、小心的代码逻辑：代码时刻都要小心，多担心一点这里会不会有性能问题，那里会不会出现并发，代码就不会有多少问题；

3、优秀的集群部署：一台机器永远会有性能瓶颈，优秀的集群部署，可以将一台机器的稳定放大无限倍，是高并发与大流量的保障；

4、科学的限流熔断：高并发来临时，科学的限流和熔断是系统稳定的必要条件；

5、精细的监控体系：没有监控体系，你永远不会知道你的系统到底有多少隐藏的问题和坑，也很难知道瓶颈在哪里；

6、强悍的压测机制：压测是高并发稳定性的试金石，能提前预知高并发来临时，系统应该出现的模样；

7、胆小的开发人员：永远需要一群胆小的程序员，他们讨厌bug，害怕error，不放过每一个波动，不信任所有的依赖。

四、稳定性专项

专项指的是针对某些特定场景下的特定问题而梳理出对应的方案。下面是针对一些常见的稳定性专项的概述：

1、预案：分为定时预案和紧急预案，定时预案是大促常规操作对于一系列开关的编排，紧急预案是应对突发情况的特殊处理，都依赖于事前梳理；

2、预热：分为JIT代码预热和数据预热，阿里内部有专门的一个产品负责这块，通过存储线上的常态化流量或者热点流量进行回放来提前预热，起源于某年双十一零点的毛刺问题，原因是访问了数据库的冷数据rt增高导致的一系列上层限流，现在预热已经成了大促之前的一个必要流程。

3、强弱依赖:梳理强弱依赖是一个偏人肉的过程，但是非常重要，这是一个系统自查识别潜在风险点并为后续整理开关限流预案和根因分析的一个重要参考，阿里内部有一个强弱依赖检测的平台，通过对测试用例注入RPC调用的延迟或异常来观察链路的依赖变化，自动梳理出强弱依赖关系。

4、限流降级熔断:应对突发流量防止请求超出自身处理能力系统被击垮的必要手段；

5、监控告警&链路追踪:监控分为业务监控、系统监控和中间件监控和基础监控，作为线上问题发现和排查工具，重要性不言而喻。

二、场景设计

2.1 微博热搜数据设计

2.1.1 Hot Key问题怎么应对？

参考：06 Hot Key和Big Key引发的问题怎么应对？

Hot Key可能引发的问题

Hot key。对于大多数互联网系统，数据是分冷热的。比如最近的新闻、新发表的微博被访问的频率最高，而比较久远的之前的新闻、微博被访问的频率就会小很多。而在突发事件发生时，大量用户同时去访问这个突发热点信息，访问这个 Hot key，这个突发热点信息所在的缓存节点就很容易出现过载和卡顿现象，甚至会被 Crash。

Hot key 引发缓存系统异常，主要是因为突发热门事件发生时，超大量的请求访问热点事件对应的 key，比如微博中数十万、数百万的用户同时去吃一个新瓜。数十万的访问请求同一个 key，流量集中打在一个缓存节点机器，这个缓存机器很容易被打到物理网卡、带宽、CPU 的极限，从而导致缓存访问变慢、卡顿。

极热 key 解决方案

引发 Hot key 的业务场景很多，比如明星结婚、离婚、出轨这种特殊突发事件，比如奥运、春节这些重大活动或节日，还比如秒杀、双12、618 等线上促销活动，都很容易出现 Hot key 的情况。

要解决这种极热 key 的问题，首先要找出这些 Hot key 来。Hot key可以分为两种，已知和未知两种。

已知Hot key

对于重要节假日、线上促销活动、集中推送这些提前已知的事情，可以提前评估出可能的预热 key 来。

未知Hot key
对于突发事件，无法提前评估，可以通过 Spark，对应流任务进行实时分析，及时发现新发布的热点 key。
而对于之前已发出的事情，逐步发酵成为热 key 的，则可以通过 Hadoop 对批处理任务离线计算，找出最近历史数据中的高频热 key。

找到热 key 后，就有很多解决办法了。

key打散分片
首先可以将这些热 key 进行分散处理，比如一个热 key 名字叫 hotkey，可以被分散为 hotkey#1、hotkey#2、hotkey#3，……hotkey#n，这 n 个 key 分散存在多个缓存节点，然后 client 端请求时，随机访问其中某个后缀的 hotkey，这样就可以把热 key 的请求打散，避免一个缓存节点过载。

多级缓存架构
其次，也可以 key 的名字不变，对缓存提前进行多副本+多级结合的缓存架构设计。
缓存实例实时扩容
再次，如果热 key 较多，还可以通过监控体系对缓存的 SLA 实时监控，通过快速扩容来减少热 key 的冲击。
本地缓存
业务端还可以使用本地缓存，将这些热 key 记录在本地缓存，来减少对远程缓存的冲击。

2.1.2 限流问题

设计一个限流器，满足100w QPS 的限流。

令牌桶。100w的计数器，然后每次请求去获取令牌，拿到就请求，拿不到就丢弃或者等待，等待超时就丢弃。
然后面试官问怎么实现？我回答了，然后不满足他的要求，让我继续优化。

然后我说在代理层面做，他说不一定能抗住这么大的请求量，你的处理延时怎么处理。
然后我说分发在每个服务器上面做，每个服务器限小流，然后如果负载均衡就可以实现整体限流满足要求。

2.2 帖子（post）的设计实现与优化

db读写分离

采用读写分离之后存在数据延迟问题
较早的数据极少访问。而一旦读写分离，意味着每一条记录都需要存储多份。当这些数据刚发布的时候，访问频繁，随着时间的推移，他们就不再被访问了。那么百分之99的数据副本不会被读取到，存储效率低。

引入缓存，缓存的数据过期机制天然避免了陈旧数据对空间的占用。

这里我们如何设计Redis的key-value呢？我们不难发现，同一个用户一天发出的帖子数量是有限的，通常不超过10条，平均3条左右，单个用户一周发的帖子很难超过100KB，极端情况下1MB，远低于Redisvalue大小的上限。所以：

key：userId+时间戳（精确到每星期）

value：Redis为hash类型，field为postId，value为帖子内容

expire设置为一个星期，即最多同时存在两个星期的数据（假设每贴平均长度0.1KB，1亿用户每天发3贴预计数量为400GB）

对某个用户一段时间范围的查找变为针对该用户本周时间戳的hscan命令，用户发帖等操作同时同步更新DB和缓存，DB的变更操作记录保证一致性。

但是，有些热用户的follower数量极高，意味着这个热点用户所在Redis服务器的查询频率为1000万每秒。

当一些比较热点的用户查询比较频繁的时候，我们可以直接把热点用户存入本地缓存中。用来缓解服务端的缓存的压力

2.3 点赞业务如何落地

根据点赞业务特点可以发现：

吞吐量高
能够接受数据不一致

如果只考虑点赞可以怎么做？

可以用MySQL做持久存储，Redis做缓存，读写操作落缓存，异步线程定期刷新DB。

counter表：id，postId，count

RedisKV存储：key：postId value：count

但是以微博为例，不仅有点赞还有转发数，评论数，阅读量等。所以，业务拓展性和效率问题是难点，如果这么设计，我们就需要多次查询Redis，多次查询DB。

假设首页有100条消息，就需要for循环每一条消息，每条消息要进行4次Redis访问进行拼装。

所以这里我们进行优化的话，可以在MySQL层面进行增加列优化

conunter表：id，postId，readCount，forwordCount，commentCount，PraiseCount

这样增加的话，缺点是如果增加一个计数服务的话，列就需要改变。那么不想改变列怎么办呢？

conunter表：id，postId，countKey（计数类型名称，比如readCount），countValue

Redis来获取业务的话，可以存储为hash用来计数。

订单表的分库分表方案设计(大数据)

https://www.cnblogs.com/wangtao_20/p/7115962.html

b2c平台。订单的卖家就一个，就是平台自己。

按用户id取模（分库分表）思考优点和缺点

优点

订单水平分库分表，为什么要按照用户id来切分呢？

好处：查询指定用户的所有订单，避免了跨库跨表查询。

因为，根据一个用户的id来计算节点，用户的id是规定不变的，那么计算出的值永远是固定的(x库的x表)

那么保存订单的时候，a用户的所有订单，都是在x库x表里面。需要查询a用户所有订单时，就不用进行跨库、跨表去查询了。

缺点

缺点在于：数据分散不均匀，某些表的数据量特别大，某些表的数据量很小。因为某些用户下单量多，打个比方，1000-2000这个范围内的用户，下单特别多，

而他们的id根据计算规则，都是分到了x库x表。造成这个表的数据量大，单表的数据量撑到极限后，咋办呢?

总结一下：每种分库分表方案也不是十全十美，都是有利有弊的。目前来说，这种使用用户id来切分订单数据的方案，还是被大部分公司给使用。实际效果还不错。程序员省事，至于数据量暴涨，以后再说呢。毕竟公司业务发展到什么程度，不知道的，项目存活期多久，未来不确定。先扛住再说。

c2b2c 平台的订单分卖家和买家的时候，选择什么字段来分库分表呢？

b2b平台，上面支持开店，买家和卖家都要能够登陆看到自己的订单。

先来看看，分表使用买家id分库分表和根据卖家id分库分表，两种办法出现的问题

如果按买家id来分库分表。有卖家的商品，会有n个用户购买，他所有的订单，会分散到多个库多个表中去了，卖家查询自己的所有订单，跨库、跨表扫描，性能低下。

如果按卖家id分库分表。买家会在n个店铺下单。订单就会分散在多个库、多个表中。买家查询自己所有订单，同样要去所有的库、所有的表搜索，性能低下。

所以，无论是按照买家id切分订单表，还是按照卖家id切分订单表。两边都不讨好。

淘宝的做法是拆分买家库和卖家库，也就是两个库：买家库、卖家库。

买家库，按照用户的id来分库分表。卖家库，按照卖家的id来分库分表。

实际上是通过数据冗余解决的：一个订单，在买家库里面有，在卖家库里面也存储了一份。下订单的时候，要写两份数据。先把订单写入买家库里面去，然后通过消息中间件来同步订单数据到卖家库里面去。

买家库的订单a修改了后，要发异步消息，通知到卖家库去，更改状态。

微博百亿数据-粉丝关系链如何分库分表

https://mp.weixin.qq.com/s/fVt7rvX-uurIEV7hMSAHtA

粉丝列表拆分为：关注列表、粉丝列表

正常用户分库分表，百万、千万等大V单独处理（单独分库分表）

一些大V账号，我们也可以进行服务器端的本地、中间件进行多级缓存。

冷热数据

数据库缓存一致性问题

1.依赖redis过期时间（对于时间不敏感业务）

1.分布式锁使请求串行化缺点：请求积压过多可能会使请求超时

2.mq异步更新

3.canal+mq+redis

如何设计低延时服务

场景：读多写少，服务返回需求在毫秒级

1.一二级缓存，local cache + redis cache

2.大map 可以分成多个小map，读写锁保证并发安全

如何在备库（读库）读到最新数据？

binglog 传送，中继日志重放需要时间，所以理论上备库延迟只能减少

中继日志：复制架构中，备服务器用于保存主服务器的二进制日志中读取到的事件；用于实现mysql的主从复制。

1.业务强制走主库，会影响业务
2.业务上增加强制延时（如转账后进度条一直转）

gtid:事物id global transcation id

数据库主从延时问题

业务上等待刷新（如银行转账等）

1)、架构方面

1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。

2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。

3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。

4.不同业务的mysql物理隔离，分散压力。

5.使用比主库更好的硬件设备作为slave，mysql压力小，延迟自然会变小。

2.硬件

3.对于要求更新立马能查到的，可以强制走主库查询数据

秒杀架构的思考

常用技术手段

高性能热点优化

静态化或 cdn 等暂不考虑

1.业务隔离
2.系统隔离（秒杀服务单独）
3.数据隔离提前预热（热点发现- 热点数据、操作）
4.缓存+限流

服务性能优化

1.减少序列化（减少rpc调用）合并部署
2.代码优化控制堆栈日志输出

一致性性能优化

高读高写场景

高读
分层次校验，滤掉无效请求
1.权限
2.秒杀是否结束
3.本地缓存

行记录排队

1.减后库存要大于0
2.设置数据库类型为无符号整数（unsigned）

type Category struct {Id          uint    `json:"id" gorm:"column:id;type:int(10) unsigned not null AUTO_INCREMENT;primary_key"`Title       string `json:"title" gorm:"column:title;type:varchar(250) not null;default:''"`Description string `json:"description" gorm:"column:description;type:varchar(250) not null;default:''"`Content     string `json:"content" gorm:"column:content;type:longtext default null"`ParentId    uint    `json:"parent_id" gorm:"column:parent_id;type:int(10) unsigned not null;default:0;index:idx_parent_id"`Status      uint   `json:"status" gorm:"column:status;type:tinyint(1) unsigned not null;default:0;index:idx_status"`CreatedTime int64   `json:"created_time" gorm:"column:created_time;type:int(11) not null;default:0;index:idx_created_time"`UpdatedTime int64   `json:"updated_time" gorm:"column:updated_time;type:int(11) not null;default:0;index:idx_updated_time"`DeletedTime int64   `json:"-" gorm:"column:deleted_time;type:int(11) not null;default:0"`
}

高可用

1.流量消峰（1.答题、验证码防作弊，提交时间验证（大于2s） 2.按钮置灰 3.排队）

秒杀架构

降低rt，提高并发

1.降低数据库锁力度：分库分表

2.降低锁持有时间

请求队列化，
比如将200ms 请求放在一个内存队列，起一个异步线程，将200ms所有商品库存进行扣减，

api请求最差为200ms

秒杀商品id计数器，如果当前并发超过阈值，会创建内存队列，会将内存队列中购买一并扣减，降低数据库io次数

库存服务被调用超时怎么办？

假如上游库存服务被调用超时，上游订单服务会发条消息给库存服务，进行库存回滚，

库存服务会根据mq中订单号查库存流水，判断订单是否扣减库存

秒杀的高并发分析

insert和update需要先执行insert
因为update同一行会导致行级锁，而insert是可以并行执行的。

缓存数据一致性

cache aside db更新创建缓存

监听binlog 保持缓存一致性，业务代码不关心缓存了，另外一个模块去刷新

缓存命中率问题

监听binlog时,设计时间窗口，判断5s内有更新，在5s结束时刷新下redis

binlog延迟、并行问题

因为binlog会并行过来，所有后面的binlog可能呗先监听到，会有消息乱序的情况。
数据库字段加版本号，先判断redis版本号，binglog中大于版本号才去更新

阿里云团队针对数据库

由业务队列改为数据库队列

http接口何如防篡改、防重放

签名机制

http 是一种无状态的协议, 服务端并不知道客户端发送的请求是否合法, 也并不知道请求中的参数是否正确

客户端: 每次请求客户端都带一个 sign 参数给服务端, 这个所谓的 sign 就是一个字符串
服务端: 每次处理请求之前先验证 sign 是否合法, 如果不合法就不处理
生成 sign 和验证 sign: 怎么生成和验证, 需要客户端和服务端约定好

客户端生成 sign: 可使用公私钥非对称加密的方式, 也可以使用计算字符串 md5 或者 hash 值的方式, 这个被加密的字符串最好不是固定的,取时间戳, 请求参数等就可以, 每次客户端把生成sign传递给服务端

服务端根据约定好的算法验证sign是否正确就可以

防重放

设计了防篡改之后, 接口总算是安全了那么一点点, 但是还不够…还需要对接口设计防重放设置

客户端在请求中添加两个参数

1.1 添加一个随机不重复的字符串参数比如uuid 至于怎么让他不重复,可以考虑拼接时间戳,md5随机数等
1.2 添加一个请求时间的参数如 request_time 值就是发送请求时的时间戳

服务端接到这个请求：
1 先验证 sign 签名是否合理，证明请求参数没有被中途篡改
2 再验证 timestamp 是否过期，证明请求是在最近 60s 被发出的
3 最后验证 uuid 是否已经有了，证明这个请求不是 60s 内的重放请求

把这些值按照账号来区分存储在redis增加过期时间就可以了。

阿里云api网关的解决方案

客户端调用API时，需要在请求中添加计算的签名。API网关在收到请求后会使用同样的方法计算签名，同用户计算的签名进行比较，相同则验证通过，不同则认证失败。
在API网关的签名中，提供X-Ca-Timestamp、X-Ca-Nonce两个可选HEADER，客户端调用API时一起使用这两个参数，可以达到防止重放攻击的目的。

X-Ca-Timestamp
发起请求的时间，可以取自机器的本地实现。当API网关收到请求时，会校验这个参数的有效性，误差不超过15分钟。
X-Ca-Nonce
这个是请求的唯一标识，一般使用UUID来标识。API网关收到这个参数后会校验这个参数的有效性，同样的值，15分内只能被使用一次。

如何在短时间内在一个接口中并发请求多个http链接

场景：一个数组，里面有100个标题id, 每一个都需要通过http请求拿标题

1.长链接
2.合并请求为一次，网络io从多次变为1次
3.mq 削峰填谷（不符合），接口需返回标题

10亿个KEY判断某KEY是否存在

要求 1.内存不能太大 2.QPS 200w 3.尽量避免误判

art前缀树
"Art前缀树"是一种基于前缀树数据结构的变体，它在自然语言处理中经常被用来进行单词或短语的搜索和匹配。前缀树是一种树形结构，其中每个节点表示一个字符串的前缀，从根节点到叶节点的路径表示一个完整的字符串。与普通的前缀树不同，Art前缀树通过压缩冗余的节点来减少内存使用，并通过最小化分支数和最大化叶子节点的分支深度来提高搜索效率。Art前缀树也支持一些高级功能，例如子字符串搜索和模糊匹配。在文本编辑器、搜索引擎和自然语言处理系统等应用程序中，Art前缀树常用于高效地搜索和查找文本中的单词、短语和相关信息。

布隆过滤器配合B+树存储

1.先用布隆过滤器判断数据是否存在, 拦截绝大多数请求
2.如果命中布隆过滤器，则查询B+树
4层1000亿数据，也可以进一步通过hash来隔离，形成多个树（分实例），进一步提高效率

分布式限流

常见的限流方法：

固定窗口计数器：按照时间段划分窗口，有一次请求就+1，最为简单的算法，但这个算法有时会让通过请求量允许为限制的两倍。
滑动窗口计数器：通过将窗口再细分，并且按照时间“滑动”来解决突破限制的问题，但是时间区间的精度越高，算法所需的空间容量就越大。
漏桶：请求类似水滴，先放到桶里，服务的提供方则按照固定的速率从桶里面取出请求并执行。缺陷也很明显，当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才能被响应。
令牌桶：往桶里面发放令牌，每个请求过来之后拿走一个令牌，然后只处理有令牌的请求。令牌桶满了则多余的令牌会直接丢弃。令牌桶算法既能够将所有的请求平均分布到时间区间内，又能接受服务器能够承受范围内的突发请求，因此是目前使用较为广泛的一种限流算法。
Google 的开源项目 guava 提供了 RateLimiter 类，实现了单点的令牌桶限流。

分布式环境下，可以考虑用 Redis+Lua 脚本实现令牌桶。

如果请求量太大了，Redis 也撑不住怎么办？我觉得可以类似于分布式 ID 的处理方式，Redis 前面在增加预处理，比如每台及其预先申请一部分令牌，只有令牌用完之后才去 Redis。如果还是太大，是否可以垂直切分？按照流量的来源，比如地理位置、IP 之类的再拆开。

字节跳动团队：春节钱包大流量奖励系统入账及展示的设计与实现

https://www.toutiao.com/article/7081542340891951657

4.4 难点四：大流量发卡券预算控制

需求背景：

春节活动除夕晚上 7 点半会开始烟火大会，是大流量集中发券的一个场景，钱包侧与算法策略配合进行卡券发放库存控制，防止超发。

具体实现：

（1）钱包资产中台维护每个卡券模板 ID 的消耗发放量。

（2）每次卡券发放前算法策略会读取钱包 sdk 获取该卡券模板 ID 的消耗量以及总库存数。同时会设置一个阈值，如果卡券剩余量小于 10%后不发这个券（使用兜底券或者祝福语进行兜底）。

（3）同时钱包资产中台方向在发券流程累计每个券模板 ID 的消耗量（使用 Redis incr 命令原子累加消耗量），然后与总活动库存进行比对，如果消耗量大于总库存数则拒绝掉，防止超发，也是一个兜底流程。

4.5 难点五：高 QPS 场景下的热 key 的读取和写入稳定性保障

在方案一实现的基础上进行优化，并且要考虑数字不断累加、节约成本与实现容灾方案。在写场景，通过本地缓存进行合并写请求进行原子性累加，读场景返回本地缓存的值，减少额外的存储资源占用。使用 Redis 实现中心化存储，最终大家读到的值都是一样的。

每个 docker 实例启动时都会执行定时任务，分为读 Redis 任务和写 Redis 任务。

读取流程：

本地的定时任务每秒执行一次，读取 Redis 单 key 的值，如果获取到的值大于本地缓存那么更新本地缓存的值。
对外暴露的 sdk 直接返回本地缓存的值即可。
有个问题需要注意下，每次实例启动第一秒内是没有数据的，所以会阻塞读，等有数据再返回。

写入流程：

因为读取都是读取本地缓存（本地缓存不过期），所以处理好并发情况下的写即可。
本地缓存写变量使用 go 的 atomic.AddInt64 支持原子性累加本地写缓存的值。
每次执行更新 Redis 的定时任务，先将本地写缓存复制到 amount 变量，然后再将本地写缓存原子性减去 amount 的值，最后将 amount 的值 incr 到 Redis 单 key 上，实现 Redis 的单 key 的值一直累加。
容灾方案是使用备份 Redis 集群，写入时进行双写，一旦主机群挂掉，设计了一个配置开关支持读取备份 Redis。两个 Redis 集群的数据一致性，通过定时任务兜底实现。

注意点：

本方案调用 Redis 的流量是跟实例数成正比，经调研读取侧的服务为主会场实例数 2 万个，写入侧服务为资产中台实例数 8 千个，所以实际 Redis 要支持的 QPS 为 2.8 万/定时任务执行间隔（单位为 s），经压测验证 Redis 单实例可以支持单 key2 万 get，8k incr 的操作，所以设置定时任务的执行时间间隔是 1s，如果实例数更多可以考虑延长执行时间间隔。

通用场景

商品服务多级缓存

本地缓存策略

redis 多个zset根据点击商品次数（热点），定时轮训做本地缓存，redis缓存

商品被修改, 删除缓存（会有网络抖动更新失败情况）
canal订阅binlog，消费mq，更新redis缓存, 广播模式重置本地缓存（兜底）

注意⚠️：更新缓存最好有版本号，防止多个线程同时修改导致缓存不一致问题

热点问题

热点问题，本地缓存

缓存击穿

1.同一进城内模式下 singleflight单飞模式保证同一时间一样的请求只有一次能够访问数据库

2.不同进程内，设置分布式锁，其它线程sleep+失败重试

微博场景

大V发动态

读扩散、写扩散优化

写扩散(Push)优化

设置上限，微信好友5000个
限流策略，X分钟内完成消息发布
优化存储策略，采用NoSQL或大数据方案

读扩散(Pull)优化

MQ削峰填谷，超长队列直接拒绝。
增加轮询间隔，减少请求次数。
服务端增加缓存，优化查询效率
增加验证码，分散时间，减少机器人刷票
本地缓存

推特的混合模式

粉丝量小于X，Push模式
粉丝量大于X，Pull模式

B站

视频显示在线观看人数是怎么做的？

要求：接受分钟级延迟、准确性要求不高
服务级别：P2-3服务

可以看到，目前B站是采用客户端定时上报心跳，客户端定时去拉人数

解决方案：

1.缓存key为视频或直播间ID加上分钟级的时间戳，数据结构用HyperLogLog，过期时间也是几分钟，当前在观看的每个客户端每分钟请求一次服务器，将用户或客户端ID加进去，查询的时候pfcount

2.Redis 一个hash+一个kv
key:field:value分别是视频id:用户id:时间戳
查看人数就是hlen一下就可以。
时间戳存进房/心跳的时间。进入写field，退出删field。退出信令不可靠，所以需要心跳过期来清理。
清理时机用另一个分钟级过期的key来保存，key就是视频id。setnx ex一下。如果key不存在，那就把hgetall出来，遍历一下，把时间戳已经过期的field删掉。key存在则不需要清理过期field。
实时性和准确读都比较高，清理的耗时操作也均摊下去了。

缺点：热点视频、大V视频可能有大KEY存在

3.长链接
消耗内存，费钱，不合适

【面试】系统架构设计（持续更新）相关推荐

29W 字总结阿里 Java 高并发编程：案例 + 源码 + 面试 + 系统架构设计
下半年的跳槽季已经开始,好多同学已经拿到了不错的 Offer,同时还有一些同学对于 Java 高并发编程还缺少一些深入的理解,不过不用慌,今天老师分享的这份 27W 字的阿里巴巴 Java 高并发编程 ...
Android开发面试：架构设计和网络知识答案精解
目录架构设计编程思想六大设计原则重构-Code Smell AOP 设计模式创建型5个行为型11个结构型7个编程范式 MVC MVP MVVM MVI 模块化组件化插件化.热修复 ...
常见的系统架构设计介绍
系统架构设计介绍分布式架构初始阶段架构特征应用服务和数据服务以及文件服务分离特征问题使用缓存改善性能特征问题使用应用服务器集群特征描述问题数据库读写分离特征描述问题 ...
《系统架构设计》-01-架构和架构师概述
文章目录 1. 架构的基本定义 1.1 架构组成理论 1.1.1 系统元素 1)概念 2)静态结构和动态结构 1.1.2 基本系统属性 1.1.3 设计和发展原则 1.2 架构的决策理论 1.2.1 ...
机器学习面试经验--2017年持续更新
机器学习面试经验--2017年持续更新搜狐面试算法实习生岗位搜狐后台开发(机器学习NLP) 10:00--11:10 1.首先自我介绍,blabla简单介绍了一下本科研究生学校专业方向,面试官开始 ...
分布式实时处理系统架构设计与机器学习实践
编者按:在2017年的1月11日,CSDN高级架构师金牌授课群为群友们带来了第一次的分享,讲师和主题参见这里,本文为课程后续的文字整理,第一时间发出来分享给读者,课件下载点击这里. 大家好,我们今天主 ...
人脸识别完整项目实战（3）：项目系统架构设计
一.前言本文是<人脸识别完整项目实战>系列博文第1部分,第2节<项目系统架构设计>,本章内容系统介绍:人脸系统系统的项目架构设计,包括:业务架构.技术架构.应用架构和数据架构 ...
大数据用户画像系统架构设计
文章目录一.用户画像数据仓库搭建.数据抽取部分二.大数据平台.用户画像集市分层设计.处理三.离线计算部分四.实时计算部分五.Solr/ES搜索引擎部分六.Java Web毫秒级实时用户画像 ...
5G 融合计费系统架构设计与实现(一)
5G 融合计费系统架构设计与实现(一) 随着5G商用临近,5G的各个子系统也在加紧研发调试,本人有兴全程参与5G中的融合计费系统(CCS)的设计.开发.联调工作.接下来将用几篇文章介绍我们在CCS实现 ...

【面试】系统架构设计（持续更新）