成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

架構(gòu)師究竟要不要懂細(xì)節(jié)?分布式 ID 生成的六種方法

開發(fā) 架構(gòu)
幾乎所有的業(yè)務(wù)系統(tǒng),都有生成一個(gè)唯一記錄標(biāo)識(shí)的需求,例如:消息ID,訂單ID,帖子ID,那如何高效生成趨勢有序的全局唯一ID呢?

幾乎所有的業(yè)務(wù)系統(tǒng),都有生成一個(gè)唯一記錄標(biāo)識(shí)的需求,例如:消息ID,訂單ID,帖子ID...

這個(gè)ID,在數(shù)據(jù)庫中往往用作主鍵,且有排序與分頁的查詢需求。這也是分布式ID生成算法的兩大核心需求:

  • 全局唯一;
  • 趨勢遞增;

如何高效生成趨勢有序的全局唯一ID,是每一個(gè)工程師都會(huì)遇到的問題。

方法一:數(shù)據(jù)庫auto-inc-id法

借助數(shù)據(jù)庫的auto_increment來生成全局唯一遞增ID。

優(yōu)點(diǎn):

  • 簡單,使用數(shù)據(jù)庫已有的功能;
  • 能夠保證唯一性;
  • 能夠保證遞增性;
  • 步長固定;

不足:

  • 可用性難以保證,需要依賴數(shù)據(jù)庫的高可用;
  • 擴(kuò)展性差,性能有上限,數(shù)據(jù)庫主庫的寫性能決定ID的生成性能上限;

改進(jìn)方法:

  • 冗余主庫,避免寫入單點(diǎn);
  • 數(shù)據(jù)水平切分,保證各主庫生成的ID不重復(fù);

改進(jìn)后,數(shù)據(jù)庫的寫壓力依然很大,每次生成ID都要訪問數(shù)據(jù)庫。為了解決這個(gè)問題,引出了第二個(gè)常見的方案。

方法二:批量ID生成服務(wù)

數(shù)據(jù)庫寫壓力大,是因?yàn)槊看紊蒊D都訪問了數(shù)據(jù)庫,可以使用批量的方式降低數(shù)據(jù)庫寫壓力。

ID生成服務(wù)假設(shè)每次批量拉取6個(gè)ID,服務(wù)訪問數(shù)據(jù)庫,將當(dāng)前ID的最大值修改為5,這樣應(yīng)用訪問ID生成服務(wù)索要ID,ID生成服務(wù)不需要每次訪問數(shù)據(jù)庫,就能依次派發(fā)0,1,2,3,4,5這些ID了。

當(dāng)ID發(fā)完后,再將ID的最大值修改為11,就能再次派發(fā)6,7,8,9,10,11這些ID了,于是數(shù)據(jù)庫的壓力就降低到原來的1/6。

優(yōu)點(diǎn):

  • 保證了ID生成的絕對(duì)遞增有序;
  • 大大的降低了數(shù)據(jù)庫的壓力,ID生成可以做到每秒生成幾萬幾十萬個(gè);

同時(shí),服務(wù)也可以做集群化,只是稍微要注意數(shù)據(jù)一致性問題,具體CAS優(yōu)化方案在《巧用CAS實(shí)現(xiàn)分布式ID生成器!》中有詳細(xì)介紹,不再展開。

方法三:uuid/guid法

不管是通過數(shù)據(jù)庫,還是通過服務(wù)來生成ID,業(yè)務(wù)方都需要進(jìn)行一次遠(yuǎn)程調(diào)用,比較耗時(shí)。有沒有一種本地生成ID的方法,即高性能,又時(shí)延低呢?

uuid是一種常見的方案:

string ID =GenUUID();

優(yōu)點(diǎn):

  • 本地生成ID,不需要進(jìn)行遠(yuǎn)程調(diào)用,時(shí)延低;
  • 擴(kuò)展性好,基本可以認(rèn)為沒有性能上限;

不足:

  • 無法保證趨勢遞增
  • uuid過長,往往用字符串表示,作為主鍵建立索引查詢效率低,常見優(yōu)化方案為“轉(zhuǎn)化為兩個(gè)uint64整數(shù)存儲(chǔ)”。

方法四:取當(dāng)前毫秒數(shù)

uuid是一個(gè)本地算法,生成性能高,但無法保證趨勢遞增,且作為字符串ID檢索效率低,有沒有一種能保證遞增的本地算法呢?

取當(dāng)前毫秒數(shù)是一種常見方案:

uint64 ID = GenTimeMS();

優(yōu)點(diǎn):

  • 本地生成ID,不需要進(jìn)行遠(yuǎn)程調(diào)用,時(shí)延低;
  • 生成的ID趨勢遞增;
  • 生成的ID是整數(shù),建立索引后查詢效率高;

缺點(diǎn):如果并發(fā)量超過1000,會(huì)生成重復(fù)的ID。

當(dāng)然,使用微秒可以降低沖突概率,但每秒最多只能生成1000000個(gè)ID,再多的話就一定會(huì)沖突了,所以使用微秒并不從根本上解決問題。

方法五:類snowflake算法

snowflake是twitter開源的分布式ID生成算法,其核心思想為,一個(gè)long型的ID:

  • 41bit作為毫秒數(shù);
  • 10bit作為機(jī)器(服務(wù))編號(hào);
  • 12bit作為毫秒內(nèi)序列號(hào);

算法單機(jī)每秒內(nèi)理論上最多可以生成1000*(2^12),也就是400W的ID,1024臺(tái)機(jī)器(服務(wù))每秒能生活40Y的ID,完全能滿足業(yè)務(wù)的需求。

借鑒snowflake的思想,結(jié)合公司的業(yè)務(wù)邏輯和并發(fā)量,可以實(shí)現(xiàn)自己的分布式ID生成算法。

舉例,假設(shè)某公司ID生成的需求如下:

  • 單機(jī)高峰并發(fā)量小于1W,預(yù)計(jì)未來10年單機(jī)高峰并發(fā)量小于10W;
  • 有2個(gè)機(jī)房,預(yù)計(jì)未來10年機(jī)房數(shù)量小于4個(gè);
  • 每個(gè)機(jī)房機(jī)器數(shù)小于100臺(tái);
  • 目前有5個(gè)業(yè)務(wù)線有ID生成需求,預(yù)計(jì)未來業(yè)務(wù)線數(shù)量小于10個(gè);

我們應(yīng)該怎么來設(shè)計(jì)公司獨(dú)特的ID生成算法呢?

其一,毫秒位數(shù)考慮。

假設(shè)系統(tǒng)至少運(yùn)行10年,那至少需要10年*365天*24小時(shí)*3600秒*1000毫秒=320*10^9,差不多預(yù)留39bit給毫秒數(shù)。

其二,1毫秒內(nèi)序列號(hào)考慮。

每秒的單機(jī)高峰并發(fā)量小于10W,即平均每毫秒的單機(jī)高峰并發(fā)量小于100,差不多預(yù)留7bit給每毫秒內(nèi)序列號(hào)。

其三,機(jī)房數(shù)少于4個(gè),預(yù)留2bit給機(jī)房標(biāo)識(shí)。

其四,每個(gè)機(jī)房機(jī)器小于100臺(tái),預(yù)留7bit給每個(gè)機(jī)房內(nèi)的服務(wù)器標(biāo)識(shí)。

其五,業(yè)務(wù)線小于10個(gè),預(yù)留4bit給業(yè)務(wù)線標(biāo)識(shí)。

這樣設(shè)計(jì)的64bit標(biāo)識(shí),可以保證:

  • 每個(gè)業(yè)務(wù)線、每個(gè)機(jī)房、每個(gè)機(jī)器生成的ID都是不同的;
  • 同一個(gè)機(jī)器,每個(gè)毫秒內(nèi)生成的ID都是不同的;
  • 同一個(gè)機(jī)器,同一個(gè)毫秒內(nèi),以序列號(hào)區(qū)區(qū)分保證生成的ID是不同的;
  • 將毫秒數(shù)放在最高位,保證生成的ID是趨勢遞增的;

以上,希望大家有收獲。

知其然,知其所以然。思路比結(jié)論更重要。

擴(kuò)展閱讀:https://github.com/twitter-archive/snowflake

責(zé)任編輯:趙寧寧 來源: 架構(gòu)師之路
相關(guān)推薦

2020-11-17 09:17:58

框架組件基礎(chǔ)服務(wù)

2018-01-24 07:58:47

框架組件技術(shù)棧開源

2024-09-30 05:38:48

2015-07-15 10:25:44

SDN物理交換機(jī)

2019-10-23 20:19:26

Python 開發(fā)編程語言

2021-11-24 22:39:03

手機(jī)系統(tǒng)功能

2025-01-03 08:48:20

列表推導(dǎo)式Python編程

2011-02-24 10:56:34

人才

2010-10-08 11:13:22

MySQL修改密碼

2023-09-06 08:00:00

ChatGPT數(shù)據(jù)分析

2025-01-02 08:21:32

2016-11-29 09:12:21

數(shù)據(jù)庫分布式ID

2020-03-23 07:30:57

數(shù)據(jù)庫運(yùn)維架構(gòu)

2017-10-30 08:52:27

vSAN架構(gòu)RAID

2021-12-06 06:58:50

List重復(fù)數(shù)據(jù)

2024-04-18 09:24:32

分布式ID分庫分表

2023-04-03 20:29:00

Linux環(huán)境變量

2023-04-26 08:41:16

Git撤消更改

2022-06-09 08:46:58

ITCIO職業(yè)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 91在线观看 | 久精品久久 | 91免费在线播放 | 国产成人免费视频网站高清观看视频 | 国产精品美女久久久久久免费 | www.狠狠干| 国产亚洲欧美日韩精品一区二区三区 | 日本高清视频在线播放 | 古装人性做爰av网站 | 中文字幕a√ | 精品免费视频 | 国产精品久久久爽爽爽麻豆色哟哟 | 午夜精品在线 | 日本久久久久久 | 99爱在线观看 | 一区二区日本 | 亚洲欧美综合 | 日韩中文字幕在线视频 | 逼逼网| 欧美精品综合 | 国产a区 | av网站免费观看 | 久久99精品视频 | 国内激情av片 | 国产成人a亚洲精品 | 中文字幕视频一区 | 亚洲av毛片| 粉嫩高清一区二区三区 | 国产丝袜一区二区三区免费视频 | 欧美在线亚洲 | 国外成人在线视频 | 欧美日韩亚洲国产 | 91原创视频 | 中文字幕第十页 | 午夜影院污 | 国产精品日韩一区 | 亚洲综合色网站 | 激情网站在线 | 国产精品久久久久一区二区三区 | 国产精品资源在线 | 国产精品久久久久久久久久久新郎 |