Hay un grupo del número 1 - 160 000 000.
Al crear un obj, debe asignar un número al obj. Hay algunas reglas
Además, el usuario a veces especificará un número para usar para la creación de obj.
A continuación se presentan algunas soluciones, cada una tiene sus propios problemas, así que espero alguna solución mejor
Tenga en cuenta que aquí usamos mongo DB. No quiero cambiar la base de datos debido a este problema.
Generar una gran tabla(colección) con 160.000.000 artículos. La estructura de la colección es
number,allocatedCuando asigne un número, use el método find_one_and_update para actualizar un registro, cambie el asignado de falso a verdadero
el problema de esta solución es que generar una colección de 160.000.000 es demasiado pesado
Similar a la solución 1 excepto que no generamos 160,000,000 a la vez. En cambio, generamos 1000 cada vez. Cuando se acaban estos 1000 registros, generamos otros 1000
El problema es que el usuario puede especificar el número a veces. Por ejemplo, generamos 1000 registros en la colección, pero queremos usar el número 5000 en su lugar. Así que este es el problema ahora porque no lo generamos.
Cada vez que creamos un obj, generamos un número aleatorio entre 1 y 160 000 000 para este obj y lo guardamos en la base de datos.
Es difícil evitar que el número aleatorio que generaste no se use previamente
La forma habitual de hacer esto es tener un contador atómico (fragmentado). El contador inicialmente tiene un valor de cero. Cuando se necesita un índice, se debe llamar a una API que incrementará atómicamente este contador y dará su valor anterior.
Si bien es probable que esto sea mucho más rápido que los enfoques que ha mencionado, es posible que aún no sea lo suficientemente rápido según sus necesidades. El cuello de botella en la situación anterior es el bloqueo único que se usa normalmente al hacer que el incremento sea atómico. Esto no es ideal en algunas situaciones distribuidas.
Uso de contadores fragmentados:
La forma habitual de aumentar el rendimiento en estos escenarios distribuidos es tener contadores fragmentados:
1..160,000,000 en N rangos separados).N subprocesos/procesos/entidades/máquinas con N bloqueos diferentes. Lo anterior aumentará el rendimiento N -fold y probablemente se adaptará a las necesidades de su aplicación.
Algunas lecturas interesantes sobre contadores fragmentados se encuentran en este enlace .
Tenga en cuenta que si desea utilizar una generación de números aleatorios (Solución 3), puede optimizar la búsqueda de la existencia de una clave mediante Bloom Filters . Esto puede ser suficiente según sus necesidades de rendimiento.