Redis 并发, 锁, 竞争锁问题.

Redis并发问题

Redis为单进程单线程模式,采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念,Redis对于多个客户端连接并不存在竞争,但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题,这些问题均是由于客户端连接混乱造成。对此有2种解决方法:

1.客户端角度,为保证每个客户端间正常有序与Redis进行通信,对连接进行池化,同时对客户端读写Redis操作采用内部锁synchronized。

2.服务器角度,利用setnx实现锁。

对于第一种,需要应用程序自己处理资源的同步,可以使用的方法比较通俗,可以使用synchronized也可以使用lock;第二种需要用到Redis的setnx命令,但是需要注意一些问题。

SETNX命令(SET if Not eXists)

语法:

SETNX key value

功能:
将 key 的值设为 value ,当且仅当 key 不存在;若给定的 key 已经存在,则 SETNX 不做任何动作。

时间复杂度:
O(1)
返回值:
设置成功,返回 1 。
设置失败,返回 0 。

模式:将 SETNX 用于加锁(locking)

SETNX 可以用作加锁原语(locking primitive)。比如说,要对关键字(key) foo 加锁,客户端可以尝试以下方式:

SETNX lock.foo <current Unix time + lock timeout + 1>

如果 SETNX 返回 1 ,说明客户端已经获得了锁, key 设置的unix时间则指定了锁失效的时间。之后客户端可以通过 DEL lock.foo 来释放锁。

如果 SETNX 返回 0 ,说明 key 已经被其他客户端上锁了。如果锁是非阻塞(non blocking lock)的,我们可以选择返回调用,或者进入一个重试循环,直到成功获得锁或重试超时(timeout)。

但是已经证实仅仅使用SETNX加锁带有竞争条件,在特定的情况下会造成错误。

处理死锁(deadlock)

上面的锁算法有一个问题:如果因为客户端失败、崩溃或其他原因导致没有办法释放锁的话,怎么办?

这种状况可以通过检测发现——因为上锁的 key 保存的是 unix 时间戳,假如 key 值的时间戳小于当前的时间戳,表示锁已经不再有效。

但是,当有多个客户端同时检测一个锁是否过期并尝试释放它的时候,我们不能简单粗暴地删除死锁的 key ,再用 SETNX 上锁,因为这时竞争条件(race condition)已经形成了:

C1 和 C2 读取 lock.foo 并检查时间戳, SETNX 都返回 0 ,因为它已经被 C3 锁上了,但 C3 在上锁之后就崩溃(crashed)了。
C1 向 lock.foo 发送 DEL 命令。
C1 向 lock.foo 发送 SETNX 并成功。
C2 向 lock.foo 发送 DEL 命令。
C2 向 lock.foo 发送 SETNX 并成功。
出错:因为竞争条件的关系,C1 和 C2 两个都获得了锁。

幸好,以下算法可以避免以上问题。来看看我们聪明的 C4 客户端怎么办:

C4 向 lock.foo 发送 SETNX 命令。
因为崩溃掉的 C3 还锁着 lock.foo ,所以 Redis 向 C4 返回 0 。
C4 向 lock.foo 发送 GET 命令,查看 lock.foo 的锁是否过期。如果不,则休眠(sleep)一段时间,并在之后重试。
另一方面,如果 lock.foo 内的 unix 时间戳比当前时间戳老,C4 执行以下命令:
GETSET lock.foo <current Unix timestamp + lock timeout + 1>

因为 GETSET 的作用,C4 可以检查看 GETSET 的返回值,确定 lock.foo 之前储存的旧值仍是那个过期时间戳,如果是的话,那么 C4 获得锁。
如果其他客户端,比如 C5,比 C4 更快地执行了 GETSET 操作并获得锁,那么 C4 的 GETSET 操作返回的就是一个未过期的时间戳(C5 设置的时间戳)。C4 只好从第一步开始重试。
注意,即便 C4 的 GETSET 操作对 key 进行了修改,这对未来也没什么影响。

这里假设锁key对应的value没有实际业务意义,否则会有问题,而且其实其value也确实不应该用在业务中。

为了让这个加锁算法更健壮,获得锁的客户端应该常常检查过期时间以免锁因诸如 DEL 等命令的执行而被意外解开,因为客户端失败的情况非常复杂,不仅仅是崩溃这么简单,还可能是客户端因为某些操作被阻塞了相当长时间,紧接着 DEL 命令被尝试执行(但这时锁却在另外的客户端手上)。

GETSET命令

语法:

GETSET key value

功能:
将给定 key 的值设为 value ,并返回 key 的旧值(old value)。当 key 存在但不是字符串类型时,返回一个错误。

时间复杂度:
O(1)

返回值:
返回给定 key 的旧值;当 key 没有旧值时,也即是, key 不存在时,返回 nil 。

ref by

http://blog.csdn.net/hpb21/article/details/7893013

http://redis.readthedocs.org/en/latest/string/setnx.html

时间: 2024-10-24 15:41:33

Redis 并发, 锁, 竞争锁问题.的相关文章

Redis并发竞争

Redis是一种单线程机制的nosql数据库,基于key-value,数据可持久化落盘.由于单线程所以Redis本身并没有锁的概念,多个客户端连接并不存在竞争关系,但是利用jedis等客户端对Redis进行并发访问时会出现问题. 比如:同时有多个子系统去set一个key.这个时候要注意什么呢? 举一个例子:多客户端同时并发写一个key,一个key的值是1,本来按顺序修改为2,3,4,最后是4:但是顺序变成了4,3,2,最后变成了2. 并发竞争可用的解决方案如: 分布式锁+时间戳 利用消息队列 原

高并发架构系列:Redis并发竞争key的解决方案详解

需求由来 1.Redis高并发的问题 Redis缓存的高性能有目共睹,应用的场景也是非常广泛,但是在高并发的场景下,也会出现问题:缓存击穿.缓存雪崩.缓存和数据一致性,以及今天要谈到的缓存并发竞争. 这里的并发指的是多个redis的client同时set key引起的并发问题. 2.出现并发设置Key的原因 Redis是一种单线程机制的nosql数据库,基于key-value,数据可持久化落盘.由于单线程所以Redis本身并没有锁的概念,多个客户端连接并不存在竞争关系,但是利用jedis等客户端

redis并发竞争问题及解决方案

redis并发竞争问题及解决方案 为什么会出现竞争问题? 多客户端同时并发写一个key,一个key的值是1,本来按顺序修改为2,3,4,最后是4,但是顺序变成了4,3,2,最后变成了2. 如何解决? 第一种方案:分布式锁+时间戳 分布式锁可以使用redis自身的分布式锁,也可以使用zookeeper,但是一般使用后者, 由于上面举的例子,要求key的操作需要顺序执行,所以需要保存一个时间戳判断set顺序. 系统A key 1 {ValueA 7:00}系统B key 1 { ValueB 7:0

java多线程并发系列之锁的深入了解

上一篇博客中 : java多线程.并发系列之 (synchronized)同步与加锁机制 .介绍了java中Synchronized和简单的加锁机制,在加锁的模块中介绍了 轮询锁和定时锁,简单回顾下 轮询锁:利用tryLock来获取两个锁,如果不能同时获得,那么回退并重新尝试. 定时锁:索取锁的时候可以设定一个超时时间,如果超过这个时间还没索取到锁,则不会继续堵塞而是放弃此次任务. 锁的公平性 在公平的锁上,线程将按照它们发出请求的顺序来获取锁 上面似乎忘记了还有一种可中断锁和可选择粒度锁 可中

如何用 redis 造一把分布式锁

基本概念 锁 wiki:In computer science, a lock or mutex (from mutual exclusion) is a synchronization mechanism for enforcing limits on access to a resource in an environment where there are many threads of execution. A lock is designed to enforce a mutual e

网上资料笔记总结!!数据库事务并发问题,锁机制和对应的4种隔离级别

数据库事务并发问题 数据库的操作通常为写和读,就是所说的CRUD:增加(Create).读取(Read).更新(Update)和删除(Delete).事务就是一件完整要做的事情.事务是恢复和并发控制的基本单位.事务必须始终保持系统处于一致的状态,不管在任何给定的时间并发事务有多少.事务在关系数据库中,一个事务可以是一条SQL语句,一组SQL语句或整个程序.是数据库中各种数据项的一个程序执行单元.事务是用户定义的一个操作序列(多个表同时读写).这些操作要么都做,要么都不做,是一个不可分割的工作单位

海量并发的无锁编程 (lock free programming)

最近在做在线架构的实现,在线架构和离线架构近线架构最大的区别是服务质量(SLA,Service Level Agreement,SLA 99.99代表10K的请求最多一次失败或者超时)和延时.而离线架构在意的是吞吐,SLA的不会那么严苛,比如99.9.离线架构一般要有流控,以控制用户发送请求的速度.以免多于服务端处理能力的请求造成大量的数据在buffer或者队列里堆积,造成大量的超时.在线架构不可能有流控了,你不能限制用户的请求.因此在线架构对于弹性扩容有很高的要求,在大量请求到来时自动扩展后台

《java并发编程实战》读书笔记8--死锁,性能与可伸缩性,锁粒度锁分解锁分段

第10章 避免活跃性危险 10.1 死锁 -10.1.1 锁顺序死锁 最简单的一种死锁形式: -10.1.2 动态的锁顺序死锁 可以通过下面的方法来解决: -10.1.3 在协作对象之间发生死锁 -10.1.4 开放调用 如果在调用某个方法时不需要持有锁,那么这种调用就被称为开放调用. -10.1.5 资源死锁 当多个线程在相同资源上等待时,也会发生死锁. 10.2 死锁的避免与诊断 -10.2.1 支持定时的锁 显示使用Lock类中的定时tryLock功能(见13章)来代替内置锁机制. -10

并发浅谈-锁和Token的应用

并发 即在同一时刻内有多个完成同一任务的进程或线程在同时运行.并发一般发生在大流量集中访问如抢购或秒杀等业务场景中,它所带来的影响主要表现在以下两个方面:1:造成系统的负载压力过大.比如说mysql天生在处理大并发时表现的异常吃力,并发大时经常可以造成数据库挂掉.2:造成业务资源的竞争出现.比如说兑换一个激活码,并发下可能会出现两个人同时兑换到的同一个激活码. 从开发的经验来看,一般开发者在写程序逻辑时,绝大多数的情况下是没有考虑并发问题的:这其中有两个方面,一是与业务有关,二是与经验有关:其中