懂做网站怎么赚钱,莆田市荔城区建设局网站,企业网站php开源系统,vs2017做网站什么是分布式系统唯一ID 在复杂分布式系统中#xff0c;往往需要对大量的数据和消息进行唯一标识。 如在金融、电商、支付、等产品的系统中#xff0c;数据日渐增长#xff0c;对数据分库分表后需要有一个唯一ID来标识一条数据或消息#xff0c;数据库的自增ID显然不能满足… 什么是分布式系统唯一ID 在复杂分布式系统中往往需要对大量的数据和消息进行唯一标识。 如在金融、电商、支付、等产品的系统中数据日渐增长对数据分库分表后需要有一个唯一ID来标识一条数据或消息数据库的自增ID显然不能满足需求此时一个能够生成全局唯一ID的系统是非常必要的。 分布式系统唯一ID的特点 全局唯一性不能出现重复的ID号既然是唯一标识这是最基本的要求。 趋势递增在MySQL InnoDB引擎中使用的是聚集索引由于多数RDBMS使用B-tree的数据结构来存储索引数据在主键的选择上面我们应该尽量使用有序的主键保证写入性能。 单调递增保证下一个ID一定大于上一个ID例如事务版本号、IM增量消息、排序等特殊需求。 信息安全如果ID是连续的恶意用户的扒取工作就非常容易做了直接按照顺序下载指定URL即可如果是订单号就更危险了竞对可以直接知道我们一天的单量。所以在一些应用场景下会需要ID无规则、不规则。 同时除了对ID号码自身的要求业务还对ID号生成系统的可用性要求极高想象一下如果ID生成系统瘫痪这就会带来一场灾难。 由此总结下一个ID生成系统应该做到如下几点 平均延迟和TP999延迟都要尽可能低 可用性5个9 高QPS。 分布式系统唯一ID的实现方案 1.UUID UUIDUniversally Unique Identifier的标准型式包含32个16进制数字以连字号分为五段形式为8-4-4-4-12的36个字符示例550e8400-e29b-41d4-a716-446655440000到目前为止业界一共有5种方式生成UUID详情见IETF发布的UUID规范 A Universally Unique IDentifier UUID URN Namespace。 优点 性能非常高本地生成没有网络消耗。 缺点 不易于存储UUID太长16字节128位通常以36长度的字符串表示很多场景不适用。 信息不安全基于MAC地址生成UUID的算法可能会造成MAC地址泄露这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。 ID作为主键时在特定的环境会存在一些问题比如做DB主键的场景下UUID就非常不适用 2.数据库生成 以MySQL举例利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增每次业务使用下列SQL读写MySQL得到ID号。 这种方案的优缺点如下 优点 非常简单利用现有数据库系统的功能实现成本小有DBA专业维护。 ID号单调自增可以实现一些对ID有特殊要求的业务。 缺点 强依赖DB当DB异常时整个系统不可用属于致命问题。配置主从复制可以尽可能的增加可用性但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。 ID发号性能瓶颈限制在单台MySQL的读写性能。 3.Redis生成ID 当使用数据库来生成ID性能不够要求的时候我们可以尝试使用Redis来生成ID。 这主要依赖于Redis是单线程的所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。 比较适合使用Redis来生成每天从0开始的流水号。比如订单号日期当日自增长号。可以每天在Redis中生成一个Key使用INCR进行累加。 优点 1不依赖于数据库灵活方便且性能优于数据库。 2数字ID天然排序对分页或者需要排序的结果很有帮助。 缺点 1如果系统中没有Redis还需要引入新的组件增加系统复杂度。 2需要编码和配置的工作量比较大。 4.利用zookeeper生成唯一ID zookeeper主要通过其znode数据版本来生成序列号可以生成32位和64位的数据版本号客户端可以使用这个版本号来作为唯一的序列号。 很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper并且是多步调用API如果在竞争较大的情况下需要考虑使用分布式锁。因此性能在高并发的分布式环境下也不甚理想。 5.snowflake雪花算法方案 这种方案大致来说是一种以划分命名空间UUID也算由于比较常见所以单独分析来生成ID的一种算法这种方案把64-bit分别划分成多段分开来标示机器、时间等比如在snowflake中的64-bit分别表示如下图图片来自网络所示 41-bit的时间可以表示1L41/1000L*3600*24*36569年的时间10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求还可以将10-bit分5-bit给IDC分5-bit给工作机器。这样就可以表示32个IDC每个IDC下可以有32台机器可以根据自身需求定义。12个自增序列号可以表示2^12个ID理论上snowflake方案的QPS约为409.6w/s这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。 这种方式的优缺点是 优点 毫秒数在高位自增序列在低位整个ID都是趋势递增的。 不依赖数据库等第三方系统以服务的方式部署稳定性更高生成ID的性能也是非常高的。 可以根据自身业务特性分配bit位非常灵活。 缺点 强依赖机器时钟如果机器上时钟回拨会导致发号重复或者服务会处于不可用状态。 应用举例Mongdb objectID MongoDB官方文档 ObjectID可以算作是和snowflake类似方法通过“时间机器码pidinc”共12个字节通过4323的方式最终标识成一个24长度的十六进制字符。 你可能也喜欢: 阿里P8架构师谈分布式Session共享的4类技术方案与优劣势比较阿里P8架构师谈分布式事务的解决方案以及原理、总结阿里P8架构师谈分布式锁的3种实现数据库、缓存、Zookeeper)阿里P8架构师谈架构设计之数据库垂直、水平拆分六大原则 阿里P8架构师谈单点登录的原理、来源、实现、以及技术方案比较 一篇文章彻底搞懂“分布式事务”
