分库分表流程梳理
2021-11-13 22:42:11 37 举报AI智能生成
笔记
作者其他创作
大纲/内容
分库分表中间件
sharding-jdbc
不用部署，运维成本低，不用代理层二次转发，性能高，但是如果jar更新，需要各个系统重新发布升级，耦合性太强；
mycat
需要部署，运维成本高，但是如果升级新版本，只需升级中间件，各个系统透明；
水平拆分，垂直拆分
垂直拆分，把访问频率高的字段集中放到一个表里，访问频率低的字段集中放到一个表里，因为数据库是有缓存的，一行数据，频率高的字段集中起来，没用的字段不往里表里放，这样缓存中就可以放更多的行；
分库分表方式：range来分，按时间范围来分；但容易产生热点数据，可能大量请求打到热点数据上；
或者按hash算法分片；
或者按hash算法分片；
场景？
1，设计分库分表，如何让系统从未分库分表的地方动态迁移到分库分表？
停机迁移，凌晨12点开干
双写迁移；同时写老库和新库；然后用导数的工具读老库，写新库；要根据数据modifiedtime判断，该条数据比新库的还要新，才往里写；多次反复对照，直到新老数据库数据一致；
如何设计可以动态扩缩容的分库分表方案？
停机扩容不推荐；
开始就32库32表，1024，长期不用扩容；根据id取模32到库，再取模32到表；
分库分表之后，id主键如何处理？
数据自增id,一个库的一个表里插入没有什么业务含量的数据；后续各个库从这个表里读取；
改进：一个服务读取后，自增几次，返回一批id，往表里插入最大的；适用于并发不高，但数据量很大的；
改进：一个服务读取后，自增几次，返回一批id，往表里插入最大的；适用于并发不高，但数据量很大的；
设置数据库sequence或者表自增字段步长；比如有8个节点，每个服务器起始值为1，2，3。。。8，
第二次值为9，10，11，。。。17；服务节点固定，如果增加服务器就麻烦了；
第二次值为9，10，11，。。。17；服务节点固定，如果增加服务器就麻烦了；
UUID：本地生成，不依赖数据库；但是；太长占空间，无序，作为主键性能太差；会导致B+树索引过多的随机IO操作；
insert不能连续，导致将B+树索引全部写入磁盘性能太差；只适合做标题，编号等，
insert不能连续，导致将B+树索引全部写入磁盘性能太差；只适合做标题，编号等，
snowflake 算法：
10bit位，5位机房，5位机器id,最后12位每毫秒内最多4096个值；
0 条评论
下一页
