mysql扩展

1.业务拆分

业务发展初期为了便于快速迭代，很多应用都采用了集中式的架构。随着业务规模的扩展，单个库的访问量越来越大，因此不得不对业务进行拆分。每一块业务都使用单独的数据库来进行存储，前端不同的业务访问不同的数据库。这样原本依赖单库的服务，变成4个库同时承担压力，吞吐能力自然就提高了。

2.复制策略

业务继续发展，按业务拆分后的库也开始承受不了。这时可以使用mysql的replication（复制）策略来对系统进行扩展。通过数据库的复制策略，可以将一台Mysql数据库上的数据复制到其他数据库上去，当各台数据库都有相同数据时，前端应用通过访问mysql集群中的一台数据库就能读取到相同的数据，这样就减轻了每台数据库的压力。

一般而言，大多数站点的读操作要比写操作更为密集，如果读的压力过大，可以新增slave来进行系统扩展。Master-Slave的架构能够显著的减轻前面提到的单库读压力。

Master-Slave复制架构存在一个问题，即所谓的单点故障。master的数据库挂了系统就用不了了。最佳的方式是Dual-Master架构。即Master-Master架构。即两台数据库都视对方为自己的Master。要保证不循环复制和避免写入冲突以及Master切换怎么搞去查相关文档。。这里只做概要笔记。

3.分表与分库

对于大型互联网企业来说，单表也会有很高的访问量。基于Master-slave的架构只能对读进行扩展，写还是集中在Master上，而且slave的数量受master能力和负载的限制。所以就会有分库和分表。

对于访问极为频繁且数据量巨大的单表来说，我们首先要做的就是减少单表的记录数，以便减少数据查询的时间，提高数据库的吞吐，这就是所谓的分表。分表之前，要选择好合适的分表策略，使得数据能较为均衡的分布到多张表中（有的时候要根据冷热程度来分），并且不影响正常的查询。

分表能够解决单表数据量过大带来的查询效率下降的问题，但是无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问，当数据库Master服务器无法承载写操作压力时，不管如何扩展Slave服务器，此时都没有意义了。此时，我们必须换一种思路，对数据库进行拆分，从而提高数据库的写入能力，这就是所谓的分库。

Paste_Image.png

有时数据库可能既面临高并发访问的压力，又需要面对海量数据的存储问题。这个时候既要分库又要分表。以便同时扩展系统的并发处理能力，以提高单表的查询性能，这就是所谓的分库分表。分库分表比单纯的分库或者分表要难些。
具体怎么做查阅相关文档。这里只做概要笔记。。
经过业务拆分和分库分表之后，虽然查询性能和并发处理能力提高了，但也会带来一系列问题。比如，原本跨表的事务上升为分布式事务。