谁能综合的评价下有缺点，如果能够提供相关资料就更好了。
比如什么情况下适合存在memcache，什么情况下适合redis?
回复内容：
谁能综合的评价下有缺点，如果能够提供相关资料就更好了。
比如什么情况下适合存在memcache，什么情况下适合redis?
好吧我不是来回答问题的 … 我是来自毁形象的 … 就当抛砖引玉了吧 …
memcache 和 redis 虽然经常被相提并论比来比去 … 但实际上这两个并不是一类 …
memcache … 是个 cache … 而 redis … 是个 database …
而对于这个问题 … 在我有限知识范围和片面的实际观察中 … 我的答案是 …
在 追求极限完美且应用逻辑简单时适合存到 memcache … 其余任何情况下都适合存到 redis …
更明确的说 … 就是在 99.99% 的情况下 php 的 session 都适合存在 redis 里 …
好吧我知道这答案很伤人 … 欢迎更多的答案来提供不同意见 …
作为国内最早一批使用 memcache 的人 /本文来源gao@!dai!ma.com搞$$代^@码5网@搞代gaodaima码… 我在使用 redis 之后没多久就基本放弃 memcache 了 …
memcache 并不是一无是处 … 它与现在的 redis 相比 … 唯一的优势 … 就是快 …
同样的环境下同样的负载同样的 k/v 结构数据 …
在单条数据比较小的时候 … 不管是读还是写 … memcache 永远比 redis 快那么几十 μs …
虽然差距微乎其微但 redis 从未赢过 …
如果你非常非常的在乎这一点点的时间差距 … 恩 … 你有成为 0.01% 的潜质 … 但还不是 …
现在来看你的应用场景 … 想成为那 0.01% … 你的 session 里面只能存储一个单位 …
比如只存储用户名来获得一个 key 到 username 的对应 … 而不能是数组 …
因为不管是 serialize / set 还是 get / unserialize 都慢于 hSet 和 hGet …
之前我们好不容易争取了几十 μs … 结果就这样被白白消耗掉了 …
如果你能做好这个架构 … 0.01% 俱乐部的大门正在为你打开 …
但等等 … 抛开性能 … 再设想两个场景 …
场景一 … 假如存储 session 的机器被重启了 …
用 memcache 的后果是 … 所有用户都必须重新获得 session … 瞬时数据库压力会很大 …
而用 redis 就不会 … 充其量只是丢失那些还没来得及保存的 session …
场景二 … 假如突然涌来大量用户产生了很多数据把存储 session 的机器内存占满了 …
memcache 会罢工 … 所有 key 都没过期的话就不停的覆盖最后写入的数据 …
而 redis 只是会变慢 … 不会影响程序的逻辑 …
如果你确认这些都不会发生 … 欢迎使用 memcache 来获得满足你对极限完美效率的追求 …
基本上现在还在使用 memcache 存储 session 的据我所知只有两类人 …
第一类是为了追求完美以及炫技 … 也就是那 0.01% …
第二类是食古不化或者代码实在太复杂导致无法更换 …
如果你不属于这两类人 … 欢迎使用主流的 redis …
大体来说就是这样 … 一边想一边写也不知道自己写了多少 …
这话题其实不太好回答 … 要展开的话能展开到超大 … 攒成一篇论文都行 …
我这就是想到哪里写到哪里 … 有些点能想到但落实到文字上又不知道该怎么去描述 …
比如内存管理 … 对多核 CPU 的应用还有分布式什么的 …
想得越多思路就越不清晰 … 行文可能是有点乱 … 将就看一下啦 …
反正我是来自毁形象的 … 无比欢迎 memcache 党来战 …
对于单一的k-v缓存来说，memcache是最佳选择，它的好处就在于简单，速度也相当不错。
但是，如果你需要存储映射或字段，或者如果你要存储定序列表或可排序的集合，那么Redis是最合适的。
我个人认为Redis做DB还是有很多欠缺的，至少在数据持久化方面还是不够完善的。所以，Redis和memcache一样，主要的应用场景还是在缓存这一块儿。
如果只是做Session存储的话，我个人比较建议使用Memcached，速度方面较快而且应用简单，但如果你需要做一些持久化的东西你还是去用Redis。我的建议是你在设计系统的时候把这两块的接口都预留，可以随时切换。
转载请注明原文链接：Session存储到Redis中和存到memcache中哪个更好呢
