从单块架构到分布式架构之数据库集群（三）

数据库集群主要有主备、主从、分库、分表等方案。

一 、主备

主要用来做存储高可用，当主库挂了之后可以利用备库来代替主库，备库不提供任何的访问能力。

问题所在：主备数据同步是有延时的，数据量非常大的情况下可能会达到一分钟以上。如果这个时候主库所在服务器宕机，可能会造成备库数据不一致的情况。当主库恢复正常运行之后，是把主库设置成新的备库来使用，还是仍然当成主库来使用呢。

二、主从

读写分离，主库负责写入数据，从库负责读取。可以是一主一从，也可以是一主多从。主要用来分散高并发时的访问压力，并且主库挂掉之后，不会影响读取相关业务。

问题所在：由于主库只有一个，所以不用担心数据丢失的问题。但是跟主备一样， 数据同步是需要时间的，当用户在主库新增一条数据之后，立马做了查询操作， 这个时候数据可能还没有同步到从库中，导致了数据不一致。比如用户注册系统之后，登陆的时候却提示账号不存在。

解决方法：1、对于刚新增/编辑过的数据，仍然访问主库；对代码侵入比较大。

                              2、从库未查询到的情况下再次查询主库；当大量访问不存在的资源会造成主库压力山大。

                              3、重要业务读写都在主库， 非重要业务采用读写分离。

也可以针对不同的业务数据采取不同的方式处理。

三、分库

将数据库按一定的方式拆分成多个数据库。这些数据库可以分开部署在不同的服务器或者实例上面。

虽然读写分离可以分散访问压力，但是所有的数据都要存放在每一个节点上，不能解决存储压力。

问题所在：1、连接查询；如果一个查询所需数据分散在不同的库中，需要多次查询组装起来后才能得到结果；

                              2、分布式事务；单库的情况下可以使用数据库自带的ACID保证数据的完整。分库后，表分散到不同的数据库中，无法通过事务统一修改。可以了解一下CAP、BASE、两阶段提交、三阶段提交、事务补偿机制、重试机制、人工干预等解决方式；

                              3、开发成本增加；服务器数量也要相应的增加；

四、分表

拆分方式有垂直拆分和水平拆分

4.1 垂直拆分

将一个表的拆分成多个表。以主外键的方式关联。数据库在查询的时候会将整行数据都加载至内存中，拆分成多个表可以减少IO和内存的使用。例如：将商品基本信息和商品详情拆分开。如果拆分后的两个表在大部分的业务。

4.2 水平拆分

水平分表适合表行数特别高的表，一般数据量超过5000万行必须分表；将表的数据拆分到多个表中，

4.2.1 范围拆分

例如：用户ID范围在1-999999的数据放在table1中，用户ID范围在1000000-1999999的数据放在table2中。

好处是扩展方便，用户量增加只需要多加几个表就可以了。

坏处是数据分布不均匀，可能几个表的数据量差异比较大，老用户可能没有新用户这么活跃。

4.2.2 hash路由拆分

选取某个列的值进行哈希运算，然后根据哈希结果将数据分散到不同的表中。哈希路由的复杂点在于表数量的选择上面。表太多了维护麻烦， 表太少了性能可能会受影响；

优缺点和范围拆分相反，数据量分布比较均匀，但是扩展麻烦。增加新的表之后需要将数据重新迁移分布。

4.2.3 配置路由

增加一张路由表，用来记录路由信息。将用户ID与tableID做个映射；

配置路由设计简单，使用起来方便；在扩充表的时候只需要迁移指定的数据，然后修改路由表就可以了。

配置路由的缺点就是查询必须多查询一次，会影响整体性能，当路由表数据量变得特别大之后也会成为性能瓶颈。

水平分表问题所在：1、join查询更复杂，需要在代码中进行多次查询

                                 2、count统计操作需要统计多个表之后加起来。

                                 3、order by 操作没法在数据库中进行，需要加载至业务代码或者数据库中间件中汇总排序。