flickr 的全域性主鍵生成方案

2021-07-08 15:09:51 字數 1465 閱讀 3071

類似於京東的資料庫設計,我們的使用者分庫有 shop_1/2/3/4 … 那麼uid怎樣生成?

現在的做法是在用一張索引表 shop_share.user_index 取其自增主鍵,insert_id 便是uid。但缺點是,有單點負載的風險。

flickr提供了乙個擴充套件的更好的方案: 他們把 user_index 抽出乙個專門用作生成 uid 的表,例如取名叫 uid_sequence,並拆成若干的字表,自增步長設定為2(機器數目),這兩張表可以放在不同的物理機器上。 其中乙個表負責生成奇數uid,另乙個負責生成偶數uid

比如建立64位的自增id:

create

table

`uid_sequence` (

`id`

bigint(20) unsigned not

null auto_increment,

`stub`

char(1) not

null

default

'',

primary

key (`id`),

unique

key`stub` (`stub`)

) engine=myisam;

select * from uid_sequence 輸出:

+-------------------+------+  

| id | stub |

+-------------------+------+

| 72157623227190423 | a |

如果我需要乙個全域性的唯一的64位uid,則執行:

replace

into uid_sequence (stub) values ('a');

select

last_insert_id();

這裡flickr使用兩台資料庫作為自增序列生成,通過這兩台機器做主備和負載均衡。

ticketserver1: 

auto-increment-increment = 2

auto-increment-offset = 1

ticketserver2:

auto-increment-increment = 2

auto-increment-offset = 2

因為是兩條sql語句,所以這兩條語句之間會不會有併發問題?

答案是不會,因為 last_insert_id() 是 connection 級別的,是單個連線客戶端裡執行的insert語句最近一條,客戶端之間是不會影響,沒必要鎖定和事務處理。

基於mysql的全域性ID生成方案

背景介紹 隨著資料庫容量的增加,在對資料庫完成垂直拆分效果不是很理想的情況下需要對資料庫進行水平拆分,而由於乙個表被分成了多份,不能再使用之前的單錶的自增id作為主鍵,所以需要乙個全域性的id生成器來統一的進行id分配,全域性id的生成有很多種方案,此處介紹乙個最簡單的實現。實現方案 mysql作為...

主鍵生成方式

在做搭建ssh專案時,用hibernate反射機制生成pojo以及對映檔案。表主鍵選擇的是uuid,但是程式執行過程中,就報錯了。結果查資料才發現一些問題。大家平時多注意點。在hibernate2.1中,主鍵生成策略中uuid分為uuid.hex和uuid.string,但是從hibernate3....

分布式全域性ID生成方案

1 背景 分布式架構下,唯一序列號生成是我們在設計乙個系統,尤其是資料庫使用分庫分表的時候常常會遇見的問題。當分成若干sharding表後,如何能夠快速拿到乙個唯一序列號,是經常遇到的問題。在網際網路的業務系統中,涉及到各種各樣的id,如在支付系統中就會有支付id 退款id等。那一般生成id都有哪些...