数据库从集中式走向分布式的一个过程
当数据库并发or连接数达到极限值，如何处理
业界两种处理方式：
----->复制的方式（每台实例数据一样）
纯复制的方式可以解决并发高的问题，不能解决数据量大的问题
----->切片的方式 （每台实例数据不一样)
比较流行的方式
1.垂直拆分数据
----->按功能模块拆分数据，把不同功能模块的数据放入不同的数据源
----->从集中到分布式过程中，刚开始拆的工作大部分都是人工的。
----->优缺点
---->拆分规则比较简单，一般我们项目都是按功能去划分模块的。
---->应用程序也可以按照功能模块，整合比较容易
---->数据定位也很方便
----->问题
----->表关联无法再数据库级别完成(join无法实现跨数据源)
---->只能通过一个查询结果作为条件查另外一个性能较差
---->特殊情况可以适当冗余数据，避免join
----->拆分到一定程度就无法继续拆分了。功能模块已经非常单一，没法继续细拆了
切分达到一定程度就，扩展就会收到限制
------>事务的问题
------>以前同一个数据源的单一事务就分配到不同数据源中了
------>如果采用分布式事务，可以达到数据一致性
但是效率极差，分布式事务是无法支持每秒上百的并发的
----->在并发要求高的系统中
我们不能采用分布式事务
通过单一数据源的小事务，然后应用程序总控制，对应用程序要求高。
降低数据一致性的要求(CAP原理）
采用消息中间件(ActiveMQ)来回避事务处理
2.读写分离
----->读写分离的控制不应该有应用程序决定？
----->master/slave 数据同步会有延迟？(CAP的原理做取舍，提高数据同步的效率)
----->可能会有异构数据源之间的读写分离产生(如oracle写,mysql读)
----->异构数据源之间数据导入导出
----->异构数据源之间数据同步的问题
----->读写分开，建立了高速通道
3.水平切分(主要解决数据量大的问题,同时也解决了并发问题)
------>按记录来切分数据
---->可能只分表操作，也可能分库分表
---->保证访问的数据表的数据量都不大。
------>水平拆分一定要有标准，要有规则，规则要根据业务情况而定
----->时间性、地域性等，要保证能够快速定位到表
4.数据切分之后的整合
---->直接交给应用程序管理
根据模块配置自己需要的数据源
很麻烦，而且不可控制
----->代理层---->数据切分及整合的中间件
---->mysql官方的mysqlProxy需要配合LUA脚本
---->amoeba for mysql --->主要通过配置方式
总结：数据存储架构
----->垂直切分
----->读写分离
----->水平切分
----->数据切分及整合的中间件(代理服务器，读写分离、数据合并排序、新的数据拆分都应该有代理直接完成)
使得异构or多数据源对应用透明