82_Bus动态刷新定点通知

好，同学们，请再坚持一下，陪杨哥加加班哈，我也知道现在呢，大家已经是饥肠辘辘，我也是啊，那么完成我们最后一个知识点动态刷新的定点通知哦。OK，那么好，同学们通过上一讲我们已经明白了，只要我们配置完成，结合我们的rabbit MQ和bus消息总线。Github上面的总配置改了，然后发一个post去刷一下我们的3344，这样是不是我们的33553366并不需要微服务重启，立刻就能够同步获得最新的消息和内容以及变更配置信息啊好，那么上一讲我们成功的完成了我们自动版的动态刷新全局广播通知，但是下面我们有一种情况是。我只想通知其中的一个。不想通知全部，那么这一波广广播下来，我们该通知的通知啊，不该通知的不让它生效的，不变更，那么这样是不是要形成一种差异化的处理啊，那么好，说穿了就是精确打击，定点清除好。

那么兄弟们look。来吧。不想全部通知二，只想定点通知二。假设我们现在只想通知3355，不想通知3366。换句话说，全局的广播通知我十个人，我只通知你们九个，一次性批处理九个人更新第十个人，我不想通知你，你就收不到我的广播，那么这样就是该通知的通知，不该通知的不受影响，那简单一句话，就是指定某一个具体实例生效，而不是全部，那么公式就是我们的3344啊，当然这个3344我这儿写死了哈，代表呃，这个我们的配置中心的端口号。嗯，应该这么说吧，省得同学们粘错了，应该是我们的这个未来的这个配置。

中心的。端口号，然后act bus refresh destination，这个destination就是目的地的意思。那么。也就是说，现在这个bus refresh请求不再发送到具体的服务实例上面。而是发给。Server，并通过destination参数指定需要变更的，那么我们这儿就是更多的是要发给具体被精确通知的，好，那么同学们。来看一下我们的案例。这里我们以刷新运行在3355端口上的conflict client为例，我们只想通知3355，不想通知3366。听懂好，那么下面同学们我们再试一把，那么现在呢？我们继续修改。我们修改完了以后呢，从六变成了七。那么完火以后看me。好，那么同学们根据我们的处理，只要是github上面修改配置消息变更了，我们接下来的一步，按照以前是不是要去刷我们的3344总控配置中心，但是现在我们呢，定点清除，我们只想通知3355这一波同学们能跟上，好，那么同学们我们直接一直行。

看啊，上面这个是全局通知啊，下面这个是3344还是配置中心，但是我的这个是只通知了我们的3355。好，那么这个时候请同学们看一下啊，回到我们的3355，大家请看这是不是有个东西叫config client，大家请看这个时候叫conflict client冒号3355，说白了是不是就是我们的目的地，就是我们微服沃加。端口号啊好，那接下来那么同学们请看一下我们的演示效果，那么。

这个时候getub是七，那么我们的3344，呃，倒是好说，因为它永远是跟着getu，只要你改了，我自己刷新一下，应该会变成七这波OK吧，那么注意我们这3355和3366现在还没刷，之前两个都是六，OK，那么现在我刷一下3355。多少变成了七跟着动了，那么我再刷一下我们的3366，大家请看，还是六，还是上一版的数据并没有。变动和更新达到了我们定点清除精确通知的效果，这么说能理解了吧？这个倒是应该好理解，Destination说穿了就是我们的微服务的名称加冒号加3355。再次强调，我说过多次，最好一定要写微服务的spring application name和我们的端口号，你看这样是不是名字才危机，你就告诉我，我动谁不动谁听懂，我们现在是只通知3355，不通知3366，那么3355变为了七。

3366依旧是上一版的数据六，那么这样的话呢，完成了我们的精确通知二，那么最终我们的通知总结就是这张图，那么加晚上的家庭作业要求同学们回顾我今天的全部讲解内容，按照这张图，按照上面的步骤给我一步一步的写出你们的总结，这个就是今天的家庭作业。好，那么同学们，我们对于我们的动态刷新的定点通知就给大家介绍到这儿。