type
status
date
slug
summary
tags
category
icon
password
这里写文章的前言：
分库分表
📝 分库分表要解决的问题
1. 解决B+树设计上本身的瓶颈问题(数据过多, 以及内存不够放索引,需要发生IO之类的问题)
2. 解决技术问题之后,要考虑业务的拆分情况,尽可能的减少业务代码的改动逻辑
3. 分库分表的本质就是把B+树的设计瓶颈重新拆散,变成无瓶颈
📔 垂直切分
通过将不同业务的数据，放到不同的数据库中，实现不同业务之间数据库层面的隔离
📔 水平切分
可以按照某种规则将某些字段分散到多个库中，每个表中只包含一部分数据 ,字段是一样的(比如日期字段，用户id字段，区域字字段等，比较理想的切分字段)
📔 如何实施
1. 先评估是否需要拆分
能不能有其他更好的优化方案，分库分表的开发周期比较长，一般只作为兜底方案去执行
2. 定制拆分的详细方案
1. 选择合适的分表策略
2. 再通知可能要更改的下游
3. 尽量做好设计，避免分库分表带来的常见问题
3. 目的评估
- 评估：拆成几个表，几个库
- 目标：读写能力提升多少，负载降低多少，容量支持未来N年的发展
举个例子：
当前30亿数据，如何拆分
解答：
找一个合理的拆分情况，比如按区域，按门店去拆分，不影响原来的业务，并且颗粒度细致到足够未来N年的发展就可以了
4. 拆分完成后防止问题兜底方案
作用：保证切换数据源之后，正常的增量数据也同步写入一份到旧数据源，这样能保证新数据发生不可短时间解决的问题的时候，避免回滚可以通过开关配置切换到旧数据源上正常执行业务
方案：
- 同步双写：同步写新、旧数据源（代码层面上直接改）
- 异步双写：通过监听binlog的方式去写旧数据源
- 中间件同步工具：通过中间件工具去实施同步数据
注意点：做好补偿机制， 因为可能写其中一个库失败，需要做好最终一致性问题
5.存量数据的迁移问题
作用：迁移旧数据源的数据同步到新的数据源上，保证原有业务的正常CRUD
方案：
1. 自己写job开发，查询旧数据源，写入新库
2.用中间件去同步
3.交给DBA去同步
注意点：一定要校验数据的准确性，因为这是分库分表后的最后一步，一定要再三确认数据的一致性校验问题，并且要有相关的job做好补偿方案
分库分表后存在的问题
分布式id问题
1. 雪花算法，
2. 全局的自增id，
3. 美团分布式id方案
跨表查询问题
1. 从设计上解决跨表查询的情况，设计上基本能解决95%以上的问题，比如冗余字段，拆分的时候按业务隔离性去拆分
2. 分开查询，通过java代码去组合数据
3. 同一个线程需要跨库的，可以通过JDBC的方式去查询
4. 用ES等查询工具查询出主要信息，再组装数据
分布式事务问题
1. 做好补偿方案
2. 最大努力通知（使用MQ）
3. 人工兜底补偿 - 保底
📔 切分策略
范围切片
- 优点： 天然水平扩展;单表大小可控
- 缺点：存在明显的写偏移
中间映射表
- 优点： 灵活
- 缺点： 引入额外的单点，增加了流程的复杂度
hash切分
- 优点： 数据分片比较均匀，不容易出现热点和访问并发的瓶颈
- 缺点： 后续扩容需要迁移数据，存在跨节点查询等问题
🤗 总结归纳
📎 参考文章
有关文章的问题，欢迎您在底部评论区留言，一起交流~