Replicar la función de cola de tareas de App Engine en EC2/Elastic Beanstalk

Question

Estoy considerando pasar de AppEngine a EC2/Elastic Beanstalk ya que necesito mis servidores ubicados dentro de la UE [App Engine no ofrece una opción de ubicación de servidor AFAIK]. He ejecutado la aplicación de muestra Elastic Beanstalk, que es buena hasta donde llega; Sin embargo, una de las características de App Engine de la que dependo mucho es la función de cola de tareas sin conexión/cron, ya que periódicamente obtengo una gran cantidad de datos de otros sitios. Me pregunto qué necesitaría configurar en Elastic Beanstalk/EC2 para replicar esta instalación de cola de tareas, si hay alguna mejor práctica aún, cuánto trabajo tomaría, etc.

¡Gracias!

Answer 1

Si está moviendo su aplicación, probablemente sea mejor que simplemente usando TyphoonAE o AppScale. Ambos son entornos alternativos en los que puede ejecutar su aplicación de App Engine sin modificaciones, y ambos son compatibles con EC2.

Answer 2

Un posible problema con los servicios cron en Beanstalk es que un comando programado determinado podría ser invocado por más de un servicio si la aplicación se ejecuta en más de una instancia. Se necesita coordinación entre las instancias en ejecución de Tomcat para garantizar que los trabajos se ejecuten solo en una, y que si uno de ellos muere, el servicio cron no se interrumpe.

Cómo estoy poniendo en práctica es como esto:

1. paquete del trabajo cron "archivo de configuración" en la guerra. Este archivo debe contener frecuencias y URL (ya que cada cron real es simplemente una invocación de una URL específica, como lo hace AE)
2. Use una sola tabla de base de datos para mantener la coordinación. Requiere al menos dos columnas.
   1. tecla principal o única que (cadena) para mantener el comando junto con su frecuencia. (por ejemplo, "@daily http://your-app/some/cron/handler/url")
   2. una segunda columna que contiene el último tiempo de ejecución.

cada instancia de Tomcat se ejecutará un hilo cron que debe leer la configuración de la guerra y programar en sí a dormir el tiempo necesario hasta la siguiente invocación de servicio. una vez que llega el momento, la instancia primero debe intentar "reclamar" la invocación primero agarrando la última vez de invocación para ese comando de la base de datos y luego actualizándola para obtener el "bloqueo".

1. query(SELECT last_execution_time FROM crontable WHERE command = ?)
2. if(NOW() - last_execution_time < reasonable window) skip;
3. query(UPDATE crontable SET last_execution_time = NOW() WHERE command = ? AND last_execution_time = ?)
4. if(number of rows updated == 0) skip;
5. run task()

El elemento clave aquí es que también incluimos el last_execution_time en la cláusula WHERE, asegurando que si algún otro instancia lo actualiza entre cuando SELE CT y UPDATE, la actualización devolverá que no se afectaron las filas y esta instancia se saltará la ejecución de esa tarea.