您的位置 首页 java

Java那些事之分布式的理解

智云科技发布于 2022年12月7日评论关闭阅读(422)

分布式锁

有哪些方案实现分布式锁？

综合讲讲方案：

  • 使用场景
    • 需要保证一个方法在同一时间内只能被同一个线程执行
  • 实现方式:
    • 加锁和解锁
  • 方案,考虑因素(性能,稳定,实现难度,死锁)
    • 基于数据库做分布式锁–乐观锁(基于版本号)和悲观锁(基于排它锁)
    • 基于 redis 做分布式锁:setnx(key,当前时间+过期时间)和Redlock机制
    • 基于 zookeeper 做分布式锁:临时有序节点来实现的分布式锁,Curator
    • 基于 Consul 做分布式锁

基于数据库如何实现分布式锁？有什么缺陷？

  • 基于数据库表 （锁表，很少使用）

最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。当我们想要获得锁的时候，就可以在该表中增加一条记录，想要释放锁的时候就删除这条记录。为了更好的演示，我们先创建一张数据库表，参考如下： 

 CREATE TABLE database_lock (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`resource` int NOT NULL COMMENT '锁定的资源',
`description` varchar(1024) NOT NULL DEFAULT "" COMMENT '描述',
PRIMARY KEY (id),
UNIQUE KEY uiq_idx_resource (resource)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='数据库分布式锁表';

当我们想要获得锁时，可以插入一条数据： 

 INSERT INTO database_lock(resource, description) VALUES (1, 'lock');

当需要释放锁的时，可以删除这条数据： 

 DELETE FROM database_lock WHERE resource=1;
  • 基于悲观锁

悲观锁实现思路？

  1. 在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
  2. 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
  3. 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
  4. 其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

以MySQL InnoDB中使用悲观锁为例？

要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0; 

 //0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;

上面的查询语句中，我们使用了 select…for update 的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到，使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。

  • 基于乐观锁

乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

以使用版本号实现乐观锁为例？

使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。 

 1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

需要注意的是，乐观锁机制往往基于系统中数据存储逻辑，因此也具备一定的局限性。由于乐观锁机制是在我们的系统中实现的，对于来自外部系统的用户数据更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况，并进行相应的调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。

  • 缺陷

对数据库依赖，开销问题，行锁变表锁问题，无法解决数据库单点和可重入的问题。

基于redis如何实现分布式锁？有什么缺陷？

  • 最基本的Jedis方案

加锁： set NX PX + 重试 + 重试间隔

向Redis发起如下命令: SET productId:lock 0xx9p03001 NX PX 30000 其中，”productId”由自己定义，可以是与本次业务有关的id，”0xx9p03001″是一串随机值，必须保证全局唯一(原因在后文中会提到)，“NX”指的是当且仅当key(也就是案例中的”productId:lock”)在Redis中不存在时，返回执行成功，否则执行失败。”PX 30000″指的是在30秒后，key将被自动删除。执行命令后返回成功，表明服务成功的获得了锁。 

 @Override
public boolean lock(String key, long expire, int retryTimes, long retryDuration) {
    // use JedisCommands instead of setIfAbsense
    boolean result = setRedis(key, expire);

    // retry if needed
    while ((!result) && retryTimes-- > 0) {
        try {
            log.debug("lock failed, retrying..." + retryTimes);
            Thread.sleep(retryDuration);
        } catch (Exception e) {
            return false;
        }

        // use JedisCommands instead of setIfAbsense
        result = setRedis(key, expire);
    }
    return result;
}

private boolean setRedis(String key, long expire) {
    try {
        RedisCallback<String> redisCallback = connection -> {
            JedisCommands commands = (JedisCommands) connection.getNativeConnection();
            String uuid = SnowIDUtil.uniqueStr();
            lockFlag.set(uuid);
            return commands.set(key, uuid, NX, PX, expire); // 看这里
        };
        String result = redisTemplate.execute(redisCallback);
        return !StringUtil.isEmpty(result);
    } catch (Exception e) {
        log.error("set redis occurred an exception", e);
    }
    return false;
}

解锁： 采用lua脚本： 在删除key之前，一定要判断服务A持有的value与Redis内存储的value是否一致。如果贸然使用服务A持有的key来删除锁，则会误将服务B的锁释放掉。 

 if redis.call("get", KEYS[1])==ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
  • 基于RedLock实现分布式锁

假设有两个服务A、B都希望获得锁，有一个包含了5个redis master的Redis Cluster，执行过程大致如下:

  1. 客户端获取当前时间戳，单位: 毫秒
  2. 服务A轮寻每个master节点，尝试创建锁。(这里锁的过期时间比较短，一般就几十毫秒) RedLock算法会尝试在大多数节点上分别创建锁，假如节点总数为n，那么大多数节点指的是n/2+1。
  3. 客户端计算成功建立完锁的时间，如果建锁时间小于超时时间，就可以判定锁创建成功。如果锁创建失败，则依次(遍历master节点)删除锁。
  4. 只要有其它服务创建过分布式锁，那么当前服务就必须轮寻尝试获取锁。
  • 基于Redisson实现分布式锁 ？

过程？

  1. 线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。
  2. 线程去获取锁，获取失败: 订阅了解锁消息，然后再尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。

互斥？

如果这个时候客户端B来尝试加锁，执行了同样的一段lua脚本。第一个if判断会执行“exists myLock”，发现myLock这个锁key已经存在。接着第二个if判断，判断myLock锁key的hash数据结构中，是否包含客户端B的ID，但明显没有，那么客户端B会获取到pttl myLock返回的一个数字，代表myLock这个锁key的剩余生存时间。此时客户端B会进入一个while循环，不听的尝试加锁。

watch dog自动延时机制？

客户端A加锁的锁key默认生存时间只有30秒，如果超过了30秒，客户端A还想一直持有这把锁，怎么办？其实只要客户端A一旦加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下，如果客户端A还持有锁key，那么就会不断的延长锁key的生存时间。

可重入？

每次lock会调用incrby，每次unlock会减一。

  • 方案比较
  1. 借助Redis实现分布式锁时，有一个共同的缺陷: 当获取锁被决绝后，需要不断的循环，重新发送获取锁(创建key)的请求，直到请求成功。这就造成空转，浪费宝贵的CPU资源。
  2. RedLock算法本身有争议，并不能保证健壮性。
  3. Redisson实现分布式锁时，除了将key新增到某个指定的master节点外，还需要由master自动异步的将key和value等数据同步至绑定的slave节点上。那么问题来了，如果master没来得及同步数据，突然发生宕机，那么通过故障转移和主备切换，slave节点被迅速升级为master节点，新的客户端加锁成功，旧的客户端的watch dog发现key存在，误以为旧客户端仍然持有这把锁，这就导致同时存在多个客户端持有同名锁的问题了。

基于zookeeper如何实现分布式锁？

说几个核心点：

  • 顺序节点

创建一个用于发号的节点“/test/lock”，然后以它为父亲节点的前缀为“/test/lock/seq-”依次发号：

  • 获得最小号得锁

由于序号的递增性，可以规定排号最小的那个获得锁。所以，每个线程在尝试占用锁之前，首先判断自己是排号是不是当前最小，如果是，则获取锁。

  • 节点监听机制

每个线程抢占锁之前，先抢号创建自己的ZNode。同样，释放锁的时候，就需要删除抢号的Znode。抢号成功后，如果不是排号最小的节点，就处于等待通知的状态。等谁的通知呢？不需要其他人，只需要等前一个Znode 的通知就可以了。当前一个Znode 删除的时候，就是轮到了自己占有锁的时候。第一个通知第二个、第二个通知第三个，击鼓传花似的依次向后。

分布式事务

什么是ACID？

一个事务有四个基本特性，也就是我们常说的（ACID）：

  1. Atomicity（原子性） ：事务是一个不可分割的整体，事务内所有操作要么全做成功，要么全失败。
  2. Consistency（一致性） ：事务执行前后，数据从一个状态到另一个状态必须是一致的（A向B转账，不能出现A扣了钱，B却没收到）。
  3. Isolation（隔离性） ： 多个并发事务之间相互隔离，不能互相干扰。
  4. Durability（持久性） ：事务完成后，对数据库的更改是永久保存的，不能回滚。

分布式事务有哪些解决方案？

什么是分布式的XA协议？

XA协议是一个基于 数据库 的 分布式事务协议 ，其分为两部分： 事务管理器 和 本地资源管理器 。事务管理器作为一个全局的调度者，负责对各个本地资源管理器统一号令提交或者回滚。 二阶提交协议（2PC） 和 三阶提交协议（3PC） 就是根据此协议衍生出来而来。主流的诸如Oracle、MySQL等数据库均已实现了XA接口。

XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。也就是说，在基于XA的一个事务中，我们可以针对多个资源进行事务管理，例如一个系统访问多个数据库，或即访问数据库、又访问像消息中间件这样的资源。这样我们就能够实现在多个数据库和消息中间件直接实现全部提交、或全部取消的事务。 XA规范不是java的规范，而是一种通用的规范 。

什么是2PC？

两段提交顾名思义就是要进行两个阶段的提交：

  • 第一阶段，准备阶段（投票阶段）；
  • 第二阶段，提交阶段（执行阶段）。

下面还拿下单扣库存举例子，简单描述一下两段提交（2PC）的原理：

之前说过业务服务化（SOA）以后，一个下单流程就会用到多个服务，各个服务都无法保证调用的其他服务的成功与否，这个时候就需要一个全局的角色（ 协调者 ）对各个服务（ 参与者 ）进行协调。

一个下单请求过来通过协调者，给每一个参与者发送Prepare消息，执行本地数据脚本但不提交事务。

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交（Commit）消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中被占用的资源，显然2PC做到了所有操作要么全部成功、要么全部失败。

两段提交（2PC）的缺点：

二阶段提交看似能够提供原子性的操作，但它存在着严重的缺陷：

  • 网络抖动导致的数据不一致 ：第二阶段中协调者向参与者发送commit命令之后，一旦此时发生网络抖动，导致一部分参与者接收到了commit请求并执行，可其他未接到commit请求的参与者无法执行事务提交。进而导致整个分布式系统出现了数据不一致。
  • 超时导致的同步阻塞问题 ：2PC中的所有的参与者节点都为事务阻塞型，当某一个参与者节点出现通信超时，其余参与者都会被动阻塞占用资源不能释放。
  • 单点故障的风险 ：由于严重的依赖协调者，一旦协调者发生故障，而此时参与者还都处于锁定资源的状态，无法完成事务commit操作。虽然协调者出现故障后，会重新选举一个协调者，可无法解决因前一个协调者宕机导致的参与者处于阻塞状态的问题。

什么是3PC?

三段提交（3PC）是对两段提交（2PC）的一种升级优化， 3PC在2PC的第一阶段和第二阶段中插入一个准备阶段 。保证了在最后提交阶段之前，各参与者节点的状态都一致。同时在协调者和参与者中都引入超时机制，当参与者各种原因未收到协调者的commit请求后，会对本地事务进行commit，不会一直阻塞等待，解决了2PC的单点故障问题，但3PC还是没能从根本上解决数据一致性的问题。

3PC的三个阶段分别是CanCommit、PreCommit、DoCommit：

  • CanCommit ：协调者向所有参与者发送CanCommit命令，询问是否可以执行事务提交操作。如果全部响应YES则进入下一个阶段。
  • PreCommit ：协调者向所有参与者发送PreCommit命令，询问是否可以进行事务的预提交操作，参与者接收到PreCommit请求后，如参与者成功的执行了事务操作，则返回Yes响应，进入最终commit阶段。一旦参与者中有向协调者发送了No响应，或因网络造成超时，协调者没有接到参与者的响应，协调者向所有参与者发送abort请求，参与者接受abort命令执行事务的中断。
  • DoCommit ：在前两个阶段中所有参与者的响应反馈均是YES后，协调者向参与者发送DoCommit命令正式提交事务，如协调者没有接收到参与者发送的ACK响应，会向所有参与者发送abort请求命令，执行事务的中断。

什么是TCC？

TCC（Try-Confirm-Cancel）又被称补偿事务，TCC与2PC的思想很相似，事务处理流程也很相似，但 2PC是应用于在DB层面，TCC则可以理解为在应用层面的2PC，是需要我们编写业务逻辑来实现 。

TCC它的核心思想是：”针对每个操作都要注册一个与其对应的确认（Try）和补偿（Cancel）”。

还拿下单扣库存解释下它的三个操作：

  • Try阶段 ：下单时通过Try操作去扣除库存预留资源。
  • Confirm阶段 ：确认执行业务操作，在只预留的资源基础上，发起购买请求。
  • Cancel阶段 ：只要涉及到的相关业务中，有一个业务方预留资源未成功，则取消所有业务资源的预留请求。

TCC的缺点：

  • 应用侵入性强：TCC由于基于在业务层面，至使每个操作都需要有try、confirm、cancel三个接口。
  • 开发难度大：代码开发量很大，要保证数据一致性confirm和cancel接口还必须实现幂等性。

分布式缓存

分布式系统中常用的缓存方案有哪些？

  • 客户端缓存：页面和浏览器缓存，APP缓存，H5缓存，localStorage和sessionStorage
  • CDN缓存：
    • 内存存储：数据的缓存
    • 内容分发：负载均衡
  • nginx缓存：本地缓存，外部缓存
  • 数据库缓存：持久层缓存（mybatis，hibernate多级缓存），Mysql查询缓存
  • 操作系统缓存：Page Cache，Buffer Cache

分布式系统缓存的更新模式？

  • Cache Aside模式
  1. 读取失效：cache数据没有命中，查询DB，成功后把数据写入缓存
  2. 读取命中：读取cache数据
  3. 更新：把数据更新到DB，失效缓存 

 // Read
data = cache.get(id);
if (data == null) {
    data = db.get(id);
    cache.put(id, data);
}

// Write
db.save(data);
cache.invalid(data.id);
  • Read/Write Through模式

缓存代理了DB读取、写入的逻辑，可以把缓存看成唯一的存储。

  • Write Back模式

这种模式下所有的操作都走缓存，缓存里的数据再通过 异步的方式同步 到数据库里面。所以系统的写性能能够大大提升了。

分布式系统缓存淘汰策略

缓存淘汰，又称为缓存逐出(cache replacement algorithms或者cache replacement policies)，是指在存储空间不足的情况下，缓存系统主动释放一些缓存对象获取更多的存储空间。一般LRU用的比较多，可以重点了解一下。

  • FIFO 先进先出（First In First Out）是一种简单的淘汰策略，缓存对象以队列的形式存在，如果空间不足，就释放队列头部的（先缓存）对象。一般用链表实现。
  • LRU 最近最久未使用（Least Recently Used），这种策略是根据访问的时间先后来进行淘汰的，如果空间不足，会释放最久没有访问的对象（上次访问时间最早的对象）。比较常见的是通过优先队列来实现。
  • LFU 最近最少使用（Least Frequently Used），这种策略根据最近访问的频率来进行淘汰，如果空间不足，会释放最近访问频率最低的对象。这个算法也是用优先队列实现的比较常见。
标签:
打赏 点赞(0)

文章来源：智云一二三科技

文章标题：Java那些事之分布式的理解

文章地址：https://www.zhihuclub.com/169126.shtml

关于作者: 智云科技

相关文章

热门文章

1分享新浪图床上传接口源码

点赞(974)阅读(61,666)

2PHP简单实现路由Route功能

点赞(1.19K)阅读(35,993)

3Tideways、xhprof 和 xhgui 打造 PHP 非侵入式监控平台

点赞(414)阅读(4,324)

4centos系统如何查看是否安装了mysql

点赞(579)阅读(3,814)

5curl 工具简述

点赞(568)阅读(3,003)
网站地图