系统设计 Design Unique ID in distributed System.

https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

1. Using UUID. 128 Bits

Pros: each application generate independently, if you use a timestamp as first component of ID, the IDs remain time-sorted.

Cons: Requires more storage space (96 bits) to make reasonable uniques, some UUID are completely random and have no natural sort.

2. Use Ticket Server . Use one node to generate Unique Auto-increase ID 

Pros: Master-Master, increase ID saved in DB.  using MySql auto-increment columns for Primary keys.

Cons: Single point of failure, not suitable for Write per second very high cases. It will be bottleneck.

3. Twitter Snowflake service (open source service)

ID are Unique 64-bit unsiged integers (timestamp + Node ID + sequence number)

Node ID: coordinate by Zookeeper.

Pros: 64-bits, half size of UUID, time can be 1st part which still sortable. Distributed, can survive nodes dying.

Cons: add more complexity (zookeeper, snowflake servers)

4. Instagram build its own solution:

41 bits for time in milliseconds.

13 bits that represent the logical hard ID

10 bits represent an auto-iincrementing sequence modulus 1024. (which means we can generate 1024 IDs, per hard, per millionsecond);