数据访问层的设计和实现（分布式系统七）

（1）如何对外提供数据访问层的功能

数据访问层就是方便应用进行数据读写访问的抽象层，在该层上解决各个应用通用的访问数据库的问题。

上图显示了三种方式，第一种是为用户提供专有API，不过不推荐，通用性很差。第二种是通用的方式，java应用中一般是通过JDBC方式访问数据库，数据库自身可以作为一个JDBC实现，也就是暴露出JDBC的接口给应用。第三种是基于ORM或类ORM接口方式。

2.按照数据层流程的顺序看数据层设计

（1）sql解析阶段处理

主要考虑两个问题，一是sql支持程度，是否需要支持所有的sql，要根据具体场景来决定，二是支持多少sql方言。

（2）规则处理阶段

a、采用固定哈希算法作为规则

固定哈希的方式，根据某个字段（例如用户id）取模，然后将数据分散到不同的数据库和表中，除了根据id取模，还经常根据时间维度。

一致性哈希所带来的最大变化就是把节点对应的哈希值变为了一个范围，而不再是离散的。在一致性哈希中，我们会把整个哈希值的范围定义的非常大，然后把这个范围分配给现有节点，如果有节点加入，那么这个新节点会从原有的某个节点上分管一部分范围的哈希值；如果有节点退出，这个节点原来管理的哈希值会给它的下一个节点来管理。假设哈希值范围从0到100，共有4个节点，那么他们管理的范围就变成[0,25],[25,50],[50,75],[75,100],如果第二个节点退出，那么剩下节点管理的范围就变成[0,25],[25,75),[75,100],若是在第二个和第三个节点增加一个，就变成0,25),[25,50),[50,63),[63,75),[75,100],减少一个节点时，只有一个节点受影响，它要承担原来自己的和减去节点的工作，压力明显比其他节点要高。一致性哈希的优势就不明显了。所以引入了虚拟节点，4个物理节点可以变成很多虚拟节点，如果有一个物理节点加入，就会响应加入很多虚拟节点，这些新的虚拟节点相对均匀插入整个哈希环上，如果减少一个物理节点，对应很多虚拟节点就会失效，这样会有很多剩余的虚拟节点来承担之前虚拟节点的工作，对物理节点来说，增加的负载是相对均衡的。

（3）sql改写

如果我们分库时按照卖家id来分，可以保证同一个卖家的商品在一个数据库中，但是要根据商品id来查询就比较麻烦了，因为只有商品id不能确定这个商品是在哪个数据库中，还需要卖家id或其他标志才能确定。为什么要修改sql呢？

数据表从原来单库单表变成了多库多表，这些分布在不同数据库中的表的结构一样，但是表名未必一模一样，如果把原来的表分布在多库且每个库都只有一个表的话，那么这些表是可以同名的，若干单库中不止一个表，那就不能用同样的名字，如User表分库分表后命名为user_1,user_2。在命名表示需要作出一个选择，不同库中的表名是否要一样？如果每个表的名字是唯一的，看起来似乎不太优雅，但可以避免很多误操作，另外表名唯一在进行路由和数据迁移时比较便利。

除修改表名，sql中用到的索引名，在分库分表时也要进行修改，需要从逻辑上的名字变成对应数据库中物理的名字。

（4）如何选择数据源

user经历分库分表后，都会给分库后的库提供备库，也就是原来一个数据库变成一个数据库的矩阵了。分库是把数据分到了不同的数据分组中，我们决定了数据分组后，还要决定访问分组中的哪个库。

4、读写分离的挑战的应对

（1）数据结构相同，多从库对应一主库

比较优雅解决方式是基于数据库的日志来进行数据的复制。

（2）主备库分库方式不同的数据复制

一般情况进行的是对称的复制，也就是镜像，但是也会有一些进行非对称复制，非对称复制是源数据和目标数据不是镜像关系，也就是源数据库和目标数据库是不同的实现。

一个是根据买家id进行分库，把所以买家订单分到4个库中，保证一个买家查询自己的交易使都是在一个数据库上的，不过卖家的查询就可能跨多个库，我们可以做一组备库，按照卖家id进行分库，这样卖家就可以从备库上查询自己的订单都是在同一个数据库中了，这就是非对称复制，需要控制数据的分发，而不是进行简单的镜像复制。

（3）如何进行数据平滑迁移

在迁移过程中可能又会有数据的变化，可以考虑的方案是，在开始进行数据迁移时，记录增量的日志，在迁移结束后，再对增量的变化进行处理，最后，可以把要被迁移的数据的写暂停，保证增量日志都是处理完毕后，在切换规则，放开所有的写，完成迁移工作。