Redis乐观锁实现秒杀 - 好文

1、使用watch，采用乐观锁
2、不使用悲观锁，因为等待时间非常长，响应慢
3、不使用队列，因为并发量会让队列内存瞬间升高
import java.util.concurrent.ExecutorService; import
java.util.concurrent.Executors;import redis.clients.jedis.Jedis; /** *
redis测试抢购 * * @author 10255_000 * */ public class RedisTest { public static void
main(String[] args) { final String watchkeys = "watchkeys"; ExecutorService
executor = Executors.newFixedThreadPool(20); final Jedis jedis = new Jedis(
"192.168.3.202", 6379); jedis.set(watchkeys, "0");// 重置watchkeys为0 jedis.del(
"setsucc", "setfail");// 清空抢成功的，与没有成功的 jedis.close(); for (int i = 0; i < 10000
; i++) {// 测试一万人同时访问 executor.execute(new MyRunnable()); } executor.shutdown();
} }import java.util.List; import java.util.UUID; import
redis.clients.jedis.Jedis;import redis.clients.jedis.Transaction; public class
MyRunnable implements Runnable { String watchkeys = "watchkeys";// 监视keys Jedis
jedis =new Jedis("192.168.3.202", 6379); public MyRunnable() { } @Override
public void run() { try { jedis.watch(watchkeys);// watchkeys String val =
jedis.get(watchkeys);int valint = Integer.valueOf(val); String userifo =
UUID.randomUUID().toString();if (valint < 10) { Transaction tx = jedis.multi();
// 开启事务 tx.incr("watchkeys"); List<Object> list = tx.exec();//
提交事务，如果此时watchkeys被改动了，则返回null if (list != null) { System.out.println("用户：" +
userifo +"抢购成功，当前抢购成功人数:" + (valint + 1)); /* 抢购成功业务逻辑 */ jedis.sadd("setsucc",
userifo); }else { System.out.println("用户：" + userifo + "抢购失败"); /* 抢购失败业务逻辑 */
jedis.sadd("setfail", userifo); } } else { System.out.println("用户：" + userifo +
"抢购失败"); jedis.sadd("setfail", userifo); // Thread.sleep(500); return; } } catch
(Exception e) { e.printStackTrace(); }finally { jedis.close(); } } }
* 1
* 2
* 3
* 4
* 5
* 6
* 7
* 8
* 9
* 10
* 11
* 12
* 13
* 14
* 15
* 16
* 17
* 18
* 19
* 20
* 21
* 22
* 23
* 24
* 25
* 26
* 27
* 28
* 29
* 30
* 31
* 32
* 33
* 34
* 35
* 36
* 37
* 38
* 39
* 40
* 41
* 42
* 43
* 44
* 45
* 46
* 47
* 48
* 49
* 50
* 51
* 52
* 53
* 54
* 55
* 56
* 57
* 58
* 59
* 60
* 61
* 62
* 63
* 64
* 65
* 66
* 67
* 68
* 69
* 70
* 71
* 72
* 73
* 74
* 75
* 76
* 77
* 78
* 79
* 80
* 81
* 82
* 83
* 84

Redis对事物的支持目前比较简单。Redis只能保证一个client发起的事务中的命令可以连续的执行,但后面命令出错前面不会回滚。而中间不会插入其他client的命令。当一个client在找一个连续中发出multi命令时，这个链接会进入一个事务上下文，该链接后续的命令不会立即执行，而是先放到队列中，当执行exec命令是，redis会顺序的执行队列中的所有命令。当如果队列中有命令错误，不会回滚。

乐观锁：大多数是基于数据版本(version)的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个”version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号+1。此时，将提交数据的版本号与数据库表对应记录版本号进行比对，如果提交的数据版本号大于数据当前版本号，则予以更新，否则认为是过去数据。

在Redis中，使用watch命令实现乐观锁(watch key):

watch命令会监视给定的key，当exec时，如果监视的key从调用watch后发生过变化，则事务会失败，也可以调用wathc多长监视多个key。这样就可以对指定key加乐观锁了。注意watch的可以是对整个连接有效的。事务也一样。如果连接断开，监视和事务都会被自动清除。当然exec，discard，unwatch命令都会清除连接中的所有监视

热门工具换一换