数据访问层DAL部署实战

 在10月份开始接手公司数据访问层的代码，这里记录下系统的主要结构

互联网公司随着访问量的增加，都会慢慢经历从单一DB server，到Master/salve主从分离，再到散库散表，水平切分的过程。
加入公司比较晚，没有经历过这一过程，目前公司的数据库规模已经比较大了：
800+台服务器 1200+ DB instance
在这样的机器级别下，需要认为宕机是常态，而不是特殊场景
目前公司内部使用的数据库主要是mysql，所以也不太需要考虑各种不同数据库数据源之间的兼容

为了让sharding能对应用透明，所以需要数据访问层（Data Access Layer）的存在。
目前公司DAL支持：
1.数据源配置集中管理
2.动态添加，减少数据源
3.数据源水平分片
4.读写分离
5.负载均衡
6.动态通知客户端数据源分片、主从等配置变化
7.自动检测数据库宕机
不支持：
1.分布式联表查询
2.分布式事务等

目前的架构如图：

一.轻量的Master

系统使用了一个轻量级的中心管理节点(本文后面就简称为Master)来保存配置。
整体架构可以简化为Observer模式，数据源即为Subject，应用向Master订阅Subject。

客户端仍然是直接与数据库sever建立连接，但当客户端第一次访问某一个数据源时，要先与Master通讯来获取该数据源的配置，来确定具体与哪个ip:port的数据库建立连接。客户端会缓存这部分配置，类似于租约机制，客户端从Master取得配置之后，配置有效期30s。30s之后配置失效，会异步地重新从Master拉取数据源的配置。

数据源的配置统一由DBA管理，Master为DBA提供了修改配置源的方法，可以动态添加，减少数据源，可以改变某一数据源的切片方式。当某一数据源配置被改变时，Master也会主动将配置变化推送到订阅该数据源的客户端。Master会有后台任务监控检测所有数据源配置中所有server是否正常工作，会自动检测切下宕机的数据库，并推送给客户端。
这样，并不是每次访问数据库都要与Master通讯，正常情况下，每个应用每隔30s才与Master通讯一次。因此，Master保证了自己的轻量性，不会成为瓶颈和限制。

如果Master结点发生故障，可以迅速重启。在故障期间，应用仍然使用客户端的缓存配置来访问数据库。

其实数据源的配置信息管理也可以引入zookeeper，而不使用目前的这种Master节点的做法。当配置源发生改变后，客户端通过zookeeper的watcher机制来获取更新，这样可以由zookeeper自己的机制来保证数据源配置信息更好的可用性。

二.客户端

当访问某一数据源时，sharding，读写分离，负载均衡的等主要逻辑都在客户端实现。配置中包含了sharding的主key列名称和sharding规则和各个分片shard中数据库server的信息。客户端根据从Master获取的该数据源的配置来实现具体的访问。

1.sharding:
。例如图中某数据源水平分片为n份，shard_1,shard_2，shard_n，应用需要读写该数据源时，会根据主key和sharding规则计算出散在某一份分片上shard_k

2.读写分离和负载均衡：
散到某个分片上之后，如图，每个分片中有两个ip:port list，分别对应的是读和写
写list中ip:port的个数只有1个，这个即为主库
读list中ip:port可以有多个，写list中的元素也可以出现在读list中，这些即为从库
对于写sql，则会去主库执行
对于读sql，负载均衡的算法比较简单，从库中的随机选一个执行

三.检测数据库宕机

1.对于从库
Master会有后台任务监控检测所有数据源配置中所有分片中的从库是否正常工作，正常从库会配多个，如果检测到某一个从库挂掉，就会从数据源配置中切掉该从库，通知客户端更新配置信息，并发出报警。

2.对于主库
对于某一数据源配置来说，一个分片中主库只有一个，表面看这是个单点。
但其实正常主库配的ip是个虚ip，后面对应的有两台机器，做了linuxha主备自动切换，这个主库其实并不是单点，自身做了ha