

首页  思维导图  详情



分库分表流程梳理

2021-11-13 22:42:11   38  举报





AI智能生成

笔记

系统架构

微服务

mysql主从复制读写分离分库分表

模版推荐

作者其他创作

大纲/内容

分库分表中间件

sharding-jdbc

不用部署，运维成本低，不用代理层二次转发，性能高，但是如果jar更新，需要各个系统重新发布升级，耦合性太强；

mycat

需要部署，运维成本高，但是如果升级新版本，只需升级中间件，各个系统透明；

水平拆分，垂直拆分

垂直拆分，把访问频率高的字段集中放到一个表里，访问频率低的字段集中放到一个表里，因为数据库是有缓存的，一行数据，频率高的字段集中起来，没用的字段不往里表里放，这样缓存中就可以放更多的行；

分库分表方式：range来分，按时间范围来分；但容易产生热点数据，可能大量请求打到热点数据上；<br>或者按hash算法分片；

场景？

1，设计分库分表，如何让系统从未分库分表的地方动态迁移到分库分表？

停机迁移，凌晨12点开干

双写迁移；同时写老库和新库；然后用导数的工具读老库，写新库；要根据数据modifiedtime判断，该条数据比新库的还要新，才往里写；多次反复对照，直到新老数据库数据一致；

如何设计可以动态扩缩容的分库分表方案？

停机扩容不推荐；

开始就32库32表，1024，长期不用扩容；根据id取模32到库，再取模32到表；

分库分表之后，id主键如何处理？

数据自增id,一个库的一个表里插入没有什么业务含量的数据；后续各个库从这个表里读取；<br>改进：一个服务读取后，自增几次，返回一批id，往表里插入最大的；适用于并发不高，但数据量很大的；

设置数据库sequence或者表自增字段步长；比如有8个节点，每个服务器起始值为1，2，3。。。8，<br>第二次值为9，10，11，。。。17；服务节点固定，如果增加服务器就麻烦了；

UUID：本地生成，不依赖数据库；但是；太长占空间，无序，作为主键性能太差；会导致B+树索引过多的随机IO操作；<br>insert不能连续，导致将B+树索引全部写入磁盘性能太差；只适合做标题，编号等，

snowflake 算法：

10bit位，5位机房，5位机器id,最后12位每毫秒内最多4096个值；

 Collect

Get Started

MyCat（读写分离/分库分表/高可用）

 Collect

Get Started

分库分表实践

 Collect

Get Started

分库分表学习1

 Collect

Get Started

分库分表方案





0 条评论

下一页