论JAVA分布式服务架构(五)

随着业务的发展，单个库的访问量越来越大，因此，不得不对业务进行拆分。每一个业务都使用单独的数据库来进行存储，前端不同的业务就访问不同的数据库，这样原本依赖单库的服务，变成多个库同时承担压力，吞吐能力自然就提高了。

同时，业务拆分不仅仅能提高系统的可扩展性，也带来了开发工作效率的提升。

2、复制策略

架构变化的同时，业务也在不断的发展，很快会发现，随着访问量的不断增加，拆分后的某个库压力越来越大，马上就要达到能力的瓶颈，数据库架构不得不再次变更，这是可以使用mysql的replication（复制）策略来对系统进行扩展。

通过数据库的复制策略，可以将一台mysql数据库服务器中的数据库服务器中的数据复制到其他mysql服务器，当各台数据库服务器上都包含相同的数据，前端应用通过访问mysql集群中的任意一台服务器，都能够读到相同的数据，这样每天mysql服务器承受的压力就大大降低了，从而提高了整个系统的承载能力，达到系统扩展的目的。

要实现数据库的复制，需要开启Master服务器的Binary log，数据复制的过程实际上就是Slave从master获取binary log，然后再本地镜像的执行日志中记录的操作，由于复制过程是异步的，因此Master和Slave之间的数据有可能存在延迟的现象，此时只能够保证数据最终的一致性。

mysql的复制可以基于一条语句（statement level），也可以基于一条记录（row level）。通过row level的复制，可以不记录执行的sql语句相关联的上下文信息，只需要记录数据变更的内容即可。但由于每行的变更都会被记录，这样可能会产生大量的日志文件，而是用statement level则只记录修改数据的sql语句，减少binary log的日志量，节约I/O成本。但是，为了让sql语句在slave端也能正确的被执行，还需要记录sql执行的上下文信息，以保证所有语句在slave段执行能够得到在master端执行时的相同结果。

前端服务器通过master来执行数据的写入操作，数据的更新通过binary log同步到slave集群，而对于数据读取的请求，则交由slave来处理，这样slave集群可以分担数据库读的压力，并且读写分离还保障了数据能够达到最终一致性，一般而言，站点的读数据操作要比写数据操作多得多。如果读的压力较大，可以通过新增 

slave来进行系统的扩展，因此，master-slave的架构能够显著地减少前面所提到的单库读的压力。

Master-Slaves复制架构存在一个问题，即所谓的单点故障。当Master宕机时，系统将无法写入，而在某些特定的场景下，也可能需要Master停机，以便进行系统维护、优化或者升级。为了尽可能降低系统停止写入的时间，最佳的方式就是采用Dual-Master架构。

所谓Dual-Master架构，实际上就是两台Mysql服务器互相将对方作为自己的master，自己作为对方的slave，这样任何一台服务器的数据变更，都会通过mysql的复制机制同步到另一台服务器。mysql在记录Binary log时，会记录当前的server-id,这样不会导致循环赋值。

两台mtster并不是为了能够同时提供写入服务，通常情况下，仅开启一台Master的写入，另一台Master仅仅stand by或者作为读库开放，这样可以避免写入数据冲突，防止数据不一致的情况发生。

3、分表与分库

对于大型互联网应用来说，数据库单表的记录行数可能是千万级或者亿级，并且数据库面临着极高的并发访问。采用Master-Slaves复制策略，只能够对数据库的读进行扩展，而对数据的写入还是几种在master上，并且单个Master挂载的slave也可能无限制多，slave的数量收到master能力和负载的限制。因此，需要对数据库的吞吐能力进行进一步的扩展，以满足高并发访问和海量数据存储的需要。

对于访问极为频繁的且数据流巨大的单表来说，我们首先要做的是减少单表的数据流，以提高查询所需要的时间，提高数据库的吞吐，这就是所谓的分表。在分表之前，要选择合适的分表策略，使得数据能够较为均衡的分布在多张表中，并且不影响正常查询。

对于互联网企业来说，大部分数据都是与用户关联的，因此，用户id是最常用的分表字段。因为大部分查询都需要带上用户id，这样既不影响查询，又能够使数据较为均衡地分布到各个 表中12，如下图所示。 

分表能解决单表数据量过大带来的查询效率下降的问题，但是，无法给数据库的并发处理能力带来质的提示。面临高并发的访问操作，但数据库master服务器无法承载写入操作压力时，不管如何扩展slave服务器，此时都没有意义。因此需要对数据库进行拆分，从而提高数据库的写入能力，这就是分库。

有时数据库可能既面临着高并发访问的压力，又需要面对海量数据的存储问题，这是需要对数据库既采用分库策略，又采用分表策略，以便同时扩展系统的并发处理能力，以及提高单表的查询性能，这就是所谓的分库分表。

一种分库分表的路由策略为：

中间变量=user_id % (库数量*每个库的表数量)

库=取整(中间变量/每个库表的数量)