categories: 分库分表
— 分库分表实战及中间件
背景描述
刚开始我们的系统只用了单机数据库
随着用户的不断增多，考虑到系统的高可用和越来越多的用户请求，我们开始使用数据库主从架构
当用户量级和业务进一步提升后，写请求越来越多，这时我们开始使用了分库分表
遇到的问题
- 用户请求量太大
单服务器TPS、内存、IO都是有上限的，需要将请求打散分布到多个服务器
- 单库数据量太大
单个数据库处理能力有限；单库所在服务器的磁盘空间有限；单库上的操作IO有瓶颈
- 单表数据量太大
查询、插入、更新操作都会变慢，在加字段、加索引、机器迁移都会产生高负载，影响服务
如何解决
垂直拆分
垂直分库
垂直分表
表中字段太多且包含大字段的时候，在查询时对数据库的IO、内存会受到影响，同时更新数据时，产生的binlog文件会很大，MySQL在主从同步时也会有延迟的风险
- 水平拆分
水平分表
针对数据量巨大的单张表（比如订单表），按照规则把一张表的数据切分到多张表里面去。但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。
水平分库
将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈
- 水平分库规则
不跨库、不跨表，保证同一类的数据都在同一个服务器上面。
数据在切分之前，需要考虑如何高效的进行数据获取，如果每次查询都要跨越多个节点，就需要谨慎使用。
- 水平分表规则
RANGE
时间：按照年、月、日去切分。例如order_2020、order_202005、order_20200501
地域：按照省或市去切分。例如order_beijing、order_shanghai、order_chengdu
大小：从0到1000000一个表。例如1000001-2000000放一个表，每100万放一个表
HASH
用户ID取模
业务层改造
基于代理层方式：Mycat、Sharding-Proxy、MySQL Proxy
基于应用层方式：Sharding-jdbc
- 分库后面临的问题
事务问题：一次投递需要插入两条记录，且分布在不同的服务器上，数据需要保障一致性。
跨库跨表的join问题:
全局表（字典表）：基础数据/配置数据，所有库都拷贝一份
字段冗余：可以使用字段冗余就不用join查询了
系统层组装：可以在业务层分别查询出来，然后组装起来，逻辑较复杂额外的数据管理负担和数据运算压力：数 据库扩容、维护成本变高.
ShardingSphere
Apache ShardingSphere是一款开源的分布式数据库中间件组成的生态圈。它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立的产品组成。 他们均提供标准化的数据
分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的
应用场景。
Sharding-JDBC：被定位为轻量级Java框架，在Java的JDBC层提供的额外服务，以jar包形式使用。
Sharding-Proxy：被定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。
Sharding-Sidecar：被定位为Kubernetes或Mesos的云原生数据库代理，以DaemonSet的形式代理所有对数据库的访问。