第一个问题从后端视角怎么处理楼上大佬都说的差不多了。 楼上也提到从现实来说，一个学校同时抢课不会有太高的并发量，这种学校的服务大部分就是个单机服务，可能 redis 没有，加个悲观锁基本就可以了。 但是面试官如果说并发量超级高，全地球人都要抢这门课，那么就要从整个系统上看这个问题，可以在前端就做一些规则过滤，不可能让所有的用户操作都请求到服务器，例如根据用户规模，用户点击时的时间戳 %n=0 才发请求到服务器，现实中的高并发场景我们确实是这么干的。
1 秒杀库存设计，你说 redis lua 没什么问题，所以直接跳过了。 2 线上 redis 内存满了，删 key 、扩容，然后分析内存满的原因，因为一般都设置了过期时间，不存在会打满的情况，从应用、数据、数据结构等方面去分析优化 redis 的使用。 3 缓存、异步、可扩容，再多说的话，就是性能优化、监控、并发控制等。
简单回答下： 1. 抢课本质就是秒杀。 在系统层面，用户从前端、网关、后端、缓存最后到数据库，要尽可能把用户挡在前面。例如前端限制操作频率，网关限流限制地域等，后端 app 判断用户情况是否合格，不合格的要求 30 分钟后再试，合格的从缓存扣减。 在热点的 xx 分钟内， 相关数据不同步到库，等热点过去了再统一写库（根据场景判断是否使用 MQ 等、是否可以阶段写库）。 2. 针对单节点，有内存淘汰策略。参考官网 key eviction( https://redis.io/docs/latest/develop/reference/eviction/) 达到最大内存会按规则淘汰（ LRU 、LFU 、随机等）。 集群环境下应该扩容。 3. 高并发本质是资源的争用，需要解决数据同步的问题。如何展开看面试聊啥。。。
