分库分表与读写分离

分库分表

随着业务的发展，用户数量与数据数量不断增加，迫使进行分库分表。

分表

所谓分表就是指将一个表的数据存放到多个表，然后查询时候按id的范围到对应的表里去查。因为数据太多，单个表已经不足以存储。

分库

所谓分库就是将数据存放到多个数据库中，访问时访问其中一个库。

常见中间件

cobar

社区已经黄了，基本不用了。

TDDL

不支持联表，且依赖diamond配置中心。

Atlas

社区也差不多黄了。

Sharding-jdbc

使用比较多，社区活跃，不用部署，性能高，但是需要引入依赖，系统间耦合度较高。

Mycat

从cobar中改造，社区较活跃。需要部署，耦合度低。

水平拆分与垂直拆分

顾名思义，水平拆分就是把一个表的数据放到多个库多个表中，提高并发量；垂直拆分即把表结构拆开，将字段拆分成多个表，充分利用数据库缓存。

分库分表方案

停机迁移

选一个流量较小的时段，直接停机手动更新。

双写迁移

再搞一个新的库，在原来进行增删改的操作上都加上新的库的增删改，进行双写。然后使用字段来判断数据最后修改的时间，不允许用老数据来覆盖新数据。同时开始导数据，直到数据完全一致，直接迁移到新库。

动态扩容

停机扩容

先停机，再手动扩容

优化方案

1. 设定好几台数据库服务器，分表分库分够。
2. 配置路由的规则
3. 扩容申请增加更多的服务器。
4. 由DBA负责迁移。
5. 修改配置，调整迁移的库。
6. 修改配置，调整成新库的地址。
7. 重新发布。

主键id的处理

数据库自增id

给数据库自增id设置不同的步长

UUID

本地直接生成，但是性能较差，没有顺序。

可信时间戳

存在并发场景时出现重复的情况

snowflake算法

简单说就是把一个64位的长整型id进行操作，第一个bit舍弃，当前毫秒数作为41bits，工作机器id作为10bits，序列号作为12bits。比较适合高并发场景

读写分离

简单说就是基于主从复制架构。通俗的说就是两个数据库实例，一个用来读，一个用来写，然后通过主从架构，将写的库的数据搞的和读的库的诗句同步。

原理

主库来控制写，将变化写入binlog，然后从库连接到主库之后，从库把主库的binlog复制到自己的binlog，然后从binlog中读取命令，在自己的库中执行。
主要分成两个机制，一个是半同步复制机制，指主库写入binlog后会强制数据同步到从库，而从库将日志写入之后操作就完成了。另一个机制是并行复制，简单说就是从库开启多线程读取日志然后并行重放不同库的日志，就是库级别的并行。