Hello，大家好，我是你们的老朋友小米！今天我们来聊聊秒杀场景下的“削峰填谷”策略，尤其是如何应对那一瞬间的流量暴增。相信大家对“秒杀”这个词已经不陌生了，特别是当你看中的商品突然降价，手指快点，商品就能秒到手！可是，背后这流量可不是闹着玩的。流量爆发时，系统如果没有处理好，很容易崩掉！所以今天，我要分享的内容就是如何削去秒杀场景下的峰值写流量，让系统平稳度过流量高峰。
秒杀场景下的挑战在秒杀活动中，成千上万的用户同时发起请求。对于系统来说，这样的高并发流量会对服务器、数据库等资源带来巨大的压力，往往会导致服务不可用，甚至直接崩溃。尤其是在库存减少和数据库写操作的过程中，瞬间涌入的写请求容易造成锁表、死锁，严重影响整个系统的性能。
这时候，削峰填谷就成了一种非常有效的解决方案。它的基本思路是通过合理的技术手段，将那种瞬时涌入的流量进行平滑处理，从而避免服务器和数据库的崩溃。那么，怎么削去峰值，稳住我们的系统呢？
消息队列：秒杀流量的缓冲带在秒杀场景中，消息队列就是缓冲带。我们可以将用户的秒杀请求暂存到消息队列中，然后再逐个处理。具体流程是这样的：
用户请求秒杀：用户点击秒杀按钮，发出秒杀请求。
业务服务器快速响应：业务服务器接收请求后，不立即处理，而是将请求写入消息队列，同时快速向用户返回一个响应：“秒杀结果正在处理中，请稍等……”。
释放系统资源：这样一来，业务服务器不会因为瞬间的高并发而被拖垮，释放了资源来处理其他用户的请求。
后台慢慢处理：后台从消息队列中按顺序取出秒杀请求，依次处理。
消息队列能够很好地削去秒杀请求带来的流量高峰，因为它将并发请求排队处理，避免了瞬时的大量写操作直接冲击数据库。
削峰填谷：分散压力消息队列的本质是将高峰的请求均匀分布在一个相对长的时间段里处理，这就是所谓的“削峰填谷”。让我们来举个例子：
假设有一场秒杀活动，商品总共 1000 件，每个请求处理时间大约是 500 毫秒。这意味着，如果所有请求瞬间到达，系统需要处理 500 秒的时间！这可不是一般的数据库能承受得住的。
这时，我们可以通过消息队列来削峰填谷。假设我们部署了 10 个处理程序，每个处理程序可以并发处理一个请求。这样，处理1000个请求的时间就缩短到了 50 秒。虽然用户需要等待几十秒才能看到秒杀结果，但这种延迟在秒杀场景下是可以接受的。
这样，系统不会因为瞬时的高并发写操作而崩溃，同时也不会对数据库造成巨大的压力。每次最多并发 10 个请求，保证了系统的稳定性。
解决延迟问题：用户体验优化虽然通过消息队列的方式可以削去峰值流量，但毕竟用户还是要等待一定时间才能看到结果。如何让用户在等待过程中不会焦虑甚至流失，是我们需要关注的问题。
即时反馈：在用户发起秒杀请求后，业务服务器可以立即向用户返回一个处理中状态的反馈，比如提示信息：“秒杀正在进行，请稍等……”，这种即时的反馈会给用户心理上的安慰，让他们知道系统没有“卡住”或出问题。
进度条或倒计时：可以在页面上展示一个进度条或倒计时，提示用户大概还需要多少时间才能得到秒杀结果。这样用户的期待感会增强，耐心等待的时间也就变得更长了。
异步通知：用户的秒杀结果处理完成后，可以通过短信、站内信等方式异步通知用户，这样即使用户离开了页面，也不会错过秒杀成功的消息。
削峰后的数据处理：确保一致性秒杀活动中，库存的减少和订单的生成是核心的业务逻辑。这部分的处理一定要保证数据的一致性，否则用户看到自己秒杀成功，实际上库存已经不足，那就是灾难了。
1.库存预扣减
在处理秒杀请求时，可以在消息队列中设计一个库存预扣减的机制。比如，当消息队列中的请求被处理时，系统首先检查商品的库存是否足够，如果足够就先将库存量扣减，生成订单；否则，直接返回秒杀失败。
这种预扣减机制确保了即使并发量很大，也不会出现超卖的情况。因为库存扣减是通过消息队列按顺序处理的，不会出现多个请求同时扣减库存的冲突问题。
2.分布式锁
如果库存的数据是分布式存储在多个服务器上，为了防止并发写操作引发数据不一致，可以考虑使用分布式锁。Redis等工具提供了可靠的分布式锁实现，可以确保每一次扣减库存操作都是安全的。
削峰填谷的最佳实践在实际的秒杀场景中，为了确保系统的高可用和低延迟，以下是一些最佳实践：
合理配置消息队列的容量：消息队列的容量需要根据业务场景和流量进行合理配置。容量太小，会导致队列被挤爆，丢失请求；容量太大，可能会造成资源浪费。
消息队列的高可用：确保消息队列系统本身的高可用性，避免在高并发场景下队列自身成为瓶颈。可以采用Kafka、RabbitMQ等成熟的消息队列系统，它们在高并发下表现出色，并且支持分布式部署。
数据库的负载均衡：即使削峰填谷后，数据库的负载也不容忽视。我们可以通过读写分离、分库分表等方式来提高数据库的吞吐量。
END在秒杀场景中，削峰填谷是一个非常有效的技术手段，通过消息队列缓冲用户请求，避免了高并发写操作对数据库和服务器的冲击。虽然这种方式会带来一定的处理延迟，但在秒杀场景下，用户对短暂的延迟是有一定容忍度的。
今天分享的削峰填谷技术是处理高并发场景的一个经典方案，不仅适用于秒杀，还可以应用于各种需要削减流量高峰的业务场景。希望大家能够学以致用，打造更加稳定和高效的系统！
如果你觉得这篇文章对你有帮助，别忘了点赞、收藏、分享给你的朋友！我们下次见啦！
我是小米，一个喜欢分享技术的29岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
