如何处理秒杀中同一商品的多次并发请求？
本题考察秒杀系统如何处理用户的高并发请求，这是一个难点，知识内容丰厚， 以下是几种常见的处理策略和技术，来应对秒杀中同一商品的多次并发请求：
1. 分布式锁
分布式锁是一种保证同一时刻只有一个请求能够修改库存的机制。它通常用来解决并发访问时的竞争问题。
实现：
- Redis 分布式锁：可以通过 Redis 来实现分布式锁，保证每个商品的库存在每次请求时只能被一个请求修改。
- 请求秒杀时，首先获取 Redis 锁。锁成功获取后，才继续执行库存扣减操作。
- 如果无法获取到锁，则说明该商品库存正在被其他请求操作，可以直接返回秒杀失败。
- 锁释放后，其他请求可以继续获取锁。
优点：
- 保证原子性：只有一个请求能够成功执行库存扣减操作，避免了并发导致的库存不准确。
- 灵活性：可以针对每个商品设置不同的锁，防止不同商品的并发请求互相干扰。
注意：
- Redis 的
SETNX（Set if Not Exists）可以用来实现分布式锁，但需要确保锁的过期时间，以防止死锁。 - 在获取锁时需要有超时机制，以防锁获取失败后无限等待。
2. 乐观锁
乐观锁是一种假设系统没有并发冲突的策略。当并发请求修改库存时，系统会检测库存是否已被其他请求修改，如果修改了，则让后续的请求重试。
实现：
- 在数据库中维护一个版本号字段（
version），每次扣减库存时，都会检查该商品的库存版本号是否与当前一致。如果一致，执行扣减操作并更新版本号；如果不一致，说明库存已经被其他请求修改，返回失败或重新尝试。 - 例如，在扣减库存时，执行类似 SQL 语句：
如果 version 值不匹配，说明库存已被更新，当前请求无法修改库存。
优点：
- 避免锁竞争：没有像分布式锁那样的性能瓶颈，因为乐观锁不需要在每次请求之间锁定资源。
- 高效：适合于冲突较少的场景，减少了锁竞争带来的性能问题。
注意：
- 重试机制：当并发请求发生冲突时，需要有合适的重试机制，否则可能导致请求频繁失败。
- 数据库压力：对于高并发的秒杀活动，乐观锁可能会频繁碰到库存版本号不一致的情况，从而导致大量请求失败，需要合理调整重试策略。
3. 消息队列
使用消息队列（如 RabbitMQ、Kafka）可以将秒杀请求异步处理，将高并发的请求转化为队列中的消息，逐一处理。
实现：
- 用户的秒杀请求首先进入消息队列，而不是直接访问数据库。消息队列中的每条请求都会被一个消费进程逐一处理。
- 消费进程会从队列中取出一个请求，并对商品库存进行扣减。
- 这样，系统就避免了瞬时的大量并发请求，而是按照队列顺序依次处理请求，防止并发请求导致的超卖。
优点：
- 流量控制：将请求异步化，缓解了瞬时高并发带来的压力。
- 高容错性：消息队列能够缓存请求，即使系统短时间内无法处理请求，也能保证消息不丢失。
注意：
- 消息队列的消费过程需要确保顺序性和幂等性。重复请求需要避免造成重复扣减库存。
本题小结:处理秒杀系统的高并发请求有很多种方法，如分布式锁，乐观锁，消息队列等，大家掌握一种即可，达到举一反三。