1. 介绍
cache就是人们所说的缓存。我们这里所说的cache是web上的。对用户来说，衡量一个网站是否具有良好的体验，其中一个标准就是响应速度的快慢。可能网站刚上线，功能还较少，数据库的记录也不多的情况下，网站可能访问速度比较快，也不需要优化。但是随着网站发展起来，功能越来越多，数据库越来越大的时候，这个时候可能网站的访问速度就会下降。无论网站刚上线初期还是到一定程度的情况，我们都希望网站具有良好的响应速度。
而要怎样提高页面响应速度呢？其中一个方法当然就是本章所说的cache。先来说整个网站的请求响应的过程：用户从浏览器发出一个请求，比如点击一个按钮或在浏览器输入网址回车，然后经过层层的网络最终到达网站的服务器，假设我们用nginx来作为静态文件服务器，而用unicorn作为运行ruby代码的容器，先经过nginx处理，nginx一般是处理html，css，js的，它会默认处理带有htlm，css，js后缀的请求，比如/articles.html，如果发现有它处理不了的，比如/articles/1这样的请求地址，因为nginx没有匹配这样的地址，就会反向代理到unicorn，unicorn是运行ruby代码的，它会连接数据库，它可能从数据库取到一些数据，把数据处理完，再返回给nginx，最nginx返回给用户。
这里所说的unicorn是运行ruby代码的应用容器，当然也可以是php或java的容器，比如tomcat等。道理是一样的。
server {
listen 80 default_server;
server_name www.rails365.net;
root /home/yinsigan/rails365/current/public;
...
try_files $uri/index.html $uri @rails365;
location @rails365 {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://rails365;
}
...
}
上面是nginx的配置文件的部分内容，网站根目录是/home/yinsigan/rails365/current/public，具体看try_files $uri/index.html $uri @rails365;这一句，当用户在浏览器请求/about.html地址时，nginx会首先看网站根目录有没有about.html这个文件，有的话就直接读出根目录下的about.html，因为nginx默认会对html后缀的文件作处理的，读完后直接返回响应给用户，就完成了这一次请求，没有的话，就会请求@rails365的内容，也就是反向代理到unicorn服务器。
整个请求过程无论哪一阶段都是需要时间的。而最影响速度也最容易产生性能瓶颈的主要有三个地方：
nginx处理静态文件的过程
nginx和unicorn交互的过程
unicorn和数据库交互的过程
第一点，nginx处理静态文件的过程主要指的是处理图片、javascript、css文件的过程。假如这些文件数量很多，体积又很大，在这一过程是需要耗费很多时间的，但是这些可以通过nginx的gzip来压缩大小、浏览器cache或CDN等技术来解决，这点不在cache的范围内。
第二点，nginx作为反向代理服务器和应用服务器unicorn的交互也是需要时间的，nginx也作为静态服务器只能处理一些简单的静态服务器，而unicorn可以处理复杂的逻辑，不过最后unicorn还是要转化成html给nginx，nginx再给用户，所以整个请求过程如果不到unicorn，由nginx直接返回那就更好了。这样是能大大增快响应速度的，因为不仅nginx到unicorn那步少了，而unicorn到数据库这一步也不用了，所以还是有效的，但是它有一些不好的弊端，具体的我们下面会说到。第二点的解决方案是通过nginx的proxy_cache或者文件cache来解决。
第三点，应用服务器和数据库的交互，这个数据库我们一般指的是关系型数据库，比如MySQL、PostgreSQL等。这个过程是很重要且很常见的，毕竟几乎所有网站都需要数据库来存储数据吧，但数据库很庞大时或者对数据库处理不当时，这个交互过程是很耗费时间的，所以我们会在这个过程用redis作为cache来解决。
2. cache的种类
cache有很多种，比如上文提到的文件cache，nginx的proxy_cache，浏览器的cache，html片断的cache，除此之外，还有代理服务器的cache，CDN的cache，数据库级的查询cache。这篇文章我们只会讲述文件cache还有用redis来实现cache的情况。
3. 文件cache
文件cache在上文有提到，就是在nginx和unicorn交互的过程中发挥作用的，就是让请求直接给nginx处理，而不经过unicorn。打个比方，比如要浏览一个博客网站的首页，首页列出了最近的十篇博文，这些博文肯定是存储在数据库中，请求先通过nginx，nginx再通过unicorn，unicorn去数据库取到这些博文，再组装成html文件再给nginx，nginx再给用户，整个过程完成。而文件cache要做的是当unicorn组装成html给nginx的时候，也顺便在网站根目录下生成.html结尾的文件，这样下次访问就不用经过unicorn了，直接在网站根目录取文件就可以了。这种方式，说白了，就是把动态的查询静态化，让请求过程少了，当数据库有查询瓶颈的时候用这种方式是有好处的。但是这种方式有一个弊端，就是有登录系统的情况，比如一个首页，同样是相同的网址，每个人访问就有不同的页面，因为是不同的用户在访问，比如导航菜单，可以就会出现你的名字。文件cache办不到这种事，因为它是根据地址来处理的，比如访问http://www.example.com/articles.html，它会找根目录的articles.html文件，可是这个文件只有一个啊，但我们需要的是有多少个用户就有不同的页面，所以它不好判断，就算判断了，也失去了本来静态化的意义。所以文件cache只适合那种展示页面用的，很多时候并不适用，毕竟现在谁的网站没个登录系统呢。
4. 用redis实现cache的原理
上文也有提到文件cache的情况，cache的原理就是用一种访问更快的介质或更少的请求来提高查询速度。用redis来实现cache也是一样的道理。我们先不管redis最终会存储什么内容，我们有个对比的介质，那就是关系型数据库，把存到关系型数据库的内容换到redis来存，那就是用redis来实现的cache。这样就出现了两种存储介质的数据的对比，这个数据的存储是有时间性的。当第一次浏览带有数据库查询的页面的时候，页面的数据先从数据库那里获取，获取完之后存一份到redis，比如存成string，articles_count: 100，意思是把文章的总数存到redis中。当存到redis时，我们可以设置过期时间，也可以让它永远不过期。第二次以及以后的访问，就会直接到redis去查找key为articles_count的是不是有值(数据过期就等于没有值)，有的话，直接取，没有话，还是会取数据库，然后再放到redis。当你的真实的数据库记录更新的时候，比如这个时候增加了一篇文章，除了把这一篇文章存进数据库外，还要把redis中的对应的值改过来，这样就能保证取到最新的值的。
5. 页面哪些地方需要cache
现在以本站作为实例，来考虑下页面上哪些地方要使用cache。使用cache有个原则，就是这个页面部分的内容可能是耗时的，也有可能是很少改变的。比如底部，这个部分是基本不变的。