看见表结构之后,秒懂吧?
大概意思就是记录分表后的每张表的下一个ID是多少,缺点很明显,就是每次插入数据都要访问这张表获
取插入数据的id,该表很容易称为系统性能的瓶颈,同时它也存在单点问题,一旦该表数据库失效,整个
系统都无法正常工作。此时可能通过主备机同步机制,解决单点问题。
解决方案3:Twitter的分布式自增ID算法Snowflake
snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用,接下来的41位为毫秒级时间(41位的长度可以使用69年),然后是5位datacenterId和5位
workerId(10位的长度最多支持部署1024个节点) ,最后12位是毫秒内的计数(12位的计数顺序号支持每
个节点每毫秒产生4096个ID序号)
一共加起来刚好64位,为一个Long型。(转换成字符串后长度最多19)
snowflake生成的ID整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由datacenter和
workerId作区分),并且效率较高。经测试snowflake每秒能够产生26万个ID。
7、跨分片的排序分页
在不同的分片节点中将数据进行排序,并将结果机型汇总,再次排序。
四、分库数量
分库数量首先和单库处理能力息息相关,比如MySQL单库超过5000万记录,Oracle单库超过1亿条记录,
数据库压力就很大了。
在满足上述前提下,如果分库数量少,达不到分散存储和减轻DB性能压力的目的;如果分库数量多,跨库
访问也是个问题,如果是并发模式,要消耗宝贵的线程资源,如果是串行,偶数,执行时间急剧增加。
分库数量还会直接影响硬件的投入,所以要分多少个库,要进行综合评估,一般初次分库建议分为4-8个
库。
五、分库分表第三方解决方案 -- Apache ShardingSphere
Apache ShardingSphere是一套来源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-
JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这三款相互独立,却又能够混合部署配合使用的产
品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语
言、云原生等各种多样化的应用场景。
ShardingShpere定位为关系型数据库中间件,旨在充分合理地在分布式场景下利用关系型数据库的计算和
存储能力,而并非实现一个全新的关系型数据库。它通过关注不变,进而抓住事物本质。
Apache ShardingSphere 5.x版本开始致力于可插拔式架构,项目的功能组件能够灵活的以可插拔的方式进
行扩展。目前,数据分片、读写分离、数据加密、影子库压测等功能,以及MySQL、postgresql、