中间件-数据访问层

单机情况下数据库在不同语言，不同平台都有各自数据库访问组件，各种类似odbc、jdbc的封装以及orm的处理都已经相当成熟。

数据库压力越来越大，处理方法是优化应用，减少压力。二是对数据库进行读写分离，加入搜索引擎和缓存等，进而采用拆分的方法

垂直拆分（业务逻辑拆分）

单机acid受影响，要么放弃事物，要么引入分布式事物

join操作受影响，因为在两个库中了

靠外键进行约束的场景会收到影响

水平拆分

前三条和垂直拆分一样

依赖单库的自增序列生成唯一id受影响

单个逻辑意义上的表查询要跨库

上述只是部分影响，其它例如存储过程，触发器等都需要改写才能完成相应的工作

x/open组织，现在的the open group指定的分布式事物规范

分布式事物规范：XA

分布式事物处理模型：DTP，它由三个组件，ap应用程序，rm资源管理器，tm事物管理器

事物管理器向事物指定标识，监控进程，负责事物的完成和失败。事物分支标识xid，两阶段回滚需要用到xid

ap可以通过native api调用rm，不实现事物支持，也可以通过xa api进行事物调用，ap和事物管理器通过tx接口，tm和rm通过xa接口访问

可以选择是否实现两阶段提交，两阶段提交之间有准备过程，tm可以根据日志回滚，但是由于tm的自身稳定性，网络问题，以及两阶段带来的交互次数增多以及引入tm的开销，可以考虑是否开启两阶段提交

大型网站一致性理论基础：cap

c: consistency 数据写入成功后所有的节点都会同时看到这个新数据

a:无论成功还是失败都要有响应

p：部分失效无论系统还是数据的时候系统还能正常云状

但是cap不能兼得，要有取舍，ca放弃p这正是单机数据库的选择，ap放弃c这正式很多分布式系统的选择nosql系统就是这样

一般的外面都是首先满足ap最后追求c

这就是所谓base模型

basically available：基本可用允许分区失败

soft state：软状态，允许一段时间的数据不统一

eventually consistency：最终一致

比两阶段提交更加轻量级的paxos协议

paxos的前提是不能有拜占庭将军问题

集群内数据一致性的算法：quorum和 vector clock

第二种在同一份数据的每一次修改后面加上修改者和时间戳，因为比如四个人聚餐的问题，a说周一，b和c商量说周三可以，后来b和d说周四可以，a通过从c，d返回的数据确定时间，但是不知道先后顺序无法判断，所以要加上时间戳，实现最终的时间一致性

多机的自增问题

oracle 提供对sequence的支持，mysql有auto increment，但是在多机环境下这是个难题

怎么保证自增序列的一致性和连续性

一个方案：把id集中管理，每次取用

性能问题：远程取用性能损耗

生成器稳定性

存储问题

两种实现：1、中心id生成器 2、内嵌在应用层的id生成逻辑，在id生成的时候请求id

跨库join

解决方案：1、在应用层把join分开，2、数据冗余3、借助外部系统如搜索引擎解决一些跨库问题

外键约束：

比艰难，不能完全依赖库之前的功能了，要求分库后库的内容是内聚的，否则只能靠应用层的判断和容错了

分表后的数据查询问题，一般在应用层进行相应的排序，函数处理，求平均值，排序分页等

数据层的整理流程

sql解析，规则处理，sql改写，数据源选择，sql执行，返回处理合并