关于memcache的key的管理，徘徊中

一，在说出我的困惑时，先罗嗦一下memcache

memcache是一个高性能的分布式的内存对象缓存系统，通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。Memcache是danga.com的一个项目，最早是为 LiveJournal 服务的，最初为了加速 LiveJournal 访问速度而开发的，后来被很多大型的网站采用。目前全世界不少人使用这个缓存项目来构建自己大负载的网站，来分担数据库的压力。起初作者编写它可能是为了提高动态网页应用，为了减轻数据库检索的压力，来做的这个缓存系统。它的缓存是一种分布式的，也就是可以允许不同主机上的多个用户同时访问这个缓存系统， 这种方法不仅解决了共享内存只能是单机的弊端，同时也解决了数据库检索的压力，最大的优点是提高了访问获取数据的速度！基于memcache作者对分布式 cache的理解和解决方案。 memcache完全可以用到其他地方 比如分布式数据库， 分布式计算等领域。

二，memcahce的key如何关理，更合适

大家都知道，memcache缓存的数据放在内存中，用的key=>value的方式，来查找和更新value的值，从这里可以看出对于key的管理直接影响到value的值，影响到内存的利用率和效率，以及程序员写代码的难度，怎么样才做到最优化呢，这也是我一直思考的问题，我想了二种方案，但是觉得都不完美。先说一说我的方案吧

1，对单表进行缓存

优点：

a,对于key的维护很简单

key对应一张表的数据，所以key是根这张表有关的sql或者其他。如果是我，我会用取整表的sql语句经过hash后来当key。注意一点hash过程中，如果sql有一点点不同，hash出来就会不同，包括空格，字母大小字等。所以建议将sql建行封装。

b,就同一张表来说，内存中不会有重复数据

缺点：

a，加大程度开发难度

举个例子来说，如果我想对二张表或者更多表，进行联合查寻时，正常情况，我可以用left join或者其他来进行查寻就行了，也许一个sql语句就能搞定，但是现在对单表进行缓存时，就要把单表的数据取出来，用php的循环进行查找数据了。这样对于程序员来说是一件很痛苦的事。

b，加大系统负担，影响memcache效果

这个缺点很明显，因为多表操作时，用php的循环套循环，会加大系统负担，如果一张表有几百M， 另一张表也有几十M，你用php循环来把你想要的数据找到时，所花的时间也许比直接用联合查寻访问数据库所用的时间更长，这样我就没必要用memcache，这个也是致命缺点。

个人觉得这种对key进行管理的方式，比较适合写入，或者更新操作比较多的网页，因为对于key的update很容易，key根表名是一一对应关系，这样找起来就容易多了。

２，对数据段，数据点进行缓存

优点：

a,查找效率高

我想memcache设计的目的也就是这个了，通过key找到value，就是我们所要的数据，不要进行任何处理。不要对数据库进行操作，不要用php循环来取数据，可以说省了很多事情。

b,开发效率高

对于程序员来说，以前是怎么开发现在还怎么开发，就当memcache不存在就行了。

缺点：

a,内存利用率差

举个例子来说吧，数据段A和数据B有重复数据，内存中的二个数据段都会包括相同的数据，这对内存利用率来说是不好的。如果你的memcach所占内存是１G的话，并且你用这种方法来进行key的管理的话，1Ｇ内存中重复数据有可能占了一半。

b ，key的管理难

为什么对key的管理难呢，因为key受很多因素的影响。不像上面的那种方法，key和表名是一对一关系。在这里，key受表名，可能是多个表名，where后面所带的参数所影响，所以管理起来相当的不方便。当你更新一个数据时，入库的同时，key对应的value就要相应的改动，不然用户会认为网站有bug。根这张表有关系的key很多，很有可能你就没有把所有key对应的value都更新掉

个人觉得这种对key的管理方式比较适合，读取比较多的，写入比较少的网站，如果经常写入的话，更新key所耗的资源也很大，不如用上面的那一种对key的管理方式。

如果读取比较大，写入也比较频繁呢，怎么办呢，个人觉得这二种方法都不合适，如果非要做个选择的话，我会选择第二种，有没有别的方法来，综合上面二种方法的优点，去除上面二种方法的缺点的方法呢。思考中