java redis事务_Redis的Java客户端 Jedis和redis事务

1)         Jedis所需要的jar包 ,可通过Maven的依赖引入

Commons-pool-1.6.jar

Jedis-2.1.0.jar

2)         使用Windows环境下Eclipse连接虚拟机中的Redis注意事项

l  禁用Linux的防火墙：Linux(CentOS7)里执行命令 ： systemctl stop firewalld.service

l  redis.conf中注释掉bind 127.0.0.1 ,然后 protect-mode no。

3)         Jedis测试连通性

public class Demo01 {

public static void main(String[] args) {

//连接本地的 Redis 服务

Jedis jedis = new Jedis("127.0.0.1",6379);

//查看服务是否运行，打出pong表示OK

System.out.println("connection is OK=======>:"+jedis.ping());

}

}

4)         完成一个手机验证码功能

要求:

1、输入手机号，点击发送后随机生成6位数字码，2分钟有效

2、输入验证码，点击验证，返回成功或失败

3、每个手机号每天只能输入3次

Jedis jedis =new Jedis("192.168.137.128",6379);//输入手机号，点击发送后随机生成6位数字码，2分钟有效//获取手机号

String phoneNumber = request.getParameter("phone_no");if(phoneNumber==null) {return;

}//每个手机号每天只能输入3次

String countKey = phoneNumber +":count";

String countStr= jedis.get(countKey);if(countStr ==null) {//当前的手机号是第一次发送验证码

jedis.setex(countKey,VerifyCodeConfig.SECONDS_PER_DAY , "1");

}else {//该手机号不是第一次发送验证码

int count =Integer.parseInt(countStr);if(count<3) {

jedis.incr(countKey);//次数增加1

}else{

response.getWriter().print("limit");

jedis.close();return;

}

}//生成6个长度的随机数(验证码)

String code =genCode(6);//将验证码存到redis中，两分钟有效

String codeKey=VerifyCodeConfig.PHONE_PREFIX + phoneNumber+VerifyCodeConfig.CODE_SUFFIX;

jedis.setex(codeKey, VerifyCodeConfig.CODE_TIMEOUT, code);

System.out.println(code);//将验证码发送到手机，(控制台)

response.getWriter().print(true);

jedis.close();

Redis中事务的定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

Redis事务的主要作用就是串联多个命令防止别的命令插队

multi 、exec、discard

1)         从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，至到输入Exec后，Redis会将之前的命令队列中的命令依次执行。

2)       组队的过程中可以通过discard来放弃组队。

事务中的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列会都会被取消。

为什么要做成事务?

1)         想想一个场景: 有很多人有你的账户，同时去参加双十一抢购

2)   通过事务解决的问题

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

Redis事务的使用

1)         WATCH key[key….]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

1)         unwatch

取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。

2)         三特性

l  单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

l  没有隔离级别的概念

队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题

l  不保证原子性

Redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚