昨天面试的几个 MySQL 和 Redis 的题目，来请教一下

[dumbbell5kg]

1.MySQL 里的记录有这么两个字段：
课程 id，课程余额
同时间大量学生抢同一门课，如何设计这个功能？

2.线上 Redis 内存满了，应该如何处理？

3.你认为解决高并发问题的本质是什么？

求大佬赐教 orz

Redis 内存满了这个问题，应该问的是满了之后的处理方案

[hoythan]

不如你先说说你怎么回答的。

[BiChengfei]

缓存 异步 分区

[dumbbell5kg]

@hoythan
1.我：我说这是一个热点行数据争用锁的问题，可以把一行课程数据分成多行，减少行锁争用
面试官：这样增加编程复杂度，而且性能也不会高
我：可以把课程数据放到 Redis 里，用 lua 脚本来做，lua 脚本里判断课程余额，减少余额

我说完就问下一题了，但是我觉得是不是有更好的方案？这个问题就用 Redis 感觉问的价值不高呀

2.完全没思路

3.
我：大部分系统瓶颈都在数据库 IO 上，一般可以 NIO 这类技术避免 IO 等待
他没怎么说话，我感觉也不是这个答案

[zhoujx]

1.感觉是秒杀库存问题
2.人工删除一些业务废弃的 key ，统计一些可以清理的先清理掉。
3.锁、如何优化锁、什么条件下可以不用锁

[zhoujx]

@zhoujx 第三点范围很大，不好说

[c3de3f21]

有没有可能有的点没放出来就是在等你聊？等你一步一步和他确认出问题？

- 比如什么业务场景下 redis 内存满了？是跑起来就满了还是突然就满了？
- 比如什么情况下的高并发？是类似抢课造成的并发？还是中台或者什么情况下造成的高并发？
- 不同的业务场景给他不同的回答

[Orlion]

2. 先扩容保证服务可用，根据业务选择合适的缓存淘汰策略，如果是上线后引起的，能回滚先回滚，然后排查代码看下是否是正常内存占用（过期时间设计是否合理等等）
3. 个人认为是性能与事务（一致性）的 tradeoff

[guisheng]

第一个直接弄一个 key ，decr 做减法不就好了么，还是我想的简单了
第二个内存满了，可以停机和不可停机有不同的处理方法，最简单的删除一些内容，这里面有个专业术语 淘汰策略，事后扩容或者集群
第三个 在高效率的情况下避免程序出现问题

[qping]

@BiChengfei 这是回答的哪个？

[dobelee]

1. 秒杀问题（队列）
2. 检查 key 补上过期时间（监控告警、扩容）
3. 高性能的同时保证并发安全（锁、幂等）

[qxdo1234]

1 可以参考我这个问题，差不太多，有大佬回答了个还算靠谱的答案

[Rache1]

1 、乐观、悲观锁都行？
2 、第二个肯定是先扩容，然后再排查，可以先拉 bigkey 看看人工清理一些，如果近期有新功能上线涉及到了，就先回退。

[LieEar]

我来斗胆回答一下，麻烦各位大佬指正：

抢课是谁先到先得模式，还是先报名再摇号方式？考虑到学校的硬件性能不会太好，先开启限流，比如 nginx ，就让 1 秒钟只有 500 个请求，避免系统崩溃。抢课过程：
第一种，可以开启事务，开启事务->扣减课程余额->给学生添加课程信息->结束事务；
第二种，先在内存中记录下课程 id 和对应的学生学号。比如限制一天内报名，到期后，随机抽取 n 个学生。然后余额=0 ，给学生添加课程信息。可以使用 redis ，或者本地 cache

redis 满了，看是不是某些超大的 key 没有设置过期时间，可以优先把这种忘记设置过期时间的临时 key 删除掉。如果 key 都在使用中，而且数据都有意义，只能加内存。开启内存淘汰机制，LRU

解决高并发的本质是什么？
资源是有限制的，对于远超资源的流量，如何处理。比如抢课，只有 50 个名额，但是有 500 个学生要来抢课；或者说我的服务器硬件不行，无法处理那么多请求，大量流量下如何不宕机。首先要限流，不让系统被大流量打崩溃。到了具体的数据要加锁处理。数据修改完了，后续的其他操作（比如给学生添加课程信息），异步解耦还是跟着同步操作。

[WashFreshFresh]

1 、告诉学生余量很多，放心，不用抢，有空上去选就行。学生嘛，好忽悠。
2 、flushdb
3 、本质是资源不足、生产力不足，加机器只能缓解，不能解决实际问题。

[kenneth104]

1 ，只从 MySQL 看，那用乐观锁或悲观锁，分库分表。。
2 ，如果硬件暂时无法拓展，缩短过期时间，让压力分担到后端，同时考虑其他方案拓展这个 Redis,例如分布式等等
3 ，解决高并发的本质是，解决资源争用。需要对资源管理，对资源的横向纵向扩展，解决队列和熔断，等等

[fzzff]

本菜鸡的主观回答:
1. 考察互斥锁吧, 这种抢课的场景加个悲观锁就完全 ok, 再大点规模的并发考虑上消息队列
2. 如果项目本身使用 redis 就比较多那应该在设计初期就构建 redis 集群以保证动态扩容的灵活性; 如果是短期异常增长导致, 排查是否有异常的大规模缓存, 清理废数据; 再就是可能业务规模突然爆发超出预期, 我觉得可以全量备份以后到新服务器恢复数据然后后端暂时切换 redis 的连接
3. 并发问题主要在 io 和锁资源竞争, 优化 io 的基本方式就是异步解耦吧, 锁的话主要是对应业务场景下选择合适的锁

[imokkkk]

1.方法有很多 说一个上面没提到的 合并请求 把多个扣减课程余额的事务维护在内存或者缓存，合并成一次批量扣减课程余额的事务
2.搞不懂这个问题想问什么 分析大 key? 内存淘汰策略？集群架构打散数据？
3.这个问题大了 不好回答
性能优化：代码优化(异步、并行、各种资源的池化)、缓存(Nginx 静态缓存、CDN 、JVM 缓存、Redishuanc)、数据库优化(索引、大数据量下的分库分表、分布式数据库)
分布式架构：微服务拆分(水平扩展、负载均衡)
并发控制：高并发带来的问题(合理的使用锁、尽量避免事务/长事务、乐观锁)
监控：APM 、压力测试

[xxxccc]

高并发的本质就是有效的资源下完成更多的请求。如何完成更多的请求？
1. 减少单个请求的处理时间。从缓存、异步的角度考虑。
2. 提升服务承接并发数。以 web 服务为例子，就是提升最大连接数。
另外一方面就是扩展性，如果服务都是无状态的服务，那么直接水平扩展，因此这要求服务尽量做到无状态。

[cenbiq]

1.乐观锁，人再多那就只能队列解决；
2.不造；
3.资源永远是有限的，而 IO 资源更为有限，所以高并发的本质是抢夺有限的资源，解决方法是对资源合理利用（线程和锁的优化，缓存）、流量进行削峰填谷（消息队列）、以及服务器负载均衡来尽量确保资源的合理分配。

[8355]

@WashFreshFresh 6 实在是 6

[isno]

1. 大概率是是想问你悲观锁、乐观锁的区别
1.1 使用悲观锁，串行阻塞，资源占用大
1.2 乐观锁，CAS 机制，失败了再增加个重试机制

3. 解决高并发的本质是需求与资源的不对等
3.1 有钱增加资源：分布式、横向/竖向扩容
3.2 没钱增加资源：限流、部分服务不可用

[lsk569937453]

1.秒杀直接上 redis ，把课程 Id 和对应的数量放到 redis 里，抢到后往消息队列发消息，然后通过消费者处理后续的流程。
2.redis 满了之后可以设置过期策略。把策略设置一下就好。
3.这是扩展题。发现性能瓶颈，然后通过削峰、限流、扩容、分表等手段让系统平稳的处理流量。

[8355]

1.2 个方向 redis decr 或着 队列消费 应该规避回答 mysql 锁相关的回答，我认为是陷阱问题。
2.扩容+监控，实际上不可能满。这种题的预设本身就比较失败
猜测是想问内存碎片相关，或着排查流程类似找大 key ，要么就是集群分片方案。
3.通过优化响应速度提高并发量，应用场景包括不限于缓存/消息队列削峰/部分操作提前等等

[whahuzhihao]

估计面试官看过《高并发的哲学原理》才会问第三个问题。https://pphc.lvwenhan.com/

[japeth]

@imokkkk 请教一下 第一个问题的这种解法，放内存不合适吧，如果有多个实例同时运行可能会不一致，合并成一次批量扣减，如果在用户提交的时候反馈结果呢
@lsk569937453 请教一下 第一个问题的这种解法 是不是也是不能在用户提交的时候反馈结果呢

[mightybruce]

@whahuzhihao 我也看过这个，写得非常好。

前三个问题上来就谈具体方案的人基本都是缺少架构设计经验，上面 V2EX 回答大多数都基本上都是具体方案，

同一的问题不同复杂度和需求下设计是不一样的， 不少架构师照搬别人或自己原来公司架构导致崩盘的事件不少。

[yangxiaopeipei]

抢课做成拼多多的砍单怎么样

[22yune]

1 、采用摇号机制，报名同一课程的同学都进一个池子，随机选择。5 分钟一轮。
2 、线上 redis 应该有监控，预警了可以先试着清理：查看内存主要消耗在哪里，是否有必要（数据结构、过期策略）。还是内存不足就扩容，加内存。
3 、高并发的本质是资源共享、导致要争抢（竞争）。

[zhao8681286]

解决高并发的本质就是在业务上避免高并发的场景的产生，看看早年的双十一和现在的双十一。

[iosyyy]

@8355 #23 2 应该是想问如果满了怎么排查 big key 以及 redis 的内存清理机制吧 包括可能一些过期时间的实际问题
3 我觉得应该答本质是拿空间换时间

[iosyyy]

@iosyyy 内存淘汰机制太久没看给忘了

[killva4624]

1 其实用队列感觉更简单，一个人只运行提交一次，按提交时间先后消费占课。

[twofox]

我还真做过教务系统。首先抢课是肯定要先开设课程的，然后每个课程就是有限定选课学生数量。
也就是
课程 id ，课程余额

实际业务不单止会判断学生数量而已。
按照判断条件的先后排列的话，我们需要判断这些条件

1. 面向的选课学生范围（一门课首先要设置上课学生的年级、专业范围）
2. 课程类型是否满足（公选课、专业选修课）
3. 是否设置了课程类型的学分上限？（例如专业选修课本次选课只能选 5 个学分的）
4. 上课时间是否冲突？（要判断已经排好的专业课、本次选课的其它课程、实习周、军训时间）
5. 最后才是容量问题

所以针对这种场景，前东家是这么做的
1. 选课需要缓存好各类数据（就上面的那些判断条件，数据量大、硬件差的学校需要缓存一二十分钟的）
2. 选课的相关条件都从缓存取（避免大 key ，redis 多部署几个节点做集群）
3. 打开选课界面的时候，获取的可选课程也是从缓存取
4. 选择课程提交的时候，把课程 id 用 redisson 锁起来，然后进行条件判断
5. 如果成功之后就把选课的相关数据写进数据库
6. 缓存里的数量-1 ，释放锁

这一套下来，几千人抢课还是可以的。
但是实际上我当初提过用消息队列去缓解压力，leader 没用过，不敢用。怕消息队列崩了

当时选课真的一团糟，包括不限于数据库锁表了，jvm oom 了，redis 超时了
因为当时判断条件，真就硬从 Oracle 里面查询啊

[twofox]

选课还有个业务场景的，就是退选

退选的情况下，又要考虑数据库和缓存的一致性。

[fkdog]

我对问题本身兴趣不大。
倒是对楼下的回复挺感兴趣的。
可以看出，虽然本质都是 CRUD ，但是工程师思考的角度和普通开发思考的角度还是差别挺大的。

[admol]

第一问，实际上是在问你系统设计问题
而你只是直接回答了其中很小的一个点（做法），也不能说不对，只能说不完全对。


尝试从下面几个步骤回答下：
1. 多问
- 学校总的有多少学生需要抢课
- 学校大概总的有多少非常热门的课程
- 平均到每门热门课程大概有多少学生会同一时刻抢
- 给出一些人数，然后是否可以估算出 QPS
假设：需要抢课的学生 1000 人，
假设查询课程 QPS 粗略估算：1000QPS ，峰值*2 ，算 2000QPS

- 其他开放性问题，是否有其他要求
2.初步方案
分为两部来进行涉及：
1. 查询课程（查询并发最大）
设计一个高效的索引和缓存机制，以应对高并发查询需求。方案有：缓存、读写分离等
2. 提交抢课
设计一个分布式锁机制，确保同一时间只有一个学生可以成功抢课。方案有：Redis 、ZK 分布式锁、消息队列等

3.详细方案
- 开始抢课之前，提前将课程-课程余额缓存到 Redis 中
- 使用读写分离，分散查询课程和抢课程写结果时数据库的压力
- 使用 Redis 进行扣减余额
- 扣减成功，记录抢课结果（学生-课程）
4.总结
- 缓存、锁、读写分离、其他方案

[admol]

线上 Redis 内存满了，应该如何处理？

思路：
1. 解决线上问题，快速恢复线上功能正常访问
- Redis 扩容
- 手动清理不必要的缓存数据，释放内存

线上功能恢复后再做
2. 找出为什么满问题
- 分析 Redis key ，是否是热点数据访问量暴增？
- 是否是 缓存 key 设计不合理
- Redis 配置参数不合理，导致内存使用效率低下
3. 避免为什么满问题
- 针对 2 进行优化，增加监控告警等措施

[admol]

3.你认为解决高并发问题的本质是什么？
- 本质就是在大量的请求和有限的资源情况下，如何来保持系统的性能和可用性等。
- 手段很多：增加资源、减小开销、缓存、服务化、冗余、异步、队列、限流、熔断等

[admol]

推荐看下这个：
系统设计面试：内幕指南 https://learning-guide.gitbook.io/system-design-interview

[mightybruce]

@admol 学校 qps 很低的， 到不了 1000 ， 另外学校也不会就只开放几个小时不到一天去选课
你实在太高估学校了。

除非这个学校很特殊，哈哈。面试官假想的学校。

[darkengine]

你认为解决高并发问题的本质是什么？

- 如何最大化资源利用率

[LiaoMatt]

3.你认为解决高并发问题的本质是什么？
我认为是解决客户端体验一致性问题, 因为客户端不能理解为什么并发高低会影响服务, 对于客户端来说, 它希望服务端的表现不要偏离这个预期, 偏离这个预期就算破坏了客户端体验的一致性;

[boboaiya3]

@admol #36 qps=并发/响应时间

[dilu]

小菜鸡一枚，尝试回答一下，以下答案没查阅资料也没参考楼上大佬们的答案。

1. 这个问题我觉得可以分开讨论一下，首先如果真的只是学校的抢课场景，从经验来说，那就算有并发也不会有很高的并发，在不保证高可用的情况下（如果真是学校抢课，没必要真的做什么高可用吧？）单台 redis 足够支撑需求了，最简单的实现肯定是 setnx ，但是可以从这里延伸一下，例如锁的时长要设置多久，锁过期了怎么办，要不要重试等等八股文，也可以用 lua 脚本，但是缺点是什么巴拉巴拉（掺杂八股文）
但是如果不是简单的学校抢课场景，而是电商的抢购商品这种场景（说时候电商秒杀的八股文和方案大家估计背的比我熟了吧？）既要保证高可用也要数据一致性的情况下，我觉得可以这样设计：

a) 根据以往秒杀时期的数据前提下，前端直接抛弃一部分流量，例如只有 20%的请求才能真正的请求，80%的请求在前端直接抛弃。
b) 秒杀请求进入队列，这样可以把对 redis db 等资源的峰值削平避免服务出现毛刺。由于是秒杀场景，失败了用户也会重试，所以完全可以不在意消息是否会丢失，这种情况下 mq 的性能绝对是能承载主流量的
c) 在消费的时候，再按照商品纬度加锁，这里可以用 redis 集群模式，也可以用 zk 等等组件，调你熟悉的讲，例如你熟悉 redis 的 redlock 那就讲 redlock ，熟悉 zk 脑裂你就讲脑裂

2. reidis 内存满了怎么办？我认为有也得分类讨论（前提是 redis 满了已经导致服务不可用了，如果配置了内存淘汰策略那就不用在乎满不满了）
a) 首先确认这个 redis 里面的数据是不是全是“缓存型数据”，如果是，可以挑一些 topn 的 key 先删一批，先让服务正常可用，然后迅速扩容，如果能动态扩容最好，如果不行先用 rdb 复制一台更高规格的 redis ，然后切换过去。
b) 如果 redis 后面不是传统 MySQL 或者 qps 不高的情况下，直接重启是最好的办法，当然这种情况不太常见，如果 qps 过高可能会直接拖垮 DB 。
c) 这件事的关键是要做好事后复盘、做好防护，避免下次再出问题，一个是要增加 redis 内存监控告警，超过 80%要告警，其次要配置一下 redis 的缓存淘汰策略，（这里也可以卖弄一下 LRU 之类的八股文）。

3. 我认为并发问题就是资源竞争的边界问题，解决并发的问题就是让资源竞争的请求从并行变成串行(加锁)，让无序变有序，让混沌变秩序。这里可以卖弄一下读写锁，互斥锁，CAS ，原子操作之类的八股文。



其次，有一些关于面试的经验，想分享给 V 友们。

1. 面试跟谈恋爱是一样的，眼缘最重要，而不是闯关或者解密游戏，答对所有题，写出所有算法，不会决定你能否通过，能通过面试，一个是因为合适，一个是因为眼缘。而我认为后者的占比更大一些，所以建议可以适当处理一下个人形象，面试的时候别太颓废，别太随意。不管是面试还是生活中，看起来让人舒服的人，总能占更多的好处。

2. 面试的时候，问题不会，算法不会是很正常的一件事，计算机的知识没人能做到全都懂，你需要做的是把握面试节奏，让面试官去讨论你熟悉的东西，引导面试官的话题。例如楼主的题目，问你 redis 怎么实现分布式锁，如果你不熟悉 redlock 但是你熟悉 zk 那就说不好意思面试官，xxx 我不太熟，但是 zzz 我用的比较多，zzz 的原理是这样的 balabala 。要把节奏掌握在自己手中。

3. 面试官不一定能决定你是否通过，很多情况下还是 HR 话语权大一些

4. 面试前最好了解一下面试的公司和部门，他们有什么产品？主营什么业务，熟悉一下，对方问起来可以增加一些好感。

5. 面试必问，自我介绍、离职原因、语气薪资，这些问题一定要提前想好避免回答的时候大脑一片空白。

[xhawk]

1. 同时间大量学生抢同一门课，如何设计这个功能？

场景分析： 同时大量， 代表资源是有限的。 所以基本策略就是限流和排队的机制。

技术逻辑： 其实跟淘宝的竞拍逻辑基本一样，就是粥少僧多的逻辑。 用户入口与业务入口要做分离， 确保所有用户都可以正常登录，业务入口的请求做流量限定， 同时规划请求 timeout 时间， 确保想提交的人都有机会提交。 提交之后， 要额外开通一个排队的表纪录 用户的提交时间和纪录。 后端的异步逻辑通过用户的提交时间和纪录的合理性确定是否命中这门课。

最后效果： 所有想选课的人， 都能实时在线跟踪课表情况， 想选这门课的人， 基本上， 都有机会提交选票， 同时派发选票号码，并作公布。 采用后端的异步机制， 确认最终命中的人的选票。



2. 线上 Redis 内存满了，应该如何处理？

技术逻辑：Redis 内存满首先是查找问题原因， 能从源头解决最好， 不能解决的话， 只能从技术测来解决。redis 是有 cache 的， 可以在 config 文件自己配置 cache 的大小，可以考虑尽量多， 甚至 80%的内存都做分配，同时调整内存的轮询方法， 这个要根据实际的数据来调整。 当然， 一般一个 redis 就是单独一个服务， 可以多开几个 redis 服务并行处理， 这个也是一种方法。



3. 你认为解决高并发问题的本质是什么？

技术逻辑：其实就是流量分配， 最开始金融行业用的 F5 方案， 到后面各种云端企业用的负载均衡， 到最后各种 K8s ，k3s ， 不外乎就是规划流量。 做好流量和资源的匹配。 就像 k8s 就会说很牛掰的说， 不行的话， 就多配置几个应用， 多配置几个数据库。

[Cola98]

第一种用消息队列，第二种做配套监控，使用 ttl 定期淘汰任务，做好扩容准备

[Campanula]

1. 预分配、队列、悲观锁、乐观锁；
2. 加内存、扩容 redis 节点、排查内存数据；
3. 本质是资源分配和调度；

[han1988]

1. 先引导到一个在线吃鸡游戏，每场赢得前 N 位可以获得兑换码兑换课程资格

[han1988]

2. 加 Redis 集群节点
3. 加钱

[publicWyt]

还是一句话,抛开业务谈实现都是耍流氓,应该具体问题具体分析的,就比如楼上说的 redis,启动就满了和缓存堆满了就是两码事

[me1onsoda]

redis 满了不是很正常吗，redis 自己会淘汰一部分出去，就跟内存的换入换出一样。觉得太不可控频率太高了就加钱呗

[monmon]

第一个问题从后端视角怎么处理楼上大佬都说的差不多了。
楼上也提到从现实来说，一个学校同时抢课不会有太高的并发量，这种学校的服务大部分就是个单机服务，可能 redis 没有，加个悲观锁基本就可以了。
但是面试官如果说并发量超级高，全地球人都要抢这门课，那么就要从整个系统上看这个问题，可以在前端就做一些规则过滤，不可能让所有的用户操作都请求到服务器，例如根据用户规模，用户点击时的时间戳 %n=0 才发请求到服务器，现实中的高并发场景我们确实是这么干的。

[ospider]

@WashFreshFresh 你这哪里是写代码，写的都是人情世故啊，啊哈哈

[Seulgi]

1 秒杀库存设计，你说 redis lua 没什么问题，所以直接跳过了。
2 线上 redis 内存满了，删 key 、扩容，然后分析内存满的原因，因为一般都设置了过期时间，不存在会打满的情况，从应用、数据、数据结构等方面去分析优化 redis 的使用。
3 缓存、异步、可扩容，再多说的话，就是性能优化、监控、并发控制等。

[zanx817]

简单回答下：

1. 抢课本质就是秒杀。 在系统层面，用户从前端、网关、后端、缓存最后到数据库，要尽可能把用户挡在前面。例如前端限制操作频率，网关限流限制地域等，后端 app 判断用户情况是否合格，不合格的要求 30 分钟后再试，合格的从缓存扣减。 在热点的 xx 分钟内， 相关数据不同步到库，等热点过去了再统一写库（根据场景判断是否使用 MQ 等、是否可以阶段写库）。

2. 针对单节点，有内存淘汰策略。参考官网 key eviction( https://redis.io/docs/latest/develop/reference/eviction/) 达到最大内存会按规则淘汰（ LRU 、LFU 、随机等）。 集群环境下应该扩容。

3. 高并发本质是资源的争用，需要解决数据同步的问题。如何展开看面试聊啥。。。

[sulinehk]

@whahuzhihao 好书！

[Ashe007]

尝试解答第三题（解决高并发问题的本质）
1-限流，从入口层控制流量
2-集群，从架构层提升系统负载
3-避免并发安全，并行改为串行（无论是单机锁还是分布式锁）

[mintongcn]

我如先问问 gpt

[inostarling]

3.你认为解决高并发问题的本质是什么？
个人认为是资源分配和数据同步。

[cheng6563]

1.db 性能有限，本质是用更快的方案/中间件做缓冲区
2.要看是否是 Key 泄露，对于线上产品都是先扩容再说。
3.用更快/能水平扩容的中间件来缓存/缓冲数据库，用单线程处理多个 IO 任务（异步/协程）

[Huelse]

1. 要么限流+事务+锁，要么把选课事件插入到一个新表里然后按序分配
2. 删除没用的数据，集群扩容
3. 本质上就是分配资源问题，按序或者随缘分配

[andykuen959595]

大佬多 我来学习！

[homjay]

小白总结了下，大佬们是这个意思吗

1：
场景：秒杀系统（新起专门处理秒杀请求的服务，独立部署，减少对主站的影响）
流程：前端 -> 网关(nginx) -> 后端 -> 缓存(redis) -> 数据库(mysql)
原则：
1 、限流：前端选择性向后端发送真正请求（根据时间戳取余，用户会多次点击）、nginx （网关限流 1 分钟最多请求 10000 次）
2 、过程：
1 、2024-07-15 12:00 开启秒杀活动
2 、2024-07-15 11:30 秒杀服务从 mysql 读取数据，写入到 redis 缓存（预热准备）
3 、2024-07-15 12:00 时间到达
4 、（小王）请求发送 -> 后端判断用户是否符合参加活动 -> 开启 redis 锁 -> 从 redis 读取数据 -> 实现业务逻辑（库存相减...） -> 更新 reids 里面的值
5 、秒杀活动持续 1 分钟
6 、2024-07-15 12:01 时间结束
7 、2024-07-15 12:01 将 redis 数据回写到 mysql

2：
线上 Redis 内存满了，应该如何处理？
方案:
1 、判断是否有未设置过期时间(TTL)的 key
2 、内存淘汰策略
3 、添加监控


3:
你认为解决高并发问题的本质是什么
本质:
1 、系统同时处理大量请求,确保响应时间可接受且系统资源不被耗尽
方案:
1 、系统同时处理大量请求 => 减少请求（限流）
2 、系统资源不被耗尽 => 加强系统资源 => 花钱升级服务器
3 、系统资源不被耗尽 => 耗时的任务 => 减少耗时时间 => （旁路缓存，不经常更新数据，原来从 mysql 读取，优化为从 redis 读取）