《Seckill秒杀系统》第96章：热点数据问题与解决方案

作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)
源码获取地址：https://t.zsxq.com/0dhvFs5oR (opens new window)

沉淀，成长，突破，帮助他人，成就自我。

• 本章难度：★★☆☆☆
• 本章重点：了解热点数据问题与其产生的场景，重点掌握解决热点数据问题的落地实现方案，并能够灵活将实现方案应用到自身实际项目中。

大家好，我是冰河~~

秒杀系统最关键的就是要解决高并发读和高并发写的问题，如果某些数据频繁的被读写，就可能会成为热点数据，我们需要充分了解热点数据问题，了解解决热点数据的落地实现方案。最终解决这些热点数据的高并发读和高并发写的问题。

一、前言

在前面的文章中，我们详细的介绍了服务降级的核心原理与落地实现方案，相信小伙伴们对服务降级有了更进一步的认识。其实，秒杀最核心的问题，就是要解决当个秒杀商品的高并发读和高并发写的问题，也就是热点数据问题，对于热点数据问题，我们需要有相应的应对机制，避免由于热点数据打垮整个应用系统。

二、本章诉求

介绍热点数据问题与解决热点数据问题的落地实现方案，从本质上讲，热点问题就是某个或某些商品存在高并发读和高并发写的现象。重点理解理解热点问题产生的场景与应对方案，并能够将其灵活应用到自身实际项目中。

三、热点数据

一般情况下，用户在秒杀活动开始前，就已经打开APP、小程序或者PC页面，在等待秒杀活动开始的同时，也会不断刷新页面来查看是否能够点击抢购按钮，以便秒杀活动开始的瞬间来点击抢购按钮，抢购自己喜欢的商品。

当秒杀活动开始的瞬间，会有大量的请求进入秒杀系统，此时系统的压力骤增，最直接的表现就是CPU使用率上升，IO处理与等待时间变长等等。此时，为了保证秒杀交易链路的整体稳定性，我们会对部分非核心服务进行降级处理。

但是对于某些秒杀商品来说，可能会存在高并发读和高并发写的现象，从而产生热点数据问题。所谓的热点数据，通常是从单个数据在单个时间单位内被访问的频率来说的。如果在单个时间单位内，比如1秒内，某个数据被访问的非常频繁，就可以将这个数据称为热点数据。

四、常规解决方案

热点数据的本质，就是数据的高并发写和高并发读。相信很多小伙伴第一印象就是分库分表，如果涉及到Redis的话，就可以通过增加Redis的分片来解决。在设计应用层的程序代码时，将其设计成无状态的模式，这样，无论是应用层的服务、还是Redis缓存，亦或是数据库，都可以通过横向扩展系统资源来提升系统的整体处理能力，解决高并发问题。

但是，细细想来，这种对数据库分库分表，对Redis缓存增加数据分片，横向扩展应用服务的方案真的可行吗？

要知道，热点数据是针对某个秒杀商品来说的，对这个特定的秒杀商品来说，无论再怎么对数据库分库分表，或者再怎么增加Redis的分片数量，这个商品实际上还是会落在某个特点的数据表或者Redis分片中，实际上并没有提升对这个商品的并发读写能力。一旦某个商品的高并发读写流量把Redis打挂，就可能造成缓存击穿，最终发生服务雪崩。

所以，针对热点数据问题，我们还是要有优化的解决方案才行。

五、优化解决方案

对于热点数据问题，我们不能仅仅按照常规的分库分表，增加缓存分片的思路去处理，在这些常规的处理方案之上，我们还要进一步优化落地方案。既然热点数据问题是高并发读和高并发写问题，那我们就可以将热点数据问题分为读热点数据和写热点数据两个方面来进行论述。

5.1 读热点问题解决方案

读热点问题就是某些商品会频繁出现高并发读，解决读热点问题通常会有两种解决方案，一是增加热点数据的副本数，二是热点数据放到服务进程内存中。

1.增加热点数据的副本数

我们先来看增加热点数据的副本数的解决方案，假设我们目前的秒杀系统部署结构如图96-1所示。

查看完整文章

加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码