Redis入门5-Redis事务与Redis管道（pipeline）-Nosql-About云-梭伦科技

不会飞的小凯凯 发表于 2016-2-19 15:35:10

Redis入门5--Redis事务与Redis管道（pipeline）

问题导读：
1.redis怎么样处理事务？
2.redis管道有什么作用？
3.如何测试redis事务与管道功能？

static/image/hrline/4.gif

1.redis事务
redis对事务的支持目前还比较简单。redis只能保证一个client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令。由于redis是单线程来处理所有client的请求的所以做到这点是很容易的。一般情况下redis在接受到一个client发来的命令后会立即处理并返回处理结果，但是当一个client在一个连接中发出multi命令有，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接受到exec命令后，redis会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给client.然后此连接就结束事务上下文。
下面可以看一个例子：

redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> incr a
QUEUED
redis 127.0.0.1:6379> incr b
QUEUED
redis 127.0.0.1:6379> exec
1. (integer) 1
2. (integer) 1
从这个例子我们可以看到incr a ,incr b命令发出后并没执行而是被放到了队列中。调用exec后俩个命令被连续的执行，最后返回的是两条命令执行后的结果。
   我们可以调用discard命令来取消一个事务。接着上面例子：

redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> incr a
QUEUED
redis 127.0.0.1:6379> incr b
QUEUED
redis 127.0.0.1:6379> discard
OK
redis 127.0.0.1:6379> get a
"1"
redis 127.0.0.1:6379> get b
"1"
可以发现这次incr a incr b都没被执行。discard命令其实就是清空事务的命令队列并退出事务上下文。
   虽说redis事务在本质上也相当于序列化隔离级别的了。但是由于事务上下文的命令只排队并不立即执行，所以事务中的写操作不能依赖事务中的读操作结果。很可能有两个client同时做这个操作，也就是说如果我们要实现一个类似incr命令的功能，先get a取出我的值，再将a++，然后set a，我们期望是加两次a从原来的1变成3. 但是很有可能两个client的get a，取到都是1，造成最终加两次结果却是2。主要问题我们没有对共享资源a的访问进行任何的同步。也就是说redis没提供任何的加锁机制来同步对a的访问。
还好redis 2.1后添加了watch命令，可以用来实现乐观锁。看个正确实现incr命令的例子，只是在前面加了watcha ：

redis 127.0.0.1:6379> watch a
OK
redis 127.0.0.1:6379> get a
"1"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set a 2
QUEUED
redis 127.0.0.1:6379> exec
1. OK
redis 127.0.0.1:6379> get a
"2"
watch 命令会监视给定的key，当exec时候如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key.这样就可以对指定的key加乐观锁了。注意watch的key是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自动清除。当然了 exec、discard、unwatch命令都会清除连接中的所有监视.
   redis的事务实现是如此简单，当然会存在一些问题。第一个问题是redis只能保证事务的每个命令连续执行，但是如果事务中的一个命令失败了，并不回滚其他命令，比如使用的命令类型不匹配。

redis 127.0.0.1:6379> set a 5
OK
redis 127.0.0.1:6379> lpush b 5
(integer) 1
redis 127.0.0.1:6379> set c 5
OK
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> incr a
QUEUED
redis 127.0.0.1:6379> incr b
QUEUED
redis 127.0.0.1:6379> incr c
QUEUED
redis 127.0.0.1:6379> exec
1. (integer) 6
2. (error) ERR Operation against a key holding the wrong kind of value
3. (integer) 6
可以看到虽然incr b失败了，但是其他两个命令还是执行了。
还有一个问题是当事务的执行过程中，如果redis意外的挂了。很遗憾只有部分命令执行了，后面的也就被丢弃了。当然如果我们使用的append-only file方式持久化，redis会用单个write操作写入整个事务内容。即是是这种方式还是有可能只部分写入了事务到磁盘。发生部分写入事务的情况下，redis重启时会检测到这种情况，然后失败退出。可以使用redis-check-aof工具进行修复，修复会删除部分写入的事务内容。修复完后就能够重新启动了。

2.Redis管道（pipeline）
redis是一个cs模式的tcp server，使用和http类似的请求响应协议。一个client可以通过一个socket连接发起多个请求命令。每个请求命令发出后client通常会阻塞并等待redis服务处理，redis处理完后请求命令后会将结果通过响应报文返回给client。基本的通信过程如下：

Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
基本上四个命令需要8个tcp报文才能完成。由于通信会有网络延迟,假如从client和server之间的包传输时间需要0.125秒。那么上面的四个命令8个报文至少会需要1秒才能完成。这样即使redis每秒能处理100个命令，而我们的client也只能一秒钟发出四个命令。这显示没有充分利用 redis的处理能力。除了可以利用mget,mset 之类的单条命令处理多个key的命令外我们还可以利用pipeline的方式从client打包多条命令一起发出，不需要等待单条命令的响应返回，而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端。通信过程如下：

Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
假设不会因为tcp报文过长而被拆分。可能两个tcp报文就能完成四条命令，client可以将四个incr命令放到一个tcp报文一起发送，server则可以将四条命令的处理结果放到一个tcp报文返回。通过pipeline方式当有大批量的操作时候。我们可以节省很多原来浪费在网络延迟的时间。需要注意到是用 pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并是不是打包的命令越多越好。具体多少合适需要根据具体情况测试。下面是个jedis客户端使用pipeline的测试：
package com.jd.redis.client;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;

publicclass PipelineTest {

/**
* @param args
*/
publicstaticvoid main(String[] args) {

   int count = 1000;

   long start = System.currentTimeMillis();
   withoutPipeline(count);
   long end = System.currentTimeMillis();
   System.out.println("withoutPipeline: " + (end-start));

   start = System.currentTimeMillis();
   usePipeline(count);
   end = System.currentTimeMillis();
   System.out.println("usePipeline: " + (end-start));

}

privatestaticvoid withoutPipeline(int count){
   Jedis jr = null;
   try {
         jr = new Jedis("10.10.224.44", 6379);
         for(int i =0; i<count; i++){
            jr.incr("testKey1");
         }
   } catch (Exception e) {
         e.printStackTrace();
   }
   finally{
         if(jr!=null){
            jr.disconnect();
         }
   }
}

privatestaticvoid usePipeline(int count){
   Jedis jr = null;
   try {
         jr = new Jedis("10.10.224.44", 6379);
         Pipeline pl = jr.pipelined();
         for(int i =0; i<count; i++){
            pl.incr("testKey2");
         }
            pl.sync();
   } catch (Exception e) {
         e.printStackTrace();
   }
   finally{
         if(jr!=null){
            jr.disconnect();
         }
   }
}
}
输出：
withoutPipeline: 11341
usePipeline: 344

测试结果还是很明显有较大的差距，所以多次操作用pipeline还是有明显的优势。我用的是Win7中的Jedis Java客户端程序连接局域网的Linux虚拟机上的Redis Server。

相关文章

Redis入门1--入门篇
http://www.aboutyun.com/thread-17346-1-1.html

Redis入门2--Redis数据类型及相关命令
http://www.aboutyun.com/thread-17347-1-1.html

Redis入门3--Redis键值设计和Redis数据存储优化机制
http://www.aboutyun.com/thread-17361-1-1.html

Redis入门4--Redis排序
http://www.aboutyun.com/thread-17377-1-1.html

Redis入门5--Redis事务与Redis管道（pipeline）
http://www.aboutyun.com/thread-17378-1-1.html

Redis入门6--Redis发布/订阅
http://www.aboutyun.com/thread-17384-1-1.html

Redis入门7--Redis持久化
http://www.aboutyun.com/thread-17388-1-1.html

Redis入门8--Redis主从复制与分布式
http://www.aboutyun.com/thread-17401-1-1.html

页: [1]

About云-梭伦科技's Archiver

Redis入门5--Redis事务与Redis管道（pipeline）