mysql 服务发现_如何实现一个简单的服务发现框架？

zookeeper是一个强一致(不严格)的分布式数据库，由多个节点共同组成一个分布式集群，挂掉任意一个节点，数据库仍然可以正常工作，客户端无感知故障切换。客户端向任意一个节点写入数据，其它节点可以立即看到最新的数据。

zookeeper的内部是一个key/value存储引擎，key是以树状的形式构成了一个多级的层次结构，每一个节点既可以存储数据，又可以作为一个目录存放下一级子节点。

zookeeper提供了创建／修改／删除节点的api，如果父节点没有创建，字节点会创建失败。如果父节点还有子节点，父节点不可以被删除。

zookeeper和客户端之间以socket形式进行双向通讯，客户端可以主动调用服务器提供的api，服务器可以主动向客户端推送事件。有多种事件可以watch，比如节点的增删改，子节点的增删改，会话状态变更等。

zookeeper的事件有传递机制，字节点的增删改触发的事件会向上层依次传播，所有的父节点都可以收到字节点的数据变更事件，所以层次太深／子节点太多会给服务器的事件系统带来压力，节点分配要做好周密的规划。

zookeeper满足了CAP定理的分区容忍性P和强一致性C，牺牲了高性能A。zookeeper的存储能力是有限的，当节点层次太深／子节点太多／节点数据太大，都会影响数据库的稳定性。所以zookeeper不是一个用来做高并发高性能的数据库，zookeeper一般只用来存储配置信息。

zookeeper的读性能随着节点数量的提升能不断增加，但是写性能会随着节点数量的增加而降低，所以节点的数量不宜太多，一般配置成3个或者5个就可以了。

图中可以看出当服务器节点增多时，复杂度会随之提升。因为每个节点和其它节点之间要进行p2p的连接。3个节点可以容忍挂掉1个节点，5个节点可以容忍挂掉2个节点。

客户端连接zookeeper时会选择任意一个节点保持长链接，后续通信都是通过这个节点进行读写的。如果该节点挂了，客户端会尝试去连接其它节点。

服务器会为每个客户端连接维持一个会话对象，会话的ID会保存在客户端。会话对象也是分布式的，意味着当一个节点挂掉了，客户端使用原有的会话ID去连接其它节点，服务器维持的会话对象还继续存在，并不需要重新创建一个新的会话。

如果客户端主动发送会话关闭消息，服务器的会话对象会立即删除。如果客户端不小心奔溃了，没有发送关闭消息，服务器的会话对象还会继续存在一段时间。这个时间是会话的过期时间，在创建会话的时候客户端会提供这个参数，一般是10到30秒。

也许你会问连接断开了，服务器是可以感知到的，为什么需要客户端主动发送关闭消息呢？

因为服务器要考虑网络抖动的情况，连接可能只是临时断开了。为了避免这种情况下反复创建和销毁复杂的会话对象以及创建会话后要进行的一系列事件初始化操作，服务器会尽量延长会话的生存时间。

zookeeper的节点可以是持久化(Persistent)的，也可以是临时(Ephermeral)的。所谓临时的节点就是会话关闭后，会话期间创建的所有临时节点会立即消失。一般用于服务发现系统，将服务进程的生命期和zookeeper子节点的生命期绑定在一起，起到了实时监控服务进程的存活的效果。

zookeeper还提供了顺序节点。类似于mysql里面的auto_increment属性。服务器会在顺序节点名称后自动增加自增的唯一后缀，保持节点名称的唯一性和顺序性。

还有一种节点叫着保护(Protected)节点。这个节点非常特殊，但是也非常常用。在应用服务发现的场合时，客户端创建了一个临时节点后，服务器节点挂了，连接断开了，然后客户端去重连到其它的节点。因为会话没有关闭，之前创建的临时节点还存在，但是这个时候客户端却无法识别去这个临时节点是不是自己创建的，因为节点内部并不存储会话ID字段。所以客户端会在节点名称上加上一个GUID前缀，这个前缀会保存在客户端，这样它就可以在重连后识别出哪个临时节点是自己之前创建的了。

接下来我们使用Go语言实现一下服务发现的注册和发现功能。

如图所示，我们要提供api.user这样的服务，这个服务有3个节点，每个节点有不一样的服务地址，这3个节点各自将自己的服务注册进zk，然后消费者进行读取zk得到api.user的服务地址，任选一个节点地址进行服务调用。为了简单化，这里就没有提供权重参数了。在一个正式的服务发现里一般都有权重参数，用于调整服务节点之间的流量分配。钱文品：徒手教你使用zookeeper编写服务发现​zhuanlan.zhihu.com