真机运行鸿蒙HarmonyOS

ZooKeeper 采用全局递增的事务 Id 来标识，所有 proposal(提议)在被提出的时候加上了ZooKeeper Transaction Id ，zxid是64位的Long类型，这是保证事务的顺序一致性的关键。zxid中高32位表示纪元epoch，低32位表示事务标识xid。你可以认为zxid越大说明存储数据越新。

每个leader都会具有不同的epoch值，表示一个纪元/朝代，用来标识 leader 周期。每个新的选举开启时都会生成一个新的epoch，新的leader产生的话epoch会自增，会将该值更新到所有的zkServer的zxid和epoch，

xid是一个依次递增的事务编号。数值越大说明数据越新，所有 proposal(提议)在被提出的时候加上了zxid，然后会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

3.2 Leader选举

Leader的选举一般分为启动时选举跟Leader挂掉后的运行时选举。

3.2.1 启动时Leader选举
 

CAS，全称是Compare And Swap，即比较并交换，是一种乐观锁的实现。

悲观锁与乐观锁

悲观锁

总是假设最坏的情况，线程a每次去获取或更新数据的时候，都会觉得别的线程也正在修改这个数据，为了避免自己的更新操作丢失，线程a会尝试获取此数据的锁，线程a获取到之后，才能对此数据进行一些更新操作。在此期间，别的线程无法更新，只能等到线程a释放锁之后，才能进行更新。

之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修改之前先加锁。

悲观并发控制，实际上是一种“先取锁再访问”的保守策略。

synchronized就是对悲观锁的一种实现。

乐观锁

乐观锁假设数据一般不会造成冲突，所以在拿数据的时候不会去加锁，但是会在更新的时候判断此期间内有没有别的线程修改过数据。

CAS机制就是对乐观锁的一种实现。

乐观锁的实现——CAS

CAS操作一般包含3个参数，期望值、内存值、新值。如果期望值与内存值相等，则用新值去更新这个内存值。如果不相等，则可以再次进行比较，一直到成功为止。

CAS是一种非阻塞的算法，线程在更新失败时，不需要挂起，因此省去了大量线程上下文切换的开销。

java使用Unsafe类来支持CAS操作，对Unsafe类不了解的同学可以先参考我的另外一篇文章JUC基石——Unsafe类。

我们用java代码来简要模拟CAS的过程：

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!