How Flickr generates a unique ID, a GUID. Consistency Hash. are not, use the MySQL key automatically increment can.
There is a nonstandard extension in MySQL, the syntax is replace into, although inert on DUPLICATE KEY update also has the same functionality, but replace into is still supported.
Flickr uses the replace into to generate a globally unique ID.
REPLACE works exactly like inserts, except that if the "if" in the "table has" same value as a new row for a PRIMARY KE Y or a UNIQUE index, the old row was deleted before the new row is inserted.
The TICKETS64 schema looks like:
CREATE TABLE ' Tickets64 ' (
' id ' bigint () unsigned not null auto_increment,
' stub ' char (1) NOT null default ',
primary key (' ID '), the
UNIQUE key ' stub ' (' Stub ')
Engine=myisam #这里创建了一个表, specifically used to generate key
SELECT * FROM Tickets64 returns a single row that looks something like:
| id | stub |
| 72157623227190423 | A |
When I need a new globally unique 64-bit ID I issue the following SQL:
REPLACE into Tickets64 (stub) VALUES (' a ');
SELECT last_insert_id (); #每次需要获取key的时候, executing this query, you can get a different key, which is the return value of last_insert_id ()
They then used 2 of these servers to rotate the key, and each server's auto-increment-increment and Auto-increment-offset were different. The global unique key was born like this, but I'm still a little skeptical of the force as the author says. The author finally said that this thing from 2006 to now work shcokingly ... Try it this way when you need it. Original link: http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/