选redis还是memcache

业务需求决定技术选型

选择redis场景

• 复杂数据结构
  value是哈希，列表，集合，有序集合这类复杂的数据结构时，会选择redis，因为mc无法满足这些需求。
  最典型的场景，用户订单列表，用户消息，帖子评论列表等。
• 持久化：mc无法满足持久化的需求，只得选择redis。
• 千万不要把redis当作数据库用：
  （1）redis的定期快照不能保证数据不丢失
  （2）redis的AOF会降低效率，并且不能支持太大的数据量
• 缓存场景，开启固化功能，有什么利弊？
  如果只是缓存场景，数据存放在数据库，缓存在redis，此时如果开启固化功能：
  优点是，redis挂了再重启，内存里能够快速恢复热数据，不会瞬时将压力压到数据库上，没有一个cache预热的过程。
  缺点是，在redis挂了的过程中，如果数据库中有数据的修改，可能导致redis重启后，数据库与redis的数据不一致。
  因此，只读场景，或者允许一些不一致的业务场景，可以尝试开启redis的固化功能。
• 天然高可用
  redis天然支持集群功能，可以实现主动复制，读写分离。
  redis官方也提供了sentinel集群管理工具，能够实现主从服务监控，故障自动转移，这一切，对于客户端都是透明的，无需程序改动，也无需人工介入。
• 存储的内容比较大
  memcache的value存储，最大为1M，如果存储的value很大，只能使用redis。

选择memcache场景

• 要想要实现高可用，需要进行二次开发，例如客户端的双读双写，或者服务端的集群同步。
  （1）缓存场景，很多时候，是允许cache miss
  （2）缓存挂了，很多时候可以通过DB读取数据
• 纯KV，数据量非常大，并发量非常大的业务，使用memcache或许更适合。

memcache与redis的底层实现机制差异

• 内存分配
  memcache使用预分配内存池的方式管理内存，能够省去内存分配时间。
  redis则是临时申请空间，可能导致碎片。
  从这一点上，mc会更快一些。
• 虚拟内存使用
  memcache把所有的数据存储在物理内存里。
  redis有自己的VM机制，理论上能够存储比物理内存更多的数据，当数据超量时，会引发swap，把冷数据刷到磁盘上。
  从这一点上，数据量大时，mc会更快一些。
• 网络模型
  memcache使用非阻塞IO复用模型，redis也是使用非阻塞IO复用模型。
  但由于redis还提供一些非KV存储之外的排序，聚合功能，在执行这些功能时，复杂的CPU计算，会阻塞整个IO调度。
  从这一点上，由于redis提供的功能较多，mc会更快一些。
• 线程模型
  memcache使用多线程，主线程监听，worker子线程接受请求，执行读写，这个过程中，可能存在锁冲突。
  redis使用单线程，虽无锁冲突，但难以利用多核的特性提升整体吞吐量。
  从这一点上，mc会快一些。

总结

• mc的核心就是内存管理，因为mc不会产生内存碎片，所以会极其稳定，除非机器故障mc几乎不会崩溃。因此设计者就没有考虑过主从或反序列化。但是mc还是要做分片的。redis很取巧的使用单线程的IO复用模型，因此不用考虑多线程的各种问题，所以才会很轻松的支持各种数据类型。带来的问题就是cpu无法用满，如果计算复杂的话，redis性能会降低。redis用的jemalloc理念和mc管理内存的方式类似，但毕竟是通用内存管理器，还是会产生内存碎片。长时间运行的redis实际使用的内存会超过最大内存，从而导致系统不稳定，甚至崩溃。所以redis才设计的高可用方案。但总的来讲，两种缓存都是非常可靠的
• jemalloc会分配8.16.32.64字节的整块的内存，redis为啥会有出现内存碎片问题。他会把内存还给操作系统，他只要有申请有归还，就会有碎片，日积月累碎片就会多起来。相比之下memcached是给了他多少内存他是绝对不会还。