为什么要分库分表和读写分离？
类似淘宝网这样的网站，海量数据的存储和访问成为了系统设计的瓶颈问题，日益增长的业务数据，无疑对数据库造成了相当大的负载，同时对于系统的稳定性和扩展性提出很高的要求。随着时间和业务的发展，数据库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作的开销也会越来越大；另外，无论怎样升级硬件资源，单台服务器的资源（CPU、磁盘、内存、网络IO、事务数、连接数）总是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。分表、分库和读写分离可以有效地减小单台数据库的压力。
MySQ一主多从，读写分离；写主库，读从库（所有的数据库的数据都是一样的）
数据一样的，那么当数据量太大的时查询还是很慢的
分库分表的原因
- 随着单库中的数据量越来越大，相应的，查询所需要的时间也越来越多，这个时候，相当于数据的处理遇到了瓶颈
- 单库发生意外的时候，需要修复的是所有的数据，而多库中的一个库发生意外的时候，只需要修复一个库（当然，也可以用物理分区的方式处理这种问题）
分库（根据用户的ID分库）
所有数据库的表结构是一样的，但存储的数据完全不同
真实的开发环境以用户的ID进行分离，每一个库的数据量小，查询就很快了
无法解决问题：当一个数据库中表中数据量过大的时候，查询依然很慢
分表（根据存储数据的时间来分）
当一个数据库的数据量过大时，必须进行表拆分
分表主要是基于数据表的某个字段来将一个表拆分为多个子表，即一个表中的数据行拆分到多个子表中去保存，子表存放到同一个数据库的不同表或者不同的数据库中。
分库分表带来的问题及解决办法
任何事情都有两面性，分库分表也不例外，如果采用分库分表，会引入新的的问题
1、分布式事务问题
使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求，这里就不多说。
2、跨节点关联查询 Join 问题
切分之前，我们可以通过Join来完成。而切分之后，数据可能分布在不同的节点上，此时Join带来的问题就比较麻烦了，考虑到性能，尽量避免使用Join查询。
解决这个问题的一些方法：
全局表
全局表，也可看做是 “数据字典表”，就是系统中所有模块都可能依赖的一些表，为了避免跨库Join查询，可以将 这类表在每个数据库中都保存一份。这些数据通常
很少会进行修改，所以也不担心一致性的问题。
字段冗余
利用空间换时间，为了性能而避免join查询。例：订单表保存userId时候,也将userName冗余保存一份，这样查询订单详情时就不需要再去查询"买家user表"了。
数据组装
在系统层面，分两次查询。第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。
3、跨节点分页、排序、函数问题
跨节点多库进行查询时，会出现Limit分页、Order by排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；
当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。
4、全局主键避重问题
如果都用主键自增肯定不合理，如果用UUID那么无法做到根据主键排序，所以我们可以考虑通过雪花ID来作为数据库的主键，
5、数据迁移问题
采用双写的方式，修改代码，所有涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写，
边写边按时间比较数据是不是最新的。
当业务系统的数据容量接近或超过单台服务器的容量、QPS/TPS接近或超过单个数据库实例的处理极限等此时，往往是采用垂直和水平结合的数据拆分方法，把数据服务和数据存储分布到多台数据库服务器上
读写分离
什么是读写分离
读写分离的实质是将应用程序对数据库的读写操作分配到多个数据库服务器上，从而降低单台数据库的访问压力。
读写分离一般通过配置主从数据库的方式，数据的读取来自从库，对数据库增加修改删除操作主库。
为什么要读写分离呢？
通过数据库中间件，可以对数据库进行水平扩展，由原来单台数据库扩展到多台数据库，数据库中间件通过路由规则将数据的访问请求路由到其中一台数据库上
- 因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。
- 但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。
- 所以读写分离，解决的是，数据库的写入，影响了查询的效率。
- 降低了数据访问的瓶颈和单台数据库的压力。通过数据库中间件还可以将DBA和研发进行解耦，提升DBA运维效率。
读写分离方案
- 当数据库读远大于写，查询多的情况，就可以考虑主数据负责写操作，从数据库负责读操作，一主多重，从而把数据读写分离
- 可以结合redis等缓存来配合分担数据的读操作，大大的降低后端数据库的压力
