3 ms·
You could always just use UUIDs [1], or generate your own isolation and uniqueness. Personally, instead of randomness, it's easier to just make your keys multi
by jpollock 11y ago
You could always just use UUIDs [1], or generate your own isolation and uniqueness.
Personally, instead of randomness, it's easier to just make your keys multi-part to give each process an independent portion of the address space.
{ip/mac, pid, thread_id, start_timestamp, counter}
128 + 32 + 32 + 32 + 32.
increment the per-thread counter, because it's per-thread, no atomic operations required.
Weaknesses : pid re-use inside of the resolution of start_timestamp.
[1] https://tools.ietf.org/html/rfc4122 https://tools.ietf.org/html/rfc4122
- nemothekid 11y agoWith Version 1 UUIDs you expose the MAC/IP and it may also not be desirable if you don't want your ids to be predictable (which IIRC, may have been a requirement of the original article).
- antirez 11y agoThis method leaks internal info (ip/mac), and is not as collision resistant as the one I propose. imagine you have an embedded system that after a restart has the internal clock reset because of clock battery failure. Pid and thread_id are the same after every restart (or may be the same) because of the OS initialization steps which are simple and deterministic. You have your system in "reboot loop" for some reason. It reboots every few minutes. Soon or later you'll generate a repeated ID. Given the method is also more complex, why to use it?