时间：2021-07-01 10:21:17 帮助过：55人阅读
谁能综合的评价下有缺点，如果能够提供相关资料就更好了。
比如什么情况下适合存在memcache，什么情况下适合redis?
好吧我不是来回答问题的 ... 我是来自毁形象的 ... 就当抛砖引玉了吧 ...
memcache 和 redis 虽然经常被相提并论比来比去 ... 但实际上这两个并不是一类 ...
memcache ... 是个 cache ... 而 redis ... 是个 database ...
而对于这个问题 ... 在我有限知识范围和片面的实际观察中 ... 我的答案是 ...
在 追求极限完美且应用逻辑简单时适合存到 memcache ... 其余任何情况下都适合存到 redis ...
更明确的说 ... 就是在 99.99% 的情况下 php 的 session 都适合存在 redis 里 ...
好吧我知道这答案很伤人 ... 欢迎更多的答案来提供不同意见 ...
作为国内最早一批使用 memcache 的人 ... 我在使用 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。我的建议是你在设计系统的时候把这两块的接口都预留，可以随时切换。