Algorithm is relatively simple, each ID id-generator responsible for generating the three-part, 41 millisecond time stamp may represent the internal self 10bit worker-id divided, such as three said IDC, 7 bits represent the machine. The last 12 bits are incremented by id in a millisecond, that is, the algorithm may be generated every millisecond 2 ^ 12 = 4096 id, QPS 400 a million;
snowflake ensure 1) globally unique, 2) id id trends in distributed systems generate incremental; not strictly increasing, because the machine time cluster sync issues
There is a most serious problems that the algorithm is time rollback. For example, one machine A, generating a t id, but the clock is transferred back to the t-15, the id generated duplicate again possible.
Thinking a way to solve this problem,
After a single service id-generator, generated per ms id, detection current_ms, or <= last_ms waiting last_ms-current_ms, resumed normal service. If the id-generator so after the restart still have a problem because there is no place to record last_ms. And because of the high qps 400w, but also can not be persistent.
We introduce a third party, such as zookeeper or Redis, id-generator when the service starts atomic increase a key, and the result is used as the worker-id. . .
oops! Looks like not only supports restart 1024