利用Zookeeper技术 Mysql容灾切换
一、 ZooKeeper介绍
1. 简介
ZooKeeper 是一个为分布式应用所设计的分布的、开源的协调服务。分布式的应用可以建立在同步、配置管理、分组和命名等服务的更高级别的实现的基础之上。 ZooKeeper 意欲设计一个易于编程的环境，它的文件系统使用我们所熟悉的目录树结构。ZooKeeper使用Java所编写，但是支持Java和C两种编程语言。 2. ZooKeeper总体结构
3. ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为
Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。
4. Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当
所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
5. ZooKeeper使用了一种自定义的原子消息协议，在消息层的这种原子特性，保证了整
个协调系统中的节点数据或状态的一致性。Follower基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。 6. 当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择
一个Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步（广播）到其他的Follower节点。
Zookeeper逻辑图
7. ZooKeeper数据模型
Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个文件系统
Zookeeper 这种数据结构有如下这些特点：
? 每个子目录项如NameService都被称作为znode，这个znode是被它所在的路径唯一标
识，如 Server1 这个znode的标识为 /NameService/Server1
? znode可以有子节点目录，并且每个znode可以存储数据，注意 EPHEMERAL 类型的目
录节点不能有子节点目录
? znode是有版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径中
可以存储多份数据
? znode可以是临时节点，一旦创建这个znode的客户端与服务器失去联系，这个znode
也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果znode是临时节点，这个 session 失效，znode也就删除了 ? znode的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2 ? znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一
旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍
Zookeeper 数据结构
8. ZooKeeper特性
? 顺序一致性：按照客户端发送请求的顺序更新数据。 ? 原子性：更新要么成功，要么失败，不会出现部分更新。 ? 单一性 ：无论客户端连接哪个server，都会看到同一个视图。 ? 可靠性：一旦数据更新成功，将一直保持，直到新的更新。 ? 及时性：客户端会在一个确定的时间内得到最新的数据。
9. ZooKeeper应用场景
? 数据发布与订阅
应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。 ? 名空间服务
分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。 ? 分布式通知/协调
不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。 ? 分布式锁
Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。 ? 集群管理
每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会受到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。
二、 ZooKeeper应用：Mysql容灾切换
对于多数应用来说，MySQL都是作为最关键的数据存储中心的，所以，如何让MySQL提供HA服务，是我们不得不面对的一个问题。当master当机的时候，我们如何保证数据尽可能的不丢失，如何保证快速的获知master当机并进行相应的故障转移处理，都是需要我们好好思考的。
要保证MySQL数据不丢失，replication是一个很好的解决方案，而MySQL也提供了一套强大的replication机制。只是我们需要知道，为了性能考量，replication是采用的asynchronous模式，也就是写入的数据并不会同步更新到slave上面，如果这时候master当机，我们仍然可能会面临数据丢失的风险，我们不能等到master当了几分钟才知道出现问题了。所以一套好的监控工具是必不可少的。使用zookeeper来解决整个MySQL集群的monitor以及failover，它能很方便的对整个集群进行监控，并能即时的获取整个集群的变化信息并触发相应的事件通知感兴趣的服务，同时协调多个服务进行相关处理。
对于任何一个MySQL实例，我们都有一个对应的agent程序，agent跟该MySQL实例放到同一台机器上面，并且定时的对MySQL实例发送ping命令检测其可用性，同时该agent通过ephemeral的方式挂载到zookeeper上面。如果agent或者该agent代理的mysql宕掉，注册在zookeeper上的节点就会发生变化，利用zookeeper watch功能实现mysq实例失效后的主库的选举操作。 主要有以下几种情况：
? 机器当机，这样MySQL以及agent都会当掉，agent与zookeeper
连接自然断开
? MySQL当掉，agent发现ping不通，主动断开与zookeeper的连接 ? Agent当掉，但MySQL未当
相关推荐：
loading