分布式唯一主键生成策略的一种开销比较小的方法

原文链接：http://www.javaarch.net/jiagoushi/709.htm
分布式唯一主键生成策略的一种开销比较小的方法

分布式场景下，经常需要做分库分表，master和master结构，那么此时就会用到全局的唯一主键id。
如果使用mysql的分区策略，master到master的复制，那么此时就需要保证分区的唯一性避免主键冲突。
我们可以使用mysql的自增列，但是mysql却无法保证物理和逻辑数据库的主键唯一性。

mysql5.6以上出现了GUID，但是GUID很大，而且如果需要建索引需要拿性能会比较差。这样对于某些查询只需要索引
或者需要利用索引来满足高并发下的性能的话，GUID会是一个性能瓶颈。

一致性哈希能够来解决GUID和分片问题，在多写少读下比较好，但是mysql确实用来优化为快速的随机读。

所以我们就就试试中心化一个数据库，将单独一个数据库作为自增列生成机器，mysql的replase into和INSERT ... ON DUPLICATE KEY UPDATE是来解决主键冲突的问题，当主键存在时，当前记录会替换更新旧记录
http://dev.mysql.com/doc/refman/5.0/en/replace.html和http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
比如创建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
	
原文请查看：http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
分布式唯一主键生成策略的一种开销比较小的方法

猜你喜欢
