Acerca del proceso de adquisición de datos por lotes de Redis
Supongamos que existe tal escenario, redis almacena miles de valores clave y obtiene el valor de campo correspondiente a cada clave, luego debe solicitar hget (clave, campo) para redis miles de veces, la respuesta obtenido es también el número de veces correspondiente. Si puede enviar todas las solicitudes al servidor a la vez, una vez completada la respuesta por lotes, solo necesitará solicitar Redis una vez y el rendimiento mejorará enormemente
Antes de usar la canalización, básicamente tomaba más Más de 90 segundos para obtener todos los datos, y ahora solo se necesitan 0,3 segundos, la mejora del rendimiento es obvia
Realice el siguiente escenario: una tarea está programada para ejecutar una función de tarea cada 1 segundo, pero la función de tarea. no ejecutará la función de la tarea cada 1 s, pero la función de la tarea se completa. El tiempo excede 1 s. En este momento, la hora de inicio de la tarea programada debe agregarse a los dos parámetros; de lo contrario, se informará un error.
El número de instancias permitidas, si no se establece, el valor predeterminado es 1, es decir, tiene el mismo número de instancias de tarea para id
Como en el ejemplo anterior, se informará como omitido: Se alcanzó el error de número máximo de instancias en ejecución (1), lo que significa que APScheduler está intentando volver a ejecutar la tarea, pero la tarea anterior aún está ejecutándose.
Este parámetro se puede interpretar como la configuración de tolerancia de tiempo de espera del trabajo, que proporciona al ejecutor un período de tiempo de espera dentro del cual el ejecutor dejará de ejecutar el trabajo si el trabajo no ha terminado de ejecutarse.
p >Como en el ejemplo anterior, el tiempo de ejecución del trabajo... La siguiente ejecución será en:...)" perdido debido a un error. ...) "perdido debido a un error
.