Python使用分布式锁的代码演示示例
在计算机并发领域编程中总是会与锁打交道，锁又有很多种，互斥锁、自旋锁等等。
锁总是伴随着线程、进程这样的词汇出现，阮一峰有 一篇文章 对这些名词进行了简单易懂的解释。
我的理解是，使用线程、进程是为了实现并发从而获得性能的提升(利用多核CPU，多台服务器)，但这种并发由于调度的不确定性，很容易出乱子，为了(在一些共享资源、关键节点上)不出乱子，又需要对资源加锁，在操作这个资源时控制这种并发，将乱子消灭。
很多语言都提供了一些线程级别的锁实现以及一些相应的工具，但在进程方面就无能为力了。而一个服务部署到生产环境，往往会部署多个实例，这种情况下，就经常会用到给不同进程用的锁，分布式锁便是在分布式系统中对某共享资源进行加锁的构件。
现在来试着展示一下在Python项目中如何使用简单的分布式互斥锁。
不使用分布式锁会怎样
先用一个简单的实例来演示一下，不使用分布式锁会出怎样的乱子。
假设商城系统要做秒杀活动，在redis中记录着 count:1 的信息，到秒杀时间点的时候，会收到许多的请求，这时各应用程序去查redis中count的值，若count还大于0，则将count-1，这样其他请求就不再能秒杀到了。
# -*- coding: utf-8 -*-
import os
import arrow
import redis
from multiprocessing import Pool
HOT_KEY = 'count'
r = redis.Redis(host='localhost', port=6379)
def seckilling():
name = os.getpid()
v = r.get(HOT_KEY)
if int(v) > 0:
print name, ' decr redis.'
r.decr(HOT_KEY)
else:
print name, ' can not set redis.', v
def run_without_lock(name):
while True:
if arrow.now().second % 5 == 0:
seckilling()
return
if __name__ == '__main__':
p = Pool(16)
r.set(HOT_KEY, 1)
for i in range(16):
p.apply_async(run_without_lock, args=(i, ))
print 'now 16 processes are going to get lock!'
p.close()
p.join()
print('All subprocesses done.')
以上代码使用多进程来模仿这种并发请求场景，程序开始的时候将count设为1，之后各进程开始进入等待，当秒数为5的时候，所有进程同时去访问秒杀函数，来看一下效果：
运行结果
redis查询展示
从程序打印与查redis的结果来说并未如愿，本来秒杀商品只有一件，但却被成功抢购到了4次。这是由于各进程在get count的值时，对redis值更新的指令已经发出而还未进行完毕，会让其他进程认为自己可以购得。
这种问题可归为 不可重复读 种类的数据并发问题。
在这种毫无保护的情况下，其他常见并发问题幻读、脏读、第一第二类丢失更新等都有可能发生，这里不再一一举例。
使用ZooKeeper作分布式锁
作为致力于解决分布式协同问题的知名工具，利用zookeeper提供的API和它对于节点唯一性与顺序一致性的保证可以实现分式式锁。
实现思路为，各进程去创建 /exclusive_lock/lock 的结点，zookeeper保证只有一个client可以创建成功，那么便认为创建成功的那个client获得了锁，当它处理完业务后，将该node删除，其他client会监听到这个事件，并再次尝试创建该节点，如此进行下去。
Kazoo库实现了这种Lock，使用起来非常简单，编程人员可以不用再去自己实现acquire，release等锁的通用接口。
同时在Python中，对锁的使用往往可以通过优雅的上下文管理器with。
def run_with_zk_lock(name):
zk = KazooClient()
zk.start()
lock = zk.Lock("/lockpath", "my-identifier")
while True:
if arrow.now().second % 5 == 0:
with lock:
seckilling()
return
使用zk结果
redis查询展示
当秒杀发生时，只有获得锁的进程可以去进行秒杀操作。
在锁的帮助下，程序按照预想的方式运行了。
使用redis作分布式锁
在redis的网站有一篇文章 专门介绍如何使用redis作为分布式锁，文尾还附带了对此文章的反对文章以及再次回击的文章，有点精彩。
文章提到了一个redlock的分布式锁设计。
设置锁的redis命令为 SET resource_name my_random_value NX PX 30000 ，当加NX参数时，若resouce_name不存在才会创建，若不存在则会向client返回不同的结果，利用这个机制，便只有一个client可以set成功，就像上面的zk一样了。
但是，实现这样一个分布式锁远不止这么简单，redis并不像zk一样是一个分布式协同工具，会向client做出分布式中各种一致性及容错、可用性的保证。
redis本身也是集群部署的，它们之间有着异步复制时间差、容错等问题可能会出现，要真正做到这个锁的实现在线上大规模分布式系统中可用，真的是要考虑各种情况，很不容易。
关于如何在语言上实现一个锁的接口，redlock的原理与代码实现，以及上述kazoo包里实现lock的源码，我会在另一篇专门的文章中说一下。
redlock-py包是python语言中对上述文章的实现，我们现在使用它来进行尝试。
rlock = RedLock([{"host": "localhost", "port": 6379, "db": 0}, ])
def run_with_redis_lock(name):
while True:
if arrow.now().second % 5 == 0:
with rlock:
seckilling()
return
redis锁运行结果
运行结果和上面使用zk一样，符合程序设计预期。
以上只是基于python语言的一些代码展示，通过使用两个第三方包，来使用分布式锁来避免并发程序中混乱的产生。
但其实这中间是有一个断层的，即，这两个工具都是提供了一个机制，而并不是直接对外提供了操作锁的API，那么如何利用这个机制来实现这样的锁正是这两个第三方做的事情。
简单看过它们实现的源码，以及threading中一些lock的代码，发现在锁的实现上是有着共通之处的，都有通用的acquire与release方法，然后将 enter 与 exit 指向前面两个方法来实现上下文管理器with的用法。
此外，还可以利用关系型数据库如MySQL固有的锁机制来作为分布式锁，但由于数据库往往是系统的瓶颈所在，没有必要为它引入不必要的压力。同时，MySQL中的锁、隔离级别也有一大堆可说的，在github上找了一下也并未找到一个成熟的像上面的基于MySQL实现的对外暴露锁通用API的第三方包，故未能在上面加以展示。
想要说清楚这个事情并没有那么容易，之后我会尝试搞清楚如何写一个比较地道的锁，并对上面两个第三方包的具体实现加以研究，争取把这个断层补上。之后，或许可以尝试实现一下基于MySQL的类似第三方包，这需要对MySQL的一些机制搞得更加清楚才行。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。
相关推荐
-
python互斥锁、加锁、同步机制、异步通信知识总结
某个线程要共享数据时,先将其锁定,此时资源的状态为"锁定",其他线程不能更改:直到该线程释放资源,将资源的状态变成"非锁定",其他的线程才能再次锁定该资源.互斥锁保证了每次只有一个线程进入写入操作,从而保证了多线程情况下数据的正确性. 采用f_flag的方法效率低 创建锁 mutex=threading.Lock() 锁定 mutex.acquire([blocking])#里面可以加blocking(等待的时间)或者不加,不加就会一直等待(堵塞) 释放 mutex
-
python使用锁访问共享变量实例解析
本文研究的主要是python使用锁访问共享变量,具体介绍和实现如下. python 做多线程编程时,多个线程若同时访问某个变量,可能会对变量数据造成破坏,pyhon中的threading模块提供了lock对象,lock中的acquire方法用于获取一个锁,而release用于释放一个锁.当一个线程取得锁时,它变获得了共享变量的访问权,此时进入阻塞状态,若其它线程申请访问这个变量,则必须等到这个线程调用release方法释放这个锁.下面是python中使用锁的实例: #!/usr/bin/env
-
Python多线程中阻塞(join)与锁(Lock)使用误区解析
关于阻塞主线程 join的错误用法 Thread.join() 作用为阻塞主线程,即在子线程未返回的时候,主线程等待其返回然后再继续执行. join不能与start在循环里连用 以下为错误代码,代码创建了5个线程,然后用一个循环激活线程,激活之后令其阻塞主线程. threads = [Thread() for i in range(5)] for thread in threads: thread.start() thread.join() 执行过程: 1. 第一次循环中,主线程通过start函
-
Python多线程编程之多线程加锁操作示例
本文实例讲述了Python多线程编程之多线程加锁操作.分享给大家供大家参考,具体如下: Python语言本身是支持多线程的,不像PHP语言. 下面的例子是多个线程做同一批任务,任务总是有task_num个,每次线程做一个任务(print),做完后继续取任务,直到所有任务完成为止. # -*- coding:utf-8 -*- #! python2 import threading start_task = 0 task_num = 10000 mu = threading.Lock() ###通
-
详解python多线程、锁、event事件机制的简单使用
线程和进程 1.线程共享创建它的进程的地址空间,进程有自己的地址空间 2.线程可以访问进程所有的数据,线程可以相互访问 3.线程之间的数据是独立的 4.子进程复制线程的数据 5.子进程启动后是独立的 ,父进程只能杀掉子进程,而不能进行数据交换 6.修改线程中的数据,都是会影响其他的线程,而对于进程的更改,不会影响子进程 threading.Thread Thread 是threading模块中最重要的类之一,可以使用它来创建线程.有两种方式来创建线程:一种是通过继承Thread类,重写它的run
-
python线程中同步锁详解
在使用多线程的应用下,如何保证线程安全,以及线程之间的同步,或者访问共享变量等问题是十分棘手的问题,也是使用多线程下面临的问题,如果处理不好,会带来较严重的后果,使用python多线程中提供Lock Rlock Semaphore Event Condition 用来保证线程之间的同步,后者保证访问共享变量的互斥问题 Lock & RLock:互斥锁 用来保证多线程访问共享变量的问题 Semaphore对象:Lock互斥锁的加强版,可以被多个线程同时拥有,而Lock只能被某一个线程同时拥有. E
-
利用Python批量提取Win10锁屏壁纸实战教程
前言 相信使用Win10的朋友会发现,每次开机锁屏界面都会有不一样的漂亮图片,这些图片通常选自优秀的摄影作品,十分精美. 但是由于系统会自动更换这些图片,所以就算再好看的图片,也许下次开机之后就被替换掉了. 借助Python,我们可以用简单的几行代码,批量提取这些精美的锁屏图片.把喜欢的图片设置成桌面背景,就不用担心被替换掉啦. 下面话不多说了,来一起看看详细的介绍吧. 提取原理 Win10系统会自动下载最新的锁屏壁纸,并将他们保存在一个系统文件夹中,路径是C:\Users\[用户名]\AppD
-
Python实现的redis分布式锁功能示例
本文实例讲述了Python实现的redis分布式锁功能.分享给大家供大家参考,具体如下: #!/usr/bin/env python # coding=utf-8 import time import redis class RedisLock(object): def __init__(self, key): self.rdcon = redis.Redis(host='', port=6379, password="", db=1) self._lock = 0 self.lock
-
Python线程下使用锁的技巧分享
使用诸如Lock.RLock.Semphore之类的锁原语时,必须多加小心,锁的错误使用很容易导致死锁或相互竞争.依赖锁的代码应该保证当出现异常时可以正常的释放锁. 典型代码如下: try: lock.acquire() #关键部分 ... finally: lock.release() 另外,所有种类的锁还支持上下文管理协议(写起来更简洁): with语句自动获取锁,并且在控制流离开上下文时自动释放锁. with lock: #关键部分 ... 此外,编写代码时一般应该避免同时获取多个锁,例如
-
Python使用分布式锁的代码演示示例
在计算机并发领域编程中总是会与锁打交道,锁又有很多种,互斥锁.自旋锁等等. 锁总是伴随着线程.进程这样的词汇出现,阮一峰有 一篇文章 对这些名词进行了简单易懂的解释. 我的理解是,使用线程.进程是为了实现并发从而获得性能的提升(利用多核CPU,多台服务器),但这种并发由于调度的不确定性,很容易出乱子,为了(在一些共享资源.关键节点上)不出乱子,又需要对资源加锁,在操作这个资源时控制这种并发,将乱子消灭. 很多语言都提供了一些线程级别的锁实现以及一些相应的工具,但在进程方面就无能为力了.而一个服务
-
python多线程高级锁condition简单用法示例
本文实例讲述了python多线程高级锁condition简单用法.分享给大家供大家参考,具体如下: 多线程编程中如果使用Condition对象代替lock, 能够实现在某个事件触发后才处理数据, condition中含有的方法: - wait:线程挂起,收到notify通知后继续运行 - notify:通知其他线程, 解除其它线程的wai状态 - notifyAll(): 通知所有线程 - acquire和release: 获得锁和解除锁, 与lock类似, - enter和exit使得对象支持
-
Redis对批量数据实现分布式锁的实现代码
目录 需求背景 代码实现 实现效果 需求背景 在开发的收入结转平台界面上有一个归集按钮,可以实现抓取结转表里面的多条数据进行归集操作.为了防止多人多电脑同时操作一条数据,我们自己开发了一个简单的基于Redis实现的分布式锁. 代码实现 逻辑代码中的使用案例 参数说明: scIds:结转数据的ID主键集合. timeOutToDeleteRedisKey:最大锁超时时间(用于自动解锁) organizationId:租户ID(这个参数根据情况选择是否需要) ReturnLock returnLoc
-
ZooKeeper入门教程三分布式锁实现及完整运行源码
目录 1.0版本 2.0版本 LockSample类 构造方法 获取锁实现 createLock() attemptLock() 释放锁实现 TicketSeller类 sell() sellTicketWithLock() 测试入口 测试方法 代码清单如下: 1.LockSample 2.TicketSeller ZooKeeper入门教程一简介与核心概念 ZooKeeper入门教程二在单机和集群环境下的安装搭建及使用 1.0版本 首先我们先介绍一个简单的zookeeper实现分布式锁的思路:
-
Redis实现分布式锁的几种方法总结
Redis实现分布式锁的几种方法总结 分布式锁是控制分布式系统之间同步访问共享资源的一种方式.在分布式系统中,常常需要协调他们的动作.如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源,那么访问这些资源的时候,往往需要互斥来防止彼此干扰来保证一致性,在这种情况下,便需要使用到分布式锁. 我们来假设一个最简单的秒杀场景:数据库里有一张表,column分别是商品ID,和商品ID对应的库存量,秒杀成功就将此商品库存量-1.现在假设有1000个线程来秒杀两件商品,500个线程秒杀第一个商品,
-
基于Redis实现分布式锁以及任务队列
一.前言 双十一刚过不久,大家都知道在天猫.京东.苏宁等等电商网站上有很多秒杀活动,例如在某一个时刻抢购一个原价1999现在秒杀价只要999的手机时,会迎来一个用户请求的高峰期,可能会有几十万几百万的并发量,来抢这个手机,在高并发的情形下会对数据库服务器或者是文件服务器应用服务器造成巨大的压力,严重时说不定就宕机了,另一个问题是,秒杀的东西都是有量的,例如一款手机只有10台的量秒杀,那么,在高并发的情况下,成千上万条数据更新数据库(例如10台的量被人抢一台就会在数据集某些记录下 减1),那次这个
-
zookeeper实现分布式锁
一.分布式锁介绍 分布式锁主要用于在分布式环境中保护跨进程.跨主机.跨网络的共享资源实现互斥访问,以达到保证数据的一致性. 二.架构介绍 在介绍使用Zookeeper实现分布式锁之前,首先看当前的系统架构图 解释: 左边的整个区域表示一个Zookeeper集群,locker是Zookeeper的一个持久节点,node_1.node_2.node_3是locker这个持久节点下面的临时顺序节点.client_1.client_2.client_n表示多个客户端,Service表示需要互斥访问的共享
-
Redis分布式锁的使用和实现原理详解
模拟一个电商里面下单减库存的场景. 1.首先在redis里加入商品库存数量. 2.新建一个Spring Boot项目,在pom里面引入相关的依赖. <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <gr
-
基于Redis实现分布式锁的方法（lua脚本版）
1.前言 在Java中,我们通过锁来避免由于竞争而造成的数据不一致问题.通常我们使用synchronized .Lock来实现.但是Java中的锁只能保证在同一个JVM进程内中可用,在跨JVM进程,例如分布式系统上则不可靠了. 2.分布式锁 分布式锁,是一种思想,它的实现方式有很多,如基于数据库实现.基于缓存(Redis等)实现.基于Zookeeper实现等等.为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件 互斥性:在任意时刻,只有一个客户端能持有锁. 不会发生死锁:即使客户端
-
redis分布式锁的实现原理详解
首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件: 1.互斥性.在任意时刻,只有一个客户端能持有锁. 2.不会发生死锁.即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁. 3.具有容错性.只要大部分的Redis节点正常运行,客户端就可以加锁和解锁. 4.解铃还须系铃人.加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了. 下边是代码实现,首先我们要通过Maven引入Jedis开源组件,在pom.xml文件加入下面的代码: <depe