Aquí podría ser tu PUBLICIDAD


Escalabilidad de la aplicación Java EE. ¿Cómo lo abordarías?

votos
1

He estado trabajando en la solución para la industria financiera. La principal funcionalidad de la aplicación es la capacidad de cargar archivos de entrada masivos, digerirlos, actualizar el estado en la tienda persistente y generar extractos de la tienda persistente a petición. Muy claro.

Los archivos de entrada son grandes XML formateados estándar (más de cientos de megabytes) que contienen muchas entradas repetidas. El almacenamiento persistente es una base de datos relacional. El motor se ha implementado como una aplicación Java basada en POJO (Spring Framework como back-bone) que se puede implementar en el servidor de aplicaciones J2EE.

La pregunta es sobre la escalabilidad y el rendimiento de la solución. Si la aplicación procesa entradas de XML en secuencia, la escalabilidad de la solución es bastante pobre. no hay forma de incluir más de una instancia de la aplicación en el procesamiento del único archivo. Es por eso que introduje el procesamiento paralelo para las entradas del archivo XML de entrada. Básicamente, la idea es despachar el procesamiento de entradas individuales para los trabajadores del grupo. Decidí usar JMS para el envío. El componente que carga el archivo lee la secuencia y simplemente extrae entradas individuales y alimenta la cola de envío. Hay una cantidad de consumidores simultáneos en el otro extremo de la cola. Cada uno elige un mensaje de la cola y procesa la entrada y está inmediatamente disponible para procesar otra entrada. Esto es bastante similar a los servlets dentro del contenedor web. Lo que encontré particularmente poderoso acerca de este enfoque es que los trabajadores pueden residir en instancias separadas de la aplicación implementada en servidores remotos, siempre que la cola esté compartida. Desafortunadamente, todos los trabajadores se conectan a la misma base de datos que mantiene el almacenamiento de persistencia y esto puede ser un cuello de botella si el servidor de base de datos no es lo suficientemente potente como para manejar la carga de los trabajadores concurrentes.

¿Cuál es su opinión sobre esta arquitectura? ¿Tuviste una aplicación similar al diseño? ¿Cuál fue tu elección de diseño entonces?

Publicado el 12/03/2009 a las 16:56
fuente por usuario Tomasz Błachowicz
En otros idiomas...        العربية       

7 respuestas

votos
3

También puede echar un vistazo a Hadoop, una plataforma muy útil para Map / Reduce jobs. La gran ventaja es que Hadoop proporciona toda la infraestructura, por lo que solo aplicará nuevos nodos de hardware para escalar. La implementación de los trabajos de Asignar y Reducir solo debe hacerse una vez, después de esto, puede alimentar su clúster con una carga masiva.

Respondida el 12/03/2009 a las 05:16
fuente por usuario Mork0075


Aquí podría ser tu PUBLICIDAD


votos
2

Creo que la arquitectura en general es sólida. Si la base de datos tiene problemas para tratar con un gran número de actualizaciones simultáneas de los trabajadores, puede introducir una segunda cola en el otro "lado" de la aplicación: a medida que cada trabajador completa su tarea, agrega los resultados de esa tarea a la cola. Entonces, ¿un proceso de un solo trabajador agarra periódicamente los objetos resultantes de la segunda cola y actualiza la base de datos en una gran operación por lotes? Eso reduciría la concurrencia de la base de datos y podría aumentar la eficiencia de las actualizaciones.

Respondida el 12/03/2009 a las 05:08
fuente por usuario cliff.meyers

votos
1

Recientemente, pasé parte de mi tiempo libre investigando Spring Batch 2.0. Esta es una nueva versión del motor de procesamiento por lotes Java basado en Spring framework. Los chicos que implementaron Spring Batch se concentraron en la simultaneidad y paralelización de la ejecución para esta versión. Debo decir que parece prometedor

Respondida el 14/05/2009 a las 10:39
fuente por usuario Tomasz Błachowicz

votos
1

Para el procesamiento paralelo, como dijo Mork0075, hadoop es una gran solución. En realidad, muchas empresas lo usan para análisis de registros muy grandes. Y se ha construido un proyecto interesante Hive basado en hadoop para data warehousing.

De todos modos, creo que su diseño actual es bastante escalable. En cuanto a su preocupación acerca de todos los trabajadores que aciertan en la base de datos, puede simplemente poner otra cola de mensajes entre los trabajadores y la base de datos. Los trabajadores colocan los resultados de procesamiento en la cola y usted crea otro programa para suscribirse a la cola y actualizar la base de datos. El inconveniente es que dos colas pueden hacer que el sistema sea demasiado complicado. Por supuesto, puede agregar otro tema al sistema MQ existente. Eso hará que el sistema sea más simple. Otro enfoque es usar un sistema de archivos compartido, como NFS, cada máquina de trabajo monta el mismo directorio en el servidor de archivos compartido, y cada trabajador escribe sus resultados de procesamiento en un archivo separado en el servidor de archivos compartidos. Luego construyes un programa para verificar nuevos archivos para actualizar la base de datos. En este enfoque, introduce otra complejidad: servidor de archivos compartidos.

Respondida el 13/05/2009 a las 06:51
fuente por usuario yanky

votos
1

Además, eche un vistazo a la solución de agrupamiento de Terracota.

Respondida el 13/03/2009 a las 07:46
fuente por usuario Alexander Temerev

votos
0

En respuesta a tus preguntas:

¿Cuál es su opinión sobre esta arquitectura? ¿Tuvo aplicación similar al diseño? ¿Cuál fue su elección de diseño, entonces?

Creo que es una buena arquitectura, y tienes razón el PP es el cuello de botella. Sin embargo, el diseño es lo suficientemente flexible como usted puede controlar la cantidad de entrada a la base de datos.

Tengo y multi-threading en los nodos de obras. No estoy del todo seguro de que Haddoop, u otro sistema de procesamiento distribuido le dará mucho más de lo que ya tiene, desde el simple hecho de hacer E / S a una base de datos.

He implementado algo simliar utilizando colas JMS para el registro centralizado, y funcionó bastante bien con un menor impacto en el código a continuación, escribir los registros en el disco. Creo que va a funcionar bien para su aplicación.

Respondida el 10/04/2012 a las 11:02
fuente por usuario Jim Barrows

votos
0

Si ya está utilizando Spring / Java EE, es natural aplicar Spring Batch como solución para su "arquitectura de concurrencia".

Dos beneficios justo del murciélago:

  1. Spring Batch (a partir de 2,0) implementa de partición, que significa que el marco se encargará de datos de partición para que en los pasos de partición separados ( StepExecution), y delegar la ejecución real de estos pasos a múltiples hilos u otros sistemas distribuidos ( PartitionHandlers, por ejemplo, TaskExecutorPartitionHandlero para estar más distribuido MessageChannelPartitionHandler, etc.)

  2. Spring tiene un buen paquete OXM para tratar con XML + Spring Batch tiene una StaxEventItemReaderque extrae fragmentos del documento XML de entrada que corresponderían a los registros para su procesamiento

Prueba Spring Batch. Avíseme si tiene alguna pregunta, estaré encantado de ayudar.

EDIT:

También mira Scala/AKKA Actorsy / o Scala parallel collections. Si su tarea es aplicable para ser fragmentada / particionada / distribuida => para qué es el modelo Actor.

Si desea considerar una solución que no sea JVM, eche un vistazo a Erlang OTP=> simple y elegante.

Respondida el 17/11/2009 a las 01:00
fuente por usuario tolitius