如果数据也要像垃圾一样分类，热数据算哪类呢？
大家好，我是鱼皮，今天分享一个有点儿干的技术知识。
大家知道，各种网站、应用的运行离不开数据的支撑，尤其对于企业来说，业务数据就是它的生命。
但有时，将所有数据堆成一坨、统一处理可能无法满足我们对性能和存储空间等要求。因此，我们需要对数据进行分类处理，以适应不同的业务需求和应用场景。
其中，有一种划分方式是将数据分为 “热数据”、“冷数据”，甚至还有 “暖数据”！
就和垃圾分类一样一样的~
先来聊一聊什么是热数据吧！
什么是热数据？
顾名思义，热数据是指 很热门、频繁被访问 的数据。
比如某度热榜上的新闻，可能每秒都会有成千上万次的访问量。
根据热数据的特点，又可以分为两类：
- 有预期：数据成为热门是在意料之中的，比如提前预告的大促活动中由网红代言的爆款商品，某宝的双十一购物节就是最好的例子。
- 无预期：数据的访问量突然飙升！可能是受到了人为恶意攻击、网络爬虫，或者是不经意间突然火爆的内容。比如突然出现了一个大新闻，某浪微博还没来得及做好防护，可能就炸了。
为了应对热数据，通常我们会选用缓存技术，将数据以 K / V（键值对）的方式提前存储到内存中。
键值对
当我们需要访问缓存数据时，需要根据一个 key 字符串，来找到对应的值。
频繁被访问的 key，又称为热 key，热 key 是一个广泛的概念，不仅仅局限于缓存系统，例如以下这些都是热 key：
- 数据库中被频繁访问的主键，如爆款应用的 appId
- K / V 缓存系统中经常被访问的 key
- 恶意攻击、机器人刷的请求信息，如用户的 userId、机器 IP 等
- 频繁被访问的接口地址，如 app 信息查询 /app/query
- 统计单个用户访问某接口的频率，如 userId + /app/query
- 统计某台机器访问某接口的频率，如 IP + /app/query
- 统计某用户访问某接口特定内容的频率，如 userId + /app/query + appId
了解了啥是热数据后，我们再来聊聊热数据探测技术，即 “找出热数据” 的技术。
为什么要检测热数据？
我们检测热数据的原因很简单：
1. 提升性能
如果使用分布式缓存，在读取时还是需要网络通讯的，就会有额外的时间开销。那如果能对热点数据提前进行本地缓存，即预热，就能大幅提升机器读取数据的性能，减轻下层缓存集群的压力。
热数据多级缓存读取流程
当然，这不意味着所有数据都应该存储到本地。缓存级数越多，更新操作就越复杂，数据不一致的风险就越大！
2. 规避风险
对于无预期的热数据（热 key），可能会对业务带来极大的风险，可将风险分为两个层次：
对数据层的风险
正常情况下，Redis 缓存单机就可支持十万左右 QPS（每秒请求量），并能通过集群增大并发度。对于并发量一般的系统，用 Redis 做缓存就足够了。但是如果有一个商品数据突然爆火，或者收到恶意请求，对该数据 key 的访问 QPS 可能飙升到百万、千万量级！在低版本 Redis 单线程的工作方式下，会导致正常的请求排队，无法及时响应，严重时会导致整个分片集群瘫痪。
还有一种情况，某热点 key 突然过期，会导致大量请求直接砸向脆弱的数据库，导致数据库挂掉！
对应用服务的风险
每个应用在单位时间所能接受和处理的请求量是有限的，如果受到恶意请求的攻击，让恶意用户独自占用了大量请求处理资源，就会导致其他人畜无害的正常用户的请求无法及时响应。
恶意请求导致的请求排队
因此，需要一套动态热 key 检测机制，当无预期的热点数据出现时，第一时间发现他，并针对这些数据进行特殊处理。如本地缓存、拒绝恶意用户、接口限流 / 降级等。在提升数据访问性能的同时规避可能的风险。
那么如何检测热数据呢？
如何检测热数据？
首先，我们需要给 “热” 定义一个阈值或规则，到底多热算热呢？
可以根据经验值定义，也可以根据系统数据的平均热度来定义，比如 1 秒内访问 1000 次的数据算是热数据。
对于单机应用，检测热数据很简单，直接在本地为每个key创建一个滑动窗口计数器，统计单位时间内的访问总数（频率），并通过一个集合存放检测到的热 key。
滑动窗口
而对于分布式应用，对热 key 的访问是分散在不同的机器上的，无法在本地独立地进行计算，因此，需要一个独立的、集中的 热 key 计算单元。
至此，可将热数据探测工作分为配置规则、热 key 上报、热 key 统计、热 key 推送四个步骤：
- 配置规则：指定热 key 的上报条件，圈出需要重点监测的 key
- 热 key 上报：每台机器将自己的 key 访问情况上报给集中计算单元
- 热 key 统计：收集各应用实例上报的信息，使用滑动窗口算法计算key的热度
- 热 key 推送：当key的热度达到设定值时，推送热key信息至所有应用实例，各应用实例将key值进行本地缓存。
上报和计算
通过上述步骤，一套基本的热 key 检测机制就完成了。但热数据探测系统往往会面对复杂的业务场景，还要考虑其他的问题，比如 key 失效处理等。
有赞 TMC 热 Key 探测设计
为满足高并发场景，在设计热 key 探测框架时，还应重点关注如下指标：
- 实时性：考虑到热 key 的突发性（甚至可能是 1 毫秒），必须能够实时发现热 key 并推送
- 高性能：框架应保持轻量且高性能，有效降低成本
- 准确性：精准探测符合规则的热 key，不漏报、更不误报
- 一致性：保证应用实例与本地缓存的热 key 一致，不能出现数据错误
- 可扩展：要统计的 key 数量级很大时，集中计算集群可水平扩展
此外，优秀的热 key 探测框架还应满足易接入、业务无侵入、可动态配置、规则热更新、可视化管理等特性。
最后，想深入学习的同学可以看一下京东开源的热 key 探测框架 JD-hotkey 以及有赞开源的 TMC，他们的设计都非常巧妙。
我之前也写过有关这两个框架的分析文章，后面有机会整理下再发出来。