redis和memcached的区别.pdfVIP

redis 与 memcached 的区别 传统 MySQL+ Memcached 架构遇到的问题 实际 MySQL 是适合进行海量数据存储的，通过 Memcached 将热点数据加载到 cache ，加速访问，很多公司都曾经使 用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题： 1.MySQL 需要不断进行拆库拆表，Memcached 也需不断跟着扩容，扩容和维护工作占据大量开发时间。 2.Memcached 与 MySQL 数据库数据一致性问题。 3.Memcached 数据命中率低或 down 机，大量访问直接穿透到 DB ，MySQL 无法支撑。 4.跨机房 cache 同步问题。 众多 NoSQL 百花齐放，如何选择 最近几年，业界不断涌现出很多各种各样的 NoSQL 产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处， 是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的 tradeoffs ，在实 际应用中做到扬长避短，总体上这些 NoSQL 主要用于解决以下几种问题 1.少量数据存储，高速读写访问。此类产品通过数据全部 in-momery 的方式来保证高速访问，同时提供数据落地的功 能，实际这正是 Redis 最主要的适用场景。 2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 3.这方面最具代表性的是 dynamo 和 bigtable 2 篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过 gossip 方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致 性,数据写入先写内存和 redo log ，然后定期 compat 归并到磁盘上，将随机写优化为顺序写，提高写入性能。 4.Schema free ，auto-sharding 等。比如目前常见的一些文档数据库都是支持 schema-free 的，直接存储json 格式 数据，并且支持 auto-sharding 等功能，比如 mongodb。 面对这些不同类型的 NoSQL 产品,我们需要根据我们的业务场景选择最合适的产品。 Redis 适用场景，如何正确的使用 前面已经分析过，Redis 最适合所有数据 in-momory 的场景，虽然 Redis 也提供持久化功能，但实际更多的是一个 disk-backed 的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎 Redis 更像一个加强版的 Memcached ，那么何时使用Memcached,何时使用 Redis 呢? 如果简单地比较 Redis 与 Memcached 的区别，大多数都会得到以下观点： 1 Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list ，set ，zset ，hash 等数据结构的存储。 2 Redis 支持数据的备份，即 master-slave 模式的数据备份。 3 Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 抛开这些，可以深入到 Redis 内部构造去观察更加本质的区别，理解 Redis 的设计。 在 Redis 中，并不是所有的数据都一直存储在内存中的。这是和 Memcached 相比一个最大的区别。Redis 只会缓存所有的 key 的信息，如果 Redis 发现内存的使用量超过了某一个阀值，将触发 swap 的操作，Redis 根据 “swappability = age*log(size_in_memory)”计 算出哪些 key 对应的 value 需要 swap 到磁盘。然后再将这些 key 对应的 value 持久化到 磁盘中，同时在内存中清除。这种特性使得 Redis 可以 保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要 1 / 14 能够保持所有的 key ，毕竟这些数据是不会进行swap 操作的。同时由于 Redis 将内存 中的数据 swap 到磁盘中的时候，提 供服务的主线程和进行 swap 操作的子线程会共享这部分内存，所以如果更新需要 swap 的数据，Redis 将阻塞这个 操作， 直到子线程完成 swap 操作后才可以进行修改。 使用 Redis 特