Identificador único, numérico, incremental

Question

Necesito generar identificadores de transacciones numéricos únicos e incrementales para cada solicitud que realizo a un determinado RPC XML. Estos números solo deben ser únicos en mi dominio, pero se generarán en varias máquinas.

Realmente no quiero tener que hacer un seguimiento de este número en una base de datos y tratar con el bloqueo de filas, etc. en cada transacción. Traté de hackear esto usando una marca de tiempo de microsegundos, pero hubo colisiones con solo unos pocos subprocesos: mi aplicación necesita admitir cientos de subprocesos.

Cualquier idea sería apreciada.

Editar: ¿Qué sucede si cada ID de transacción tiene que ser más grande que la solicitud anterior?

Answer 1

Si va a usar esto de cientos de hilos, trabajando en múltiples máquinas y necesita una identificación incremental, necesitará un lugar centralizado para almacenar y bloquear el último número de identificación generado. Esto no necesariamente tiene que estar en una base de datos, pero esa sería la opción más común. Un servidor central que no hizo nada más que servir IDs podría proporcionar la misma funcionalidad, pero que probablemente anula el propósito de distribuir esto.

Si necesitan ser incrementales, cualquier forma de marca de tiempo no se garantizará como única.

Si no necesita que sean incrementales, un GUID funcionaría. Potencialmente, hacer algún tipo de fusión de la marca de tiempo + una identificación de hardware en cada sistema podría dar identificadores únicos, pero la parte del número de identificación no necesariamente sería única.

¿Podría usar un par de ID de hardware + marcas de tiempo incrementales? Esto haría que las ID de cada máquina específica sean incrementales, pero no necesariamente sean únicas en todo el dominio.

---- EDITAR -----

No creo que usar ninguna forma de marca de tiempo vaya a funcionar para usted, por 2 razones.

Primero, nunca podrá garantizar que 2 hilos en diferentes máquinas no intenten programar exactamente al mismo tiempo, sin importar qué resolución de temporizador use. Con una resolución lo suficientemente alta, sería poco probable, pero no está garantizado.

Segundo, para que esto funcione, incluso si pudiera resolver el problema de colisión anterior, tendría que hacer que todos los sistemas tengan exactamente el mismo reloj con una precisión de microsegundos, lo que no es realmente práctico.

Answer 2

Este es un problema muy difícil, especialmente si no desea crear un cuello de botella en el rendimiento. Usted dice que los ID deben ser 'incrementales' y 'numéricos': ¿es una restricción comercial concreta o una que existe para algún otro propósito?

Si esto no es necesario, puede usar UUID, para lo cual las plataformas más comunes tienen bibliotecas. Le permiten generar muchos (¡millones!) De identificaciones en períodos de tiempo muy cortos y sentirse bastante cómodos sin colisiones. El artículo relevante en wikipedia afirma:

  

En otras palabras, solo después de generar   1000 millones de UUID por segundo para el   próximos 100 años, la probabilidad de   crear solo un duplicado sería   alrededor del 50%.

Answer 3

Si elimina 'incremental' de sus requisitos, puede usar un GUID .

No veo cómo puede implementar incrementalmente en múltiples procesos sin algún tipo de datos comunes.

Answer 4

Si apuntó a una plataforma Windows, ¿intentó API enclavada ?

Answer 5

Google para generadores GUID para el idioma que esté buscando, y luego conviértalo a un número si realmente necesita que sea numérico. Sin embargo, no es incremental.

O haga que cada hilo '' reserve '' mil (o millones, o miles de millones) de ID de transacciones y entregarlas de a una por vez, y "reservar" el siguiente grupo cuando se agote. Todavía no es realmente incremental.

Answer 6

Estoy con la multitud de GUID, pero si eso no es posible, ¿podría considerar usar db4o o SQL Lite sobre un peso pesado base de datos?

Answer 7

Si cada cliente puede realizar un seguimiento de su propia "próxima identificación", entonces puede hablar con un servidor sentral y obtener un rango de identificaciones, quizás 1000 a la vez. Una vez que un cliente se quede sin ID, tendrá que volver a hablar con el servidor.

Esto haría que su sistema tenga una fuente central de identificación, y aún así evitar tener que hablar con la base de datos para cada identificación.