遇到高并发的需求该如何处理

一、案例：

我所在公司有同事吧，同事吧可以添加活动报名。当下遇到一个问题是，中秋即将到来，我们再同事吧设定名额，让大家抢票参加活动。之前做的系统出现抢占人数超出限制，或是系统崩了的情况。同事吧用户8K多人，同时参加将会产生高并发的情况。

那针对这种情况，产品设计的时候可以做哪些事情呢？在技术实现上需要注意些什么呢？

二、解决方案和思路整理：

一、前端优化

1、限流提示：

• 在前端显示当前的抢票人数和剩余票数，让用户了解抢票的竞争情况。
• 当抢票人数接近系统承载极限时，给出提示，告知用户当前抢票压力较大，可能会出现延迟或失败的情况，让用户有心理准备。

2、防止重复提交：

• 在用户点击抢票按钮后，立即禁用该按钮，防止用户重复提交请求。可以通过设置按钮的 disabled 属性或者使用 JavaScript来实现。
• 可以在前端对用户的请求进行一定的限流，例如在一定时间内只允许用户提交一次请求。

二、后端优化

1、队列机制：

• 使用消息队列（如 RabbitMQ、Kafka等）来处理抢票请求。将抢票请求放入消息队列中，由后台线程依次处理，避免瞬间高并发请求直接冲击数据库和业务逻辑层。
• 可以根据系统的处理能力，设置合理的队列长度和处理速度，确保系统不会因为过多的请求而崩溃。

2、乐观锁或悲观锁：

• 在数据库层面，可以使用乐观锁或悲观锁来防止超卖情况。
• 乐观锁可以通过在数据库表中增加一个版本号字段，在更新数据时检查版本号是否一致，如果一致则进行更新，否则表示数据已经被其他用户修改，需要重新获取数据进行处理。
• 悲观锁则是在查询数据时就对数据进行加锁，其他用户无法同时修改该数据，直到当前用户完成操作后释放锁。

3、缓存预热：

• 在抢票开始前，可以将一些热门的票信息提前加载到缓存中，减少对数据库的查询压力。
• 可以使用缓存框架（如 Redis）来存储票的信息和剩余票数，在抢票过程中，优先从缓存中获取数据，提高响应速度。

4、分布式锁：

• 如果抢票系统是分布式部署的，可以使用分布式锁来确保同一时间只有一个节点在处理某个特定的票的抢票请求。
• 可以使用分布式锁框架（如 Redisson）来实现分布式锁，确保数据的一致性和系统的稳定性。

5、限流和熔断：

• 可以在后端设置限流策略，限制同一时间内的抢票请求数量。例如，可以使用令牌桶算法或漏桶算法来控制请求的速率。
• 当系统负载过高时，可以触发熔断机制，暂时停止接受新的抢票请求，直到系统恢复正常。

三、服务器优化

1、水平扩展：

• 如果系统在高并发情况下出现性能问题，可以考虑增加服务器的数量，进行水平扩展。
• 可以使用负载均衡器将请求分发到多个服务器上，提高系统的并发处理能力。

2、性能优化：

• 对服务器的硬件资源进行优化，如增加 CPU、内存、存储等资源，提高服务器的处理能力。
• 对服务器的软件配置进行优化，如调整数据库连接池大小、线程池大小、缓存策略等，提高系统的性能。

四、监控和报警

1、实时监控：

• 使用监控工具（如 Prometheus、Grafana 等）实时监控系统的性能指标，如 CPU
  使用率、内存使用率、网络流量、请求响应时间等。
• 对抢票的关键业务指标进行监控，如抢票成功人数、剩余票数、请求失败率等，及时了解系统的运行状态。

2、报警机制：

• 设置报警机制，当系统性能指标超过阈值或出现异常情况时，及时发出警报，以便及时处理问题。
• 可以通过邮件、短信、即时通讯等方式发送报警信息，确保相关人员能够及时收到通知。