学习任何新知识,都是一个循序渐进的过程,从刚开始的懵懂无知,到简单熟悉,然后突然的彻悟,成果让人欣喜若狂,心情也会快乐很久。
redis+mysql和内存+硬盘类似的地方
首先看图:
首先,我们知道,mysql是持久化存储,存放在磁盘里面,检索的话,会涉及到一定的IO,为了解决这个瓶颈,于是出现了缓存,比如现在用的最多的memcached(简称mc)。首先,用户访问mc,如果未命中,就去访问mysql,之后像内存和硬盘一样,把数据复制到mc一部分。
redis和mc都是缓存,并且都是驻留在内存中运行的,这大大提升了高数据量web访问的访问速度。然而mc只是提供了简单的数据结构,比如string存储;redis却提供了大量的数据结构,比如string、list、set、hashset、sorted set这些,这使得用户方便了好多,毕竟封装了一层实用的功能,同时实现了同样的效果,当然用redis而慢慢舍弃mc。
内存和硬盘的关系,硬盘放置主体数据用于持久化存储,而内存则是当前运行的那部分数据,CPU访问内存而不是磁盘,这大大提升了运行的速度,当然这是基于程序的局部化访问原理。
推理到redis+mysql,它是内存+磁盘关系的一个映射,mysql放在磁盘,redis放在内存,这样的话,web应用每次只访问redis,如果没有找到的数据,才去访问Mysql。
然而redis+mysql和内存+磁盘的用法最好是不同的。
redis+mysql和内存+硬盘运行模式是不同的
了解过内存和硬盘运行过程的同学,都知道他俩之间通过页面置换算法进行调度,也就是说每次是按块将数据从硬盘换入或者换出内存,比如硬盘有一个100G的文件,如果要读 这个文件,内存中每次只放该文件10MB的一部分(图1中的小块就是这个意思)。
于是有人会猜测,mysql存储了100G的数据,用户访问mysql的时候,把10MB数据拷贝到redis,比如select一个id=1000的数据,那就把id=10到id=9999的数据放到redis,用于下次访问。可是关键在于mysql数据的访问,并不是文件这种局部性原理,不同的用户访问的是完全不同的东西,跟id的次序没有任何关系。
其实redis的强项也不在此,它擅长保存元数据类的数据,也就是说描述性的而不是数据本身
就此我假定了redis的几个应用场景,请大家批评指正:
存放计数器的数字
存放检索关键词的id列表(不放内容)
存放用户之间的follow关系(非用户信息)
存放简单的静态Html,而非所有的CSS和JS
总之发现,就是redis大量存放的是数据表的索引字段,如果刚好用到符合条件的信息,可以根据索引字段,再去mysql查找,比如搜索关键词”redis”,第一步我们去mysql获取redis相关的信息返回给用户,然后记录一个zset,将redis作为名字,将搜索到的每个Id以先后顺序存在里面,那么下次有人搜索”redis”,直接根据该列表去mysql找对应id的信息就行了,这已经大大提升了访问速度。
下图是一个检索的流程图: