发布日期:
2024-06-13
文章字数:
2.3k
阅读时长:
8 分
阅读次数:
- CAP：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼
- zookeeper 更看重C和P，即一致性和分区容错性，当进入选举模式时，就无法正常对外提供服务
- Eureka更在意的是A和P，集群是对等的，地位是相同的，虽不能保证一致性，但至少可以提供注册服务
- RPC 微服务的远程过程调用最核心的是：高可用
- Zookeeper：是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能
- zookeeper 保证最终一致性，尽量保持强一致性
- zookeeper=文件系统+通知机制
- Zookeeper的主要作用是为分布式系统提供协调服务,包括但不限于:分布式锁,统一命名服务,配置管理,负载均衡,主控服务器选举以及主从切换等
- Zookeeper自身通常也以分布式形式存在。一个Zookeeper服务通常由多台服务器节点构成,只要其中超过一半的节点存活,Zookeeper即可正常对外提供服务
- 客户端可以通过TCP协议连接至任意一个服务端节点请求Zookeeper集群提供服务,而集群内部如何通信以及如何保持分布式数据一致性等细节对客户端透明
- Zookeeper 的每个 ZNode 上都会存储数据，对应于每个 ZNode，Zookeeper 都会为其维护一个叫作 Stat 的数据结构
- version（当前 ZNode 的版本）
- cversion（当前 ZNode 子节点的版本）
- aversion（当前 ZNode 的 ACL 版本）
- Watcher（事件监听器）：ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性
- ACL（AccessControlLists）：类似于 UNIX 文件系统的权限控制
- CREATE；READ；WRITE；DELETE；ADMIN（设置节点ACL权限）
- znode：持久化目录节点；持久化顺序编号目录节点；临时目录节点；临时顺序编号目录节点
- ZooKeeper 特点
- 顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去
- 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用
- 单一系统映像：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的
- 可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖
- Zookeeper集群：Leader；Follower；Observer
- Leader服务器在整个正常运行期间有且仅有一台,集群会通过选举的方式选举出Leader服务器,由它同统一处理集群的事务性请求以及集群内各服务器的调度
- Follower的主要职责：参与Leader选举投票；参与事务请求Proposal的投票；处理客户端非事务请求(读),并转发事务请求(写)给Leader服务器
- Observer是弱化版的Follower。其像Follower一样能够处理非事务也就是读请求,并转发事务请求给Leader服务器。但是其不参与任何形式的投票,也不参与写操作的“过半写成功”策略。引入这个角色主要是为了在不影响集群事务处理能力的前提下提升集群的非事务处理的吞吐量
- ZAB 协议（ZooKeeper Atomic Broadcast 原子广播）：支持崩溃恢复，实现分布式数据一致性（主备模式）
- 崩溃恢复和消息广播
- 当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式
- 所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进人消息广播模式了
- 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播。那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去
- ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。Leader 服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议。而如果集群中的其他机器接收到客户端的事务请求，那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。
- Zookeeper实现分布式锁：临时有序节点 + 事件监听
- Zookeeper实现集群管理
- 机器加入退出：使用临时目录节点
- 选举：临时顺序编号目录节点里的最小编号
- Zookeeper选举：默认是采用投票数大于半数则胜出的逻辑
- Serverid：编号越大在选择算法中的权重越大
- Zxid：值越大说明数据越新，在选举算法中数据越新权重越大
- Epoch：投票次数
- Server状态：LOOKING（竞选状态）；FOLLOWING（随从状态，同步leader状态，参与投票）；OBSERVING（观察状态，同步leader状态，不参与投票）；LEADING（领导者状态）
- 选举消息内容：在投票完成后，需要将投票信息发送给集群中的所有服务器（Serverid；Zxid；Epoch；Server状态）
- Zookeeper集群数据一致性
- leader -> 领导者选举算法
- 2PC：两阶段提交（强一致、中心化的原子提交协议）
- 过半机制
- 最好奇数台服务器构成 ZooKeeper 集群：如果有 3 个 Server，则最多允许 1 个 Server 挂掉；如果有 4 个 Server，则同样最多允许 1 个 Server 挂掉。既然 3 个或者 4 个 Server，同样最多允许 1 个 Server 挂掉，那么它们的可靠性是一样的，所以选择奇数个 ZooKeeper Server 即可
- Dubbo 优点：基于Netty的高性能RPC框架，提供服务自动注册、自动发现等高效服务治理方案，可以和Spring框架无缝集成
- 透明化的远程方法调用：就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入
- 软负载均衡及容错机制：可在内网替代nginx等硬件负载均衡器，降低成本
- 服务自动注册与发现：不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址
- Dubbo超时时间设置
- 推荐优先在服务提供者端设置超时时间
- 如果在消费者端设置了超时时间，以消费者端为主
- Dubbo集群的负载均衡
- RandomLoadBalance：随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀
- RoundRobinLoadBalance：轮循选取提供者策略，平均分布，但是存在请求累积的问题
- LeastActiveLoadBalance：最少活跃调用策略，解决慢提供者接收更少的请求
- ConstantHashLoadBalance：一致性Hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动
- Dubbo的核心组件：Provider（服务提供者）；Consumer（服务消费者）；Registry（注册中心）；Monitor（监控中心）；Container（服务容器）
- 服务治理：服务URL配置困难；负载均衡分配节点压力过大；服务依赖混乱，启动顺序不清晰；过多服务导致性能指标分析难度较大，需要监控
- Dubbo的注册中心集群挂掉，发布者和订阅者之间可以继续通信：启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地，每次调用时，按照本地存储的地址进行调用
- Dubbo安全机制：通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方
