Seata 注册中心

淡淡的烟草味﹌ 2022-11-21 11:20 259阅读 0赞

# 注册中心 #

注册中心的实现有很多种方式， 如下图所示。  
![注册中心实现图][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_center]  
这是注册中心定义的接口， 分别给不同的角色使用。 例如协调者： 注册，取消注册，关闭。 事务管理器和资源管理器： 订阅，取消订阅，查找

public interface RegistryService<T> { 
    	// 注册
    	void register(InetSocketAddress address) throws Exception;
    
       	// 取消注册
       	void unregister(InetSocketAddress address) throws Exception;
    
       	// 订阅
       	void subscribe(String cluster, T listener) throws Exception;
    
        // 取消订阅
        void unsubscribe(String cluster, T listener) throws Exception;
    
        // 查找
        List<InetSocketAddress> lookup(String key) throws Exception;
    
        // 关闭
        void close() throws Exception;
    
        // 获得服务组名称
        default String getServiceGroup(String key) { 
            key = PREFIX_SERVICE_ROOT + CONFIG_SPLIT_CHAR + PREFIX_SERVICE_MAPPING + key;
            if (!SERVICE_GROUP_NAME.contains(key)) { 
                ConfigurationCache.addConfigListener(key);
                SERVICE_GROUP_NAME.add(key);
            }
            return ConfigurationFactory.getInstance().getConfig(key);
        }
         Set<String> SERVICE_GROUP_NAME = new HashSet<>();
    }

注册中心有什么意义呢？

注册中心主要就是为了让TM,RM动态感知协调者的变更。 在向协调者发送请求的时候，会从注册中心里的协调者列表用负载均衡算法选择一个协调者，然后发送请求。 从这里可以看出协调者必须是对等的， 每个请求发给哪一台协调者都是一样的。

例如seata中的各个角色和注册中心的交互图:

事物管理器资源管理器协调者注册中心注册订阅通过事件更新协调者列表订阅通过事件更新协调者列表通过注册中心工厂获取协调者列表通过协调者列表用负载均衡组件选择一个协调者发送请求通过注册中心工厂获取协调者列表通过协调者列表用负载均衡组件选择一个协调者发送请求事物管理器资源管理器协调者注册中心

## zookeeper注册中心加载流程 ##

在创建 GlobalTransactionScanner 时，会确认事物分组名称，例如: my\_test\_tx\_group

注册中心的加载

CallerRegistryFactoryEnhancedServiceLoadergetInstanceload RegistryProviderSPI 方式加载 RegistryProviderRegistryProviderRegistryService = RegistryProvider.provideCallerRegistryFactoryEnhancedServiceLoader

接下来看获取注册中心的协调者（TC）列表

1.  首先从本地缓存中获取, 不存在从注册中心获取
2.  通过配置中心获取集群名称: service.vgroupMapping.my\_test\_tx\_group = default
3.  获取协调者列表, zk的节点数据: /registry/zk/default = \[192.168.1.103:8091\]
4.  将协调者列表加入本地缓存

RegistryServiceConfigurationZookeeperlookUp获取集群名称default获取协调者列表\[192.168.1.103:8091\]将ip放入本地集群名称缓存,订阅zk节点RegistryServiceConfigurationZookeeper

# 负载均衡 #

负载均衡算法在1.3.0 还没有最少使用算法和一致性hash算法， 这里是1.4.0 的负载均衡图  
![负载均衡实现图][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_left]  
负载均衡算法，用来在多台协调者中选择一台机器，将消息发送给协调者。 例如TC1,TC2,TC3 通过负载均衡算法选择了TC2， 将全局事物开启请求发送给TC2。

**当只有一台机器的时候，是不会采用任何负载均衡算法的**

## 随机 ##

从当前机器总数5， 通过 ThreadLocalRandom 随机一个下标， 例如 随机到 3, 选择3的下标，就是第四台机器

## 最少使用 ##

1.4.0 的负载均衡算法

最少使用的算法由RpcStatus实现，RemotingClient 内部有通过SPI机制加载的列表: List<RpcHook>,  
发消息前对RpcStatus计数+1， 收到响应后对计数-1  
![RemotingClient][]

发消息变更 RpcStatus 的流程

ResourceManagerRemotingClientStatusRpcHookRpcStatusTCsendSyncRequestdoBeforeRpcHooksdoBeforeRequestbeginCountrequestresponsedoAfterRpcHooksdoAfterRequestendCountResourceManagerRemotingClientStatusRpcHookRpcStatusTC

首先遍历Invoker， 然后通过RpcStatus拿到对应的调用次数。  
首先过滤到一组最少的调用次数，如果只有一个，就只用这一个， 如果有多个最少的，就随机一个。

例如有五台机器的调用次数如下: (4,8,9,29,4), 筛选到新数组(0,5) , 新数组的内容是老数组的下标， 然后新数组随机一个值： 下标1， 取得里面的值：5. 那么就取原数组的第5个下标。 最终调用第五台机器。

例如有五台机器调用次数如下: (5,8,19,6,2), 只有2是最少的， 所以调用第五台机器

## 一致性哈希 ##

1.4.0 的负载均衡算法  
在 \[0,Integer,MAX\_VALUE) 范围看成一个环， 如果环上用实际节点，很容易会不均匀。 例如 0,MAX\_VALUE-100 属于节点A， 其他的属于节点B。 那么这种负载均衡算法就没有意义了， 99.99%都是选择节点A。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_center 1]

为了解决节点分布不均匀的问题， 引入了虚拟节点。 例如原先的节点A的hash是MAX\_VALUE-1000, 虚拟节点就是计算 节点A+1，节点A+2，节点A+n 重新计算的hash值， 会有更大概率分布在整个环上。 根据调用的全局事物ID 计算一个hash值， 找到环上的下一个虚拟几点， 最后找到实际节点进行调用。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_center 2]

一致性hash听起来还是很高大上的，实现方式一个是虚拟节点的hash计算， 另一个是用 SortedMap.tailMap 找到下一个hash值

## 轮询 ##

先从 \[0,Integer.MAX\_VALUE) 取值， 然后用当前值 % 机器总数

例如轮询到 18， 总共 5 太机器 ， 18%5 = 3, 选择3的下标，就是第四台机器

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/5c9e5c64c3934d51a7e9ce4133d2aa17.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_left]: /images/20221120/d1f484e2355543578d38f128399df26c.png
[RemotingClient]: /images/20221120/79e6cc7d507a4eca96ac0db9b1ca2fc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/fe5800ce4e20424e97b25d0354fdc91d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L216NDEzOA_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/c2af3653f60747dbb0629c3039f5cba0.png