redis笔记3--事务及优

info clients ：查看当前连接的客户端数

config get maxclients ：查看redis允许的最大连接数

前言:

redis事务和传统关系型数据库的事务还有区别。

传统关系型数据库会告诉数据库服务器：开始事务，然后执行一系列的读写操作，然后提交事务或回滚。

在redis中，有简单的方法可以控制多个读写命令按顺序执行并相互保持一致。通过multi命令开始事务，发送一系列的命令，执行exec。在exec命令之前，不会做任何处理。

redis命令都具有原子性，包括一次处理多项事情的命令。对于使用多个命令，redis支持事务功能。

redis实际上是单线程运行的，这就是为什么每个redis命令都能保证具有原子性，当一个命令在执行时，没有其他命令会运行。

inrc 实际上是一个get命令后紧随一个set命令

getset 设置一个新的值，然后返回原始值

setnx(SET IF NOT EXISTS) 先测试关键字是否存在，当关键字不存在时就进行值的设置

事务特点:

事务中的命令将会按顺序地被执行

事务中的命令将会如单个原子操作般被执行(中途不会有其他客户端命令被执行)

事务中的命令要么全部被执行，要么不会执行

注意：虽然redis是单线程运行的，但是我们可以同时运行多个redis客户端进程。如此多个客户端进程操作同一个数据就会有问题。通过添加watch来解决。监视一个(或多个)key，如果在事务执行之前这个(或这些)key被其他命令所改动，那么事务将会执行失败。

常见的场景就是购物付费。

multi/exec的延迟执行可以提高性能：

multi命令后，所有的命令都会放入队列中，直到exec命令才会执行。同时客户端会等待所有命令执行完后返回的结果。通过减少与服务器的交互次数，这种命令管道(pipelining)的方式能够提高redis的性能。

购物付费案例:

1.定义用户和库存

使用Hash来存储用户信息。每个用户的库存清单都使用Set来保存唯一的ID。如图：

商城的需求很简单：用户能展示商品和商品价格，当其他用户付钱时，卖家就会收到钱。为了记录足够的信息，我们要关联货品ID和卖货品的人，通过ZSET集合来记录该信息，score就是货品卖出的价钱。

2.在市场列出要出售的货品

在列表程序中，我们需要用到watch命令，结合multi和exec命令来使用。还有unwatch和discard命令。当我们用watch命令来监视任何key时，在我们执行exec命令之前，任何时候有客户端替换，更新或删除了这个key，操作都会失败。通过使用watch,multi/exec,unwatch/discard这些命令，可以保证操作数据意外中断时不会出现问题。

在执行watch命令后，multi命令之前，执行unwatch命令会重置我们的连接。在multi之后，exec命令之前执行discard命令也会重置连接。

也就是说，如果我们监视了某个或某些key，我们能够通过这两个命令取消监视，并且清除命令队列里的待执行命令。

程序清单：添加产品到超市的zset集合中，通过watch监视卖家的库存清单，来保证产品任然有效。
function list_item(conn,itemid,sellerid,price){
var inventory = "inventory:"+sellerid;//market set
var item =itemid+":"+sellerid;  //market zset 

end = new Date().getTime()+5;
pipe = conn.pipeline();
while(new Date().getTime < end){
try{
              pipe.watch(inventory);//监视inventory中的数据变化
    if(!pipe.sismember(inventory,itemid)){//查看库存集合中是否存在
pipe.unwatch(inventory);//如果库存中没有，停止监视这条库存信息
return null;
                }
                pipe.multi();
                pipe.zadd("market:",item,price);//将用户库存的商品放入超市
                pipe.srem(inventory,itemid);
                pipe.execute();
                return true;
         }catche(Exception e){

         }
         return false;
       }
}
在一系列初始化工作之后，我们就告诉redis要监视库存inventory集合中的数据，验证用户是否还能卖这些货物，如果能卖，就将这些货物添加到超市，同时从库存表里删除这条信息。如果在监视期间，这条库存记录有改动，就会报错。
如果user17要以97刀的价格卖itemM，需要执行的一系列操作如下：

watch("inventory:17") 监视库存表

sismember("inventory:17","itemM")，查看商品是否还能卖

zadd("market","item:17",97) 添加产品到超市

srem("inventory:17","itemM") 删除库存中的记录

3.给已买的货品付费

为了付款，首先我们要监视商城(market)中的信息，和买这个产品的用户信息。然后获取用户的总资金和购买产品的价钱，并且验证买家有足够的金额。

为什么redis不实现传统的锁机制？

当修改传统关系型数据库时，关系型数据库会给操作的行记录添加锁，直到事务结束commit或rollback。任何其他的客户端尝试修改数据时，都会阻塞，直到事务提交。可能造成潜在的长时间的等待。

由于redis的目的是最小化等待时间，所以在监视(watch)过程中，redis不会锁定数据。替代的是redis会提醒客户端，有人修改了数据，也就是我们常说的乐观锁。

4.Non-transactional pipelines

在multi和exec命令执行期间，其他客户端不能做任何事。

通过使用pipeline技术(不添加事务)，可以提高redis命令执行效率。

在redis中，本身就有一些命令可以接收处理多个参数，如 mget,mset,hmget,hmset,rpush/lpush,sad,zadd。这些命令是为了简化一些相同的重复操作。

使用非事务的管道执行技术也能提升一部分性能，该技术允许我们同时运行一些列命令。

在不需要事务的场景下，我们任然可以通过multi/exec来发送所有命令，来最小化通信次数和延迟。但是multi和exec也不是毫无损耗的，这些命令会延迟其他重要命令的执行。通过pipelining(不使用multi/exec)命令，我们可以获取同样的性能，同时不会有事务带来的性能损耗。

使用测试函数来测试函数的性能：
function benchmark_update_token(conn,duration){
for(function in (update_token,update_token_pipeline)){
    count =0;
    start = time.time();
    end = start+duration;
    while(time.time() < end){
        count += 1;
        function(conn,”token”,”user”,”item”);
            }
            delta = time.time() – start;
        }
}
5.性能考虑

使用redis-benchmark去测试redis性能，默认会限制50个客户端连接。

redis常用场景：

使用redis保存应用的配置信息

由于我们经常会在配置文件中维护一些标识性的信息，这就导致在每次修改标识后，所有的服务都需要去更新这个配置文件，同时还要重启服务来读取新的配置文件。解决方案就是使用redis来替换配置文件的存取。建议：每个应用单独的部分都各自配置一个redis服务，如：保存日志的，保存静态资源的，保存cookies的等等。我们可以在一台机器上跑多个redis服务，只需要改变端口即可。这样会导致要连接的redis配置信息很多，由于每个服务都有各自的连接配置，导致很难管理。同理，单独运行一个redis服务来保存和维护所有的连接配置信息。

秒客网

redis笔记3--事务及优

redis常用场景：

相关文章