08 | 服务发现：到底是要CP还是AP？

记得之前在京东的时候，服务挂了，在注册中心上还得要手动删除下死亡节点，如果zk的话，服务没了，就代表会话也没了，临时节点的特性，应该会被通知到呀？为什么还要手动删除呢

如果要能切换流量，那么要服务端配置有权重负载均衡策略，这样服务器端可以通过调整权重来安排流量

消息总栈类似一个队列，队列表示是递增的数字，注册中心集群的任何一个节点接收到注册请求，都会把服务提供者信息发给消息总栈，消息总栈会像队列以先进先出的原则推送消息给所有注册中心集群节点，集群节点接收到消息后会比较自己内存中的当前版本，保存版本大的，这种方式有很强的实效性，注册中心集群也可以从消息总栈拉取消息，确保数据AP，个人理解这是为了防止消息未接收到导致个别节点数据不准确，因为服务提供者可以向任意一个节点发送注册请求，从而降低了单个注册中心的压力，而注册和注册中心同步是异步的，也解决了集中注册的压力，在Zookeeper中，因为Zookeeper注册集群的强一致性，导致必须所有节点执行完一次同步，才能执行新的同步，这样导致注册处理性能降低，从而高I/O操作宕机。 以上是我的个人理解，老师给看一下是否正确。 还有一个问题：当集中注册时，消息总栈下发通知给注册中心集群节点，对于单个节点也会不停的收到更新通知，这里也存在高I/O问题，会不会有宕机？

服务消费者都是从注册中心拉取服务提供者的地址信息，所以我们要切走某些服务提供者数据，只需要将注册中心这些实例的地址信息删除（其实下线应用实例，实际也是去删除注册中心地址信息），然后注册中心反向通知消费者，消费者受到拉取最新提供者地址信息就没有这些实例了。 老师，提问一个问题：现有开源注册中心是不是还没有消息总线这种实现方式？消息总线有没有开源实现？

路由负载

老师，在AP实现中“两级缓存，注册中心和消费者的内存缓存，通过异步推拉模式来确保最终一致性”能展开讲一下具体实现吗？另外请教下CP可以基于zk实现，AP在业内的实现方式有哪些呢？

消息总线策略是啥，老师能指点下么，怎么保证消息总线全局版本递增

小结一下 1：注册中心的核心作用？ 完成服务消费者和服务调用者，两者的路径匹配 2：注册中心的核心指标？ 高效、稳定、高可用，使服务消费者及时感知节点的变化 3：路径匹配需要的信息？ 服务提供者IP、端口、接口、方法＋服务分组别名 服务消费者IP、端口 路径匹配可以把分组别名利用上，即使提供者实例上线，不过由于设置的别名和服务消费者需要的不一致流量也不会打过去，什么时候打过去可以通过配置中心来自由的控制。分组内也是有多个服务提供者的，这里可以再利用相关的负载均衡策略来具体分发流量。

zookeeper注册中心实现原理 1. 服务平台向zookeeper创建服务目录 2. 服务提供者向zookeeper创建临时节点 3. 服务调用者订阅zookeeper，创建临时节点，拉取服务全量数据，watch服务全部节点数据 4. zookeeper节点发生变化会通知服务调用者 切掉服务流量，只需要将注册中心的配置节点下掉就好了

稍微做点压测作为参考，我说的未必是对的，zookeeper写要是zab协议的， 提交要大多数成功才能提交，所以越多节点效率可能越慢，