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的操作；使用缓存可以有效的避免这种情况；所以在架构设计过程中，涉及到查询数据库的时候，应该考虑一下是不是考虑使用缓存技术来提高系统的性能，并且降低数据库的负载。

转载于：http://blog.csdn.net/weis_2007/article/details/50678281