Redis和Memcache的区别

版权声明：也可以说是一种借鉴，或者说是一种复制，无私分享，望君能心想事成。 https://blog.csdn.net/APULSABLE/article/details/89440598

本文虽说是自己手动摘取的，但是也是结合了一些朋友的意见和自己的意见还有感悟的意见，自己的语言可能不够完美，所以大家尽量观看并收藏，同时也希望各位朋友给个小赞赞了，嘿嘿

echo "Thank you !!";

Redis和memcache的区别之 Memcache

Memcached是分布式的内存对象缓存系统，是基于Key/Value对的HashMap。每一对，都可以设定过期时间,(如果设置为0则永不过期【永不过期实际为30天后过期】) 。但由memcache是存在内存中的，所以发生断电或者是服务器故障都会使数据丢失,Memcached可以存储数组、对象、字符、汉字等各种数据类型。

Memcached特点:

• （1）无备份，各Memcached节点的数据之间没有互相备份，一旦某个节点挂掉，缓存中的数据就会丢失。

• （2）命令基本就是对特定key的添加，删除，替换，原子更新，读取等，具体包括 Set, Get, Add, Replace, Append, Inc/Dec 0

• （3）Memcached的应用模式中，不支持事务，但可以做一些原子命令的操作。

Memcached的内存分配的原理

Memcached的内存分配的原理 就是会预先分配内存，特点是速度快，但是不能合理运用空间，简单点就是用空间换速度，一般来说一个memcahced进程会预先将自己划分为若干个slab，每个slab下又有若干个page，每个page下又有多个 chunk

slab的数量是有限得，几个，十几个，或者几十个，这个跟进程配置得内存有关，而每个slab下得page对应实际的物理空间默认情况是1M，也就是说100M的一个slab下有100个page,而chunk就是我们得数据存放得最终地方。Chunk为固定大小的内存空间，默认为96Byte。

同样大小的chunk又称为slab。

memcache的数据删除机制：

当数据过期时，memcache并不会直接从内存中删除数据，因为memcache并不会回收已经分配的内存，而只是在get数据时检查时间戳是否过期，如果过期那么客户端就不可见，但是原来分配的内存可以重复使用，这叫做惰性失效。所以memcache不会对过期的数据进行监视，因此也就节省了cpu的资源。

在memcache中使用LRU机制进行删除数据，即最近最少使用。在每个slab中数据都是存放在链表上的，链表有head和tail指针，分别指向最老和最新的数据。当LRU机制启动时，两个指针同时发挥作用查询失效数据，如果没有失效数据那么就会删除最近的最少被使用的数据。通过计数器来记录哪些数据最少被使用来删除它，所以也有可能删除一些尚未过期或者永久有效的数据。

LRU只针对每个slab，并不针对整体。只有在slab不能分配新的page内存时才会调用LRU。

一种有效缓解使用LRU的方法是：

避免大对象

如果系统上只有及个别几个大对象的话，会浪费内存空间，因为Slab申请了Page是不能释放内存的，及个别大对象会导致Slab申请了内存资源而得不到充分的利用。

调整增长因子

根据项目的需求调整增长因子，使内存充分利用。

Redis和memcache的区别之 Redis

Redis 是一个使用 C 语言写成的，开源的 key-value 数据库。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作以日志的形式追加写入一个记录文件

这两种方式也就是redis提供的 两种 不同级别的持久化方式 RDB 和 AOF

RDB 持久化方式能够在指定的时间间隔对你的数据进行快照存储。实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的快照文件，用二进制压缩存储。

AOF 持久化是以日志的方式记录每次对服务器写的操作。删除操作，查询操作不会记录，当服务器重启的时候会重新执行这些命令来恢复原始的数据,每次写的操作以追加的方式写到文件

当然你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB优点：

一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的根据需求恢复到不同版本的数据集.

对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免父进程执行IO（读写）操作了，使性能最大化

相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB缺点：

如果你想保证数据的较高的可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前几分钟没有来得及写入磁盘的数据都将丢失。

由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF优点：

该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

由于该机制对日志文件的写入操作采用的是追加模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

如果日志过大，Redis可以自动启用重写机制。即Redis以追加模式不断的将修改数据写入到旧的AOF文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行重写切换时可以更好的保证数据安全性。

AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF缺点：

对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较底的，禁用同步策略的化效率就和RDB一样高效。

二者选择的标准，就是看系统是愿意以AOF那样牺牲一些性能，换取更高的缓存一致性，还是愿意像RDB那样写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份。