|
|
|
|
|
by rdtsc
5266 days ago
|
|
> Why [time, node id, seq] and not [time, seq, node id] Would you rely on sub-millisecond synchronization between nodes _and_ an almost exact load amount? In other words for a particular millisecond seq order is only relevant on that particular node, so node should come first. |
|
It still seems to me that T_0,0,A (issued by node A at T_0 with seq number 0) would tend to come before T_0,1,B so putting the sequence number first does add some value. On the other hand, the ordering T_0,A,0 < T_0,A,1 < T_0,B,0 < T_0,B,1 is arbitrary.
> Would you rely on sub-millisecond synchronization between nodes _and_ an almost exact load amount?
Not rely on. Absolutely not. Maybe it's better to go further, and make it more explicit that the IDs are K ordered. Say you could synchronize your host clocks reliably to a maximum delta of 512 ms, then you could chose a scheme like:
[ milliseconds >> 9, host id, milliseconds & 0x1ff, seq id ]
The value here is that you make it much harder for consumer of the IDs to make incorrect assumptions about the precision of their ordering. Basically taking away the temptation to make statements about their ordering with false precision, by making a simple sort only provide a meaningful ordering within the real available precision.