不同的cache比如apc xache memcache是设计为接口实现比较好还是抽象类比较好？

Question

可以方便切换

Answer 1

我的实际需求是前端页面可以灵活切换数据源db,memcache,file,socket,cgi,mongodb,redis  另外可以切换不同的缓存方式，就象我提的apc,xcache,memcache, 举个例子，开始数据是保存在数据库的，后来切换成mongodb了，我在前端只需要修改一下数据源配置，或者前端页面请求可能读好几个数据源，比如列表是redis中读,一个新闻是从db中读，另外一些是从文件中读的，只需要传入不同的数据源配置参数即可，因为前端的业务不是很复杂，只是简单的query,没必要用action,service,dao那一套，便是对性能和并发要求高，而且在并发量压力下做架构调整时能平滑过渡，这个已经实现的差不多了，接下来是缓存的实现，每一个数据源设置时都带一个可选cacheDep配置，比如一个数据并发量小的时候是放在xcache中的，并发量大了就切换到memcached中，只需要修改一下cacheDep的配置，就可以，另外cache的更新是基于cacheDep过期时间参数配置的，我想做成数据更新时用update 中加hook实现触发更新缓存，但需要设计一个好的key实现方法，前后端都要用同一套key的实现策略，这样可以根据key的前缀，或者指定tag来清除缓存，不知道cache是实现为抽象类，还是接口更合理一些

Answer 2

好像没说正题，瞧我这二的。

抽象的继承、重载等，都是要性能损耗为代价的。面向接口，是不错的选择。特性描述其实真的不需要太多的实现。

Zend Frameword那样搞，也太费周章了。但是他有Zend Server，搞得起。

一般来说，针对实用性而言，数据持久化，有以下几种划分：

外部的socket服务（其实mysql、memcache或者自己写服务都属于这种），基于本地IO（数据库 io，序列化文本，php文件，静态页面）

以持久化的模式来说：

全数据缓存、片段数据缓存、索引、片段输出缓存、全输出缓存

以数据读取方式来分：

常规数据读取（本地读取、异地读取），异化数据读取（例如缓存成json，将读取的压力转嫁给客户端，服务器只承担生成io和服务器输出的压力）。

通过上述的几种区分，可以很明显的发现，决定采用何种架构，提供何种解决方案，其实很取决于你实际碰到的需求是什么。所以你没有必要考虑真的过分设计出一个包罗万有的cache操作，能提供面向各种特点的接口，然后对常用的方式进行初步封装，我觉得你已经完成任务了。更多的具体实现，完全可以让渡给有实际需要的开发当事人，他能够优雅的通过继承你的既有类、实现接口、适度的重载封装，然后完成自己任务，就已经最大限度的保证彼此的共融性。这才是一个设计良好的抽象解决方案。