分布式环境下的并发编程

在JAVA多线程编程中,经常会用到synchronized、lock和原子变量等,分布式系统中,由于分布式系统的分布性,即多线程和多进程并且分布在不同机器中,synchronized和lock这两种锁将失去原有锁的效果,需要我们自己实现分布式锁来处理并发问题。分布式系统处理并发的办法有三种

1.队列

我们可以将所有要执行的任务放入队列(kafka等)里,然后一个个消费,这样就能避免并发问题。

2.悲观锁

我们经常会用到的,将数据记录加版本号,如果版本号不一致,就不更新。这种方式同JAVA的CAS理念类似。

3.分布式锁。

常见的分布式锁有三种实现:

  基于数据库实现分布式锁
  基于缓存,实现分布式锁,如redis
  基于Zookeeper实现分布式锁

基于数据库实现分布式锁

利用数据库表

首先创建一张锁的表主要包含下列字段:方法名,时间戳等字段。方法名称要游唯一性约束。

如果有多个请求同时提交到数据库的话,数据库会保证只有一个操作可以成功,那么我们就可以认为操作成功的那个线程获得了该方法的锁,可以执行方法体内容。

可以对该方案优化,记录当前获得锁的机器的主机信息和线程信息,那么下次再获取锁的时候先查询数据库,如果当前机器的主机信息和线程信息在数据库可以查到的话,直接把锁分配给他就可以了,实现可重入锁。

基于数据库排他锁

在查询语句后面增加for update,数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后,其他线程无法再在该行记录上增加排他锁。其他没有获取到锁的就会阻塞在上述select语句上,可能的结果有2种,在超时之前获取到了锁,在超时之前仍未获取到锁。获得排它锁的线程即可获得分布式锁,当获取到锁之后,可以执行方法的业务逻辑,执行完方法之后,释放锁connection.commit()。存在的问题主要是性能不高和sql超时的异常。

基于Zookeeper实现分布式锁
基于zookeeper临时有序节点可以实现的分布式锁。每个客户端对某个方法加锁时,在zookeeper上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点。
判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个。当释放锁的时候,只需将这个瞬时节点删除即可。同时,其可以避免服务宕机导致的锁无法释放,而产生的死锁问题。
提供的第三方库有curator,具体使用大家可以自行去看一下。Curator提供的InterProcessMutex是分布式锁的实现。acquire方法获取锁,release方法释放锁。

基于缓存(redis)来实现分布式锁

网上很多用jedis.setnx()和jedis.expire()组合实现加锁。setnx()方法作用就是SET IF NOT EXIST,expire()方法就是给锁加一个过期时间。由于这是两条Redis命令,不具有原子性,如果程序在执行完setnx()之后突然崩溃,导致锁没有设置过期时间。那么将会发生死锁。网上之所以有人这样实现,是因为低版本的jedis并不支持多参数的set()方法。

多参数的set来实现分布式锁

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

可以看到,我们加锁就一行代码:jedis.set(String key, String value, String nxxx, String expx, int time),这个set()方法一共有五个形参:
第一个为key,我们使用key来当锁,因为key是唯一的。
第二个为value,我们传的是requestId,很多童鞋可能不明白,有key作为锁不就够了吗,为什么还要用到value?原因就是我们在上面讲到可靠性时,分布式锁要满足第四个条件解铃还须系铃人,通过给value赋值为requestId,我们就知道这把锁是哪个请求加的了,在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个为nxxx,这个参数我们填的是NX,意思是SET IF NOT EXIST,即当key不存在时,我们进行set操作;若key已经存在,则不做任何操作;
第四个为expx,这个参数我们传的是PX,意思是我们要给这个key加一个过期的设置,具体时间由第五个参数决定。
第五个为time,与第四个参数相呼应,代表key的过期时间。
总的来说,执行上面的set()方法就只会导致两种结果:1. 当前没有锁(key不存在),那么就进行加锁操作,并对锁设置个有效期,同时value表示加锁的客户端。2. 已有锁存在,不做任何操作。
心细的童鞋就会发现了,我们的加锁代码满足我们可靠性里描述的三个条件。首先,set()加入了NX参数,可以保证如果已有key存在,则函数不会调用成功,也就是只有一个客户端能持有锁,满足互斥性。其次,由于我们对锁设置了过期时间,即使锁的持有者后续发生崩溃而没有解锁,锁也会因为到了过期时间而自动解锁(即key被删除),不会发生死锁。最后,因为我们将value赋值为requestId,代表加锁的客户端请求标识,那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。

原文地址:https://www.cnblogs.com/zhuyuehua/p/9636329.html

时间: 2024-10-09 03:01:09

分布式环境下的并发编程的相关文章

分布式环境下的数据一致性问题的方案讨论

由于互联网目前越来越强调分布式架构,如果是交易类系统,面临的将会是分布式事务上的挑战.当然目前有很多开源的分布式事务产品,例如java JTA,但是这种解决方案的成本是非常高的,而且实现起来非常复杂,效率也比较低下.对于极端的情况:例如发布,故障的时候都是没有办法保证强一致性的. 首先,在目前的互联网应用中,我们通过一个比较常见的例子,让大家更深入的了解一下分布式系统设计中关于数据一致性的问题.拿我们经常使用的功能来考虑吧,最近网购比较热门,就以京东为例的,我们来看看京东的一个简单的购物流程 用

Windows环境下用C#编程将文件上传至阿里云OSS笔记

本系列文章由ex_net(张建波)编写,转载请注明出处. http://blog.csdn.net/ex_net/article/details/24962567 作者:张建波 邮箱: [email protected]  欢迎来信交流! 第1步: 下载阿里云OSS的SDK包,由于笔者的环境是PHP服务,所以下载的是PHP的SDK包 http://help.aliyun.com/view/13438816.html 第2步:将代码整合进你的网站或服务中. 第3步:配置OSS访问接口 (1)找到c

集群/分布式环境下5种session处理策略

转载自:http://blog.csdn.net/u010028869/article/details/50773174?ref=myread 前言 在搭建完集群环境后,不得不考虑的一个问题就是用户访问产生的session如何处理.如果不做任何处理的话,用户将出现频繁登录的现象,比如集群中存在A.B两台服务器,用户在第一次访问网站时,Nginx通过其负载均衡机制将用户请求转发到A服务器,这时A服务器就会给用户创建一个Session.当用户第二次发送请求时,Nginx将其负载均衡到B服务器,而这时

分布式环境下配置中心实现思考

转载注明出处: 季义钦的博客 最近在考虑分布式环境下配置中心实现. 对于配置中心很难设计. 光用Zookeeper吧,发现一是跨语言支持不好,需要大量跨语言支持的开发,而且没办法在上面增加大量的算法和逻辑. 如果在Zookeeper前面加一层服务的话,又怕成为单点压力. 下面是我画的一个架构图,希望大家帮忙看看,踊跃讨论. 希望各位不管有什么意见和建议.都在下面评论里面留下自己的想法,帮助我改进,谢谢 分布式环境下配置中心实现思考,布布扣,bubuko.com

【转】集群/分布式环境下5种session处理策略

转载至:http://blog.csdn.net/u010028869/article/details/50773174 在搭建完集群环境后,不得不考虑的一个问题就是用户访问产生的session如何处理.如果不做任何处理的话,用户将出现频繁登录的现象,比如集群中存在A.B两台服务器,用户在第一次访问网站时,Nginx通过其负载均衡机制将用户请求转发到A服务器,这时A服务器就会给用户创建一个Session.当用户第二次发送请求时,Nginx将其负载均衡到B服务器,而这时候B服务器并不存在Sessi

【架构师之路】集群/分布式环境下5种session处理策略

转自:http://www.cnblogs.com/jhli/p/6557929.html 在搭建完集群环境后,不得不考虑的一个问题就是用户访问产生的session如何处理.如果不做任何处理的话,用户将出现频繁登录的现象,比如集群中存在A.B两台服务器,用户在第一次访问网站时,Nginx通过其负载均衡机制将用户请求转发到A服务器,这时A服务器就会给用户创建一个Session.当用户第二次发送请求时,Nginx将其负载均衡到B服务器,而这时候B服务器并不存在Session,所以就会将用户踢到登录页

【转】分布式环境下5种session处理策略(大型网站技术架构:核心原理与案例分析 里面的方案)

前言 在搭建完集群环境后,不得不考虑的一个问题就是用户访问产生的session如何处理.如果不做任何处理的话,用户将出现频繁登录的现象,比如集群中存在A.B两台服务器,用户在第一次访问网站时,Nginx通过其负载均衡机制将用户请求转发到A服务器,这时A服务器就会给用户创建一个Session.当用户第二次发送请求时,Nginx将其负载均衡到B服务器,而这时候B服务器并不存在Session,所以就会将用户踢到登录页面.这将大大降低用户体验度,导致用户的流失,这种情况是项目绝不应该出现的. 我们应当对

Cpython解释器下实现并发编程——多进程、多线程、协程、IO模型

一.背景知识 进程即正在执行的一个过程.进程是对正在运行的程序的一个抽象. 进程的概念起源于操作系统,是操作系统最核心的概念,也是操作系统提供的最古老也是最重要的抽象概念之一.操作系统的其他所有内容都是围绕进程的概念展开的.   一.操作系统相关的知识 详情见链接:http://www.cnblogs.com/linhaifeng/p/6295875.html 即使可以利用的CPU只有一个(早期的计算机确实如此),也能保证支持(伪)并发的能力.将一个单独的CPU变成多个虚拟的CPU(多道技术:时

分布式环境下rabbitmq发布与订阅端

假设rabbitmq配置了集群,且客户端连接rabbitmq-server通过lvs实现HA但一般情况下不建议做LB.在分布式系统的环境下,由于节点的非预知性,使用spring amqp模板进行配置不足以灵活到满足弹性扩展的需求,因此,更加方便的方式是通过rabbitmq原生的java client进行订阅和发布.在我们的场景中,某些节点需要同时是发布端和订阅端以便做到弹性扩展,无需额外的配置.以fanout类型为例,如下所示: 发布端: /** * @Title: Send.java * @P