redis竞汰数据同步问题解决

Redis

面试的时候遇到过问Redis是如何解决“竞态条件”的，相关知识点总结一下。

乐观锁

所谓竞态条件，举个例子，一个代表点击数的数值hitcount，每个客户点击一次则＋1。

没有事务的时候，假设我们的操作如下：

hc=GET hitcount;

hc=hc+1;

SET hitcount $hc;

非并发状态下，这样做是OK的，但是并发状态下会出现的问题是：

1

A和B两个客户端分别从Redis处取值，并+1，值都是11。

2

Redis是单线程模型，所以A和B的SET命令只能先执行1个，此处先执行A，hitcount更新为11。

3

接着执行B的SET命令，hitcount依然是11，这就是明显的因为竞态而产生的错误，hitcount应该为12才是。

Redis的事务其实是通过MULTI命令开启事务，将后续一系列的命令放在一个队列里，不立即执行，直到EXEC命令，队列中的命令才会依次执行。

命令类似：

MULTI;

set val1 111;

set val2 222;

EXEC;

在实际工作中，我们也会经常遇到这种问题：我们必须先拿到数据，根据数据做出判断，进行一些处理之后，再更新数据，这时候我们就没法保证取数据、更新数据在同一个队列事务中了。

这就需要乐观锁。简单说，我们每取一个数据的时候，Redis不仅返回数值，还会返回这个数值的版本号。

当我们执行更新命令时，Redis会拿你要SET值的版本号与库里现在值的版本号进行比对，如果相同，则更新，版本号变更。

如果版本号不同，则说明在我们执行更新命令之前，有其他客户端修改了这条数据，我们的更新操作失败。

Redis里是通过WATCH命令来监控版本号的。

WATCH hitcount;

hc=GET hitcount;

hc=hc+1;

MULTI;

SET hitcount $hc;

EXEC;

因为通过WATCH监控了hitcount这个Key，那么在事务中SET的时候，一旦发现版本号不对，执行就失败。

悲观锁

乐观锁是CAS——Check And Set，先检查（版本号）再设置更新，那么悲观锁就是先锁，再查，最后更新。

以MySQL为例，我们要实现悲观锁：

SELECT * FROM tabA AS t WHERE t.id=1 FOR UPDATE;

这样，因为主键是明确指定的（id=1），所以这一行记录就被锁定了——行锁定，在本事务被commit之前，这条数据都只会被本事务的SQL语句进行修改，其他事务的加锁操作，更新操作都会在本事务提交之后再执行，单纯的查询则不受影响。

如果没有指定明确地主键，则锁定的是表——表锁定。