分库分表
随着业务的发展,用户数量与数据数量不断增加,迫使进行分库分表。
分表
所谓分表就是指将一个表的数据存放到多个表,然后查询时候按id的范围到对应的表里去查。因为数据太多,单个表已经不足以存储。
分库
所谓分库就是将数据存放到多个数据库中,访问时访问其中一个库。
常见中间件
cobar
社区已经黄了,基本不用了。
TDDL
不支持联表,且依赖diamond配置中心。
Atlas
社区也差不多黄了。
Sharding-jdbc
使用比较多,社区活跃,不用部署,性能高,但是需要引入依赖,系统间耦合度较高。
Mycat
从cobar中改造,社区较活跃。需要部署,耦合度低。
水平拆分与垂直拆分
顾名思义,水平拆分就是把一个表的数据放到多个库多个表中,提高并发量;垂直拆分即把表结构拆开,将字段拆分成多个表,充分利用数据库缓存。
分库分表方案
停机迁移
选一个流量较小的时段,直接停机手动更新。
双写迁移
再搞一个新的库,在原来进行增删改的操作上都加上新的库的增删改,进行双写。然后使用字段来判断数据最后修改的时间,不允许用老数据来覆盖新数据。同时开始导数据,直到数据完全一致,直接迁移到新库。
动态扩容
停机扩容
先停机,再手动扩容
优化方案
设定好几台数据库服务器,分表分库分够。配置路由的规则扩容申请增加更多的服务器。由DBA负责迁移。修改配置,调整迁移的库。修改配置,调整成新库的地址。重新发布。主键id的处理
数据库自增id
给数据库自增id设置不同的步长
UUID
本地直接生成,但是性能较差,没有顺序。
可信时间戳
存在并发场景时出现重复的情况
snowflake算法
简单说就是把一个64位的长整型id进行操作,第一个bit舍弃,当前毫秒数作为41bits,工作机器id作为10bits,序列号作为12bits。比较适合高并发场景
读写分离
简单说就是基于主从复制架构。通俗的说就是两个数据库实例,一个用来读,一个用来写,然后通过主从架构,将写的库的数据搞的和读的库的诗句同步。
原理
主库来控制写,将变化写入binlog,然后从库连接到主库之后,从库把主库的binlog复制到自己的binlog,然后从binlog中读取命令,在自己的库中执行。
主要分成两个机制,一个是半同步复制机制,指主库写入binlog后会强制数据同步到从库,而从库将日志写入之后操作就完成了。另一个机制是并行复制,简单说就是从库开启多线程读取日志然后并行重放不同库的日志,就是库级别的并行。