健康平安的活着的专栏

在读取数据时锁住那几行，其他对这几行的更新需要等到悲观锁结束时才能继续。，交出CPU资源，可以把CPU给其他线程使用，提高了CPU的利用率。

在mysql中，select ... for update 仅适用于InnoDB，且必须在事务块中才能生效。Innodb引擎默认是行锁。场景1：查询条件为主键会话A： select * from tb_pab where id=1 for update;会话B： update tb_pab set uname='bj' where id=1;

简化了Zookeeper客户端的开发量。Curator解决了很多zookeeper客户端非常底层的细节开发工作，包括连接重连、反复注册wathcer和NodeExistsException异常等。、集群领导选举、共享计数器、缓存机制、分布式队列等)的抽象封装，这些实现都遵循了zk的最佳实践，并考虑了各种极端情况。1.封装ZooKeeper client与ZooKeeper server之间的连接处理。提供了一套Fluent风格的操作API。Zookeeper提供的原生客户端。

【代码】分布式锁3: zk实现分布式锁4 使用临时顺序节点+watch监听+可重入(threadLocal)

接上一篇文章，每个请求要想正常的执行完成，最终都是要创建节点，如果能够避免争抢必然可以提高性能。这里借助于zk的临时序列化节点，实现分布式锁1. 主要修改了构造方法和lock方法：2.并添加了getPreNode获取前置节点的方法。存在的问题就是羊群效应。

由于zookeeper获取链接是一个耗时过程，这里可以在项目启动时，初始化链接，并且只初始化一次。3.修改service4.修改controller。

1.指令：ls /delete /aa2..znode节点类型：永久节点：create /path content临时节点：create -e /path content。只要客户端程序断开链接自动删除永久序列化节点：create -s /path content临时序列化节点：create -s -e /path content。

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这3个基本需求，最多只能同时满足其中的2个。

Redisson分布式锁是一种基于redis实现的分布式锁，它利用redis的setnx命令实现分布式锁的互斥访问。同时还支持锁的自动续期功能，可以避免因为某个进程崩溃或者网络故障导致锁无法释放的情况。只要线程一加锁成功，就会启动一个watchdog看门狗，它是一个后台线程，会每隔10秒检查一下，等锁进行加锁操作，完成后然后释放锁。其他线程BCD判断加锁的次数为0，就可以进行加锁操作。因此，Redisson就是使用watch dog解决了「还持有锁，那么就会不断的延长锁key的生存时间。

redis中setnx+expire是非原子操作, 除了用LUA脚本保证实现原子操作, 其实可以直接使用redis自带的set方法直接实现.setnx+expire+del 命令实现redis的分布式锁；其中 setnx 不存在则新增；给锁设置一个过期时间，防止锁忘记了释放。来抢锁，如果抢到之后，再用。

在多线程高并发场景下，为了保证资源的线程安全问题，jdk为我们提供了synchronized关键字和ReentrantLock可重入锁，但是它们只能保证一个工程内的线程安全。在分布式集群、微服务、云原生横行的当下，jdk并没有给我们提供既有的解决方案。需要自己通过编写方案来解决，目前主流的实现有以下方式：基于mysql关系型实现基于redis非关系型数据实现基于zookeeper/etcd实现。

在分布式系统中一次操作需要由多个服务协同完成，这种由不同的服务之间通过网络协同完成的事务称为分布式事务。1.首先满足事务特性：ACID2.而在分布式环境下，会涉及到多个数据库总结：分布式事务处理的关键是：1需要记录事务在任何节点所做的所有动作，事务进行所有的操作要么全部提交，要么全部回滚。