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

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

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

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



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

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



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

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