主要是根据这三个参数的大小对比结果,选择对应的数据同步方式。
Zookeeper中数据同步一共有四类,如下:
peerlastZxid介于minCommittedLog和maxCommittedLog之间
当Leader服务器发现某个Learner包含了一条自己没有的事务记录,那么就需要让该Learner进行事务回滚到Leader服务器上存在的
peerlastZxid大于maxCommittedLog,Leader会要求Learner回滚到ZXID值为maxCommitedLog对应的事务操作
peerLastZxid小于minCommittedLog
在初始化阶段,Leader服务器会优先初始化以全量同步方式来同步数据。learner先向leader注册,上报peerLastZxid
不能确保任何客户端能够获取(即Read Request)到一样的数据,除非客户端自己要求,方法是客户 端在获取数据之前调用函数sync,再调用getData()
ZK客户端A对节点的内容从v1->v2,但是ZK客户端B对内容获取,依然得到的是v1.这个是实际存在的 现象,存在同步时延
ZooKeeper对于事务性的支持主要依赖于四个函数,zoo_create_op_init,zoo_delete_op_init,zoo_set_op_init以及zoo_check_op_init。
每一个函数都会在客户端初始化一个operation,客户端程序有义务保留这些operations。当准备好一 个事务中的所有操作后,可以使用zoo_multi来提交所有的操作,由zookeeper服务来保证这一系列操 作的原子性。也就是说只要其中有一个操作失败了,相当于此次提交的任何一个操作都没有对服务端的 数据造成影响。zoo_multi的返回值是第一个失败操作的状态信号。
peerType=observer
server.1:localhost:2181:3181:observ
客户端连接zk,有zk分配一个全局唯一的sessionId,客户端需要配置超时时间timeOut并传到zk,zk会据此计算会话下一次超时的时间点,zk根据这个时间点按照分桶策略进行分开存放,zk会给session设置一个isClosing属性、如果检测到超时会将该属性标记为关闭
会话状态:CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE
SessionTracker:zk中的会话管理器,负责会话的创建、管理和清理
ExpiractionTime = CurrentTime + SessionTimeout
SessionTracker根据ExpiractionTime将session进行分桶管理,同时按照一定的时间间隔进行定期检查,
同时客户端读写请求都可以将session的超时时间重置,SessionTracker会将session进行分桶迁移,如果没有读写请求,客户需要发送ping心跳链接,否则session超时会被清除
连接断开后客户端可以重连zk,如果该session未过期,session重新变为CONNECTED
如果时间超过sessinTimeout,服务器则会进行会话的清理工作,如果此时ZK客户端才恢复连接,则会收到State为Expired的WatchedEvent,并断开与服务器的连接。
重连:断开后更换服务器链接,RECONNECTING状态,会将会话迁移到新连接的服务器上
当一个客户端发一个心跳请求个服务端,但是网络延时,导致服务端没有收到,过一会后,客户端连接上了另一个新的服务端,在这之后,之前的心跳被旧的服务端收到了,这时候旧的服务端会被提醒,当前session已经被转移了,然后旧的服务端会关闭这个连接。客户端一般不会感知到这个异常,因为旧连接一般都会被关闭。但是还有一个特殊情况,两个客户端同时使用保存这的session id+密码来重新连接服务端,第一个连接成功,紧着第二个又连接成功,这会导致第一个连接被关闭,然后就是这两个客户端无限重连了
eureka还有一种自我保护机制,如果15分钟内超过85%的节点没有正常心跳会开启保护机制。eureka 不再从注册列表移除长时间没有心跳的服务、eureka仍能接受新的服务注册和查询,只不过不会同步到 其他节点。网络稳定后再同步到其他节点。同时eureka的客户端也会缓存服务信息。eureka对于服务 注册发现来说是非常好的选择
如有问题,欢迎加微信交流:w714771310,备注- 技术交流 。或关注微信公众号【码上遇见你】。