数据库分库分表

为什么分？
业务需求的不断增加，数据量越来越大，因此数据的增删改查开销越来越大。再加上物理服务器的资源也是有限的。最终数据库的处理能力，承载的数量都会达到瓶颈。就需要合理的数据库架构来存放不断增长的数据。

如何分表？
单表随着数据量的增大，数据库执行的速度也会被拖累。如果需要多表联合查询，那么劣势更加的明显。例如拿mysql举例，在插入数据的时候，整个表就会被加锁，知道此操作完成以后，就会造成数据访问的堆积，影响数据库的效率。
所以根据业务场景和实际情况具体分析，大致分为两种情况，垂直分表和水平分表。
垂直分表：将一些不常用的表字段，或者长度比较长的字段，分开到别的表上去。主要是避免数据量大查询的时候会出现"跨页“问题(跨页问题：数据量太大不得已需要分页显示)
水平分表：将一个表中的数据，按照关键字可以根据hash之后的数字进行取模，将得到的不用结果添加到不同的数据库中去。也可以根据数据产生的先后顺序来拆分存放（例如主表只存放最近两个月的数据，比较老旧的数据拆分到其他表中，通过时间来做数据的区分，当然还可以根据服务的地域来进行区分）。
需要注意的问题:那就是分表造成的一系列记录级别的问题，例如join和id的生成，事务处理问题，同时注意跨库问题。
id如果用uuid占用的空间比较大，要是用单表实现效率并不算高。所以有一种snowke开源的分布式id生成算法，会生成一个long型的id。核心思想就是：使用 41bit 作为毫秒数，10bit 作为机器的 ID(5 个 bit 是数据中心，5 个 bit 的机器 ID)，12bit 作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID)，最后还有一个符号位，永远是 0。

事务：考虑用补偿事务，或者用 TCC(Try Confirm Cancel)协助完成。
数据分库：
每一次数据库请求都会产生一次数据库连接，当一个库无法支持更多的访问的时候，就会进行分库。
分库一般分为：按照业务需求分库，例如可以分为订单数据库和配置数据库等。
也可以根据时间分库：例如前两个月的是经常使用的，可以放到一个数据库，三到四月中频放到一个。。一次类推。 也可以根据地域来分类，等等
分库以后每一个数据库会包含多张表，多个数据库会组成一个集群，我们就可以做成读写分离。master库主要是负责写操作，slave库主要负责读操作。在应用访问数据库的时候会通过一个负载均衡代理，通过判断读写操作的请求路由来进行访问对应的数据库。
如果是读操作。也会根据数据库的权重平均分配请求。另外数据库还有监听心跳机制，定时发送心跳检测数据库的健康状态。如果salve挂点以后就会使用熔断机制，让此节点不在被访问，如果是master挂掉，那么就会推选出一个新的master节点继续执行。

数据库扩容：
主从数据库扩容：如果有s1和s2两天主数据库，并且对应有m1和m2两台从数据库，那么扩容的时候会将id%2改为id%4, 这样就会扩容到四台服务器，而负载均衡器就会直接停止掉m1,m2的同步，将会作为新的主库存在，进行写操作。而且这样不用重启数据库服务，只需要修改配置即可，然后配从库，最后可以通过后台清理掉冗余的数据。
双写数据库扩容（在没有备用服务器的时候扩容）：
新增的库是 M3，M4 路由的方式分别是 ID%2=0 和 ID%2=1。这样的话新的数据就会被分到四台服务器上，之后后台服务将数据同步，同步完成以后，将每天服务器重新编号，之后数据就会评分在四台服务器上。