图解各路分布式ID生成算法

最新推荐文章于 2024-03-12 16:42:31 发布
最新推荐文章于 2024-03-12 16:42:31 发布
阅读量909 收藏
点赞数
分类专栏： 面试哪些事儿 文章标签： uuid 分布式id 分布式 snowflake 唯一性
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/i6448038/article/details/101875593
版权
面试哪些事儿 专栏收录该内容
12 篇文章 42 订阅 ¥19.90 ¥99.00
订阅专栏
本文探讨了分布式系统中全局唯一ID的生成策略，包括基于数据库主键自增的Flickr方案、Redis原子操作、UUID以及Twitter的Snowflake算法。Flickr方案利用MySQL自增主键，但扩展性和安全性有限；Redis提供高性能但面临重复ID风险；UUID虽然全局唯一但存储不便；Snowflake算法则结合时间戳、工作机器ID和序列号生成趋势递增且不依赖第三方的ID。
摘要由CSDN通过智能技术生成

在分布式系统中，通常会用到分布式ID来标注数据的唯一性，而分布式ID的生成方式又多种多样，今天我们就来讨论一下主流的分布式ID生成策略。

分布式ID基本需求

  • 全局唯一
  • 趋势递增
  • 信息安全

全局唯一

这是基本要求，不必解释

趋势递增

为什么要趋势递增呢？
第一，由于我们的分布式ID，是用来标识数据唯一性的，所以多数时候会被定义为主键或者唯一索引。
第二，并且绝大多数互联网公司使用的数据库是：MySQL，存储引擎为innoDB。
对于B + Tree这个数据结构来讲，数据以自增顺序来写入的话，b+tree的结构不会时常被打乱重塑，存取效率是最高的。

信息安全

由于数据是递增的，所以，恶意用户的可以根据当前ID推测出下一个，非常危险，所以，我们的分布式ID尽量做到不易被破解。

数据库主键自增(Flicker)

基于数据库主键自增的方案，名为Flicker。
主要是利用MySQL的自增

了解本专栏 订阅专栏 解锁全文
分布式共识算法——Paxos算法（图解）
流楚丶格念的博客
11-06 6542
准备阶段：Proposer负责接收 client 请求并产生提案，必须由多数派 Acceptor 批准通过提案接受阶段：提案通过后，再将要执行的修改操作广播给 Acceptor，这次仍然多数派通过，此修改才能生效，可以返回响应给客户端。
snowflake-C语言实现分布式自增有序的唯一ID生成算法
01-05
We have retired the initial release of Snowflake and working on open sourcing the next version based on Twitter-server, in a form that can run anywhere without requiring Twitter's own infrastructure services. The initial version, released in 2010, was based on Apache Thrift and it predated Finagle, our building block for RPC services at Twitter. The Snowflake we're using internally is a full rewrite and heavily relies on existing infrastructure at Twitter to run. We cannot commit to a date but we're doing our best to add necessary features to make Snowflake fit for many environments outside of Twitter. Source code is still in the repository and is reachable from snowflake-2010 tag. We won't be accepting pull requests or responding to issues for the retired release.
SnowFlake--分布式id生成算法
acw0866的博客
01-02 880
分布式id生成算法的有很多种，Twitter的SnowFlake就是其中经典的一种。 概述 SnowFlake算法生成id的结果是一个64bit大小的整数，它的结构如下图： 1位，不用。二进制中最高位为1的都是负数，但是我们生成的id一般都使用整数，所以这个最高位固定是0 41位，用来记录时间戳（毫秒）。 41位可以表示241−1个数字， 如果只用来表...
超简单的分布式ID生成方案！美团开源框架介绍
磊哥聊Java
07-24 428
目录阐述背景Leaf snowflake 模式介绍Leaf segment 模式介绍Leaf 改造支持 RPC阐述背景不吹嘘，不夸张，项目中用到 ID 生成的场景确实挺多。比如业务要做幂...
012 分布式统一ID生成策略-统一ID生成服务的架构设计思路
诸般世界
07-25 1124
在实际的工作中，尤其在高并发的场景下，我们一定要对任何外部服务做好兜底策略，也就是说，如果我们调用外部的统一ID生成服务失败，那么我们也要有一个自己服务内部的ID生成策略用来进行最终的兜底（唯一ID生成方式及机器码+时间戳+自增）。很显然，在高并发巨大的流量冲击下，任何的服务都不可能保障100%高性能，低延迟的提供服务，我们的统一ID生成服务也是如此，那么我们要尽最大的努力保障ID...
9种分布式ID生成方式，总有一款适合你
最新发布
程序员高级码农的博客
03-12 1244
通过DefaultUidGenerator的实现可知，它对时钟回拨的处理比较简单粗暴。
分布式共识算法——Raft算法（图解）
流楚丶格念的博客
11-06 2245
Paxos 和 Raft 都是分布式一致性算法，这个过程如同投票选举领袖（Leader），参选者（Candidate）需要说服大多数投票者（Follower）投票给他，一旦选举出领袖，就由领袖发号施令。Paxos 和 Raft 都是分布式一致性算法，这个过程如同投票选举领袖（Leader），参选者（Candidate）需要说服大多数投票者（Follower）投票给他，一旦选举出领袖，就由领袖发号施令。在 Raft 算法中充当逻辑时钟的作用，使得服务器节点可以查明一些过期的信息（比如过期的 Leader）。
分布式一致性算法 - raft 图解
zzzsmm的博客
06-13 929
前言 应用服务架构的发展是一个循序渐进的过程，从最开始的单机架构逐步演化到如今的基于微服务的分布式架构。与此同时，应用服务最底层的数据支撑 – 数据存储服务也逐渐由单节点单副本逐步往多节点多副本的方向演进。 多副本节点通过数据复制技术，可以实现分布式容灾，提高服务的可用性，降低单点故障带来的风险；同时多节点部署，还可以很大程度上提高整个系统的吞吐量，降低访问延迟。但是与此同时，基于 CAP 理论，多副本技术也带来了一致性的问题。 raft 算法的诞生正是为了解决在分布式场景之下的数据一致性问题。本文我们将从
分布式ID生成服务，真的有必要搞一个
技术分享
07-23 318
目录 阐述背景 Leaf snowflake 模式介绍 Leaf segment 模式介绍 Leaf 改造支持 RPC 阐述背景 不吹嘘，不夸张，项目中用到 ID 生成的场景确实挺多。比如业务要做幂等的时候，如果没有合适的业务字段去做唯一标识，那就需要单独生成一个唯一的标识，这个场景相信大家不陌生。 很多时候为了图方便可能就是写一个简单的 ID 生成工具类，直接开用。做的好点的可能单独出一个 Jar 包让其他项目依赖，做的不好的很有可能就是 Copy 了 N 份一样的代码。 单独搞一个独立的 ID 生成
Flicker_量测原理及应用.pdf
08-11
Flicker_量测原理及应用.pdf，液晶面板Flicker量测，计算方法，包含Flicker Measurement by Contrast Method，Flicker Measurement by JEITA Method，Flicker Measurement by VESA Method
（三）架构篇之分布式id生成策略
Carry_Jey
10-24 265
  分布式系统常见的一种场景就是要求id全局唯一，以下介绍七种，并分析优劣。 1、利用数据库自增id特性。 优点： 1）简单。 2）ID有序排列，分页和排序方便，方便统计数据增长。 缺点： 1）可用性难以保证：数据库常见架构是一主多从+读写分离，生成自增ID是写请求，主库挂了就玩不转了 2）扩展性差，性能有上限：因为写入是单点，数据库主库的写性能决定ID的生成性能上限，并且难以扩展...
【微服务】--分布式 ID
qq_46489900的博客
02-08 922
分布式下如何解决多个数据中重复的主键ID分布式下带来的数据库ID问题解决方案 分布式下带来的数据库ID问题 在分布式下每个服务可能有至少大于 1 的台的部署，这些服务如果都拥有独立的数据库，或者N个微服务拥有N-1个数据库（有两个微服务使用了同一个数据库）。大多数公司都是使用 MySql 数据库， 在分库分表后，由于数据库 ID 的唯一性且自增，会发生 ID 冲突的情况。因此需要某个服务在多台部署后每台的 ID 与其他服务中的 ID 不重复，即使用全局 ID。 解决方案 UUID 在插入新的行时不使用主键
九种分布式ID生成算法详解
Crystalqy的博客
09-04 2万+
一、分布式ID简介 1、什么是分布式ID？ 在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。 但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；例如我们的订单，需要有一个全局唯一标识的订单号，这个订单号就是分布式ID 2、分布式ID需要满足那些条件？ 全局唯一：必须保证ID是全局性唯一的，基本要求 高可用： 高性能：高可
ffmpeg的deflicker算法
WX_Chen的博客
09-11 799
ffmpeg -threads 16 -i xxx.mp4 -vf "deflicker" -preset fast -crf 18 deflicker.mp4 https://grimore.org/fuss/ffmpeg ffmpeg -threads 16 -i xxx.mp4 -filter_complex deflicker=size=15:mode=am -preset fast -crf 18 deflicker.mp4 ffmpeg -s 1350x1080 -i input.yuv -
flickr 的全局主键生成方案
乐乐的专栏
12-05 2076
flickr提供了一个扩展的更好的方案： 他们把 user_index 抽出一个专门用作生成
HDR算法整理
不以己悲的博客
01-15 4882
详解HDR的三个标准——HLG/HDR10/Dolby Vision HDR 相关的术语（中英对照） https://blog.csdn.net/Aoulun/article/details/104278502 HDR视频色调映射算法（之一：各种算法对应文章） https://blog.csdn.net/Aoulun/article/details/104411068 HDR视频色调映射算法（之二：Adaptive temporal TMO） https://blog.csdn.net/Aoulun/art
TFT模块闪屏（Flicker)现象分析
热门推荐
撒哈拉的绿洲
01-14 3万+
一、FLICKER         FLICKER俗称抬头纹，是我们遇到较多的一种闪屏。理想状态下Vcom的中心值与Vpixel的中心值一致且VpixelH和VpixelL的差值与VcomH和VcomL的差值一致，在这样的情况下不会出现FLICKER现象。当这两个电压的中心值或差值出现偏差时，就会出现FLICKER现象。对于FLICKER，如果采用line inversion，则现象如下：拿一个
Flicker方案用于生成自增ID
Huohuo
05-31 1599
主要思路采用了MySQL自增长ID的机制(auto_increment + replace into)建表语句：CREATE TABLE `tb_seqno` ( `a` varchar(1) NOT NULL, `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`), UNIQUE KEY `uk_a` (`a`) ) E...
图解算法：算法入门的通俗指南
资源摘要信息:"《算法图解》这本书是一本针对算法入门的经典教程，其内容以图解的方式呈现，使得读者即使没有深厚的数学或计算机科学背景也能够理解和掌握。书中涵盖了一些基础的算法概念和数据结构，例如排序算法、...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

菜刚

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值