redis 实际应用中的缓存作用
从系统的层面说,CPU的速度远远高于磁盘IO的速度;所以要想提高响应速度,必须减少磁盘IO的操作,但是有很多信息又是存在数据库当中的,每次查询数据库就是一次IO操作;比如查询用户信息的例子,通常如下图:
请求响应时间等于网络响应时间和服务器响应时间;网络我们控制不了,服务器响应时间包括CPU计算时间和磁盘IO时间,其中CPU计算时间这个有硬件资源决定的,我们尽量减少算法的复杂度来减少它,磁盘IO时间,这个时间是非常慢的,应该尽量减少;
当客户端调用getUser接口的查询用户信息的时候,执行顺序1、2、3、4;由于用户信息存放在DB中,所以2、3就有一次磁盘IO;这个看似非常简单业务逻辑,但是当你做架构设计的时候往往要考虑最坏的场景,或者当成千上万的用户频繁的调用这个接口应该怎么处理?如果按照上图这样的架构处理,这个看似简单业务的接口会使整个系统变慢,这样用户的请求就会长时间得不到响应;这样的问题怎么解决那,这时候就该缓存登场了;
谈到缓存有几种形式,其中最简单的是在每个进程中开辟一块内存,存放缓存的信息,每次先从内存查… … 但是在一个分布式或者集群的环境中,getUser的接口可能会部署多套,每个进程的的内存是不能共享、相互独立的,这就悲剧了;还有一种使用一个第三方的缓存也叫公共缓存(比如redis、memcache等);不论部署多少个包含getUser接口的服务,都去访问同一套缓存,那结果就不一样了,看一下下面这幅图:
当用客户端调用getUser接口查询用户信息的时候,getUser接口直接去redis中查询,如果redis中有该用户信息,直接返回,避免查询DB,从而避免了磁盘IO操作;如果redis中没有该用户信息,则从DB查询,并且把该用户信息存放到redis中;这样在服务接口(getUser)和DB中间,增加了一个缓存层;看似逻辑增加了,其实当面对高并发的时候,比如上边提到的频繁查询用户信息的情况,只有第一次查询有磁盘IO操作,以后只要redis中存在就没必要再查询数据库了;由于没有了磁盘IO操作,并且redis所有数据都在内存操作,所以速度回大大提升;
我们上面用到的缓存是redis,其实常用的还有memcache等,它们都提供了集群模式,并且都是直接内存操作,所以速度特别快,也是目前业内使用的比较热门的技术;redis相对于memcache提供了更丰富的数据类型,根据不同的业务场景可以选在不同的数据类型;redis本身也提供了主从模式、集群模式;也有第三方的比如codis提供了redis集群解决方案;这次咱们主要聊缓存在架构设计中的作用,等有机会详细介绍redis的使用;
总之一句话,要想提高系统的性能,尽量减少IO的操作,特别是磁盘IO的操作;使用缓存可以有效的避免这种情况;所以在架构设计过程中,社交到查询数据库的时候,应该考虑一下是不是考虑使用缓存技术来提高系统的性能,并且降低数据库的负载。