什么时候使用redis？什么时候使用memcache？

要清楚为什么，redis具有高可用特性，并且可固化，但特性有时候不能成为选择他的理由，一些业务场景中并不需要这样的特性。

 

什么时候倾向于选择redis？

1.复杂数据结构

value是哈希，列表，集合，有序集合等复杂数据结构的时候，选择redis更合适，因为mc无法满足这样的需求。

典型场景：用户消息，评论，订单列表等

 

2.持久化

mc不支持持久化

但redis持久化的使用需要注意

 

千万不要将redis作为数据库来使用：

1）redis的定期快照不能保证数据不丢失

2）redis的AOF会降低效率，并且不能支持太大的数据量

 

缓存场景，开启持久化有什么利弊？

优点：down机重启，内存中能够快速恢复热点数据，分担数据库压力，没有cache预热过程

缺点：redis挂了以后，数据库中数据有修改，可能导致redis中数据不一致

只读场景，或者一些允许不一致的业务场景，可以尝试开启redis持久化功能

 

3.天然高可用

redis天然支持集群功能，可实现主从复制，读写分离

Redis官方提供了sentinel集群管理工具，能够实现主从服务监控，故障自动转移

 

Mc想要实现高可用，需要进行二次开发

 

需要注意的是，大部分业务场景，缓存真的需要高可用吗？

1）存场景，很多时候，是允许cache miss

2）缓存挂了，很多时候可以通过DB读取数据

 

4.存储的value很大

mc的value存储，最大为1m，如果存储的value很大，只能使用redis

 

什么时候倾向于选择memcache？

纯kv，数据量非常大，并发量非常大的业务，使用mc或许更合适

 

这个要从mc与redis的底层实现机制说起

 

内存分配

mc使用预分配内存池的方式管理，能够省去内存分配的时间

redis是临时申请空间，可能导致碎片

这一点上，mc会快一些

 

虚拟内存使用

mc会把所以数据存到物理内存中

redis有自己的vm机制，当数据超量时，会引发swap，把冷数据刷到磁盘上

数据量大时，mc会快一些

 

网络模型

mc使用的是非阻塞IO复用模型，redis也是非阻塞IO复用模型

redis还提供一些非kv存储之外的排序，聚合功能，在执行这些功能的时候，会阻塞整个IO调度

在这一点上，由于redis提供的功能较多，mc会快一些

 

线程模式

mc使用多线程，主线程监听，worker子线程接受请求，执行读写，可能存在锁冲突。

redis使用单线程模式，不存在锁冲突，但难以利用多核的特效提升整体吞吐量。

在这一点上，mc要快一些