Oracle 实例名服务名 请问SID和Service

对于单节点（单机）数据库，实例名就是服务名。 对于Oracle
RAC就不同了，实例名是Oracle服务在每个节点上的SID，一个Oracle
RAC的所有服务器节点的实例名（SID）必须不相同，服务名是全部服务器群共用

在配置单点登录的时候需要证书互导啊，里需要填SID和client，这两个都是基于Netweaver的， 在你的“单点登录”（SSO？）配置中，你这三个系统谁是证书颁布者，谁是证书接收者？他们的 Instance Name，Number，client都是什么？是使用的何种SSO策略？SAP Logon Ticket X509 Cookie, etc

您好，欢迎您使用惠普产品~
很抱歉，百度知道企业平台暂时没有HP服务器产品相应的技术支持。关于服务器产品问题，建议您可以直接拨打支持热线800-810-2058（不支持手机拨打，请使用固话或小灵通拨打）或400-610-2058（可手机拨打）进行咨询。
如果不方便拨打电话，惠普服务器方面的问题您也可以尝试打开下面的网址，选择所使用的产品类型（服务器及存储设备）然后点击相应的产品前的+号，再点击选择登录聊天室进行咨询即可，>在之前的Zookeeper系列基本介绍里有提到 ZK 的角色，那篇文章只是简单介绍 Leader 、 Follower 和 Observer 这三种角色。那么在一个 ZK 集群中，我怎么知道 ZK 服务是哪一个角色呢？角色是怎么分配的？为什么某个 ZK 是 Follower，而不是 Leader ？结论先行，先简单回答上面的问题。

ZXID：当发生写请求的时候，在 ZK 内会发起一个事务，每个事务会分配一个 zxid 作为标识符。zxid 是64位的 long 类型，高32位代表时间戳，低32位可以认为是事务ID，用来标识服务器状态的变更次数

SID：服务器ID。用来标识一台在 ZooKeeper 集群中的机器，每台机器不能重复。注意：这里和启动时指定的myid一致

Epoch：每个 Leader 任期的代号。每次新选举一个 Leader 就会递增1

Observer：不参与投票和选举换句话说，不参与 Leader 的选举，也不会投票给某个节点

节点状态：

好了，前置知识大概这么多，接下来咱们看一下，上面这些东西和选举有什么关系。

选举目的是为了从一堆 ZK 的服务节点中找一个大佬（Leader），然后所有非 Observer 节点都会成为小弟（Follower）。Leader负责读写数据，而 Follower 会分担大佬的负担，分担部分的读请求。

那么问题来了，根据什么条件判断，认为某一台 ZK 服务能成为 Leader 呢？

实际上，选举的规则是按照 Epoch > 事务Id > SID 依次由大到小排序，值最大作为 Leader。

简单来说，选举的时候会比较 epoch 的大小，如果所有 ZK 节点的 Leader 任期大小一样，则继续比较 ZXID 的低32位，也就是事务Id大小，如果事务ID大小都一样的话，就会比较服务器ID（SID）

ps 由于我是基于 Docker 部署 ZK 集群，进入其中的ZK节点，执行 cat /data/version-2/currentEpoch 既可以看到epoch的大小

接下来，看下 ZK 集群是怎样选举 Leader 的，但值得注意的是，选举区分了第一次启动和非第一次启动。第一次选举流程比较简单，但非第一次选举的时候，会涉及到 Leader 宕机或假死的情况，这样的话细节就会多一些。

背景：ZK集群是由5台ZK节点组成，只要集群中过半的节点投票就可选出 Leader

在集群节点启动之初，所有的epoch都是一样的，此时 Leader 还没选举出来，此时不会有写请求进来，所以事务Id也是没有的，所以最终的判断条件是根据SID，也就是节点的 ZOO_MY_ID 决定，理论上来说，ZOO_MY_ID 值最大的就会成为Leader，但为什么说是理论上呢？咱们来看下实际的效果。

基于docker-compose一次性部署5台ZK节点，参考我另外一篇博客 Zookeeper系列基于docker-compose快速搭建Zookeeper集群

最终结果是例子中的zoo5成为Leader，符合上面 ZOO_MY_ID 值最大的就会成为 Leader 的说法。

先把5台节点都关掉执行docker-compose stop，模拟集群的节点准备启动的状态，然后依次执行

集群中有5台节点，先启动3台，符合过半投票的情况，这时候已经可以选举出 Leader，盲猜一下，应该是 zoo3 这台机器成为Leader 了吧？进入 zoo3 容器，执行 zkServersh status 查看节点角色。果然，此时的 zoo3 是 Leader

此时，再依次执行 docker start zoo4 和 docker start zoo5，可以发现，Leader依旧是 zoo3。这是因为，当成功选举出 Leader 后，后续启动的 zk 节点都会成为 Follower（现在先不讨论Observer的情况）。

但这种结果并不与选举规则冲突，当 zk 集群内的机器不是同一时刻启动的时候，其大致选举流程是：

但为什么在场景1的时候，不是 zoo3 成为 Leader 而是 zoo5 成为 Leader 呢？这是因为在近乎同一时刻，zk 集群所有的服务都启动了，此时所有节点都是先投票给自己，然后再与其他节点交换信息，发现 zoo5 的 Sid 最大，接着所有的节点都投票给了 zoo5 ，其余节点就都处于 FOLLOWING 状态，而 zoo5 是 LEADING 状态。

假设 zoo3 是 Leader，其余都是 Follower。当 zoo3 宕机，其余节点都变为 FOLLOWING 状态，重新参与选举。

为降低复杂度，将真实的 zxid 简化为只有事务Id。假设 zoo1、zoo2、zoo4、zoo5 的 (epoch,zxid,sid) 分别是 (1,13,1)，(1,10,2)，(1,13,4)，(1,12,5)

此时选举流程是怎样呢？

zoo3 为 LEADING 状态，此时 zoo3 假死。如果 zoo3 忽然网络出问题，断开与其他 follower 节点的连接。其他节点以为 zoo3 宕机，则重新选举新 Leader，假设此时 zoo1 成为大佬，此时 zoo3 忽然正常了，那么剩下的 follower 节点会不会蒙圈？怎么会有两个大佬，正所谓一山不能容二虎，我应该听谁？

实际上，zk 有考虑到这种情况，还记得上面说的 epoch 的定义吗？这是每个 Leader 的代号，每更新一次 Leader，epoch 就会递增1。假如 zoo3 假死前，所有的节点的 epoch 都是2。zoo3 假死，zoo3 的 epoch 不会变，因为没想到有其他节点想替代自己的位置嘛。但其他节点选举 zoo1 为 Leader 后，除了 zoo3 ，其他的节点的 epoch 都是3了。此时 zoo3 恢复正常，即使向其他节点同步事务消息，但其余节点发现 zoo3 的 epoch 和自己不一样，就不会认这个大佬，而是认准 zoo1 才是自己的老大。

实际上，zk 集群的选举并不简单，底层选举算法使用到的 ZAB 协议保证分布式消息一致性，本篇文章并没过多描述。对于初学者来说，了解其选举的规则和某些场景下是如何选举，大概了解流程足矣。当实际开发中，为了保证高可用，需要注意的是 ZK 集群节点为奇数。另外，感兴趣的读者可以再去关注 ZAB 协议的细节。

参考资料：

《从Paxos到Zookeeper分布式一致性原理与实践》

如果觉得文章不错的话，麻烦点个赞哈，你的鼓励就是我的动力！对于文章有哪里不清楚或者有误的地方，欢迎在评论区留言~

---