网站源码系统,语音网站怎么做,淮安网站建设要多少钱,wordpress 禁止ip学习的最大理由是想摆脱平庸#xff0c;早一天就多一份人生的精彩#xff1b;迟一天就多一天平庸的困扰。各位小伙伴#xff0c;如果您#xff1a; 想系统/深入学习某技术知识点… 一个人摸索学习很难坚持#xff0c;想组团高效学习… 想写博客但无从下手#xff0c;急需… 学习的最大理由是想摆脱平庸早一天就多一份人生的精彩迟一天就多一天平庸的困扰。各位小伙伴如果您 想系统/深入学习某技术知识点… 一个人摸索学习很难坚持想组团高效学习… 想写博客但无从下手急需写作干货注入能量… 热爱写作愿意让自己成为更好的人… 文章目录 背景一、介绍二、结构三、数据库分表1.垂直分表2.水平分表1主键自增2取模3雪花算法主角登场 四、雪花算法优缺点1、**优点**2、**缺点**3、**其它补充** 总结 背景
需要选择合适的方案去应对数据规模的增长以应对逐渐增长的访问压力和数据量。 数据库的扩展方式主要包括业务分库、主从复制数据库分表。 一、介绍 雪花算法Twitter的分布式自增ID算法Snowflake雪花算法是由Twitter公布的分布式主键生成算法它能够保证不同表的主键的不重复性以及相同表的主键的有序性。 最初Twitter把存储系统从MySQL迁移到Cassandra由Facebook开发一套开源分布式NoSQL数据库系统因为Cassandra没有顺序ID生成机制所有开发了这样一套全局唯一ID生成服务。Twitter的分布式雪花算法SnowFlake经测试SnowFlake每秒可以产生26万个自增可排序的ID
twitter的SnowFlake生成ID能够按照时间有序生成SnowFlake算法生成ID的结果是一个64Bit大小的整数为一个Long型转换成字符串后长度最多19分布式系统内不会产生ID碰撞由datacenter 和 workerID做区分并且效率较高
分布式系统中有一些需要全局唯一ID的场景生成ID的基本要求
在分布式环境下必须全局唯一性一般都需要单调递增因为一般唯一ID都会存在数据库而InnoDB的特性就是将内容存储在主键索引上的叶子节点而且是从左往右递增的所有考虑到数据库性能一般生成ID也最好是单调递增的。为了防止ID冲突可以使用36位UUID但是UUID有一些缺点首先是它相对比较长并且另外UUID一般是无序的可能还会需要无规则因为如果使用唯一ID作为订单号这种为了不让别人知道一天的订单量多少就需要这种规则
二、结构
雪花算法的几个核心组成部分
在Java中64bit的证书是long类型所以在SnowFlake算法生成的ID就是long类存储的。
第一部分二进制中最高位是符号位1表示负数0表示正数。生成的ID一般都是用整数所以最高位固定为0。第二部分是41bit时间戳位用来记录时间戳毫秒级41位可以表示 2^41 -1 个数字。如果只用来表示正整数可以表示的范围是0 - 2^41 -1减1是因为可以表示的数值范围是从0开始计算的而不是从1也就是说41位可以表示 2^41 - 1 毫秒的值转换成单位年则是 69.73年。第三部分工作机器ID10Bit用来记录工作机器ID可以部署在2^10 1024个节点包括5位 datacenterId数据中心机房 和 5位 workerID机器码5位可以表示的最大正整数是 2 ^ 5 31个数字来表示不同的数据中心 和 机器码。第四部分12位bit可以用来表示的正整数是 2^12 4095即可以用0 1 2 … 4094 来表示同一个机器同一个时间戳内产生的4095个ID序号。 SnowFlake可以保证所有生成的ID按时间趋势递增整个分布式系统内不会产生重复ID因为有datacenterId 和 workerId来做区分。雪花算法是由scala算法编写的有人使用java实现github地址 三、数据库分表 将不同业务数据分散存储到不同的数据库服务器能够支撑百万甚至千万用户规模的业务但如果业务继续发展同一业务的单表数据也会达到单台数据库服务器的处理瓶颈。例如淘宝的几亿用户数据如果全部存放在一台数据库服务器的一张表中肯定是无法满足性能要求的此时就需要对单表数据进行拆分。 单表数据拆分有两种方式垂直分表和水平分表。示意图如下
1.垂直分表 垂直分表适合将表中某些不常用且占了大量空间的列拆分出去。 例如前面示意图中的 nickname 和 description 字段假设我们是一个婚恋网站用户在筛选其他用户的时候主要是用 age 和 sex 两个字段进行查询而 nickname 和 description 两个字段主要用于展示一般不会在业务查询中用到。description 本身又比较长因此我们可以将这两个字段独立到另外一张表中这样在查询 age 和 sex 时就能带来一定的性能提升。
2.水平分表 水平分表适合表行数特别大的表有的公司要求单表行数超过 5000 万就必须进行分表这个数字可以作为参考但并不是绝对标准关键还是要看表的访问性能。对于一些比较复杂的表可能超过 1000万就要分表了而对于一些简单的表即使存储数据超过 1 亿行也可以不分表。 但不管怎样当看到表的数据量达到千万级别时作为架构师就要警觉起来因为这很可能是架构的性能瓶颈或者隐患。 水平分表相比垂直分表会引入更多的复杂性例如要求全局唯一的数据id该如何处理
1主键自增
①以最常见的用户 ID 为例可以按照 1000000 的范围大小进行分段1 ~ 999999 放到表 1中 1000000 ~ 1999999 放到表2中以此类推。 ②复杂点分段大小的选取。分段太小会导致切分后子表数量过多增加维护复杂度分段太大可能会导致单表依然存在性能问题一般建议分段大小在 100 万至 2000 万之间具体需要根据业务选取合适的分段大小。 ③优点可以随着数据的增加平滑地扩充新的表。例如现在的用户是 100 万如果增加到 1000 万只需要增加新的表就可以了原有的数据不需要动。 ④缺点分布不均匀。假如按照 1000 万来进行分表有可能某个分段实际存储的数据量只有 1 条而另外一个分段实际存储的数据量有 1000 万条。
2取模
①同样以用户 ID 为例假如我们一开始就规划了 10 个数据库表可以简单地用 user_id % 10 的值来表示数据所属的数据库表编号ID 为 985 的用户放到编号为 5 的子表中ID 为 10086 的用户放到编号为 6 的子表中。 ②复杂点初始表数量的确定。表数量太多维护比较麻烦表数量太少又可能导致单表性能存在问题。 ③优点表分布比较均匀。 ④缺点扩充新的表很麻烦所有数据都要重分布。
3雪花算法主角登场
雪花算法是由Twitter公布的分布式主键生成算法它能够保证不同表的主键的不重复性以及相同表的主键的有序性。具体上诉已讲解
四、雪花算法优缺点
1、优点
毫秒数在高维自增序列在低位整个ID都是趋势递增的不依赖数据库等第三方系统以服务的方式部署稳定性更高生成ID的性能也是非常高的可以根据自身业务特性分配bit位非常灵活
2、缺点
– 依赖机器时钟如果机器时钟回拨会导致重复ID生成
在单机上是递增的但由于涉及到分布式环境每台机器上的时钟不可能完全同步有时候会出现不是全局递增的情况此缺点可以认为无所谓一般分布式ID只要求趋势递增并不会严格要求递增90%的需求只要求趋势递增。
3、其它补充
为了解决时钟回拨问题导致ID重复后面有人专门提出了解决的方案
百度开源的分布式唯一ID生成器 UidGeneratorLeaf - 美团点评分布式ID生成系统 总结
以上就是雪花算法详细讲解的相关知识点希望对你有所帮助。 积跬步以至千里积怠惰以至深渊。时代在这跟着你一起努力哦
