高可用和一致性的保障

一、高可用性原则

1、集群部署

将Eureka服务器部署在一个集群中，而不是单个节点。这可以通过在不同物理位置或虚拟机上运行多个Eureka服务器实例来实现。这样，即使一个节点失败，其他节点仍然可以提供服务。

2、负载均衡

在Eureka服务器之前使用负载均衡器，以确保流量均匀分布到各个Eureka服务器实例。这有助于防止单点故障，并提高系统的整体性能和可用性。

3、数据复制和同步

如果使用多个Eureka服务器实例，确保它们之间的服务注册信息是相同和一致的。可以使用数据复制和同步机制，如主从复制，以确保在一个节点更新时，其他节点也能够获取最新的服务注册信息。

4、故障检测和恢复

实现故障检测机制，及时发现故障节点并将流量转移到可用节点。自动恢复机制可以确保在节点故障后，系统可以自动恢复到正常运行状态。

5、监控和报警

设置监控系统，以便及时发现潜在的问题并采取措施。配置报警系统，以便在系统出现异常时及时通知相关人员。

二、Eureka高可用实现

1、客户端缓存和定期心跳 （注册列表获取+心跳检测）

Eureka客户端（服务提供者）会定期向Eureka服务器> 发送心跳，以表明自己仍然存活。Eureka服务器通过这些心跳信息来维护服务实例的状态。此外，Eureka客户端会缓存从服务器获取的服务注册信息，这有助于在Eureka服务器不可用时，仍然能够提供服务发现功能。

2、服务注册的分布式架构 (去中心化)

Eureka采用了分布式的服务注册架构，允许多个Eureka服务器实例协同工作。这就意味着，即使其中一个Eureka服务器实例发生故障，其他实例仍然可以提供服务注册和发现的功能。

3、负载均衡

在Eureka架构中，负载均衡器通常用于在客户端和Eureka服务器之间均匀分布流量，防止某个节点成为瓶颈或单点故障。

4、服务注册信息的复制和同步（集群同步）

Eureka服务器之间通过定期的复制和同步机制来保持服务注册信息的一致性。这样，即使一个Eureka服务器发生故障，其他服务器上的信息仍然是完整和准确的，确保服务发现功能的可用性。

5、故障转移和恢复 （哨兵模式有的）

如果某个Eureka服务器实例发生故障，客户端会自动切换到其他可用的Eureka服务器。这种故障转移机制确保了服务注册和发现功能的持续性。

6、监控和报警

Netflix通常会使用监控系统对Eureka进行监测，以及时发现潜在问题。设置报警系统，以在系统出现异常时及时通知运维人员，有助于快速响应和解决问题。

注意：Eureka的高可用实现，完全符合高可用的设计原则，并且还多了【服务列表缓存和心跳检测】，当然还包括Eureka的【自我保护机制】

三、服务的一致性设计原则

1、BASE 模型：

1、基本可用（Basically Available）： 系统保证在出现故障时仍然能够提供基本的可用性。
2、软状态（Soft state）： 系统允许在一段时间内存在不一致，但最终会达到一致状态。
3、最终一致性（Eventual Consistency）： 系统最终会达到一致的状态，尽管在中间可能
存在一段时间的不一致。

BASE 模型相对于 ACID（原子性、一致性、隔离性、持久性）模型更适用于【分布式系统】，
允许一定程度的柔性，提高系统的可用性。

2、乐观并发控制：

使用乐观并发控制（Optimistic Concurrency Control）机制，允许多个节点并发地修改数据，但在提交时检测冲突并解决。（zookeeper没有这个但是通过版本控制和时间戳实现了这个功能）

3、版本控制：

使用版本控制机制来跟踪和管理数据的变化，从而实现一致性。例如，通过在数据中引入【时间戳】或【版本号】

4、分布式锁：

合理使用分布式锁机制，以确保对共享资源的访问是有序和同步的。

5、数据复制和同步：

在分布式环境中，确保数据在不同节点之间的复制和同步。使用合适的复制策略，如主从复制，以确保数据一致性。

6、事务日志：

记录事务日志以确保对数据的更新是可追溯和可恢复的。事务日志可以用于在发生故障时进行数据恢复。

四、zookeeper是如何保障服务的一致性

1、ZAB 协议

ZooKeeper使用ZAB（ZooKeeper Atomic Broadcast）协议，这是一种基于Paxos算法的原子广播协议。ZAB协议确保了对数据变更的原子性和一致性。它通过选举一个领导节点（Leader）来负责接收和处理写入操作，其他节点（Followers）复制Leader的操作，以确保一致性。

2、原子广播：

ZooKeeper使用原子广播（Atomic Broadcast）协议，确保在整个集群中对更新的顺序达成一致。这意味着，如果一个节点成功地接收并提交了一次更新，那么所有其他节点也会以相同的顺序接收并提交这次更新。这确保了整个系统对于更新操作的顺序是一致的。

3、事务日志

ZooKeeper将所有的写入操作都记录在一个事务日志中。这个事务日志是一个持久化的数据结构，可以用于在节点启动时进行恢复。通过事务日志，ZooKeeper可以确保即使在发生故障或重启时，系统依然能够维持一致性。

4、临时顺序节点

ZooKeeper提供了临时节点和顺序节点的概念，这有助于实现有序的访问和控制。这对于某些分布式场景下的协调和锁的实现是非常有用的，从而维护一致性。

小结：可以说ZAB协议，保障了234所有的功能点

五、ZAB协议和Paxos算法区别

ZooKeeper Atomic Broadcast（ZAB）协议和Paxos 都是用于分布式系统中实现【一致性的算法】。
ZAB是ZooKeeper使用的一种改进的 Paxos变体，下面简要比较这两者：

1、目标和用途:

1、ZAB: 用于ZooKeeper分布式协调服务。主要关注在分布式系统中实现原子
广播的一致性问题，确保节点之间的数据一致性。 
2、Paxos: 【通用】的分布式一致性算法，用于解决分布式系统中的一致性问题，包括状态机复制等。

2、选举方式不同

1、ZAB: ZAB 在其中的一个节点被选举为 Leader，其他节点作为 Follower。 
Leader 负责处理写操作，而Follower复制Leader 的操作。
2、Paxos: Paxos 中有一个称为 Proposer 的角色，负责提出提案，以及一个称为 Acceptor 的角色，
负责接受或拒绝提案。Proposer 和 Acceptor 的角色可以在不同的节点上。

3、消息顺序保证:

1、ZAB: ZAB确保所有节点对【更新的顺序】达成一致。通过Leader发布的提案，
所有节点最终都按照相同的顺序应用这些提案。
2、Paxos: Paxos【通过阶段性提交】的方式，确保所有节点最终达成一致。每个提案有一个唯一的编号，
通过协议的多个阶段来达成一致。

4、多轮通信

1、ZAB: ZAB 引入了更少的【通信轮次】，减少了消息传递的次数，提高了效率。
ZAB 在 Leader 和 Follower 之间使用【心跳】来保持连接状态。
2、Paxos: Paxos 需要多轮通信，包括提案的【提交】和阶段的【确认】

5、数据恢复:

1、ZAB: ZAB保留了事务日志，可用于在节点失败后进行数据恢复。
2、Paxos: Paxos 需要更复杂的机制来处理节点故障后的数据一致性和恢复。