日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
分布式架構(gòu)系統(tǒng)生成全局唯一序列號的一個思路

分布式架構(gòu)系統(tǒng)生成全局唯一序列號的一個思路

作者：佚名 2017-11-22 09:46:53

存儲

存儲軟件

分布式 分布式架構(gòu)下，唯一序列號生成是我們在設(shè)計(jì)一個系統(tǒng)，尤其是數(shù)據(jù)庫使用分庫分表的時候常常會遇見的問題。當(dāng)分成若干個sharding表后，如何能夠快速拿到一個唯一序列號，是經(jīng)常遇到的問題。

 一、相關(guān)背景

分布式架構(gòu)下，唯一序列號生成是我們在設(shè)計(jì)一個系統(tǒng)，尤其是數(shù)據(jù)庫使用分庫分表的時候常常會遇見的問題。當(dāng)分成若干個sharding表后，如何能夠快速拿到一個唯一序列號，是經(jīng)常遇到的問題。

在攜程賬號數(shù)據(jù)庫遷移MySql過程中，我們對用戶ID的生成方案進(jìn)行了新的設(shè)計(jì)，要求能夠支撐攜程現(xiàn)有的新用戶注冊體量。

本文通過攜程用戶ID生成器的實(shí)現(xiàn)，希望能夠?qū)Υ蠹以O(shè)計(jì)分庫分表的唯一id有一些新的思路。

二、特性需求

  1. 全局唯一
  2. 支持高并發(fā)
  3. 能夠體現(xiàn)一定屬性
  4. 高可靠，容錯單點(diǎn)故障
  5. 高性能

三、業(yè)內(nèi)方案

生成ID的方法有很多，來適應(yīng)不同的場景、需求以及性能要求。

常見方式有：

1、利用數(shù)據(jù)庫遞增，全數(shù)據(jù)庫唯一。

優(yōu)點(diǎn)：明顯，可控。

缺點(diǎn)：單庫單表，數(shù)據(jù)庫壓力大。

2、UUID， 生成的是length=32的16進(jìn)制格式的字符串，如果回退為byte數(shù)組共16個byte元素，即UUID是一個128bit長的數(shù)字，一般用16進(jìn)制表示。

優(yōu)點(diǎn)：對數(shù)據(jù)庫壓力減輕了。

缺點(diǎn)：但是排序怎么辦？

此外還有UUID的變種，增加一個時間拼接，但是會造成id非常長。

3、twitter在把存儲系統(tǒng)從MySQL遷移到Cassandra的過程中由于Cassandra沒有順序ID生成機(jī)制，于是自己開發(fā)了一套全局唯一ID生成服務(wù)：Snowflake。

  1. 41位的時間序列（精確到毫秒，41位的長度可以使用69年）
  2. 10位的機(jī)器標(biāo)識（10位的長度最多支持部署1024個節(jié)點(diǎn)）
  3. 12位的計(jì)數(shù)順序號（12位的計(jì)數(shù)順序號支持每個節(jié)點(diǎn)每毫秒產(chǎn)生4096個ID序號） ***位是符號位，始終為0。

優(yōu)點(diǎn)：高性能，低延遲；獨(dú)立的應(yīng)用；按時間有序。

缺點(diǎn)：需要獨(dú)立的開發(fā)和部署。

4、Redis生成ID

當(dāng)使用數(shù)據(jù)庫來生成ID性能不夠要求的時候，我們可以嘗試使用Redis來生成ID。這主要依賴于Redis是單線程的，所以也可以用生成全局唯一的ID?？梢杂肦edis的原子操作INCR和INCRBY來實(shí)現(xiàn)。

可以使用Redis集群來獲取更高的吞吐量。假如一個集群中有5臺Redis?？梢猿跏蓟颗_Redis的值分別是1,2,3,4,5，然后步長都是5。各個Redis生成的ID為：

A：1,6,11,16,21

B：2,7,12,17,22

C：3,8,13,18,23

D：4,9,14,19,24

E：5,10,15,20,25

比較適合使用Redis來生成每天從0開始的流水號。比如訂單號=日期+當(dāng)日自增長號?？梢悦刻煸赗edis中生成一個Key，使用INCR進(jìn)行累加。

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

不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

數(shù)字ID天然排序，對分頁或者需要排序的結(jié)果很有幫助。

使用Redis集群也可以防止單點(diǎn)故障的問題。

缺點(diǎn)：

如果系統(tǒng)中沒有Redis，還需要引入新的組件，增加系統(tǒng)復(fù)雜度。

需要編碼和配置的工作量比較大，多環(huán)境運(yùn)維很麻煩，

在開始時，程序?qū)嵗?fù)載到哪個redis實(shí)例一旦確定好，未來很難做修改。

5.   Flicker的解決方案

因?yàn)镸ySQL本身支持auto_increment操作，很自然地，我們會想到借助這個特性來實(shí)現(xiàn)這個功能。

Flicker在解決全局ID生成方案里就采用了MySQL自增長ID的機(jī)制（auto_increment + replace into + MyISAM）。

6．還有其他一些方案，比如京東淘寶等電商的訂單號生成。因?yàn)橛唵翁柡陀脩鬷d在業(yè)務(wù)上的區(qū)別，訂單號盡可能要多些冗余的業(yè)務(wù)信息，比如：

滴滴：時間+起點(diǎn)編號+車牌號

淘寶訂單：時間戳+用戶ID

其他電商：時間戳+下單渠道+用戶ID，有的會加上訂單***個商品的ID。

而用戶ID，則要求含義簡單明了，包含注冊渠道即可，盡量短。

四、最終方案

最終我們選擇了以flicker方案為基礎(chǔ)進(jìn)行優(yōu)化改進(jìn)。具體實(shí)現(xiàn)是，單表遞增，內(nèi)存緩存號段的方式。

首先建立一張表，像這樣：

SEQUENCE_GENERATOR_TABLE

id   stub

1    192.168.1.1

其中id是自增的，stub是服務(wù)器ip

因?yàn)樾聰?shù)據(jù)庫采用mysql，所以使用mysql的獨(dú)有語法 replace to來更新記錄來獲得唯一id，例如這樣：

  
 
 
 
    
   
  
  
  
  1. REPLACE INTO SEQUENCE_GENERATOR_TABLE (stub) VALUES (“192.168.1.1”); 
    2.

再用SELECT id FROM SEQUENCE_GENERATOR_TABLEWHERE stub = “192.168.1.1”;   把它拿回來。

到上面為止，我們只是在單臺數(shù)據(jù)庫上生成ID，從高可用角度考慮，接下來就要解決單點(diǎn)故障問題。

這也就是為什么要有這個機(jī)器ip字段呢？就是為了防止多服務(wù)器同時更新數(shù)據(jù)，取回的id混淆的問題。

所以，當(dāng)多個服務(wù)器的時候，這個表是這樣的：

id   stub

5    192.168.1.1

2    192.168.1.2

3    192.168.1.3

4    192.168.1.4

每臺服務(wù)器只更新自己的那條記錄，保證了單線程操作單行記錄。

這時候每個機(jī)器拿到的分別是5,2,3,4這4個id。

至此，我們似乎解決這個服務(wù)器隔離，原子性獲得id的問題，也和flicker方案基本一致。

但是追根溯源，在原理上，方案還是依靠數(shù)據(jù)庫的特性，每次生成id都要請求db，開銷很大。我們對此又進(jìn)行優(yōu)化，把這個id作為一個號段，而并不是要發(fā)出去的序列號，并且這個號段是可以配置長度的，可以1000也可以10000，也就是對拿回來的這個id放大多少倍的問題。

OK，我們從DB一次查詢操作的開銷，拿回來了1000個用戶id到內(nèi)存中了。

現(xiàn)在的問題就是要解決同一臺服務(wù)器在高并發(fā)場景，讓大家順序拿號，別拿重復(fù)，也別漏拿。

這個問題簡單來說，就是個保持這個號段對象隔離性的問題。

AtomicLong是個靠譜的辦法。

當(dāng)***次拿回號段id后，擴(kuò)大1000倍，然后賦值給這個變量atomic，這就是這個號段的***個號碼。

  
 
 
 
    
   
  
  
  
  1. atomic.set(n * 1000); 
    2.

并且內(nèi)存里保存一下***id，也就是這個號段的***一個號碼

  
 
 
 
    
   
  
  
  
  1. currentMaxId = (n + 1) * 1000; 
    2.

一個號段就形成了。

此時每次有請求來取號時候，判斷一下有沒有到***一個號碼，沒有到，就拿個號，走人。

  
 
 
 
    
   
  
  
  
  1. Long uid = atomic.incrementAndGet(); 
    2.

如果到達(dá)了***一個號碼，那么阻塞住其他請求線程，最早的那個線程去db取個號段，再更新一下號段的兩個值，就可以了。

這個方案，核心代碼邏輯不到20行，解決了分布式系統(tǒng)序列號生成的問題。

這里有個小問題，就是在服務(wù)器重啟后，因?yàn)樘柎a緩存在內(nèi)存，會浪費(fèi)掉一部分用戶ID沒有發(fā)出去，所以在可能頻繁發(fā)布的應(yīng)用中，盡量減小號段放大的步長n，能夠減少浪費(fèi)。

經(jīng)過實(shí)踐，性能的提升遠(yuǎn)遠(yuǎn)重要于浪費(fèi)一部分id。

如果再追求***，可以監(jiān)聽spring或者servlet上下文的銷毀事件，把當(dāng)前即將發(fā)出去的用戶ID保存起來，下次啟動時候再撈回內(nèi)存即可。

五、上線效果

運(yùn)行5個多月，十分穩(wěn)定。

SOA服務(wù)平均響應(yīng)時間 0.59毫秒；

客戶端調(diào)用平均響應(yīng)時間2.52毫秒；

附流程圖：


文章題目：分布式架構(gòu)系統(tǒng)生成全局唯一序列號的一個思路
轉(zhuǎn)載注明：http://www.5511xx.com/article/cciship.html