3.1 读写分离(主要是为了数据库读能力的水平扩展)
3.1.1 读写分离概念
单台mysql实例情况下不能支持短时间内大量的对数据库的读操作,所以会将数据库配置成集群,一个master(主库)、多个slave(从库),一般主库负责写,从库负责读,主从之间的同步方式为binlog日志方式。binlog日志可以有Statement(记录修改数据的sql,缺点slave和master执行结果可能不同)、Row(记录每一行数据的修改,缺点日志量大)、Mixed(Statement和Row两种方式的混合)三种方式。
3.1.2 读写分离好处
避免单点故障,可以主从切换。
负载均衡,读能力水平扩展:通过配置多个slave节点,可以有效避免过大的访问量对单个库造成的压力。
3.1.3 读写分离局限性
需要对sql类型进行判断。如果是select等读请求,就走从库,如果是insert、update、delete等写请求,就走主库。
主从数据同步延迟问题。因为数据是从master节点通过网络同步给多个slave节点,因此必然存在延迟。因此有可能出现我们在master节点中已经插入了数据,但是从slave节点却读取不到的问题。对于一些强一致性的业务场景,要求插入后必须能读取到,因此对于这种情况,我们需要提供一种方式,让读请求也可以走主库,而主库上的数据必然是最新的。
事务问题。如果一个事务中同时包含了读请求(如select)和写请求(如insert),如果读请求走从库,写请求走主库,由于跨了多个库,那么jdbc本地事务已经无法控制,属于分布式事务的范畴。而分布式事务非常复杂且效率较低。因此对于读写分离,目前主流的做法是,事务中的所有sql统一都走主库,由于只涉及到一个库,jdbc本地事务就可以搞定。
高可用问题。主要包括:
新增slave节点:如果新增slave节点,应用应该感知到,可以将读请求转发到新的slave节点上。
slave宕机或下线:如果其中某个slave节点挂了/或者下线了,应该对其进行隔离,那么之后的读请求,应用将其转发到正常工作的slave节点上。
master宕机:需要进行主从切换,将其中某个slave提升为master,应用之后将写操作转到新的master节点上。
3.1.4 Zebra与读写分离
zebra团队提供了GroupDataSource来完成读写分离功能,解决了上述所有问题,且对业务方透明。开发人员可以像操作单个库那样,去访问mysql数据库集群,底层细节完全由zebra屏蔽。
支持水平扩展从库,灵活的调整各个从库的任意流量比例
支持优先就近选择从库进行读取数据,避免跨机房访问
灵活的强制走主库策略,支持单条SQL或者整个请求内所有SQL等维度
3.2 分库分表(主要是为了写能力的水平扩展,如果只是为了读,那么读写分离,多几台slave机器,也可以解决)
3.2.1 分库分表概念
一旦业务表中的数据量大了,从维护和性能角度来看,无论是任何的 CRUD 操作,对于数据库而言都是一件极其耗费资源的事情。即便设置了索引,仍然无法掩盖因为数据量过大从而导致的数据库性能下降的事实 ,这个时候就该对数据库进行水平分区 (sharding,即分库分表 ).水平分区从具体表现上来看可以分为:只分表、只分库、分库分表三种。
3.2.1 分库分表好处
分库好处:降低单台机器的负载压力,提高读写性能。
分表好处:比如原来一张表4000w行数据,经过分表后每张表1000w数据,当执行插入操作时,维护索引的时间缩短,提升了写的效率;读时候可以同时从多张表中读,提升了读的效率。所以读写性能都得到了提升。
3.2.3 分库分表局限性
3.2.3.1 增删查改的功能变得复杂
原来的insert语句如下:
insert into user(id,name) values (1,”tianshouzhi”),(2,”huhuamin”), (3,”wanghanao”),(4,”luyang”);
经过分库分表后,需要将sql语句改为如下形式,并分别到每个库去执行:
insert into user_1(id,name) values (1,”tianshouzhi”)
insert into user_2(id,name) values (2,”huhuamin”)
insert into user_3(id,name) values (3,”wanghanao”)
insert into user_0(id,name) values (4,”luyang”)
具体的流程可以用下图描述:
解释如下:
sql解析:首先对sql进行解析,得到需要插入的四条记录的id字段的值分别为1,2,3,4
sql路由:sql路由包括库路由和表路由。库路由用于确定这条记录应该插入哪个库,表路由用于确定这条记录应该插入哪个表。
sql改写:上述批量插入的语法将会在 每个库中都插入四条记录,明显是不合适的,因此需要对sql进行改写,每个库只插入一条记录。
sql执行:一条sql经过改写后变成了多条sql,为了提升效率应该并发的到不同的库上去执行,而不是按照顺序逐一执行
结果集合并:每个sql执行之后,都会有一个执行结果,我们需要对分库分表的结果集进行合并,从而得到一个完整的结果。
3.2.3.2 分布式id问题的解决
分库分表后,不能再使用mysql的自增主键。因为在插入记录的时候,不同库生成的自增id可能会发生冲突,因此要有一个全局的id生成器。
Snowflake雪花算法
分配一个64bit的long型id,分配如下:
41bit用作时间戳,精确到ms,10bit用于工作机器id(5bit是数据中心id,5bit是机器id),12bit用作序列号,也就是说某一个数据中心的一台机器在1ms时间内可以分配4096个id,序列号的生成可以采用Synchornized加锁的方式,也可以采用AtomicInteger(底层采用CAS)的方式。当在1ms内向某台机器申请多于4096个id时,机器可以推到下一ms生成。这64bit也可以根据自己需要设置不同bit的用途。
缺点: 时间回拨问题、机器id的分配回收问题、机器id的上限问题。这里不再详细阐述。(待补充)
proxy服务+数据库分段获取id
注: DX、YF等表示数据中心名称、leaf表示该数据中心的某台机器、数据表中的biz_tag表示业务标识,该业务的id要保证唯一,不同业务的id不需要保证、max_id表示该业务当前申请的最大id、step表示该业务每次申请的id数量。申请完成后,该step数量的id被数据中心的某台机器所持有,然后机器可以通过Synchornized/AtomicInteger(底层采用CAS)的方式去分配。
申请sql语句如下(使用事务):
Begin
UPDATE table SET max_id=max_id+step WHERE tag=xxx
SELECT tag, max_id, step FROM table WHERE tag=xxx
Commit
优点:每次分配step数量的id,数据库读写压力很低
缺点:HA高可用性要求极高,采用主从部署+异地灾备的部署方案。
3.2.3.3 分布式事务
分库分表场景下,分布式事务涉及到对不同库、不同表的操作要么同时成功,要么同时失败。
分布式事务解决方案:
XA事务
柔性事务:最大努力通知型、可靠消息最终一致性方案以及TCC两阶段提交
(待补充)
3.2.3.4 动态扩容
动态扩容是指增加分库分表的数量。动态扩容一般情况下伴随数据迁移。但使用everydb的方式进行数据库扩容时,不需要进行数据迁移。思路如下:
在id字段的后面额外加上几位数字。比如加上4位数据,2位表示分库编号,2位表示分表编号。这样一共便拥有了100*100=10000张表。原来的同一个分库分表数据后面加的数字一样即可,这样原来同一分库扩容后还在同一个分库,原来同一分表扩容后还在同一张分表。
3.2.3.5 数据迁移
对于新的应用,如果预估到未来数据量比较大,可以提前进行分库分表。对于老的应用,单表数据量已经比较大了,这时就涉及到数据迁移过程。美团使用Buffalo进行数据迁移。数据迁移流程如下:
存量数据迁移。分批次select源数据库,依次将数据插入到目标库中,在该过程中不断有业务写入,通过binlog日志保存增量数据(存量数据迁移过程中的业务写入操作)。
增量数据迁移。存量数据迁移完成后,获取增量数据,经过反解析、过滤、封装后同步到目标库,从而实现源库、目标库数据实时同步。也就是在目标库表中执行一遍存量数据迁移过程中的业务写入操作。
增量数据迁移追上当前时间后,进行数据校验(比如行数、表大小、CRC校验等),一致后则进行切换。
如果觉得《数据库读写分离与分库分表》对你有帮助,请点赞、收藏,并留下你的观点哦!