分布式唯一主鍵生成策略的一種開銷比較小的方法

分布式唯一主鍵生成策略的一種開銷比較小的方法

分布式場景下，經常需要做分庫分表，master和master結構，那麼此時就會用到全域性的唯一主鍵id。
如果使用mysql的分割槽策略，master到master的複製，那麼此時就需要保證分割槽的唯一性避免主鍵衝突。
我們可以使用mysql的自增列，但是mysql卻無法保證物理和邏輯資料庫的主鍵唯一性。
mysql5.6以上出現了guid，但是guid很大，而且如果需要建索引需要拿效能會比較差。這樣對於某些查詢只需要索引
或者需要利用索引來滿足高併發下的效能的話，guid會是乙個效能瓶頸。
一致性雜湊能夠來解決guid和分片問題，在多寫少讀下比較好，但是mysql確實用來優化為快速的隨機讀。
所以我們就就試試中心化乙個資料庫，將單獨乙個資料庫作為自增列生成機器，mysql的replase into和insert ... on duplicate key update是來解決主鍵衝突的問題，當主鍵存在時，當前記錄會替換更新舊記錄
和比如建立64位的自增id：
create table `tickets64` (
`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 tickets64 輸出：
+-------------------+------+
| id | stub |
+-------------------+------+
| 72157623227190423 | a |
+-------------------+------+
如果我需要乙個全域性的唯一的64位id，則執行：
replace into tickets64 (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
原文請檢視：

分布式主鍵生成策略

參考鏈結 自增主鍵和uuid 自增長uuid 優點 很小的資料儲存空間 效能最好 容易記憶 獨一無二的，出現重複的機會少 跨伺服器資料合併非常方便 安全性高 缺點 如果存在大量的資料，可能會超出自增長的範圍 很難處理分布式儲存的資料表，尤其是在合併表的情況下 安全性低，有規律，容易被非法獲得資料 儲...

分布式主鍵生成策略

在分布式高併發的情況下，分布式主鍵生成策略可參考mongodb的objectid實現。objectid是一種輕量的，不同的機器不同的程序都能用全域性唯一的同種方法生成它，而不是採用傳統的自增的主鍵策略，因為在多台伺服器上同步自動增加主鍵既費力又費時。objectid 是乙個24位的字串，它是由一組十...

分布式是一種思想

分布式是一種思想，範圍很廣，我得先知道它的誕生 以前是乙個資料庫 乙個jsp 就可以做乙個應用了，後來隨著業務複雜，我們開始分層，比如mvc之類的，再後來我們的資料越來越多了，比如有上億的資料，這個時候我們乙個資料庫查詢太慢了，就開始分庫，這也算是分布式的一種。還有比如我們的系統訪問的人多了，比如雙...