Redis诞生之前

最新推荐文章于 2024-10-31 14:53:53 发布

FA-117

最新推荐文章于 2024-10-31 14:53:53 发布

阅读量1k

点赞数

分类专栏： Redis 文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/weilaizhixing007/article/details/131150197

版权

Redis 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

文章探讨了Redis作为分布式缓存的起源，从关系型数据库的数据存储和内存管理开始，分析了缓存的必要性和工作原理。Redis的出现是为了解决热点数据的高速访问需求，通过提供丰富的数据类型优化读写操作，并作为一种跨语言的网络服务提高效率。文章还讨论了缓存策略和数据结构在系统性能中的重要性。

摘要由CSDN通过智能技术生成

前言

Redis作为一个分布式缓存在日常开发中得到了广泛的使用，但Redis是怎么产生的，个人分享下自己的想法以及由此产生的联想。

一、从关系型数据库开始

已知的关系型数据库（比如MySQL，Oracle）数据默认都是存储在磁盘上，然后按需加载到内存中，客户端请求数据时从内存中返回。但“需要”的评判标准和"加载"方式各不相同，这些暂时不关心，咱们只关心磁盘存储和内存存储的特点。

类别	I/O寻址	I/O带宽	容量	成本
磁盘	ms级	<1GB/s	T级别	相对较低
内存	ns级	>=1GB/s	G级别	相对较高

抛开持久化来说，使用磁盘和内存，兼顾容量和成本。如果数据量太大，而内存又不能完全放下，那只能将需要的数据放入内存。但决定哪些数据是需要的则是由客户端触发。为了加速这个决定的过程，关系型数库中引入了索引的概念。

如果数据库认为SQL操作可以走索引，那么数据库可以通过索引来快速决定哪些数据是需要加载的，然后启动磁盘IO。如果数据库认为SQL操作无法走索引，那就变成了全表扫描，只能从头到尾读一遍。效率差异可想而知。

显然，如果我们来开发一个DB，会在DB启动时将索引加载到内存中，后续尽可能基于索引来操作数据。这个典型的数据结构就是B+树。此外，虽然可以按需加载，但如果磁盘数据100G，内存只有4G，按需加载之后还得按需卸载才能持续运转（显然这是一个时间换空间的策略），这就是咱们常听到的缓存。

二、再看缓存

假设DB运行了1年，那缓存里面都是些什么数据呢？肯定都是热点数据，并且大概率是读的热点数据，因为一般读会反复玩多次，写的话整一次就完事了(同样的数据反复写多次, 目前还没咋见过)。

但这些热点数据又是怎么来的呢？热点数据当然是DB客户端操作导致的。所以这些热点数据对DB客户端来说也是热点。那你就会想这个缓存能不能单独提出来，被应用直接使用，这样就连DB也不用请求了。

再者，缓存中的数据如果没有，还可以再请求DB，这样持久化就是非必选的。加上热点数据本身也比较少，完全可以全部放在内存中。

综上，咱们应该就有一个基本的概念了，热点数据存储在内存中，可以被应用侧直接使用，必要时再从DB中读取。这里我们可以理解Redis作为一个独立的缓存的必要性。

三、再看业务

热点数据的逻辑形式是一条条的数据（可能是用户信息，可能是商品详情），在DB中可能是一行行的表记录或者多张表记录的聚合，因此原本可能需要多次DB操作的结构，在缓存中可以一波搞定。这也是咱们的独立缓存与DB本身缓存的区别之处。当然，这里关注的是读操作。

鉴于数据已经在缓存里了，也就是操作对象已就位，咱们通常希望是有读有写。如果是进程内的缓存, 本身就是对象，可以直接根据key找到对象，然后更新对象的一部分。注意是更新对象的一部分（姑且称为半写），同样也存在“半读”需求。

对于远程缓存服务来说，如果缓存只做存储，那么不存在"半读"和"半写"，因为只能把整个对象序列化之后全部发送给客户端（这是全读），客户端再序列化之后全部发送给缓存服务(显然这是全写)。这里耗费更多的带宽和CPU。我们得做进一步的优化。

这时候咱们就需要数据类型了，就像关系型数据库一样，我们可以指定更新某个对象(id)的一列，最终由远程缓存服务在本地缓存中完成更新。搞过大数据的小伙伴可能会说，“这是计算向数据移动”。所以，Redis就设计了5大数据类型。

四、作为网络服务

这个个人认为有几个原因:

由于缓存本的概念出现比较早，进程内缓存相关库已比较普遍，甚至可以自己搓一个简单的LRU缓存；
进程内缓存是与语言强相关的，作为网络服务可以屏蔽掉语言本身的差异；
作为网络服务，可以做到热点数据对全集群可见，收益不仅是单个进程，而是整个服务，价值更大；

五、个人联想

关于缓存

缓存的作用是加速读写，其加速的原理是让需要的数据距离CPU更近。但最终实现，则是一个策略的选择问题。热点数据的大小，原始位置，加载方式等都会影响最终的策略选择。

从结构说起

从结构角度来说，一个应用程序含数据结构和程序结构两部分。鉴于数据存在于文件和内存，而两者特点不同，因此相同的数据在文件和内存中其结构是完全不同的。程序结构则更多是我们如何使用设计模式拆解目标功能。而最终服务用户的，不是应用程序文件，而是进程，因此我们还需要关注进程态的运维结构，也就是服务的部署和维护（涉及流量接入，流量分发、流量处理以及最终转换为数据的数据存储等）。程序结构和数据结构其涉及的知识是相对固定的，关键看个人后续的运用。而运维结构则是一种架构层次的概念，是一个个团队协作的结果，甚至不同团队画风完全不同，因此相对复杂。希望每个致力于此的小伙伴潜心积累经验，静待花开。