爱吃知识的土豆倪的博客

时间轮这个技术其实出来很久了，在kafka、zookeeper等技术中都有时间轮使用的方式。什么是时间轮呢？简单来说：时间轮是一种高效利用线程资源进行批量化调度的一种调度模型。把大批量的调度任务全部绑定到同一个调度器上，使用这一个调度器来进行所有任务的管理、触发、以及运行。所以时间轮的模型能够高效管理各种延时任务、周期任务、通知任务。在工作中遇到类似的功能，可以采用时间轮机制。

拦截器链的组成是：ConsumerContextClusterInterceptor -> ZoneAwareClusterInvoker。在调用服务接口之前，ConsumerContextClusterInterceptor会负责设置上下文信息，以确保上下文在整个调用链中可用。然后，调用interceptor.intercept方法来进行拦截处理。这个方法会依次调用拦截器链中的每个拦截器的intercept方法。通过拦截器链的处理，可以在调用服务接口前后进行一些额外的操作，如参数校验、日志记录等。

因此 Cluster.join，实际上是获得一个Invoker对象，这个Invoker实现了Directory的包装，并且配置了拦截器。至于它是干嘛的，我们后续再分析。......});= 0) {});//通过listener监听categoryList// 前面的监听主要是根据urls进行的，下面的监听就相当于根据 具体的url进行的。// 将注册中心的地址保存在本地缓存//保存到本地文件中，作为服务地址的缓存信息。

👏作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，很高兴认识大家📕系列专栏：Spring源码、JUC源码、Kafka原理、分布式技术原理🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦🍂博主正在努力完成2023计划中：源码溯源，一探究竟📝联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬👀文章目录Dubbo服务的注册流程服务发布步骤思考Dubbo源码分析Dubbo注解的解析流程DubboComponetScanServiceAn

在resource/META-INF/dubbo/ org.apache.dubbo.rpc.cluster.LoadBalance（文件名为 包的全路径 + 接口名）里面的内容填写 gploadbalance = com.gupaodu.springboot.dubbo.springbootdubbosampleprovider.GpDefineLoadBalance （是扩展的全路径）// 扩展了dubbo中的负载均衡@Override加载指定路径下的文件内容，保存到集合中。

而协议中有个很关键的类叫做 DubboProtocol ，在这里是可以去扩展的，Protocol是一个扩展点，我们在使用的时候在这个扩展点用什么协议取决于 RegistryDirectory 列表中url 中的协议，该url会一直沿着链路传递，直到Protocol来选择要使用的协议，然后进行转发。对于一个技术的使用来说，使用的多了以后会更加的熟练，但是使用的过程中如果出现了问题，能不能快速的定位到问题，其次就是在用这个技术的时候，能不能去了解其底层是怎么实现的。

那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B 会收到其中的2次请求，服务器 C 则收到其中的1次请求。在Dubbo的整个架构图里面，服务注册是里面很核心的一个环节，服务提供者可以有多个注册进来，那么服务消费者处就会拿到多个地址，那么这个情况喜爱，consumer通过invoke去调用的时候，应该调用哪个地址呢？这是这里面必然要考虑的问题。比如说项目中存在服务依赖的情况，如果开启了检查，那么注定会启动失败，可以先关闭检查，然后就可以启动成功，等到都注册到注册中心了，就可以去使用了。

在spring-boot-dubbo-sample-api模块中，定义接口。

所谓冷启动，就是我们的系统在启动的时候长期处于低水位（整个系统的吞吐量非常低，并发量很低），当突然出现这种瞬时流量，系统有一个启动的过程，并不是一下子将所有的流量都放进来，而是逐步的拉伸整个系统的水位直到通过一个时间维度达到最高峰的阈值。基于参数的流量控制是指根据调用方传递的参数来进行流量控制。在这里的配置会出现一个问题，就是修改 sentinel 控制台配置，和nacos上的配置不一致，这样的话最简单的就是修改sentinel的源码，当sentinel控制台变化的时候，动态去修改nacos上的配置即可。

当我们的客户端，用户量的访问大了之后，对于后端系统的并发量会更高，并发量越高对于后端整个处理的能力就是一个挑战，因为我们需要保证，用户从10个到10000个的时候，我们需要提供给用户的是 它的响应时间不能超过多少。上图存在很多相互调用的情况，里面存在很多服务调用的链路，当Service D出现故障，会导致G F阻塞，间接的又会导致A B阻塞，如果特别多的请求阻塞在这里之后，会占用特别多的资源，内存、服务器、cpu的资源，这时候会导致服务器因为大量的资源被占用而导致其他问题。

在分析问题的时候，我们所学的事件的机制、异步化、基于线程的生产者消费者模型，其实它可以在刚刚的场景中去使用，比如我们发起这个请求，他可以将其放置在队列中，通过线程去和对应的接口做远程通信，这时我们可以解决我们这端的并发量的问题，他们第三方在不改变的情况下，我们这端某种程度上提升了一定的吞吐量，然后基于事件的机制就是我们调用第三方接口给返回的时候，基于这个返回结果发送一个通知去告诉调用者结果处理完了，你去拿这个结果做后续的处理。当客户端接收到Watcher通知后，它会根据通知消息中的信息进行相应的处理。

在讲顺序一致性之前，咱们思考一个问题，假如说zookeeper是一个最终一致性模型，那么他会发生什么情况ClientA/B/C假设只串行执行， clientA更新zookeeper上的一个值x。ClientB和clientC分别读取集群的不同副本，返回的x的值是不一样的。clientC的读取操作是发生在clientB之后，但是却读到了过期的值。很明显，这是一种弱一致模型。如果用它来实现锁机制是有问题的。

比如说用户服务有个线程去监控，不可能是不断的轮询，没什么意义，那么发现没办法抢占就先阻塞，也就是抢占失败，当前一个节点被删除了之后，会有一个watcher通知，那么就会去唤醒，那么会再次调用这个逻辑，判断是不是最小的，如果是就抢占到了。这样的话，我们每个节点只需要监听上一个顺序的变化即可，如果我们发现了一个节点删除了，然后去判断自己是不是序号最好的就ok，如果是最小的，那就发起获取锁的动作，如果不是就等着。如果处理完了，其他节点监听这个，当成功的那个节点删除了之后，回调通知再次获得锁即可。

处理客户端的请求（提升集群性能）这样设计到扩容，但是并不是节点越多性能越好，因为涉及到了数据同步，这里面有一个思想叫做 过半提交 ，比如当发起一个操作的时候，整个集群中至少要有过半的节点认为这是成功的，才会成功返回给后端，也就会导致follower会参与到这个过程中来。学到这里，其实技术是存在一个取舍的，但是功能是可以实现的，甚至用数据库来实现其实都可以，无非就是一个统一的存储，然后做个监听数据的变化，那么我们可以监听数据库的变化呀，去触发一些动作也没什么问题，只不过就是会复杂一些，可行性是有的。