【总结】MySQL数据库

1，MySQL读写分离

   - MySQL复制（Replication）

   - 双主多从架构

2，MySQL高可用（HA）和读负载均衡

   - 高可用：Keeplived，失效转移

   - 读负载均衡：LVS

3，MySQL可扩展设计 - 数据切分

   - 数据的垂直切分（纵向切分）

      - 场景/出发点

         - 大字段

         - 使用用途：属性类别

         - 访问频率

         - 更新频率

         - 模块/功能解耦

      - 优点

         - 数据库的拆分简单明了，拆分规则明确

         - 应用程序模块清晰明确，整合容易

         - 数据维护方便易行，容易定位

      - 缺点

         - 部分表关联（Join）无法在数据库级别完成，需要在程序中完成

         - 对于访问极其频繁且数据量超大的表仍然存在性能瓶颈，不一定能满足要求

         - 事务处理相对更为复杂

         - 切分达到一定程度之后，扩展性会遇到限制

         - 过度切分可能会带来系统过度复杂而难以维护

   - 数据的水平切分

      - 水平切分并不依赖于特定的技术，更多的是逻辑层面的规划，需要不断的分析

      - 场景/出发点

         - 按照日期时间

         - 按照业务ID，如用户ID，商户ID

         - 功能，如置顶帖等

      - 分区算法

         - 列表List

             - 根据某个属性，如地域（华东，华北，华南等）

         - 哈希算法

             - 除余

                 - 根据ID % 节点数目

                 - 扩展性差，当需要把几点从10变成20的时候，需要数据的所有重新分区

             - 字符串Hash

         - 范围（Range）

             - 根据ID之区间进行范围分区

             - 随着用户数量的不断增长，需要创建更多的分区

             - 各个分区的工作量和负载可能存在较大的差异，老用户所在分区压力大，或者一部分ID接近热点用户的分区压力过大

         - 映射关系

             - 分区跟ID映射

             - 产生大量的映射数据

             - 有较强的可伸缩性

      - 优点

         - 表关联基本能够在数据库端全部完成

         - 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题

         - 应用程序端整体架构改动相对较小

         - 事务处理相对简单

         - 只要切分规则能够定义好，基本上较难遇到扩展性限制

      - 缺点

         - 切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则

         - 后期数据的维护难度有所增加，人为手工定位数据更困难

         - 应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难

   - 数据垂直与水平联合切分

      - 优点

         - 可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷

         - 让系统扩展性得到最大化提升

      - 缺点

         - 数据库系统架构比较复杂，维护难度更大

         - 应用程序架构也相对更复杂

   - 数据切分及整合方案

      - 思路

         - 在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各

个数据库，在模块内完成数据的整合

         - 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明

      - 选择：可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候

      - 方案

         - 自行开发中间代理层

         - 利用MySQL Proxy 实现数据切分及整合

               - 功能主要有连接路由，Query 分析，Query 过滤和修改，负载均衡，以及基本的HA机制等

               - 以上功能通过自行编写LUA 脚本来实现

               - MySQL Proxy 实际上是在客户端请求与MySQL Server之间建立了一个连接池。所有客户端请求都是发向MySQL Proxy，然后经由MySQL Proxy 进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQL Server 上

         - 利用Amoeba 实现数据切分及整合（基于Java 开发），具有Query 路由，Query 过滤，读写分离，负载均衡以及HA 机制等相关内容

               - 数据切分后复杂数据源整合

               - 提供数据切分规则并降低数据切分规则给数据库带来的影响

               - 降低数据库与客户端的连接数

               - 读写分离路由

         -  Cobar

               - 分布式

                   - Cobar的分布式主要是通过将表放入不同的库来实现

                   - Cobar支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分

                   - Cobar也支持将不同的表放入不同的库

                   - 多数情况下，用户会将以上两种方式混合使用

                   - 需要强调的是，Cobar不支持将一张表，例如test表拆分成test_1, test_2, test_3.....放在同一个库中，必须将拆分后的表分别放入不同的库来实现分布式

               - HA

                   - 在用户配置了MySQL心跳的情况下，Cobar可以自动向后端连接的MySQL发送心跳，判断MySQL运行状况，一旦运行出现异常，Cobar可以自动切换到备机工作， 强调：

                       - Cobar的主备切换有两种触发方式，一种是用户手动触发，一种是Cobar的心跳语句检测到异常后自动触发。那么，当心跳检测到主机异常，切换到备机，如果主机恢复了，需要用户手动切回主机工作，Cobar不会在主机恢复时自动切换回主机，除非备机的心跳也返回异常

                       - Cobar只检查MySQL主备异常，不关心主备之间的数据同步，因此用户需要在使用Cobar之前在MySQL主备上配置双向同步

               - 约束

                   - 不支持跨库情况下的join、分页、排序、子查询操作

                   - SET语句执行会被忽略，事务和字符集设置除外

                   - 分库情况下，insert语句必须包含拆分字段列名

                   - 分库情况下，update语句不能更新拆分字段的值

                   - 不支持SAVEPOINT操作

         - MyCat：推荐使用，请参考文章“【总结】MyCat分布式数据库中间件”

         - 利用HiveDB实现数据切分及整合

               - 自行实现了数据冗余机制

               - 基于Java 针对MySQL数据库的提供数据切分及整合的开源框架，只是目前的HiveDB仅仅支持数据的水平切分

   - 数据切分与整合中可能存在的问题

      - 引入分布式事务的问题

      - 跨节点Join的问题

      - 跨节点合并排序分页问题