3.你认为解决高并发问题的本质是什么？ 我认为是解决客户端体验一致性问题, 因为客户端不能理解为什么并发高低会影响服务, 对于客户端来说, 它希望服务端的表现不要偏离这个预期, 偏离这个预期就算破坏了客户端体验的一致性;
小菜鸡一枚，尝试回答一下，以下答案没查阅资料也没参考楼上大佬们的答案。 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. 面试必问，自我介绍、离职原因、语气薪资，这些问题一定要提前想好避免回答的时候大脑一片空白。
1. 同时间大量学生抢同一门课，如何设计这个功能？ 场景分析： 同时大量， 代表资源是有限的。 所以基本策略就是限流和排队的机制。 技术逻辑： 其实跟淘宝的竞拍逻辑基本一样，就是粥少僧多的逻辑。 用户入口与业务入口要做分离， 确保所有用户都可以正常登录，业务入口的请求做流量限定， 同时规划请求 timeout 时间， 确保想提交的人都有机会提交。 提交之后， 要额外开通一个排队的表纪录 用户的提交时间和纪录。 后端的异步逻辑通过用户的提交时间和纪录的合理性确定是否命中这门课。 最后效果： 所有想选课的人， 都能实时在线跟踪课表情况， 想选这门课的人， 基本上， 都有机会提交选票， 同时派发选票号码，并作公布。 采用后端的异步机制， 确认最终命中的人的选票。 2. 线上 Redis 内存满了，应该如何处理？ 技术逻辑：Redis 内存满首先是查找问题原因， 能从源头解决最好， 不能解决的话， 只能从技术测来解决。redis 是有 cache 的， 可以在 config 文件自己配置 cache 的大小，可以考虑尽量多， 甚至 80%的内存都做分配，同时调整内存的轮询方法， 这个要根据实际的数据来调整。 当然， 一般一个 redis 就是单独一个服务， 可以多开几个 redis 服务并行处理， 这个也是一种方法。 3. 你认为解决高并发问题的本质是什么？ 技术逻辑：其实就是流量分配， 最开始金融行业用的 F5 方案， 到后面各种云端企业用的负载均衡， 到最后各种 K8s ，k3s ， 不外乎就是规划流量。 做好流量和资源的匹配。 就像 k8s 就会说很牛掰的说， 不行的话， 就多配置几个应用， 多配置几个数据库。
