严格的来说，微信开源的phxsql不是数据库，而是一个数据库的插件；
传统的互联网数据库结构一般是这样的:
服务访问数据库是通过分片来的:
除了这种基于hash的分片,还有一种基于range的分片方式
通常,基于range的分片场景下会引入一个新的服务来保存range分片的元信息,列如etcd:
数据库连接是这样进行的:
第1步, 先监控etcd服务上的range信息变化;
第2步, 读取etcd服务上的range信息;
第3步, 接收到sql请求,解析sql语句,根据分片信息决定连接哪个数据库进行操作;
著名的开源数据库TiDB就是range来做数据库的水平拆分;
基于hash的数据库分片现在已经很少用了,因为扩容时非常麻烦;你可以自行脑补一下,1000台数据库的记录扩展到1500台,在不中断业务的情况下的操作;
上面的内容有点跑题,我们接下来看看主从复制:
为了防止某个库挂掉之后,记录丢失,有了主从复制
当然,主从复制还可以满足读写分离,减低主库的负担
数据库连接的逻辑:
第1步, 解析sql;
第2步, 判断sql是读(insert, update, delete)还是写(select);
第3步, 落到相应的库上;
由于从库获取主库的记录有延时,所以读可能会失败,比如你刚发布了个帖子,却不能马上查到;
或者还有更坏的情况,你刚发了个帖子,主库挂了,这条记录还没同步到从库;这样帖子就丢了;
如果只是丢了帖子,情况还不算糟,重新发个帖子就是了;如果是在金融场景下,问题可能就麻烦了,比如下面的场景:
mysql主从复制可能会导致数据不一致,这是问题1;
再看下面的场景,如果数据库连接是基于故障自动切换的,则有可能会产生主库和从库同时被写的问题;
这种场景下,主从库的数据也会不一致，这是第二个问题;
为了解决第一个问题,phxsql引入了第一个插件BinLogSvr:
phxsql增加了一个进程BinLogSvr,用来管理mysql日志;
主库的逻辑变成了这样:
第1步, 收到sql请求;
第2步, 准备sql执行;
第3步, 写入BinLogSvr;
BinLogSvr用paxos协议,将这条日志复制到mysql集群中的其他机器上;
BinLogSvr返回成功;
第4步, Commit数据,返回成功;
从库的逻辑变成这样:
取消从主库获取binlog;
改成从本机的BinLogSvr获取binlog;
由于BinLogSvr基于paxos协议,binlog到BinLogSvr成功即表明mysql集群中半数以上的机器已经获取到最新的日志,除非半数以上的机器挂掉,才有可能产生数据不一致;
为了解决上述的第二个问题,phxsql引入了另一个插件PhxSqlProxy:
实际上, PhxSqlProxy也是一个进程,对前端,模仿了mysql服务端,对后端,模仿了mysql客户端,将数据库连接请求平等的对应到后端的mysql服务上;
mysql的主库由BinLogSvr来选举,基于paxos算法;
如果有sql请求到来,PhxSqlProxy会向BinLogSvr来查询当前是否为主库,如果是主库,则将请求传给本机的mysql服务;如果是从库,则将请求转给主库;
结束;
主库挂了或者是租约过期,新的主库选举是由BinlogSvr来完成的；