服务端加入缓存
1. 背景
因为项目进度赶得比較紧。并且第一次自己设计系统的架构，刚開始考虑的并不全然，主要想着先把系统的功能实现了再说。因此刚開始设计系统的时候并没有考虑缓存的问题。可是对已一个web系统。缓存不仅能够大大的降低数据库的压力，也能够非常大程度的提高系统的响应时间。如今系统的功能完毕的基本差点儿相同了，因此如今须要为系统加入缓存。可是因为系统功能已经完毕的差点儿相同了。代码写的也非常多了，所以如今加入缓存确实显得比較困难了。
先说说我们当前系统的总体框架结构吧。
从图中能够清楚的看出，我们眼下採用的架构比較简单，全部的请求都通过.htaccess文件转发到index.php然后在index.php文件里启动转发函数。通过请求的将请求分配到特定的’Server’运行特定的Action。在此Action里调用一个服务从数据库里取出数据返回给client。以下是当前系统的类图(为了显示出调用的方法。所以有点不规范)。
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文章的博主，给了我非常到的启示。