SpringCloud_springcloud watcher

SpringCloud

总览

• Spring Cloud是一个基于Spring Boot的微服务框架，用于快速构建和部署分布式系统和微服务应用。它提供了一系列的组件和工具，包括服务发现、负载均衡、配置管理、断路器、分布式跟踪等，支持多种分布式系统的开发和管理。
• Spring Cloud提供了一系列的组件和工具，包括以下几个方面：

服务注册和发现组件：Eureka、Consul、Zookeeper等，用于实现服务注册和发现功能。
服务调用组件：Ribbon、Feign、RestTemplate等，用于实现服务之间的调用和负载均衡。
API网关组件：Zuul、Spring Cloud Gateway等，用于实现API网关功能，提供统一的入口和路由控制。
配置中心组件：Config Server、Spring Cloud Config等，用于实现配置管理功能，支持动态刷新配置。
熔断器组件：Hystrix、Resilience4j等，用于实现熔断器功能，提高系统的容错能力。
分布式跟踪组件：Zipkin、Sleuth等，用于实现分布式跟踪和日志追踪功能。
消息总线组件：Spring Cloud Bus、Kafka等，用于实现消息总线功能，支持消息广播和动态刷新配置等。
安全组件：Spring Cloud Security等，用于实现安全管理功能，提供基于OAuth2的安全认证和授权机制。

Zookeeper

Zookeeper是一个开源的分布式协调服务框架，主要用于解决分布式应用中的一些协调和管理问题。基于高可用性的分布式数据存储和通知机制，可以实现分布式应用的协同工作。

特点

• 分布式数据存储：Zookeeper提供了一个分布式的数据存储机制，支持数据的读写和监听等操作，可以保存各种配置信息和状态信息。

• 通知机制：Zookeeper基于发布-订阅模式，支持事件和通知机制，可以实现数据变更的监听和通知，提高分布式应用的实时性和可靠性。

• 高可用性和容错性：Zookeeper使用ZAB协议实现数据同步和一致性，支持主从切换和故障转移，保证数据的可用性和容错性。

• 分布式锁和队列：Zookeeper提供了分布式锁和队列机制，支持共享锁和排他锁，可以用于实现分布式应用的协同工作。

文件系统

Zookeeper中的文件系统是指ZNode的组织结构和存储方式，ZNode类似于一个文件或者目录，是Zookeeper的基本数据单元。ZNode存储在Zookeeper的内存中，以树形结构组织，可以通过唯一的路径进行访问和操作。

Znode类型

• 持久节点（Persistent ZNode）：指创建后永久存在的节点，直到被显式地删除。持久节点是Zookeeper中最基本的节点类型，它通常用于存储一些持久化的配置信息或者状态数据。
• 临时节点（Ephemeral ZNode）：指创建后只存在于会话期间的节点，当会话结束或者会话超时后，节点会自动删除。临时节点通常用于实现临时的分布式锁或者队列等功能。
• 持久顺序节点（Persistent Sequential ZNode）：指创建后永久存在的节点，和持久节点不同的是，持久顺序节点会自动为节点名称添加一个序列号，用于保证节点的唯一性。持久顺序节点通常用于实现全局唯一的ID或者序列号。
• 临时顺序节点（Ephemeral Sequential ZNode）：指创建后只存在于会话期间的节点，和持久顺序节点类似，临时顺序节点也会自动为节点名称添加一个序列号，用于保证节点的唯一性。临时顺序节点通常用于实现分布式的队列或者任务调度等功能。

ZAB协议

是Zookeeper用于实现数据同步和一致性的核心协议。ZAB协议的主要目标是实现数据的强一致性和可靠性，保证Zookeeper的高可用性和容错性。

具体实现方式

• 崩溃恢复阶段：当一个节点发生故障或者重启时，它需要重新加入Zookeeper集群，并且找到最新的数据状态。这个过程称为崩溃恢复。崩溃恢复阶段包含两个子阶段：数据同步和Leader选举。
• 数据同步：当一个节点重新加入集群时，它需要将自己缺失的数据同步过来，保证数据的一致性。节点通过和其他节点比较自己的数据版本号，将自己缺失的数据同步过来。
• Leader选举：当一个节点成为Leader时，它需要保证其他节点和自己的数据一致性，防止出现脑裂等问题。Zookeeper通过Leader选举机制选举一个Leader，Leader负责处理客户端请求和数据同步等任务。当Leader发生故障时，Zookeeper会自动选举一个新的Leader，保证系统的高可用性和容错性。
• 广播阶段：在广播阶段中，Leader将更新操作广播给所有Follower，保证所有节点的数据一致性和可靠性。Leader会将所有更新操作进行编号，并将操作发送给所有Follower。当Follower确认了操作后，Leader会将操作进行提交。

通知机制

Zookeeper基于发布-订阅模式，支持事件和通知机制，可以实现数据变更的监听和通知，提高分布式应用的实时性和可靠性。Zookeeper的通知机制是基于Watcher机制实现的。Watcher是Zookeeper的一种机制，用于实现对ZNode节点的监听和事件通知。当ZNode节点发生变化时，Watcher机制可以自动触发相应的事件，并向客户端发送通知，以便客户端能够及时处理和响应变化。

特点

• 实时性：Zookeeper的Watcher机制是一种实时的机制，可以实现对ZNode节点变化的实时监听和事件通知。
• 可靠性：Zookeeper的Watcher机制是一种可靠的机制，可以保证客户端能够及时接收到事件通知，避免遗漏和错误。
• 灵活性：Zookeeper的Watcher机制支持多种类型的事件监听和通知，可以根据具体的需求和场景进行配置和使用。

watcher的工作机制

• 客户端向Zookeeper服务器注册Watcher：客户端通过调用Zookeeper API，向Zookeeper服务器注册Watcher，指定要监听的ZNode节点和要监听的事件类型。
• ZNode节点发生变化：当ZNode节点发生变化时，Zookeeper服务器会检查是否存在对应的Watcher，并将Watcher的信息发送给客户端。
• 客户端处理Watcher事件：当客户端接收到Watcher的通知后，会根据事件类型，对相应的事件进行处理。

	public void getData(String path, boolean watch) throws KeeperException, InterruptedException {
        Stat stat = zooKeeper.exists(path, watch);
        if (stat != null) {
            byte[] data = zooKeeper.getData(path, watch, stat);
            System.out.println("Node data: " + new String(data));
        } else {
            System.out.println("Node not exists: " + path);
        }
    }

    @Override
    public void process(WatchedEvent event) {
        if (event.getState() == Event.KeeperState.SyncConnected) {
            if (event.getType() == Event.EventType.None && event.getPath() == null) {
                countDownLatch.countDown();
            } else if (event.getType() == Event.EventType.NodeDataChanged) {
                try {
                    getData(PATH, true);
                } catch (KeeperException | InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

在getData方法中，通过调用exists方法并传入watch参数来注册Watcher，如果节点存在，则获取节点数据，并打印出来。在process方法中，判断Watcher所接收到的事件类型，如果是NodeDataChanged事件，则调用getData方法重新获取节点数据，并继续监听节点数据的变化。

事务

怎么保证事务的顺序一致性

在分布式系统中，保证事务的顺序一致性通常需要对数据进行全局排序。一种常见的做法是使用时间戳来实现全局排序。例如，对于多个写操作，可以为每个操作分配一个全局唯一的时间戳，然后按照时间戳顺序执行操作。在一些分布式数据库系统中，也可以使用分布式锁来保证操作的顺序一致性。

Dubbo

Dubbo是一个高性能的开源RPC（远程过程调用）框架，最初由阿里巴巴开发。它提供了一组工具来构建分布式系统，包括负载均衡、服务注册和发现以及容错处理。
使用Dubbo，开发人员可以轻松创建微服务，并在分布式环境中管理它们。Dubbo采用分层架构，并支持各种通信协议，包括HTTP、TCP和UDP。它还支持各种序列化协议，如JSON、Hessian和Protobuf。

核心优势

• 快速易用：Dubbo 让微服务开发变得非常容易，它允许你选择多种编程语言、使用任意通信协议，并且它还提供了一系列针对微服务场景的开发、测试工具帮助提升研发效率。
• 超高性能：Dubbo 在通信性能、稳定性方面具有无可比拟的优势，非常适合构建近乎无限水平伸缩的微服务集群，这也是 Dubbo 从实践层面优于业界很多同类的产品的巨大优势。
• 服务治理：Dubbo 丰富的流量管控规则可以控制服务间的流量走向和 API 调用，基于这些规则可以实现在运行期动态的调整服务行为如超时时间、重试次数、限流参数等

功能

• 微服务开发：解决企业微服务从开发、部署到治理运维的一系列挑战，Dubbo 为开发者提供从项目创建、开发测试，到部署、可视化监测、流量治理，再到生态集成的全套服务。
• 服务发现：一种 Client-Based 的服务发现机制，依赖第三方注册中心组件来协调服务发现过程，支持常用的注册中心如 Nacos、Consul、Zookeeper 等。
• 负载均衡：，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。

策略：Weighted Random LoadBalance 加权随机 默认算法，默认权重相同
RoundRobin LoadBalance 加权轮询 借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，
LeastActive LoadBalance 最少活跃优先 + 加权随机 背后是能者多劳的思想
Shortest-Response LoadBalance 最短响应优先 + 加权随机 更加关注响应速度
ConsistentHash LoadBalance 一致性哈希 确定的入参，确定的提供者，适用于有状态请求

• 流量管控：提供了丰富的流量管控策略

1、地址发现与负载均衡：地址发现支持服务实例动态上下线，负载均衡确保流量均匀的分布到每个实例上。
2、基于路由规则的流量管控：路由规则对每次请求进行条件匹配，并将符合条件的请求路由到特定的地址子集。

• 通信协议：提供了自定义的高性能 RPC 通信协议：基于 HTTP/2 的 Triple 协议 和 基于 TCP 的 Dubbo2 协议。除此之外，Dubbo 框架支持任意第三方通信协议，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多协议可以通过自定义扩展实现。这对于微服务实践中经常要处理的多协议通信场景非常有用。
• 认证鉴权：Dubbo 提供了构建安全微服务通信体系 (零信任体系) 的完善机制

整体架构

• 服务层：服务层是Dubbo的最上层，用于封装服务提供者和服务消费者之间的调用细节。服务层包括两个组件：服务提供者和服务消费者。服务提供者将服务发布到注册中心，而服务消费者从注册中心获取服务提供者的地址并进行调用。
• 支撑层：支撑层为Dubbo提供了一系列的支持组件，包括协议层、远程调用层、注册中心层和集群层。支撑层提供了服务提供者和服务消费者之间的通信机制，并负责处理一些关键的分布式系统问题，如服务的注册和发现、负载均衡、容错处理等。
• 基础设施层：基础设施层为Dubbo提供了一些底层的支持组件，包括线程池、网络通信、序列化、反序列化等。基础设施层为Dubbo的高性能、高可靠性提供了强有力的支撑。

分布式事务

• 两阶段提交（2PC）：2PC是一种基于协调者和参与者的分布式事务协议，可以保证各个分布式系统的事务操作具有原子性和一致性，但是会引入阻塞和单点故障等问题。

• 补偿事务（TCC）：TCC是一种基于try-confirm-cancel三阶段的分布式事务协议，可以在不阻塞事务的前提下保证各个分布式系统的事务操作具有原子性和一致性，但是会引入代码复杂度和可靠性等问题。

• 最大努力通知（Best Effort Delivery，BED）：BED是一种基于异步消息传递的分布式事务协议，可以通过消息重试和重投等机制保证数据的最终一致性，但是无法保证数据的实时性和可靠性。