[Redis]redis的二八定律，冷数据和热数据

最新推荐文章于 2024-08-15 17:09:45 发布

pmdream

最新推荐文章于 2024-08-15 17:09:45 发布

阅读量5.2k

点赞数 2

分类专栏： redis

本文链接：https://blog.csdn.net/pmdream/article/details/106788581

版权

redis 专栏收录该内容

19 篇文章 1 订阅

订阅专栏

1.二八定律

网站访问数据的特点大多数呈现在"二八定律":80%的业务访问集中在20%的数据上。这时为了减轻数据的压力和提高网站的数据访问速度，则可以使用缓存机制来优化网站。

2.redis的冷数据和热数据？

redis是一种以内存为主的模式的高性能，内存是新的磁盘的哲学。

2.1 方案一配合SSDB

ssdb是什么？redis是内存数据库，ssdb是面向硬盘的存储，二者在存储格式和读写方式上有着根本的不同。

ssdb貌似就是一个个人项目，但代码质量还是不错的，整个设计思想比较简洁。

ssdb的主从复制效率很低。binlog和数据是分开存储的，日志冗余较多，由于ssdb本身要在多线程条件下才能发挥出更好的性能，为了使多个线程在写入binlog时能保证操作顺序和原子性，ssdb的binlog数据结构上用了一把全局锁，可想而知，这里的锁竞争会很影响性能。

另外，ssdb默认也没有集群管理的支持。

它结合了redis和ssdb的优点，实现了基于LFU的热度统计和冷热交换，做到了低成本和高性能的高平衡。

redis的好处，那就多了。缺点就是纯内存，比用SSD花钱。

redis比SSD更加费钱，因为纯内存操作。

方案提供ssdb，业务选择接入redis或ssdb

l 实现描述：redis和ssdb独立两套系统，类似之前腾讯提供CMEM和TSSD两套系统。业务开发根据业务特点决定使用哪一套系统。client、proxy可以复用，等同可以选择使用redis存储引擎或leveldb/rocksdb存储引擎。

l 优点：无须开发，只需引入ssdb系统即可。

l 缺点：业务开发可能没办法一开始确定使用哪一套系统。需要维护和运维两套系统。

也就是热数据弄到redis，但是冷数据入持久性kv的nosql数据库

2.2 redis的lru？

通过lru，做数据的换入换出，同时把落地的数据的索引index存到内存中，会让冷数据读取的更快一点。

涉及到redis的存储满了的情况，

在内存不足的情况下，实例本身会根据最近访问时间，访问频度，Value大小等维度选取出部分value作为冷数据后台异步存储到磁盘上直到内存小于制定阈值为止。

因此，Redis混合存储实例的适用场景主要有以下两种：

1、数据访问不均匀，存在热点数据；

2、内存不足以放下所有数据，且Value较大(相对于Key而言)

我们当然希望能够准确的计算出当前最冷的value。然而，value的冷热程度根据访问情况动态变化的，每次都重新计算所有value的冷热权重的时间消耗是完全不可接受的。

Redis本身在内存满的情况下会根据用户设置的淘汰策略淘汰数据，而热数据从内存写到磁盘也可以认为是一种“淘汰”的过程。从性能，准确率以及用户理解程度考虑，我们在冷热数据识别时采用和Redis类似的近似计算方法,支持多种策略, 通过随机采样小部分数据来降低CPU和内存消耗，通过eviction pool利用采样历史信息来辅助提高准确率。

热数据->冷数据

异步方式：

1、主线程在内存接近最大值时，生成一系列数据换出任务；

2、后台线程执行这些数据换出任务，执行完毕之后通知主线程；

3、主线程更新释放内存中的value，更新内存中数据字典中的value为一个简单的元信息；

同步方式：

如果写入流量过大，异步方式来不及换出数据，导致内存超出最大规格内存。主线程将直接执行数据换出任务，达到变相限流的目的。

冷数据->热数据

异步方式：

1、主线程在执行命令前，先判断命令涉及的value是否都在内存中；

2、如果不是，生成数据加载任务，挂起该客户端，主线程继续处理其他客户端请求；

3、后台线程执行数据加载任务，执行完毕后通知主线程；

4、主线程在内存中更新数据字典中的value，唤醒之前挂起的客户端，处理其请求。

同步方式：

在Lua脚本，具体命令执行阶段，如果发现有value存储在磁盘上，主线程将直接执行数据加载任务，保证Lua脚本和命令的语义不变。

冷热数据识别

当内存不足时的情况下，实例会按照最近访问时间，访问频度，value大小等维度计算出value的权重，将权重最低的value存储到磁盘上并从内存中删除。

2.3 数据的冷热？

比如网站的用户总数就是一个小而热的数据，但是比如每个用户的个人轨迹信息就是一个量大但是还冷热不均的数据，

防止数据无限膨胀，所以用户缓存放到内存中都要设立过期时间。

比如，论坛的最新发表列表，最新报名列表，包括比如最新激活的用户可以存在redis做最新列表的使用方式。

redis 一定要用在小而热的情况，防止数据的无限膨胀。

2.4 建议

基于redis做冷热分离从技术上是可行的，从业务实用角度看却不一定。因为首先redis不能很好区分冷热数据，然后很难避免读取落地冷数据时的性能问题，因此肯定不如纯内存的redis性能好，而用户对KV数据库性能的期望是没有最好，只有更好。随着内存越来越大、越来越便宜，更多的数据可以直接放到redis内存，会进一步导致冷热分离成为一个无人使用的鸡肋功能。

最理想的冷热分离是redis能够满足如下三个条件：

l lru淘汰做到淘汰的是最冷数据；

l 只在lru淘汰时落地冷数据；

l 能快速从磁盘读取冷数据并写回到内存。

其实冷热数据也可以结合MYSQL来一起做吧。

参考：

关于redis的冷热数据分离： https://blog.csdn.net/StoneNie/article/details/54708363

Redis混合存储-冷热数据识别与交换：https://www.jianshu.com/p/a648580d9ac9