mysql分布式思维（八）- mylsql分布式

数据库从集中式走向分布式的一个过程
     当数据库并发or连接数达到极限值，如何处理
     业界两种处理方式：
               ----->复制的方式（每台实例数据一样）
                        纯复制的方式可以解决并发高的问题，不能解决数据量大的问题
        ----->切片的方式 （每台实例数据不一样)
                         比较流行的方式

 1.垂直拆分数据
       ----->按功能模块拆分数据，把不同功能模块的数据放入不同的数据源
       ----->从集中到分布式过程中，刚开始拆的工作大部分都是人工的。
       ----->优缺点
               ---->拆分规则比较简单，一般我们项目都是按功能去划分模块的。
        ---->应用程序也可以按照功能模块，整合比较容易
        ---->数据定位也很方便
        ----->问题
                 ----->表关联无法再数据库级别完成(join无法实现跨数据源)
              ---->只能通过一个查询结果作为条件查另外一个性能较差
       ---->特殊情况可以适当冗余数据，避免join
   ----->拆分到一定程度就无法继续拆分了。功能模块已经非常单一，没法继续细拆了
              切分达到一定程度就，扩展就会收到限制
   ------>事务的问题
         ------>以前同一个数据源的单一事务就分配到不同数据源中了
         ------>如果采用分布式事务，可以达到数据一致性
                     但是效率极差，分布式事务是无法支持每秒上百的并发的
          ----->在并发要求高的系统中
                     我们不能采用分布式事务
       通过单一数据源的小事务，然后应用程序总控制，对应用程序要求高。

       降低数据一致性的要求(CAP原理）
       采用消息中间件(ActiveMQ)来回避事务处理

2.读写分离
       ----->读写分离的控制不应该有应用程序决定？
       ----->master/slave 数据同步会有延迟？(CAP的原理做取舍，提高数据同步的效率)
       ----->可能会有异构数据源之间的读写分离产生(如oracle写,mysql读)
                   ----->异构数据源之间数据导入导出
     ----->异构数据源之间数据同步的问题

        ----->读写分开，建立了高速通道

3.水平切分(主要解决数据量大的问题,同时也解决了并发问题)
         ------>按记录来切分数据
               ---->可能只分表操作，也可能分库分表
        ---->保证访问的数据表的数据量都不大。
        ------>水平拆分一定要有标准，要有规则，规则要根据业务情况而定
               ----->时间性、地域性等，要保证能够快速定位到表

 

4.数据切分之后的整合
      ---->直接交给应用程序管理
                根据模块配置自己需要的数据源    
  很麻烦，而且不可控制
      ----->代理层---->数据切分及整合的中间件
              ---->mysql官方的mysqlProxy需要配合LUA脚本
       ---->amoeba for mysql --->主要通过配置方式

总结：数据存储架构
             ----->垂直切分
      ----->读写分离
      ----->水平切分
      ----->数据切分及整合的中间件(代理服务器，读写分离、数据合并排序、新的数据拆分都应该有代理直接完成)
                使得异构or多数据源对应用透明