服务端添加缓存
1. 背景
由于项目进度赶得比较紧，而且第一次自己设计系统的架构，刚开始考虑的并不完全，主要想着先把系统的功能实现了再说。因此刚开始设计系统的时候并没有考虑缓存的问题，但是对已一个web系统，缓存不仅可以大大的减少数据库的压力，也可以很大程度的提高系统的响应时间。现在系统的功能完成的基本差不多了，因此现在需要为系统添加缓存，但是由于系统功能已经完成的差不多了，代码写的也很多了，所以现在添加缓存确实显得比较困难了。
先说说我们当前系统的整体框架结构吧。
从图中可以清楚的看出，我们目前采用的架构比较简单，所有的请求都通过.htaccess文件转发到index.php然后在index.php文件中启动转发函数，通过请求的将请求分配到特定的’Server’执行特定的Action，在此Action里调用一个服务从数据库里取出数据返回给客户端。下面是当前系统的类图(为了显示出调用的方法，所以有点不规范)。
2. 添加缓存
添加缓存的方法有很多，最让人想到的就是直接在dao层添加，在从数据库取数据之前，首先先从缓存取，如果缓存没有的话再从数据库取，然后放到缓存里。另一种策略是在service层添加缓存，也就说从将从dao层取出的取出的数据进行拼装之后放到缓存里。
首先分析一下两种方案的优缺点：
第一种方案：
优点：首先在dao层添加缓存对每条sql的执行结果进行缓存，缓存的粒度比较小，缓存的命中率会比较高。
缺点：每个sql查询数据不一样，则可能本来是同一个信息，但是可能仅仅是多了一个字段确又多了一条缓存记录，这是很大的浪费，毕竟缓存的成本还是比较高的。其次如果直接在dao层进行缓存，有些地方其实是不想进行缓存的，那么这样就比较不方便控制了。
第二种方案：
优点：在service进行缓存，首先是在原来系统的基础上添加代码比较少，其次对拼装好的数据缓存由于service的参数一般变化不大，缓存的数据就会比较少，命中率也不错。
缺点：缓存的粒度比较大，命中率不会那么理想，而且缓存的重用性也比较差。
综合上面的分析基本可以知道无论是在dao层还是service层进行缓存都既有优点又有缺点，最后经过考虑结合两者的优点，抽象出一个缓存层，在缓存层里控制是否进行缓存，以及缓存的逻辑，同时将缓存的对象改为数据库对应的一个一个对象，这样缓存对象的重用性以及命中率都有很不错的效果。
下面是添加缓存后的类图：
在原来的框架基础上再service里直接调用cacheServer加载指定的cache，原来的service逻辑不用改变，只有叫原来调用dao的改为调用cache即可。
到此缓存基本已经添加完成，编码也完成了，使用起来目前感觉还可以，又不合适的地方希望读者可以多多交流。
最后感谢http://www.crackedzone.com/server-need-a-new-datastore-layar.html文章的博主，给了我很到的启发。