手把手教你用docker搭建数据库中间件DBLE+zookeeper集群

最近因为公司项目需要，所以搭建了一个DBLE+zookeeper集群的框架。在此记录一下。

 

DBLE

简单介绍一下DBLE：

业内称作Mycat Plus。是一款分布式数据库中间件，一般用于MySQL分片。在知名数据库中间Mycat的基础上进行了大量的优化和定制，修复了很多Mycat的bug，有专业的团队维护，可以提供商业服务。

官方特性一览：

官方网站：DBLE官网

 

zookeeper

zookeeper我想我不用过多介绍了，时下算是最火的一个分布式服务框架。很多中间件，比如Kafka、Hadoop、HBase，都用到了 Zookeeper。

（以下内容来自知乎柳树  https://zhuanlan.zhihu.com/p/69114539?utm_source=wechat_session）

为什么需要 Zookeeper？

正经点来回答，就是我们需要一个用起来像单机但是又比单机更可靠的东西。

不正经的回答：

一个团队里面，需要一个leader，leader是干嘛用的？管理什么的咱不说，就说如果外面的人，想问关于这个团队的一切事情，首先就会去找这个leader，因为他知道的最多，而且他的回答最靠谱。

比如产品经理小饼过来要人，作为leader，老吕发现小耀最近没有项目安排，于是把小耀安排给了小饼的项目；

过了一会，另一个产品小西也过来要人，老吕发现刚刚把小耀安排走了，已经没人，于是就跟小西说，人都被你们产品要走了，你们产品自己去协调去。

如果老吕这时候忘了小耀已经被安排走了，把小耀也分配给小西，那到时两个产品就要打架了。

这就是leader在团队里的协调作用。

同样的，在分布式系统中，也需要这样的协调者。

比如我们搭建了一个数据库集群，里面有一个Master，多个Slave，Master负责写，Slave只读，我们需要一个系统，来告诉客户端，哪个是Master。

有人说，很简单，我们把这个信息写到一个Java服务器的内存就好了，用一个map，key:master，value:master机器对应的ip

但是别忘了，这是个单机，一旦这个机器挂了，就完蛋了，客户端将无法知道到底哪个是Master。

于是开始进行拓展，拓展成三台服务器的集群。

这下问题来了，如果我在其中一台机器修改了Master的ip，数据还没同步到其他两台，这时候客户端过来查询，如果查询走的是另外两台还没有同步到的机器，就会拿到旧的数据，往已经不是master的机器写数据。

所以我们需要这个存储master信息的服务器集群，做到当信息还没同步完成时，不对外提供服务，阻塞住查询请求，等待信息同步完成，再给查询请求返回信息。

这样一来，请求就会变慢，变慢的时间取决于什么时候这个集群认为数据同步完成了。

假设这个数据同步时间无限短，比如是1微妙，可以忽略不计，那么其实这个分布式系统，就和我们之前单机的系统一样，既可以保证数据的一致，又让外界感知不到请求阻塞，同时，又不会有SPOF（Single Point of Failure）的风险，即不会因为一台机器的宕机，导致整个系统不可用。

这样的系统，就叫分布式协调系统。谁能把这个数据同步的时间压缩的更短，谁的请求响应就更快，谁就更出色，Zookeeper就是其中的佼佼者。

它用起来像单机一样，能够提供数据强一致性，但是其实背后是多台机器构成的集群，不会有SPOF。

其实就是CAP理论中，满足CP，不满足A的那类分布式系统。

（以上内容来自知乎柳树  https://zhuanlan.zhihu.com/p/69114539?utm_source=wechat_session）

 

好了，概念说完，我们开始动手操作！说的这么牛逼，是骡子是马拉出来溜溜！