继续咱们 mongodb 集群的学习和分享
上次分享了 mongodb 主从集群的同步机制（oplog），心跳机制，这次我们继续看看选举机制和副本回滚
选举机制
咱们的主节点和其他次要节点选举策略默认的时间是 10 秒钟
例如上图
mongodb 主从集群中，primary 节点挂掉之后，剩下的两个 mongodb 次节点中间产生选举，选举出一个成为新的 primary 节点
对于上述集群，总共 3 个副本，计算出来结果是 2，则 mongodb 会在 这俩中选举一个出来
这个选举的方式是用的大多数选举机制，即为 集群的副本数 / 2 +1 ， （一般集群都是奇数个的）
因为如果是偶数个副本，且他们又处于 2 个网络环境中，若其中一个副本挂掉，就会出现服务不可用的情况，所有我们选择集群使用奇数个，主要是为了保证高可用
可以举一个例子：
例如，有 4 个 mongodb 副本，部署在同一个环境中，则按照大多数选举机制，4/2 + 1 = 3 ，也就是说
当其中有 primary 挂掉的时候，只要剩下的 副本有 4 个或者 4 个以上，就可以选举出 1 个primary， 服务还是正常可用
若 这 4 个 mongodb 副本 分别部署在网络不通的 2 个机房里面，这个时候 其中 1 个副本挂掉，
那么在能够网络互相通的 副本里面，无法组成 3 个副本，因此无法选举，则服务就不可用了
所有节点都可以参与选举吗？
这里需要注意，并不是所有的节点都可以参与选举哟，例如 副本里面会设置相应的字段，vote : 0 的情况则是不参与选举，只会作为一个负载
priority 字段的范围是 0 - 1000 ，见名知意，该字段的数字越大，那么投票的权重就越高
副本回滚
副本回滚，见名知意，就是副本关于数据版本的回滚，那么具体是什么效果呢？
还是刚才的 1 主 2 次的集群，当客户端发送写操作给到主的时候，主接收到了，正要将其数据同步给两个次副本的时候，主副本挂掉了
这个时候，就会通过上述的大多数选举机制来选举出一个新的主副本，暂定选中 mongodb 2
那么，刚才的写操作，由于主副本挂掉，没有及时将数据同步到 次副本，那么mongodb 集群里面会开启重写，重新将刚才的写操作写入到新的主副本中
此时，刚才旧的主副本恢复过来后，就会将自己挂掉之前的写操作要同步给集群中的副本，可是这个时候，新的主副本就会告诉就的主副本，表示你的版本太旧了，需要回滚
这里刚才有说到重写，其实写操作既写入到了旧主副本中，也写入了新的主副本中，可是他们的插入数据库的 id 是不同的，因此新的主副本认为旧的主副本需要回滚
现在，集群又开始了正常的工作和运转，只不过主副本变成了 mongodb 2
集群的读写分离
在 mongodb 集群中，默认情况下，客户端的写操作是给 主副本的，读操作也是从主副本中读
我们也可以设置客户端直接从我们指定的次副本中读取数据，将读取操作放到次副本上
本次分享了
- mongodb 的选举机制
- 副本回滚
- 集群的读写分离
学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~