前面我们对Redis事务锁机制做过简单的介绍，其中提到了悲观锁和乐观锁两个概念，不同的处理策略，也代表着适用于不同的场景。今天的大数据开发学习分享，我们就来讲讲Redis事务锁不同的锁，适用于什么样的场景。
一、悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
二、乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。
乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
三、不同事务锁的适用场景
悲观锁：比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。
乐观锁：比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。常见应用为秒杀系统、抢红包等。
四、Redis的watch机制实现乐观锁
监视一个(或多个)key，如果在事务exec执行之前这个(或这些)key被其他命令所改动，那么事务将被打断。
127.0.0.1:6379>set k 1
OK
#监视k1（当已经开始监控k1，则其他客户端不能修改k1的值）
127.0.0.1:6379>WATCH k
OK
#设置k1值为2
127.0.0.1:6379>set k 2
OK
#开始事务
127.0.0.1:6379>MULTI
OK
#修改k值为3
127.0.0.1:6379>set k 3
QUEUED
#提交事务，但k值不会被修改为3，因为在事务开启之前k的值被修改了
127.0.0.1:6379>EXEC
(nil)
127.0.0.1:6379>get k1
"2"
关于大数据开发学习，Redis事务锁适用场景，以上就为大家做了简单的介绍了。Redis事务锁当中，悲观锁和乐观锁各有其适用的场景，而在不同的场景下，也就需要结合到实际情况去制定方案。
网友评论