Cluster分析（容错机制）

最新推荐文章于 2023-02-10 20:19:06 发布
最新推荐文章于 2023-02-10 20:19:06 发布
阅读量817 收藏
点赞数
分类专栏： Dubbo框架

1. FailoverClusterInvoker失败自动切换

 在调用失败时，会自动切换 Invoker 进行重试。默认确配置下，Dubbo 会使用这个类作为缺省 Cluster Invoker。

  • doInvoke()
  1. 首先是获取重试次数，然后根据重试次数进行循环调用，失败后进行重试。
  2. 在 for 循环内，首先通过负载均衡组件选择一个 Invoker（每次都得到最新可用的Invoker列表）。
  3. 通过这个 Invoker 的 invoke 方法进行远程调用。如果失败了，记录下异常，并进行重试。重试时会再次调用父类的 list 方法列举 Invoker。
public class FailoverClusterInvoker<T> extends AbstractClusterInvoker<T> {
 
    // 省略部分代码
 
    @Override
    public Result doInvoke(Invocation invocation, final List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        List<Invoker<T>> copyinvokers = invokers;
        checkInvokers(copyinvokers, invocation);
        // 获取重试次数
        int len = getUrl().getMethodParameter(invocation.getMethodName(), Constants.RETRIES_KEY, Constants.DEFAULT_RETRIES) + 1;
        if (len <= 0) {
            len = 1;
        }
        RpcException le = null;
        List<Invoker<T>> invoked = new ArrayList<Invoker<T>>(copyinvokers.size());
        Set<String> providers = new HashSet<String>(len);
        // 循环调用，失败重试
        for (int i = 0; i < len; i++) {
            if (i > 0) {
                checkWhetherDestroyed();
                // 在进行重试前重新列举 Invoker，这样做的好处是，如果某个服务挂了，
                // 通过调用 list 可得到最新可用的 Invoker 列表
                copyinvokers = list(invocation);
                // 对 copyinvokers 进行判空检查
                checkInvokers(copyinvokers, invocation);
            }
 
            // 通过负载均衡选择 Invoker
            Invoker<T> invoker = select(loadbalance, invocation, copyinvokers, invoked);
            // 添加到 invoker 到 invoked 列表中
            invoked.add(invoker);
            // 设置 invoked 到 RPC 上下文中
            RpcContext.getContext().setInvokers((List) invoked);
            try {
                // 调用目标 Invoker 的 invoke 方法
                Result result = invoker.invoke(invocation);
                return result;
            } catch (RpcException e) {
                if (e.isBiz()) {
                    throw e;
                }
                le = e;
            } catch (Throwable e) {
                le = new RpcException(e.getMessage(), e);
            } finally {
                providers.add(invoker.getUrl().getAddress());
            }
        }
         
        // 若重试失败，则抛出异常
        throw new RpcException(..., "Failed to invoke the method ...");
    }
}
  • select()

select 方法的主要逻辑集中在了对粘滞连接特性的支持上。

  1. 首先是获取 sticky 配置，
  2. 然后再检测 invokers 列表中是否包含 stickyInvoker，如果不包含，则认为该 stickyInvoker 不可用，此时将其置空。这里的 invokers 列表可以看做是存活着的服务提供者列表，如果这个列表不包含 stickyInvoker，那自然而然的认为 stickyInvoker 挂了，所以置空。
  3. 如果 stickyInvoker 存在于 invokers 列表中，此时要进行下一项检测 — 检测 selected 中是否包含 stickyInvoker。如果包含的话，说明 stickyInvoker 在此之前没有成功提供服务（但其仍然处于存活状态）。此时我们认为这个服务不可靠，不应该在重试期间内再次被调用，因此这个时候不会返回该 stickyInvoker。如果 selected 不包含 stickyInvoker，此时还需要进行可用性检测，比如检测服务提供者网络连通性等。
  4. 当可用性检测通过，才可返回 stickyInvoker，否则调用 doSelect 方法选择 Invoker。如果 sticky 为 true，此时会将 doSelect 方法选出的 Invoker 赋值给 stickyInvoker。
protected Invoker<T> select(LoadBalance loadbalance, Invocation invocation, List<Invoker<T>> invokers, List<Invoker<T>> selected) throws RpcException {
    if (invokers == null || invokers.isEmpty())
        return null;
    // 获取调用方法名
    String methodName = invocation == null ? "" : invocation.getMethodName();
 
    // 获取 sticky 配置，sticky 表示粘滞连接。所谓粘滞连接是指让服务消费者尽可能的
    // 调用同一个服务提供者，除非该提供者挂了再进行切换
    boolean sticky = invokers.get(0).getUrl().getMethodParameter(methodName, Constants.CLUSTER_STICKY_KEY, Constants.DEFAULT_CLUSTER_STICKY);
    {
        // 检测 invokers 列表是否包含 stickyInvoker，如果不包含，
        // 说明 stickyInvoker 代表的服务提供者挂了，此时需要将其置空
        if (stickyInvoker != null && !invokers.contains(stickyInvoker)) {
            stickyInvoker = null;
        }
         
        // 在 sticky 为 true，且 stickyInvoker != null 的情况下。如果 selected 包含
        // stickyInvoker，表明 stickyInvoker 对应的服务提供者可能因网络原因未能成功提供服务。
        // 但是该提供者并没挂，此时 invokers 列表中仍存在该服务提供者对应的 Invoker。
        if (sticky && stickyInvoker != null && (selected == null || !selected.contains(stickyInvoker))) {
            // availablecheck 表示是否开启了可用性检查，如果开启了，则调用 stickyInvoker 的
            // isAvailable 方法进行检查，如果检查通过，则直接返回 stickyInvoker。
            if (availablecheck && stickyInvoker.isAvailable()) {
                return stickyInvoker;
            }
        }
    }
     
    // 如果线程走到当前代码处，说明前面的 stickyInvoker 为空，或者不可用。
    // 此时继续调用 doSelect 选择 Invoker
    Invoker<T> invoker = doSelect(loadbalance, invocation, invokers, selected);
 
    // 如果 sticky 为 true，则将负载均衡组件选出的 Invoker 赋值给 stickyInvoker
    if (sticky) {
        stickyInvoker = invoker;
    }
    return invoker;
}
  • doSelect ()

doSelect 主要做了两件事：

  1. 通过负载均衡组件选择 Invoker。
  2. 如果选出来的 Invoker 不稳定，或不可用，此时需要调用 reselect 方法进行重选。若 reselect 选出来的 Invoker 为空，此时定位 invoker 在 invokers 列表中的位置 index，然后获取 index + 1 处的 invoker，这也可以看做是重选逻辑的一部分。
private Invoker<T> doSelect(LoadBalance loadbalance, Invocation invocation, List<Invoker<T>> invokers, List<Invoker<T>> selected) throws RpcException {
    if (invokers == null || invokers.isEmpty())
        return null;
    if (invokers.size() == 1)
        return invokers.get(0);
    if (loadbalance == null) {
        // 如果 loadbalance 为空，这里通过 SPI 加载 Loadbalance，默认为 RandomLoadBalance
        loadbalance = ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(Constants.DEFAULT_LOADBALANCE);
    }
     
    // 通过负载均衡组件选择 Invoker
    Invoker<T> invoker = loadbalance.select(invokers, getUrl(), invocation);
 
    // 如果 selected 包含负载均衡选择出的 Invoker，或者该 Invoker 无法经过可用性检查，此时进行重选
    if ((selected != null && selected.contains(invoker))
            || (!invoker.isAvailable() && getUrl() != null && availablecheck)) {
        try {
            // 进行重选
            Invoker<T> rinvoker = reselect(loadbalance, invocation, invokers, selected, availablecheck);
            if (rinvoker != null) {
                // 如果 rinvoker 不为空，则将其赋值给 invoker
                invoker = rinvoker;
            } else {
                // rinvoker 为空，定位 invoker 在 invokers 中的位置
                int index = invokers.indexOf(invoker);
                try {
                    // 获取 index + 1 位置处的 Invoker，以下代码等价于：
                    //     invoker = invokers.get((index + 1) % invokers.size());
                    invoker = index < invokers.size() - 1 ? invokers.get(index + 1) : invokers.get(0);
                } catch (Exception e) {
                    logger.warn("... may because invokers list dynamic change, ignore.");
                }
            }
        } catch (Throwable t) {
            logger.error("cluster reselect fail reason is : ...");
        }
    }
    return invoker;
}
  • reselect()

reselect 方法总结下来其实只做了两件事情：

  1. 查找可用的 Invoker，并将其添加到 reselectInvokers 集合中。
  2. 如果 reselectInvokers 不为空，则通过负载均衡组件再次进行选择。

其中第一件事情又可进行细分，一开始，reselect 从 invokers 列表中查找有效可用的 Invoker，若未能找到，此时再到 selected 列表中继续查找。

​
private Invoker<T> reselect(LoadBalance loadbalance, Invocation invocation,
    List<Invoker<T>> invokers, List<Invoker<T>> selected, boolean availablecheck) throws RpcException {
 
    List<Invoker<T>> reselectInvokers = new ArrayList<Invoker<T>>(invokers.size() > 1 ? (invokers.size() - 1) : invokers.size());
 
    // 下面的 if-else 分支逻辑有些冗余，pull request #2826 对这段代码进行了简化，可以参考一下
    // 根据 availablecheck 进行不同的处理
    if (availablecheck) {
        // 遍历 invokers 列表
        for (Invoker<T> invoker : invokers) {
            // 检测可用性
            if (invoker.isAvailable()) {
                // 如果 selected 列表不包含当前 invoker，则将其添加到 reselectInvokers 中
                if (selected == null || !selected.contains(invoker)) {
                    reselectInvokers.add(invoker);
                }
            }
        }
         
        // reselectInvokers 不为空，此时通过负载均衡组件进行选择
        if (!reselectInvokers.isEmpty()) {
            return loadbalance.select(reselectInvokers, getUrl(), invocation);
        }
 
    // 不检查 Invoker 可用性
    } else {
        for (Invoker<T> invoker : invokers) {
            // 如果 selected 列表不包含当前 invoker，则将其添加到 reselectInvokers 中
            if (selected == null || !selected.contains(invoker)) {
                reselectInvokers.add(invoker);
            }
        }
        if (!reselectInvokers.isEmpty()) {
            // 通过负载均衡组件进行选择
            return loadbalance.select(reselectInvokers, getUrl(), invocation);
        }
    }
 
    {
        // 若线程走到此处，说明 reselectInvokers 集合为空，此时不会调用负载均衡组件进行筛选。
        // 这里从 selected 列表中查找可用的 Invoker，并将其添加到 reselectInvokers 集合中
        if (selected != null) {
            for (Invoker<T> invoker : selected) {
                if ((invoker.isAvailable())
                        && !reselectInvokers.contains(invoker)) {
                    reselectInvokers.add(invoker);
                }
            }
        }
        if (!reselectInvokers.isEmpty()) {
            // 再次进行选择，并返回选择结果
            return loadbalance.select(reselectInvokers, getUrl(), invocation);
        }
    }
    return null;
}

​

2. FailbackClusterInvoker失败自动恢复

在调用失败后，返回一个空结果给服务提供者。并通过定时任务对失败的调用进行重传，适合执行消息通知等操作。

这个类主要由3个方法组成：

  1. doInvoker()：该方法负责初次的远程调用。若远程调用失败，则通过 addFailed 方法将调用信息存入到 failed 中，等待定时重试。
  2. addFailed()：在开始阶段会根据 retryFuture 为空与否，来决定是否开启定时任务。
  3. retryFailed()：包含了失败重试的逻辑，该方法会对 failed 进行遍历，然后依次对 Invoker 进行调用。调用成功则将 Invoker 从 failed 中移除，调用失败则忽略失败原因。
public class FailbackClusterInvoker<T> extends AbstractClusterInvoker<T> {
 
    private static final long RETRY_FAILED_PERIOD = 5 * 1000;
 
    private final ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(2,
            new NamedInternalThreadFactory("failback-cluster-timer", true));
 
    private final ConcurrentMap<Invocation, AbstractClusterInvoker<?>> failed = new ConcurrentHashMap<Invocation, AbstractClusterInvoker<?>>();
    private volatile ScheduledFuture<?> retryFuture;
 
    @Override
    protected Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        try {
            checkInvokers(invokers, invocation);
            // 选择 Invoker
            Invoker<T> invoker = select(loadbalance, invocation, invokers, null);
            // 进行调用
            return invoker.invoke(invocation);
        } catch (Throwable e) {
            // 如果调用过程中发生异常，此时仅打印错误日志，不抛出异常
            logger.error("Failback to invoke method ...");
             
            // 记录调用信息
            addFailed(invocation, this);
            // 返回一个空结果给服务消费者
            return new RpcResult();
        }
    }
 
    private void addFailed(Invocation invocation, AbstractClusterInvoker<?> router) {
        if (retryFuture == null) {
            synchronized (this) {
                if (retryFuture == null) {
                    // 创建定时任务，每隔5秒执行一次
                    retryFuture = scheduledExecutorService.scheduleWithFixedDelay(new Runnable() {
 
                        @Override
                        public void run() {
                            try {
                                // 对失败的调用进行重试
                                retryFailed();
                            } catch (Throwable t) {
                                // 如果发生异常，仅打印异常日志，不抛出
                                logger.error("Unexpected error occur at collect statistic", t);
                            }
                        }
                    }, RETRY_FAILED_PERIOD, RETRY_FAILED_PERIOD, TimeUnit.MILLISECONDS);
                }
            }
        }
         
        // 添加 invocation 和 invoker 到 failed 中
        failed.put(invocation, router);
    }
 
    void retryFailed() {
        if (failed.size() == 0) {
            return;
        }
         
        // 遍历 failed，对失败的调用进行重试
        for (Map.Entry<Invocation, AbstractClusterInvoker<?>> entry : new HashMap<Invocation, AbstractClusterInvoker<?>>(failed).entrySet()) {
            Invocation invocation = entry.getKey();
            Invoker<?> invoker = entry.getValue();
            try {
                // 再次进行调用
                invoker.invoke(invocation);
                // 调用成功后，从 failed 中移除 invoker
                failed.remove(invocation);
            } catch (Throwable e) {
                // 仅打印异常，不抛出
                logger.error("Failed retry to invoke method ...");
            }
        }
    }
}

3. FailfastClusterInvoker快速失败

只会进行一次调用，失败后立即抛出异常。适用于幂等操作，比如新增记录。

  1. doinvoke()
  2. 通过 select 方法选择 Invoker，然后进行远程调用。如果调用失败，则立即抛出异常。
public class FailfastClusterInvoker<T> extends AbstractClusterInvoker<T> {
 
    @Override
    public Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        checkInvokers(invokers, invocation);
        // 选择 Invoker
        Invoker<T> invoker = select(loadbalance, invocation, invokers, null);
        try {
            // 调用 Invoker
            return invoker.invoke(invocation);
        } catch (Throwable e) {
            if (e instanceof RpcException && ((RpcException) e).isBiz()) {
                // 抛出异常
                throw (RpcException) e;
            }
            // 抛出异常
            throw new RpcException(..., "Failfast invoke providers ...");
        }
    }
}

4. FailsafeClusterInvoker失败安全

是一种失败安全的 Cluster Invoker。所谓的失败安全是指，当调用过程中出现异常时，FailsafeClusterInvoker 仅会打印异常，而不会抛出异常。适用于写入审计日志等操作。

public class FailsafeClusterInvoker<T> extends AbstractClusterInvoker<T> {
 
    @Override
    public Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        try {
            checkInvokers(invokers, invocation);
            // 选择 Invoker
            Invoker<T> invoker = select(loadbalance, invocation, invokers, null);
            // 进行远程调用
            return invoker.invoke(invocation);
        } catch (Throwable e) {
            // 打印错误日志，但不抛出
            logger.error("Failsafe ignore exception: " + e.getMessage(), e);
            // 返回空结果忽略错误
            return new RpcResult();
        }
    }
}

5. ForkingClusterInvoker并行调用多个提供者

在运行时通过线程池创建多个线程，并发调用多个服务提供者。只要有一个服务提供者成功返回了结果，doInvoke 方法就会立即结束运行。ForkingClusterInvoker 的应用场景是在一些对实时性要求比较高读操作（注意是读操作，并行写操作可能不安全）下使用，但这将会耗费更多的资源。

  1. 从方法开始到分割线1之间的代码主要是用于选出 forks 个 Invoker，为接下来的并发调用提供输入。
  2. 分割线1和分割线2之间的逻辑通过线程池并发调用多个 Invoker，并将结果存储在阻塞队列中。
  3. 分割线2到方法结尾之间的逻辑主要用于从阻塞队列中获取返回结果，并对返回结果类型进行判断。如果为异常类型，则直接抛出，否则返回。
public class ForkingClusterInvoker<T> extends AbstractClusterInvoker<T> {
     
    private final ExecutorService executor = Executors.newCachedThreadPool(
            new NamedInternalThreadFactory("forking-cluster-timer", true));
 
    @Override
    public Result doInvoke(final Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        try {
            checkInvokers(invokers, invocation);
            final List<Invoker<T>> selected;
            // 获取 forks 配置
            final int forks = getUrl().getParameter(Constants.FORKS_KEY, Constants.DEFAULT_FORKS);
            // 获取超时配置
            final int timeout = getUrl().getParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);
            // 如果 forks 配置不合理，则直接将 invokers 赋值给 selected
            if (forks <= 0 || forks >= invokers.size()) {
                selected = invokers;
            } else {
                selected = new ArrayList<Invoker<T>>();
                // 循环选出 forks 个 Invoker，并添加到 selected 中
                for (int i = 0; i < forks; i++) {
                    // 选择 Invoker
                    Invoker<T> invoker = select(loadbalance, invocation, invokers, selected);
                    if (!selected.contains(invoker)) {
                        selected.add(invoker);
                    }
                }
            }
             
            // ----------------------✨ 分割线1 ✨---------------------- //
             
            RpcContext.getContext().setInvokers((List) selected);
            final AtomicInteger count = new AtomicInteger();
            final BlockingQueue<Object> ref = new LinkedBlockingQueue<Object>();
            // 遍历 selected 列表
            for (final Invoker<T> invoker : selected) {
                // 为每个 Invoker 创建一个执行线程
                executor.execute(new Runnable() {
                    @Override
                    public void run() {
                        try {
                            // 进行远程调用
                            Result result = invoker.invoke(invocation);
                            // 将结果存到阻塞队列中
                            ref.offer(result);
                        } catch (Throwable e) {
                            int value = count.incrementAndGet();
                            // 仅在 value 大于等于 selected.size() 时，才将异常对象
                            // 放入阻塞队列中，请大家思考一下为什么要这样做。
                            if (value >= selected.size()) {
                                // 将异常对象存入到阻塞队列中
                                ref.offer(e);
                            }
                        }
                    }
                });
            }
             
            // ----------------------✨ 分割线2 ✨---------------------- //
             
            try {
                // 从阻塞队列中取出远程调用结果
                Object ret = ref.poll(timeout, TimeUnit.MILLISECONDS);
                 
                // 如果结果类型为 Throwable，则抛出异常
                if (ret instanceof Throwable) {
                    Throwable e = (Throwable) ret;
                    throw new RpcException(..., "Failed to forking invoke provider ...");
                }
                 
                // 返回结果
                return (Result) ret;
            } catch (InterruptedException e) {
                throw new RpcException("Failed to forking invoke provider ...");
            }
        } finally {
            RpcContext.getContext().clearAttachments();
        }
    }
}

为什么要在value >= selected.size()的情况下，才将异常对象添加到阻塞队列中？这里来解答一下。原因是这样的，在并行调用多个服务提供者的情况下，只要有一个服务提供者能够成功返回结果，而其他全部失败。此时 ForkingClusterInvoker 仍应该返回成功的结果，而非抛出异常。在value >= selected.size()时将异常对象放入阻塞队列中，可以保证异常对象不会出现在正常结果的前面，这样可从阻塞队列中优先取出正常的结果。

6. BroadcastClusterInvoker

会逐个调用每个服务提供者，如果其中一台报错，在循环调用结束后，BroadcastClusterInvoker 会抛出异常。该类通常用于通知所有提供者更新缓存或日志等本地资源信息。

public class BroadcastClusterInvoker<T> extends AbstractClusterInvoker<T> {
 
    @Override
    public Result doInvoke(final Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
        checkInvokers(invokers, invocation);
        RpcContext.getContext().setInvokers((List) invokers);
        RpcException exception = null;
        Result result = null;
        // 遍历 Invoker 列表，逐个调用
        for (Invoker<T> invoker : invokers) {
            try {
                // 进行远程调用
                result = invoker.invoke(invocation);
            } catch (RpcException e) {
                exception = e;
                logger.warn(e.getMessage(), e);
            } catch (Throwable e) {
                exception = new RpcException(e.getMessage(), e);
                logger.warn(e.getMessage(), e);
            }
        }
         
        // exception 不为空，则抛出异常
        if (exception != null) {
            throw exception;
        }
        return result;
    }
}

 

liyanan21
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Cluster代理机制
sam475259540的博客
06-17 88
开启Cluster ./create-cluster start 开启redis ./create-cluster create 分配槽位，和主从配置，也可以通过redis-cli --cluster create分配具体的IP地址实现分布式的主从配置 redis-cli --cluster reshard 可以进行重新分片，槽位不能进行精准的分配 redis-cli -c -p 端口号，进入代理模式的redis 可以进行事务，但只可以在一个redis中进行 ...
14. Dubbo原理解析-集群&容错之Cluster
热门推荐
斩秋的专栏
12-03 1万+
Dubbo作为一个分布式的服务治理框架，提供了集群部署，路由，软负载均衡及容错机制   下图描述了dubbo调用过程中的对于集群，负载等的调用关系。   Cluster 将Directory中的多个Invoker伪装成一个Invoker, 对上层透明，包含集群的容错机制 Cluster接口定义 @SPI(FailoverCluster.NAME) public interf
Dubbo 源码分析 – 集群容错之 Cluster
二师兄撒欢之地
02-10 560
为了避免单点故障，现在的应用至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多台服务器。这样，同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及及 Cluster Invoker。
Dubbo——集群(Cluster)容错原理
庄小焱
04-09 929
摘要 Dubbo 框架中的分层代表了不同的逻辑实现，它们是一个个组件，这些组件构成了整个Dubbo体系，在使用方角度更多接触到的可能是配置，更多底层构件被抽象和隐藏了，同时提供了非常高的扩展性。Dubbo框架之所以能够做到高扩展性,受益于各个组件职责分明的设计，每个组件提供灵活的扩展点，如表1-2所示。 因此我们先介绍一下服务的暴露过程。 首先，服务器端（服务提供者〉在框架启动时，会初始化服务实例，通过Proxy组件调用具体协议（ Protocol )，把服务端要暴露的接口封装成Invoker（真
Unity GI 光照系统系列(四) —— Cluster图集
韩小白的博客
08-14 770
Cluster 修改集群是一种更细致的方法。它允许我们在Unity的光照与计算过程中减少任务量，而且运行时性能也能得到改善。 当用PRGI生成场景的光照解决方案时，Unity简化了关于静态场景的体素化结构的计算。这些体素被叫做集群。集群是映射到用于光照的静态几何物体表面上的小贴片。集群被存储在一种层级关系的结构中，用来预处理漫反射全局光照的复杂的辐射度计算。注意虽然集群和光照图表的映射方式很像...
cluster_02
03-21
"cluster_02"可能代表集群项目的第二阶段，可能涉及到更深入的配置、优化或测试工作，如增加节点、测试故障恢复机制、负载均衡策略调整等。 7. **文件列表**："cluster_02"是唯一的文件名，可能是项目文档、配置...
7Cluster集群.zip
10-10
在7Cluster集群中，NFS被用作跨节点的文件共享机制，确保数据在集群内的无缝同步和访问。 4. **multipath** multipath工具为Linux提供多路径I/O功能，它能够检测和利用多个物理路径到同一存储设备，从而提高I/O...
scm_blk_cluster.rar_cluster
09-23
总的来说，"scm_blk_cluster.rar_cluster"涉及的是一项在s390架构上为SCM设计的集群块驱动技术，这项技术旨在提供高效、稳定且容错的存储解决方案，适用于大规模分布式应用和高可用性系统。通过深入理解这一领域的...
cluster
03-19
2. **Dubbo**：阿里巴巴开源的高性能RPC框架，支持服务治理、集群容错、负载均衡等功能，适合构建大规模分布式服务。 **四、Java缓存集群** 1. **Hazelcast**：Hazelcast是一个开源的内存数据网格，可以作为分布式...
mysqlcluster白皮书
03-13
MySQL Cluster通过多副本机制实现了故障检测和自动恢复。当一个节点出现故障时，集群会自动将该节点上的工作负载转移到其他活动节点，确保服务不中断。此外，如果主副本失败，系统会自动提升备用副本为新的主副本。 ...
cluster序列分析
08-31
用于多重序列比对 clustalx1.83
dubbo集群容错 参数详细说明
weixin_44647371的博客
02-27 1153
集群容错-属性说明 @Reference(cluster =“failover”) tip：默认retries=2，重试2次，即总共发起3次请求 实测结果如下 failover 默认值，失败后可切换集群里其他机器进行重试，重试次数和retries有关 failfast 失败后会报错 ，不重试 failsafe 失败不报错,返回null,不重试 failback 失败返回null，且每隔7s会将失败的那个请求进行重试 (重试次数和retries有关，但至少有4次[即retries在0-3范围都是
Dubbo架构篇 - 集群容错
The Secret
08-11 792
本文解析Dubbo的集群容错。
Dubb源码学习--FailoverCluster集群容错（六）
井底之蛙
03-27 1767
Failover Cluster失败自动切换，当出现失败，重试其它服务器 1。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。重试次数配置如下：&lt;dubbo:service retries="2" /&gt; 或&lt;dubbo:reference retries="2" /&gt; 或&lt;dubbo:reference&gt; ..
Dubbo 的集群容错模式：Failover Cluster
m0_37941483的博客
09-07 661
本文简单介绍 Dubbo 中的 Failover Cluster（失败自动切换）。 1.简介 调用实例失败后，继续调用其他实例。假如有 3 个实例：A, B, C，当调用 A 失败后，再调用 B，如果还是失败，则调用 C。 2.如何使用 <dubbo:service cluster="failover" retries="2"/> 或 <dubbo:reference clu...
Dubbo面试杀招--Dubbo集群容错负载均衡
敖丙
09-24 9208
dubbo系列终章
集群分析法(Cluster Analysis)
zdhsnail的专栏
02-21 1万+
一、何谓集群分析法众多的多变量分析方法中，集群分析法(cluster analysis)是比较简单的一种，统计学家通常应用集群分析法来对数据做简化的工作及分类，也就是把相似的个体(观测物)归于一群。然而相似的标准为何、多相似才能归为一群，则是我们需要探讨的问题。集群分析分析出来的结果若没有信息(information)，则结果究竟适不适合，也是一大考验，因此分析时的"目标"非常重要，在分析进行中各
dubbo源码分析系列——dubbo-cluster模块源码分析
weixin_33971205的博客
06-12 140
2019独角兽企业重金招聘Python工程师标准>>> ...
redis cluster 集群 容错机制
最新发布
05-27
Redis Cluster 集群具有以下容错机制： 1. 数据自动分片和备份：Redis Cluster 将数据分散到多个节点上，并在多个节点之间进行数据备份，以避免因单个节点故障而导致数据丢失。 2. 节点自动发现和重新分配：当一个节点离线时，Redis Cluster 会自动检测到该节点的离线状态，并将数据重新分配到其他在线节点上，以保证数据的可用性。 3. 集群管理节点：Redis Cluster 还提供了集群管理节点，可以用于监控集群运行状态、管理节点、进行故障转移等操作，提高集群的可靠性。 4. 多节点共享：Redis Cluster 允许多个节点共享数据，以提高集群的性能和可扩展性。这意味着即使一个节点故障，其他节点仍然可以继续提供服务，保证集群的可用性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值