基于consul实现redis以及mysql的高可用架构

基于Consul的数据库高可用架构

      几个月没有更新博客了，已经长草了，特意来除草。本次主要分享如何利用consul来实现redis以及mysql的高可用。以前的公司mysql是单机单实例，高可用MHA加vip就能搞定，新公司mysql是单机多实例，那么显然这个方案不适用，后来也实现了故障切换调用dns api来修改域名记录，但是还是没有利用consul来实现高可用方便，后面会说明优势。redis单机多实例最正常不过了，那么redis单机多实例高可用也不太好做，当然也可以利用sentinel来实现，当failover以后调用脚本调用dns api修改域名解析也是可以的。也不是那么的优雅，有人会说怎么不用codis，redis cluster，这些方案固然好，但不适合我们，这些方案不够灵活，不能很好的处理热点数据的问题。那么consul是什么呢，接下慢慢说：

consul是HashiCorp公司（曾经开发过vgrant） 推出的一款开源工具， 基于go语言开发， 轻量级， 用于实现分布式系统的服务发现与配置。 与其他类似产品相比， 提供更“一站式”的解决方案。 consul内置有KV存储， 服务注册/发现， 健康检查， HTTP+DNS API， Web UI等多种功能。官网： https://www.consul.io/其他同类服务发现与配置的主流开源产品有:zookeeper和ETCD。

consul的优势：

1. 支持多数据中心， 内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障, zookeeper和 etcd 均不提供多数据中心功能的支持

2. 支持健康检查. etcd 不提供此功能.

3. 支持 http 和 dns 协议接口. zookeeper 的集成较为复杂,etcd 只支持 http 协议. 有DNS功能， 支持REST API

4. 官方提供web管理界面, etcd 无此功能.

5. 部署简单， 运维友好， 无依赖， go的二进制程序copy过来就能用了， 一个程序搞定， 可以结合ansible来推送。

Consul和其他服务发现工具的对比表：

 Consul 架构和角色

1. Consul Cluster由部署和运行了Consul Agent的节点组成。 在Cluster中有两种角色:Server和 Client。
2. Server和Client的角色和Consul Cluster上运行的应用服务无关, 是基于Consul层面的一种角色划分.
3. Consul Server: 用于维护Consul Cluster的状态信息， 实现数据一致性， 响应RPC请求。官方建议是: 至少要运行3个或者3个以上的Consul Server。 多个server之中需要选举一个leader, 这个选举过程Consul基于Raft协议实现. 多个Server节点上的Consul数据信息保持强一致性。 在局域网内与本地客户端通讯，通过广域网与其他数据中心通讯。Consul Client: 只维护自身的状态, 并将HTTP和DNS接口请求转发给服务端。
4. Consul 支持多数据中心， 多个数据中心要求每个数据中心都要安装一组Consul cluster，多个数据中心间基于gossip protocol协议来通讯， 使用Raft算法实现一致性

基础知识就介绍这么多了，更加详细的可以参考官网。下面我们来搭建一下consul，以及如何利用consul实现redis以及mysql的高可用。