genera ID sequenziali unici nell'architettura dei microservizi

Question

genera ID sequenziali unici nell'architettura dei microservizi

#1 da (5 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Sto lavorando nel contesto di un'architettura di microservizi (di tipo) in cui i servizi possono avere più istanze che possono creare nuovi documenti nella stessa collezione di un Mongo DB.

Esiste un requisito funzionale per cui ogni documento ottiene un ID univoco (ad esempio un ID dipendente o un numero di badge). Preferibilmente i nuovi documenti ottengono un ID più alto.

Dato che MongoDB non ha una funzione di incremento automatico, come viene gestita in genere? Ho visto suggerimenti per creare un servizio separato che tenga traccia della numerazione, ma non mi piace molto perché non ci può essere una sola istanza di questo servizio e sarà necessario elaborare le richieste per un nuovo numero in modo sincronizzato .

microservices mongodb

posta herman 29.11.2017 - 12:00

fonte

3 risposte

Leggi altre domande sui tag microservices mongodb

Separazione delle preoccupazioni: di chi è questa preoccupazione? Fare la spesa per soddisfare i client non JavaScript? [duplicare]

score 5 · Answer 1

Avere il microservizio che possiede la creazione del documento genera gli ID. Avere più servizi tutti gli accessi allo stesso data-store significa che non sono individualmente distribuibili e scalabili. Se hai solo molte istanze del servizio documenti e hai bisogno di collaborare, allora hai bisogno di qualcosa come fiocco di neve .

score 1 · Answer 2

Preferably newer documents get a higher ID.

Questa è solo una preferenza personale o esiste un requisito tecnico per questo?

Nella mia esperienza, gli UUID generalmente rendono le chiavi primarie migliori rispetto agli ID sequenziali perché chiunque, inclusi i clienti , può crearle. Ciò consente ai metodi di creazione dell'API di essere asincroni poiché i client interessati al documento creato avranno già i relativi ID (poiché lo hanno specificato).

Gli ID sequenziali fanno sentire gli umani caldi e sfocati, ma in genere non risolvono i problemi tecnici meglio degli UUID.

Se i tuoi utenti vogliono vedere un ID sequenziale, allora dai a tutti i costi dargliene uno. Basta non renderlo la chiave primaria del tuo documento. Per quanto riguarda come per trovare i tuoi ID sequenziali, dovrei essere d'accordo sul fatto che un servizio centrale è la strada da percorrere.

score 0 · Answer 3

Io uso sempre gli UUID per questo. Non mi piacciono i numeri di auto-incremento perché ho visto che non va bene negli scenari di failover.

Con gli UUID non hai bisogno di un servizio separato per rintracciarli.

Il lato negativo degli UUID è che sono stringhe lunghe e lo storage non è altrettanto efficiente. D'altra parte, possono darti migliori scritture casuali, che potrebbero aiutarti a evitare l'hot-spotting.

[Modifica] Per quanto riguarda i vincoli di formato, non è certamente necessario utilizzare un UUID canonico. Puoi prendere un UUID e fare cose ad esso per accorciarlo ad un valore ragionevole. Puoi anche fare cose con le stringhe Base64, che faccio molto. Questo ti dà qualcosa per ID di YouTube che trovo abbastanza ragionevole. Ho generato anche quelli più brevi (5 caratteri) che non hanno avuto collisioni (ancora). Ovviamente il successo dipende dal numero di documenti che hai e da quali rischi di collisione il tuo metodo specifico comporta.

Se davvero non è possibile utilizzare gli UUID, sarà necessario creare un semplice servizio IdGenerator che archivi l'ultimo ID in una tabella RDBMS. Potrebbe essere necessario codificare gli aggiornamenti e i deadlock simultanei. Molti, molti anni fa, ho utilizzato questo approccio con una procedura memorizzata che implementava il blocco a livello quasi riga per garantire che più chiamate simultanee restituissero sempre valori univoci.