时间：2021-01-31 08:12:14 | 栏目：Redis | 点击：次
前言
上周“被”上线了一个紧急项目，周五下班接到需求，周一开始思考解决方案，周三开发完成，周四走流程上线，也算是面向领导编程了。之前的项目里面由于是自运维，然后大多数又都赶时间，所以在处理定时任务上面基本都是自己在服务器上添加crontab，而不是让多个实例自己去处理定时任务的并发锁，并且Laravel 5.5开始自带并发锁，我们也快升级了。但是这次项目是Python项目，无奈只能自己实现一下，以下这个方案实现起来非常简单且易于理解。
import redis
r = redis.Redis(...)
last_heart = 0 # 记录上一次得到的锁心跳
free_lock_try = 6 # 锁无心跳的最大次数
while not r.setnx('mylock', 1):
now_heart = r.get('mylock')
print(f"没获取到锁,now_heart={now_heart},last_heart={last_heart},free_lock_try={free_lock_try}")
if now_heart == last_heart:
free_lock_try = free_lock_try - 1
if free_lock_try == 0: # 锁已经1分钟没有心跳了
old_heart = r.getset('mylock', 1) # 将lock重置为1，并返回set之前的心跳值
if old_heart < now_heart:
time.sleep(10)
continue
else:
break # 成功获取到锁，退出循环
else:
free_lock_try = 6 # 锁有心跳，重置free_lock_try值
last_heart = now_heart
time.sleep(10)
def producer_exit():
"""程序正常退出时候自动清理锁"""
r.delete('mylock')
import atexit
atexit.register(producer_exit)
# 业务代码
while True:
r.incr('mylock') # 让锁心跳加一
...
我们来看看这段程序都解决了并发锁中的哪些问题
导致Redis并发原因解释
正所谓只有知其然才能知其所以然，只有弄明白问题出现的原因所在，才能对症下药，寻找解决问题的良方。众所周知，Redis程序采用单线程模式进行运行，作为单线程程序，Redis客户端的命令是逐条执行，也叫做One by One执行。既然是逐条命令执行，从表面上来看Redis似乎不存在高并发的问题，这一观点论也有道理，原子性的Redis命令本身也确实不存在高并发问题，这与多线程下的程序勃然不同。但是我们项目工作搭建Redis环境之后，通常都会是一组命令集合执行程序，一个请求中就包含了N个Redis执行命令，再加上多个客户端请求，命令就更多了，导致连接超时、数据混乱或错误、请求阻塞等多种问题。
即总结为，产生Redis并发诱因是程序中的业务复杂度导致。
总结