Codis 由四部分组成:

• Codis Proxy   (codis-proxy)

• Codis Manager (codis-config)

• Codis Redis   (codis-server)

• ZooKeeper

codis-proxy 是客户端连接的 Redis 代理服务, codis-proxy 本身实现了 Redis 协议, 表现得和一个原生的 Redis 没什么区别 (就像 Twemproxy), 对于一个业务来说, 可以部署多个 codis-proxy, codis-proxy 本身是无状态的.

codis-config 是 Codis 的管理工具, 支持包括, 添加/删除 Redis 节点, 添加/删除 Proxy 节点, 发起数据迁移等操作. codis-config 本身还自带了一个 http server, 会启动一个 dashboard, 用户可以直接在浏览器上观察 Codis 集群的运行状态.

codis-server 是 Codis 项目维护的一个 Redis 分支, 基于 2.8.13 开发, 加入了 slot 的支持和原子的数据迁移指令. Codis 上层的 codis-proxy 和 codis-config 只能和这个版本的 Redis 交互才能正常运行.

Codis 依赖 ZooKeeper 来存放数据路由表和 codis-proxy 节点的元信息, codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy.

Codis 支持按照 Namespace 区分不同的产品, 拥有不同的 product name 的产品, 各项配置都不会冲突.

目前 Codis 已经是稳定阶段，目前豌豆荚已经在使用该系统。

架构：

特性：

• 自动平衡

• 使用非常简单

• 图形化的面板和管理工具

• 支持绝大多数 Redis 命令，完全兼容 twemproxy

• 支持 Redis 原生客户端

• 安全而且透明的数据移植，可根据需要轻松添加和删除节点

• 提供命令行接口

• RESTful APIs

安装：

• Install go

• go get github.com/wandoulabs/codis

• cd codis

• ./bootstrap.sh

• make gotest

• cd sample

• follow instructions in usage.md

界面截图：

Dashboard

Migrate

Slots

一、普通同步方式

最简单和基础的调用方式，

@Test public void test1Normal() {     Jedis jedis = new Jedis("localhost");     long start = System.currentTimeMillis();     for (int i = 0; i < 100000; i++) {         String result = jedis.set("n" + i, "n" + i);     }     long end = System.currentTimeMillis();     System.out.println("Simple SET: " + ((end - start)/1000.0) + " seconds");     jedis.disconnect(); }

很简单吧，每次set之后都可以返回结果，标记是否成功。

二、事务方式(Transactions)

redis的事务很简单，他主要目的是保障，一个client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令。

看下面例子：

@Test public void test2Trans() {     Jedis jedis = new Jedis("localhost");     long start = System.currentTimeMillis();     Transaction tx = jedis.multi();     for (int i = 0; i < 100000; i++) {         tx.set("t" + i, "t" + i);     }     List<Object> results = tx.exec();     long end = System.currentTimeMillis();     System.out.println("Transaction SET: " + ((end - start)/1000.0) + " seconds");     jedis.disconnect(); }

我们调用jedis.watch(…)方法来监控key，如果调用后key值发生变化，则整个事务会执行失败。另外，事务中某个操作失败，并不会回滚其他操作。这一点需要注意。还有，我们可以使用discard()方法来取消事务。

三、管道(Pipelining)

有时，我们需要采用异步方式，一次发送多个指令，不同步等待其返回结果。这样可以取得非常好的执行效率。这就是管道，调用方法如下：

@Test public void test3Pipelined() {     Jedis jedis = new Jedis("localhost");     Pipeline pipeline = jedis.pipelined();     long start = System.currentTimeMillis();     for (int i = 0; i < 100000; i++) {         pipeline.set("p" + i, "p" + i);     }     List<Object> results = pipeline.syncAndReturnAll();     long end = System.currentTimeMillis();     System.out.println("Pipelined SET: " + ((end - start)/1000.0) + " seconds");     jedis.disconnect(); }

四、管道中调用事务

就Jedis提供的方法而言，是可以做到在管道中使用事务，其代码如下：

@Test public void test4combPipelineTrans() {     jedis = new Jedis("localhost");      long start = System.currentTimeMillis();     Pipeline pipeline = jedis.pipelined();     pipeline.multi();     for (int i = 0; i < 100000; i++) {         pipeline.set("" + i, "" + i);     }     pipeline.exec();     List<Object> results = pipeline.syncAndReturnAll();     long end = System.currentTimeMillis();     System.out.println("Pipelined transaction: " + ((end - start)/1000.0) + " seconds");     jedis.disconnect(); }

但是经测试（见本文后续部分），发现其效率和单独使用事务差不多，甚至还略微差点。

五、分布式直连同步调用

@Test public void test5shardNormal() {     List<JedisShardInfo> shards = Arrays.asList(             new JedisShardInfo("localhost",6379),             new JedisShardInfo("localhost",6380));      ShardedJedis sharding = new ShardedJedis(shards);      long start = System.currentTimeMillis();     for (int i = 0; i < 100000; i++) {         String result = sharding.set("sn" + i, "n" + i);     }     long end = System.currentTimeMillis();     System.out.println("Simple@Sharing SET: " + ((end - start)/1000.0) + " seconds");      sharding.disconnect(); }

这个是分布式直接连接，并且是同步调用，每步执行都返回执行结果。类似地，还有异步管道调用。

六、分布式直连异步调用

@Test public void test6shardpipelined() {     List<JedisShardInfo> shards = Arrays.asList(             new JedisShardInfo("localhost",6379),             new JedisShardInfo("localhost",6380));      ShardedJedis sharding = new ShardedJedis(shards);      ShardedJedisPipeline pipeline = sharding.pipelined();     long start = System.currentTimeMillis();     for (int i = 0; i < 100000; i++) {         pipeline.set("sp" + i, "p" + i);     }     List<Object> results = pipeline.syncAndReturnAll();     long end = System.currentTimeMillis();     System.out.println("Pipelined@Sharing SET: " + ((end - start)/1000.0) + " seconds");      sharding.disconnect(); }

七、分布式连接池同步调用

如果，你的分布式调用代码是运行在线程中，那么上面两个直连调用方式就不合适了，因为直连方式是非线程安全的，这个时候，你就必须选择连接池调用。

@Test public void test7shardSimplePool() {     List<JedisShardInfo> shards = Arrays.asList(             new JedisShardInfo("localhost",6379),             new JedisShardInfo("localhost",6380));      ShardedJedisPool pool = new ShardedJedisPool(new JedisPoolConfig(), shards);      ShardedJedis one = pool.getResource();      long start = System.currentTimeMillis();     for (int i = 0; i < 100000; i++) {         String result = one.set("spn" + i, "n" + i);     }     long end = System.currentTimeMillis();     pool.returnResource(one);     System.out.println("Simple@Pool SET: " + ((end - start)/1000.0) + " seconds");      pool.destroy(); }

上面是同步方式，当然还有异步方式。

八、分布式连接池异步调用

@Test public void test8shardPipelinedPool() {     List<JedisShardInfo> shards = Arrays.asList(             new JedisShardInfo("localhost",6379),             new JedisShardInfo("localhost",6380));      ShardedJedisPool pool = new ShardedJedisPool(new JedisPoolConfig(), shards);      ShardedJedis one = pool.getResource();      ShardedJedisPipeline pipeline = one.pipelined();      long start = System.currentTimeMillis();     for (int i = 0; i < 100000; i++) {         pipeline.set("sppn" + i, "n" + i);     }     List<Object> results = pipeline.syncAndReturnAll();     long end = System.currentTimeMillis();     pool.returnResource(one);     System.out.println("Pipelined@Pool SET: " + ((end - start)/1000.0) + " seconds");     pool.destroy(); }

九、需要注意的地方

1. 事务和管道都是异步模式。在事务和管道中不能同步查询结果。比如下面两个调用，都是不允许的：

    Transaction tx = jedis.multi();  for (int i = 0; i < 100000; i++) {      tx.set("t" + i, "t" + i);  }  System.out.println(tx.get("t1000").get());  //不允许   List<Object> results = tx.exec();   …  …   Pipeline pipeline = jedis.pipelined();  long start = System.currentTimeMillis();  for (int i = 0; i < 100000; i++) {      pipeline.set("p" + i, "p" + i);  }  System.out.println(pipeline.get("p1000").get()); //不允许   List<Object> results = pipeline.syncAndReturnAll();

2. 事务和管道都是异步的，个人感觉，在管道中再进行事务调用，没有必要，不如直接进行事务模式。

3. 分布式中，连接池的性能比直连的性能略好(见后续测试部分)。

4. 分布式调用中不支持事务。

   因为事务是在服务器端实现，而在分布式中，每批次的调用对象都可能访问不同的机器，所以，没法进行事务。

十、测试

运行上面的代码，进行测试，其结果如下：

Simple SET: 5.227 seconds  Transaction SET: 0.5 seconds Pipelined SET: 0.353 seconds Pipelined transaction: 0.509 seconds  Simple@Sharing SET: 5.289 seconds Pipelined@Sharing SET: 0.348 seconds  Simple@Pool SET: 5.039 seconds Pipelined@Pool SET: 0.401 seconds

另外，经测试分布式中用到的机器越多，调用会越慢。上面是2片，下面是5片：

Simple@Sharing SET: 5.494 seconds Pipelined@Sharing SET: 0.51 seconds Simple@Pool SET: 5.223 seconds Pipelined@Pool SET: 0.518 seconds

下面是10片：

Simple@Sharing SET: 5.9 seconds Pipelined@Sharing SET: 0.794 seconds Simple@Pool SET: 5.624 seconds Pipelined@Pool SET: 0.762 seconds

下面是100片：

Simple@Sharing SET: 14.055 seconds Pipelined@Sharing SET: 8.185 seconds Simple@Pool SET: 13.29 seconds Pipelined@Pool SET: 7.767 seconds

分布式中，连接池方式调用不但线程安全外，根据上面的测试数据，也可以看出连接池比直连的效率更好。

十一、完整的测试代码

package com.example.nosqlclient;  import java.util.Arrays; import java.util.List;  import org.junit.AfterClass; import org.junit.BeforeClass; import org.junit.Test;  import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPoolConfig; import redis.clients.jedis.JedisShardInfo; import redis.clients.jedis.Pipeline; import redis.clients.jedis.ShardedJedis; import redis.clients.jedis.ShardedJedisPipeline; import redis.clients.jedis.ShardedJedisPool; import redis.clients.jedis.Transaction;  import org.junit.FixMethodOrder; import org.junit.runners.MethodSorters;  @FixMethodOrder(MethodSorters.NAME_ASCENDING) public class TestJedis {      private static Jedis jedis;     private static ShardedJedis sharding;     private static ShardedJedisPool pool;      @BeforeClass     public static void setUpBeforeClass() throws Exception {         List<JedisShardInfo> shards = Arrays.asList(                 new JedisShardInfo("localhost",6379),                 new JedisShardInfo("localhost",6379)); //使用相同的ip:port,仅作测试           jedis = new Jedis("localhost");          sharding = new ShardedJedis(shards);          pool = new ShardedJedisPool(new JedisPoolConfig(), shards);     }      @AfterClass     public static void tearDownAfterClass() throws Exception {         jedis.disconnect();         sharding.disconnect();         pool.destroy();     }      @Test     public void test1Normal() {         long start = System.currentTimeMillis();         for (int i = 0; i < 100000; i++) {             String result = jedis.set("n" + i, "n" + i);         }         long end = System.currentTimeMillis();         System.out.println("Simple SET: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test2Trans() {         long start = System.currentTimeMillis();         Transaction tx = jedis.multi();         for (int i = 0; i < 100000; i++) {             tx.set("t" + i, "t" + i);         }         //System.out.println(tx.get("t1000").get());          List<Object> results = tx.exec();         long end = System.currentTimeMillis();         System.out.println("Transaction SET: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test3Pipelined() {         Pipeline pipeline = jedis.pipelined();         long start = System.currentTimeMillis();         for (int i = 0; i < 100000; i++) {             pipeline.set("p" + i, "p" + i);         }         //System.out.println(pipeline.get("p1000").get());         List<Object> results = pipeline.syncAndReturnAll();         long end = System.currentTimeMillis();         System.out.println("Pipelined SET: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test4combPipelineTrans() {         long start = System.currentTimeMillis();         Pipeline pipeline = jedis.pipelined();         pipeline.multi();         for (int i = 0; i < 100000; i++) {             pipeline.set("" + i, "" + i);         }         pipeline.exec();         List<Object> results = pipeline.syncAndReturnAll();         long end = System.currentTimeMillis();         System.out.println("Pipelined transaction: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test5shardNormal() {         long start = System.currentTimeMillis();         for (int i = 0; i < 100000; i++) {             String result = sharding.set("sn" + i, "n" + i);         }         long end = System.currentTimeMillis();         System.out.println("Simple@Sharing SET: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test6shardpipelined() {         ShardedJedisPipeline pipeline = sharding.pipelined();         long start = System.currentTimeMillis();         for (int i = 0; i < 100000; i++) {             pipeline.set("sp" + i, "p" + i);         }         List<Object> results = pipeline.syncAndReturnAll();         long end = System.currentTimeMillis();         System.out.println("Pipelined@Sharing SET: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test7shardSimplePool() {         ShardedJedis one = pool.getResource();          long start = System.currentTimeMillis();         for (int i = 0; i < 100000; i++) {             String result = one.set("spn" + i, "n" + i);         }         long end = System.currentTimeMillis();         pool.returnResource(one);         System.out.println("Simple@Pool SET: " + ((end - start)/1000.0) + " seconds");     }      @Test     public void test8shardPipelinedPool() {         ShardedJedis one = pool.getResource();          ShardedJedisPipeline pipeline = one.pipelined();          long start = System.currentTimeMillis();         for (int i = 0; i < 100000; i++) {             pipeline.set("sppn" + i, "n" + i);         }         List<Object> results = pipeline.syncAndReturnAll();         long end = System.currentTimeMillis();         pool.returnResource(one);         System.out.println("Pipelined@Pool SET: " + ((end - start)/1000.0) + " seconds");     } }

实际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. 网络IO模型

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



（Memcached网络IO模型）

Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和 select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操 作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。

2. 内存管理方面

Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存 储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数 据也可能会被剔除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/

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还同时提供了持久化和复制等功能。

5. 关于不同语言的客户端支持

在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一 些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新 的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。

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

关于Redis的一些周边功能

Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清 楚地了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的， 又比如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。

总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。

总结：

1. Redis使用最佳方式是全部数据in-memory。

2. Redis更多场景是作为Memcached的替代者来使用。

3. 当需要除key/value之外的更多数据类型支持时，使用Redis更合适。

4. 当存储的数据不能被剔除时，使用Redis更合适。

后续关于Redis文章计划：

1. Redis数据类型与容量规划。

2. 如何根据业务场景搭建稳定，可靠，可扩展的Redis集群。

3. Redis参数，代码优化及二次开发基础实践。

关于作者

田琪，目前负责新浪微博平台底层架构与研发工作，之前曾担任搜狐白社会实时游戏平台核心架构工作，主要关注webgame, 分布式存储，nosql 和 erlang 等领域，目前主要从事mysql源代码的一些深入研究工作，浪微博：http://weibo.com/bachmozart。

1. 管理 Redis 服务器

2. 管理 Redis data favorite

3. 管理 Redis 数据
   

• 新 Redis 数据：string, list, hash, set, sorted set

• 重命名 Redis 数据

• 删除 Redis 数据

• 更新 Redis 数据

• 剪切，复制，粘贴 Redis 数据

• 导入，导出 Redis 数据

• 搜索 Redis 数据

• 通过关键字，数据类型，大小来排序 Redis 数据

• 导航历史

RedisClient 是  Redis 客户端 GUI 工具，使用 Java swt 和jedis 编写。它将redis数据以windows资源管理器的界面风格呈现给用户，可以帮助redis开发人员和维护人员方便的建立，修改，删除，查询redis数据，可以让用户方便的编辑数据，可以剪切，拷贝，粘贴redis数据，可以导入，导出redis数据，可以对redis数据排序。

　　实际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可以 保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。

使用Redis特有内存模型前后的情况对比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on:  300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on:  1 million keys, 256 bytes values: 160.09M used
VM on:  1 million keys, values as large as you want, still: 160.09M used

当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行 批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。

如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。

补充的知识点：

memcached和redis的比较

1 网络IO模型

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

(Memcached网络IO模型)

　 　Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯 只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重 影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。

　　2.内存管理方面

　 　Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方 式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔 除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/

　 　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还同时提供了持久化和复制等功能。

　　5.关于不同语言的客户端支持

　 　在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客 户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应 第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。

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

　　关于Redis的一些周边功能

　 　Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清楚地 了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的，又比 如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。

　　总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。

　　总结：

　　1.Redis使用最佳方式是全部数据in-memory。

　　2.Redis更多场景是作为Memcached的替代者来使用。

　　3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。

　　4.当存储的数据不能被剔除时，使用Redis更合适。