缓存与数据库相关

一，传统MySQL与Memcached架构遇到的问题：

1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。

2.Memcached与 MySQL数据库 数据一致性问题。

3.Memcached数据命中率低或 down机，大量访问直接穿透到DB，MySQL无法支撑。

4.跨机房cache同步问题。

二，NoSQL的优势

1，少量数据存储，高速读写访问。

通过数据全部in-memory 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。

2，海量数据存储，分布式系统支持， 数据一致性保证，方便的集群节点添加/删除。

三，Redis与Memcached的区别

1，Redis不仅仅支持key/value类型的数据，同时提供list，set，zset，hash等数据结构的存储。最知合所有数据in-memory的场景。

2，Redis支持数据的备份，即master-slave模式的数据备份。

3，Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。并不是所有的数据都一直存储在内存中。这是和Memcached相比一个最大的区别。Redis只会缓存所有的key信息，如果Redis发现内存的使用量超过某一个阀值，将触发swap操作。Redis根据”swappability=age*log(size_in_memory”计算出哪些key对应的value需要swap到磁盘。然后将这些key对应的value持久化到磁盘中，同时在内存中清除。这些特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。

同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。

     从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。

     但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。

《1》Memcached是多线程的非堵塞IO复用的网络模型，分为监听主线程和worker子线程。监听线程监听网络连接，接受请求后，将连接描述字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。

     Redis使用单线程的IO复用模型。单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。

《2》内存管理方在

Memcached使用预分配的内存池方式。内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔除。

     Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis根据据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便 物理内存不够，导致swap也不会剔除任何非临时数据(但会尝试剔除部分临时数据)，这点上Redis更适合作为存储而不是cache。

《3》数据一致性问题

Memcached提供了cas命令，保证多个并发访问操作同一份数据的一致性问题。Redis没有提供cas命令，不过Redis提供了事务的功能，保证原子性，中间不会被任何操作打断。

《4》存储方式

Memcached基本只支持简单的key-value存储， 不支持枚举，不支持持久性和复制等功能。

Redis除key/value之外，还支持list,set,sorted set,hash等众多 数据结构，提供了KEYS进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。

当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。