Memcached真的过时了吗

这两年 Redis火得可以，Redis也常常被当作 Memcached的挑战者被提到桌面上来。关于Redis与Memcached的比较更是比比皆是。然而，Redis真的在功能、性能以及内存使用效率上都超越了Memcached吗？

没有必要过于关注性能，因为二者的性能都已经足够高了。由于Redis只使用单核，而Memcached可以使用多核，所以二者比较起来，平均每一个核上，Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis。虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。说了这么多，结论是，无论你使用哪一个，每秒处理请求的次数都不会成为瓶颈。

在内存使用效率上，如果使用简单的key-value存储，Memcached的内存利用率更高。而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。

如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis。因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。

当然，最后还得说到你的具体应用需求。Redis相比Memcached来说，拥有更多的数据结构，并支持更丰富的数据操作。通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果你需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。

大致为两种措施：

一、脚本同步：

1、自己写脚本将数据库数据写入到redis/memcached。

2、这就涉及到实时数据变更的问题（mysqlrowbinlog的实时分析），binlog增量订阅Alibaba的canal，以及缓存层数据丢失/失效后的数据同步恢复问题。

二、业务层实现：

1、先读取nosql缓存层，没有数据再读取mysql层，并写入数据到nosql。

2、nosql层做好多节点分布式（一致性hash），以及节点失效后替代方案（多层hash寻找相邻替代节点），和数据震荡恢复了。

redis实现数据库缓存的分析：

对于变化频率非常快的数据来说，如果还选择传统的静态缓存方式（Memocached、FileSystem等）展示数据，可能在缓存的存取上会有很大的开销，并不能很好的满足需要，而Redis这样基于内存的NoSQL数据库，就非常适合担任实时数据的容器。

但是往往又有数据可靠性的需求，采用MySQL作为数据存储，不会因为内存问题而引起数据丢失，同时也可以利用关系数据库的特性实现很多功能。所以就会很自然的想到是否可以采用MySQL作为数据存储引擎，Redis则作为Cache。

MySQL到Redis数据复制方案，无论MySQL还是Redis，自身都带有数据同步的机制，比较常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog来实现的，这样的数据复制其实还是一个异步过程，只不过当服务器都在同一内网时，异步的延迟几乎可以忽略。那么理论上也可用同样方式，分析MySQL的binlog文件并将数据插入Redis。

因此这里选择了一种开发成本更加低廉的方式，借用已经比较成熟的MySQLUDF，将MySQL数据首先放入Gearman中，然后通过一个自己编写的PHPGearmanWorker，将数据同步到Redis。比分析binlog的方式增加了不少流程，但是实现成本更低，更容易操作。

第一个问题：

数据库缓存

我们知道当网站访问量很大的时候，用户直接去访问你的数据库，这个时候数据库压力很大，往往会导致你的数据服务器蹦了，或者服务器崩了。

那么这个时候的解决方案从数据库来说，就是加上缓存层，那么常用的缓存就是redis，memcache了，或者有人使用文件。

第二个问题：

服务器端的缓存：

文件缓存属于服务器上的，redis或者memcache也是属于你服务器端的缓存

第三个问题：

浏览器缓存，我们知道当你访问网页的时候，浏览器会去给你缓存网页，会把你网页的静态载入文件去缓存，你按f5刷新实际上第二次访问的是你的浏览器的缓存，当然这个可以根据header头的参数去改动，你按ctrl+f5就是强制刷新式的访问，这个时候就会重新去请求服务器拿文件了！