Come scegliere gli ID articoli sequenziali ed evitare uno scontro

La soluzione che hai descritto si chiama Hi / Lo ed è uno dei modi per risolvere questo.

Il motivo per cui alcuni siti usano ancora numeri casuali sono pochi:

Con Hi / Lo, hai ancora bisogno di un'autorità centrale per mantenere la traccia dei blocchi. Questo potrebbe essere problematico, perché i requisiti di stabilità sono enormi per tale sistema.

Relativamente al precedente, con numeri casuali usati, i sistemi che li generano non devono fare affidamento su sistemi specifici, rendendoli più portabili.

Il secondo motivo è che non si tratta di un errore critico se due elementi hanno lo stesso ID. Molto probabilmente risulta che all'utente viene mostrato un errore se vengono generati due ID identici. Ma se lo spazio casuale è abbastanza grande, il sole finirà il carburante molto prima di te avere una buona possibilità di generare due numeri uguali . Questa possibilità è ancora più bassa con alcune generazioni GUID che garantiscono l'unicità del singolo sistema. Quindi generare lo stesso numero due volte sarebbe un problema solo in alcuni casi estremi.

Se hai davvero bisogno di ID sequenziali, puoi eseguire un servizio centrale che fornisce gli ID su richiesta. Supponendo che tu sia felice di avere buchi nella tua sequenza, questo può essere un servizio molto semplice, molto veloce, in esecuzione su socket udp e l'allocazione di blocchi di ID per ridurre la larghezza di banda della memoria. Lo svantaggio principale di questo è che se il servizio fallisce, perderai la possibilità di creare nuovi oggetti, quindi sarà necessario qualche tipo di failover rapido, il che aumenterà la complessità.

Tuttavia, mi pongo domande come @ 5gon12eder quali sono i vantaggi che otterrai da questo.

Il problema del coordinamento è che il coordinatore ha enormi requisiti di disponibilità / coerenza / latenza.

Quindi esaminiamo 4 soluzioni semplici:

• Un generatore di sequenze singole
• La soluzione Hi / Lo, con un singolo generatore Hi
• La soluzione Hi / Lo, dove Hi è l'ID del nodo (immutabile)
• La soluzione casuale, in cui viene generato un ID casuale

Nelle prime due soluzioni, hai un singolo generatore e sarà necessario essere disponibile e coerente. Nella prima soluzione dovrà anche rispondere rapidamente, mentre nel secondo se prevedi in anticipo , non deve essere altrettanto veloce.

Nella terza soluzione, il singolo generatore deve essere coerente, ma è necessario solo quando si crea un nuovo nodo / processo / thread e le sue prestazioni non hanno alcun impatto.

Nella quarta soluzione, non esiste un singolo generatore.

Si noti che è possibile ripristinare Hi / Lo mediante partizionamento di Lo. Ad esempio, uno schema semplice è:

• Genera Hi come un timestamp monotono con sufficiente accuratezza (monotonic significa che se il timestamp non è ancora avanzato, puoi ancora fare un balzo di +1 per generarne uno nuovo)
• Genera Lo dalla soluzione (3), preferibilmente o (2)

In questo modo, puoi principalmente ordinare gli ID generati da entità diverse in una linea temporale globale.