1.乐观锁，人再多那就只能队列解决； 2.不造； 3.资源永远是有限的，而 IO 资源更为有限，所以高并发的本质是抢夺有限的资源，解决方法是对资源合理利用（线程和锁的优化，缓存）、流量进行削峰填谷（消息队列）、以及服务器负载均衡来尽量确保资源的合理分配。
1. 大概率是是想问你悲观锁、乐观锁的区别 1.1 使用悲观锁，串行阻塞，资源占用大 1.2 乐观锁，CAS 机制，失败了再增加个重试机制 3. 解决高并发的本质是需求与资源的不对等 3.1 有钱增加资源：分布式、横向/竖向扩容 3.2 没钱增加资源：限流、部分服务不可用
1.秒杀直接上 redis ，把课程 Id 和对应的数量放到 redis 里，抢到后往消息队列发消息，然后通过消费者处理后续的流程。 2.redis 满了之后可以设置过期策略。把策略设置一下就好。 3.这是扩展题。发现性能瓶颈，然后通过削峰、限流、扩容、分表等手段让系统平稳的处理流量。
1.2 个方向 redis decr 或着 队列消费 应该规避回答 mysql 锁相关的回答，我认为是陷阱问题。 2.扩容+监控，实际上不可能满。这种题的预设本身就比较失败 猜测是想问内存碎片相关，或着排查流程类似找大 key ，要么就是集群分片方案。 3.通过优化响应速度提高并发量，应用场景包括不限于缓存/消息队列削峰/部分操作提前等等
@imokkkk 请教一下 第一个问题的这种解法，放内存不合适吧，如果有多个实例同时运行可能会不一致，合并成一次批量扣减，如果在用户提交的时候反馈结果呢 @lsk569937453 请教一下 第一个问题的这种解法 是不是也是不能在用户提交的时候反馈结果呢
@whahuzhihao 我也看过这个，写得非常好。 前三个问题上来就谈具体方案的人基本都是缺少架构设计经验，上面 V2EX 回答大多数都基本上都是具体方案， 同一的问题不同复杂度和需求下设计是不一样的， 不少架构师照搬别人或自己原来公司架构导致崩盘的事件不少。
1 、采用摇号机制，报名同一课程的同学都进一个池子，随机选择。5 分钟一轮。 2 、线上 redis 应该有监控，预警了可以先试着清理：查看内存主要消耗在哪里，是否有必要（数据结构、过期策略）。还是内存不足就扩容，加内存。 3 、高并发的本质是资源共享、导致要争抢（竞争）。
