中间件-数据访问层
单机情况下数据库在不同语言，不同平台都有各自数据库访问组件，各种类似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执行，返回处理合并