Redis事务,你真的了解吗

Redis事务

redis提供了简单的“事务”能力,multi,exec,discard,watch/unwatch指令用来操作事务。

• mutil：开启事务，此后所有的操作将会添加到当前链接的事务“操作队列”中。
• exec：提交事务
• discard：取消事务，记住，此指令不是严格意义上的“事务回滚”，只是表达了“事务操作被取消”的语义，将会导致事务的操作队列中的操作不会被执行，且事务关闭。
• watch/unwatch：“观察”，这个操作也可以说是redis的特殊功能，但是也可说是redis不能提供“绝对意义上”的事务能力而增加的一个“补充特性”（比如事务隔离，多事务中操作冲突解决等）；在事务开启前，可以对某个key注册“watch”，如果在事务提交后，将会首先检测“watch”列表中的key集合是否被其他客户端修改，如果任意一个key 被修改，都将会导致事务直接被“discard”；即使事务中没有操作某个watch key，如果此key被外部修改，仍然会导致事务取消。事务执行成功或者被discard，都将会导致watch key被“unwatch”，因此事务之后，你需要重新watch。watch需要在事务开启之前执行。

Watch

WATCH所注册的KEY，事实上无论是被其他Client修改还是当前Client修改，如果不重新WATCH，都将无法在事务中正确执行。WATCH指令本身就是为事务而生，你或许不会在其他场景下使用WATCH；例如：

String key = "transaction-key";  
jedis.set(key, "20");  
jedis.watch(key);//注册key,此后key将会被监控，如果在事务执行前被修改，则导致事务被DISCARD。  
jedis.incr(key);//此key被修改，即使是自己，也会导致watch在事务中执行失效  
jedis.unwatch();//取消注册  
jedis.watch(key);//重新注册,在重新注册前，必须unwatch  
Transaction tx = jedis.multi();//开启事务，开启事务前进行watch
……

Redis事务底层原理

Redis中，如果一个事务被提交，那么事务中的所有操作将会被顺序执行，且在事务执行期间，其他client的操作将会被阻塞；Redis采取了这种简单而“粗鲁”的方式来确保事务的执行更加的快速和更少的外部干扰因素。

EXEC指令将会触发事务中所有的操作被写入AOF文件（如果开启了AOF），然后开始在内存中实施这些数据变更操作；Redis将会尽力确保事务中所有的操作都能够执行，如果redis环境故障，有可能导致事务未能成功执行，那么需要在redis重启后增加额外的校验工作。
如果在EXEC指令被提交之前，Redis-server即检测到提交的某个指令存在语法错误，那么此事务将会被提前标记DISCARD，此后事务提交也将直接被驳回；但是如果在EXEC提交后，在实施数据变更时（Redis将不会预检测数据类型，比如你对一个“非数字”类型的key执行INCR操作），某个操作导致了ERROR，那么redis仍然不会回滚此前已经执行成功的操作，而且也不会中断ERROR之后的其他操作继续执行。对于开发者而言，你务必关注事务执行后返回的结果（结果将是一个集合，按照操作提交的顺序排列，对于执行失败的操作，结果将是一个ERROR）。
Redis的事务之所以如此设计，它为了确保本身的性能，同时不引入“关系型数据库”的设计复杂度；你不能完全希望Redis能为你交付完美的事务操作，只能说，你选择了错误的工具。

    public void transaction(){  
        String key = "transaction-key";  
        jedis.set(key, "20");  
        jedis.watch(key);  
        Transaction tx = jedis.multi();  
        tx.incr(key);  
        tx.incr(key);  
        tx.incr(key);  
        List