大家好~我是
米洛！
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的完整教程，希望大家多多支持。
欢迎关注我的公众号米洛的测开日记，获取最新文章教程!
回顾
上一节我们编写了在线执行Redis命令的功能，页面也勉强能用了。对于前置条件这块来说，就好像沙鲁吞了17号，已经算半个完全体了。
我们趁热打铁，解决一下因为部署多机器引发的Apscheduler重复执行的问题。
APScheduler带来的问题
APScheduler其实本质上还是一个定时任务组件，它并没有celery那么强大复杂的系统。针对多台机器，或者uvicorn(gunicorn)的多个worker，它是会重复执行的。
这里感谢一下小右君，他告诉我前面有大坑。
像我们平时那么启动:
if __name__ == "__main__":
uvicorn.run(app='main:pity', host='0.0.0.0', port=7777)
这样其实只开了1个worker，你想呀，1个工人执行定时任务，当然不存在竞争的问题，但多个工人一起执行，你就存在信息不对称的问题。
工人A到点了，要干活了，他不知道B也准备干同样的活儿，所以任务重复执行的问题，就出现了。
解决问题的方向
我只启动1个worker
有点傻，而且性能不好使，多台机器部署依然有问题。
推荐指数: 0颗星
- 初始化sceduler的时候，利用socket占据一个固定的端口比如2333
端口号只能被1个worker占领，其他worker拿不到，也就起不来了。但还是不能支持多节点部署，实际上只有1个worker使用，浪费了1个端口。
推荐指数: ⭐⭐⭐
- 分布式锁
不够轻量，需要引入第三方组件如: Redis/Zookeeper/Etcd。但能很好解决多worker和多节点的问题。
推荐指数: ⭐⭐⭐
办法很多，但是好用的真不多。由于我们本身就需要引入Redis，还是秉着不滥用中间件的原则，所以我们打算用Redis的分布式锁。
而关于redis分布式锁，有很多介绍。我们用牛人们封装好的RedLock来帮我们解决同时执行问题。
Redlock
比起自己setnx+用lua脚本保障分布式锁执行，官方后面给出了redlock的解决方案。更多这些细节可以自行搜索Redlock。
我们这边采用第三方的库: Redlock来简化我们的开发。
基本上用with获取lock，传入redis节点信息即可，接着我们就可以编写相关代码了。
我们还是用装饰器的方法，在想要加锁的方法引入此装饰器。key是自己定义的执行key，用于确定锁的唯一性。
分布式锁的原理就是多台设备同时去试图创建key，先创建成功的就执行对应的操作。所以对于所有节点来说，key必须都统一起来，并且不能和其他分布式锁的key冲突。
import functools
import os
from redlock import RedLock, RedLockError
from config import Config
def lock(key):
def decorator(func):
@functools.wraps(func)
async def wrapper(*args, **kwargs):
try:
# 试图获取分布式锁，如果没有获取到则会抛出RedLockError，所以我们这里捕获它
with RedLock(f"distributed_lock:{func.__name__}:{key}:{str(args)}",
connection_details=Config.RedisCluster,
):
return await func(*args, **kwargs)
except RedLockError:
print(f"进程: {os.getpid()}获取任务失败, 不用担心，还有其他哥们给你执行了")
return wrapper
return decorator
关于唯一key的确认，我这边首先加上了distributed_lock的前缀，是因为方便区分其他key，接着通过函数名称+唯一key确认分布式key，但由于有的方法是带参数的，所以我选择再加一个args，来支持那些同方法不同参数的任务。
运用到pity之中
我们只需要在run_test_plan方法加上lock这个装饰器即可，总体来说还是非常方便的。
如果需要测试的话，大家可以用以下命令启动pity:
uvicorn main:pity --host=0.0.0.0 --port=7777 --workers=4
可以看到，日志都输出了4份，因为有4个worker。用这个模式启动PITY的话，可以看到对应的效果。
关于Redlock，这节就介绍到这里了。下一节我们要在前置条件中支持Redis语句，敬请期待吧。