¿Cuáles son los mejores enfoques para agrupar / distribuir una aplicación de servidor Java? Estoy buscando un enfoque que le permita escalar horizontalmente agregando más servidores de aplicaciones y más servidores de bases de datos.

¿Qué tecnologías (técnicas de ingeniería de software o tecnologías específicas) sugeriría para abordar este tipo de problema?¿Qué técnicas utiliza para diseñar una capa de persistencia para adaptarse a muchos lectores / escritores? Escala las transacciones de la aplicación y el acceso a la escala de datos compartidos (el mejor enfoque es eliminar los datos compartidos; qué técnicas puede aplicar para eliminar los datos compartidos).Parece que se necesitan diferentes enfoques dependiendo de si sus transacciones son de lectura o escritura intensas, pero creo que si puede optimizar una aplicación de "escritura" pesada que también sería eficiente para "leer"

La "mejor" solución le permitiría escribir una aplicación Java para un solo nodo y, con suerte, "ocultar" la mayoría de los detalles de acceso / bloqueo de datos compartidos.

En un entorno distribuido, el problema más difícil siempre se reduce a tener varias transacciones que acceden a datos compartidos. Parece que hay 2 enfoques comunes a las transacciones concurrentes.

Cerraduras explícitas (que es extremadamente propenso a errores y lento para coordinar a través de múltiples nodos en un sistema distribuido)Memoria transaccional de software (STM) AKA concurrencia optimista en la que una transacción se retrotrae durante una confirmación si descubre que el estado compartido ha cambiado (y la transacción puede reintentarse más adelante). ¿Qué enfoque se escala mejor y cuáles son las compensaciones en un sistema distribuido?

He estado investigando soluciones de escalado (y en aplicaciones generales que proporcionan un ejemplo de cómo escalar) como:

Terracota - proporciona una escala "transparente" al extender el modelo de memoria Java para incluir memoria compartida distribuida utilizando el mecanismo de bloqueo de concurrencia de Java (sincronizado, ReentrantReadWriteLocks).Google App Engine Java - Le permite escribir aplicaciones Java (o python) que se distribuirán entre los servidores "en la nube" donde distribuye el servidor que maneja una transacción y usa BigTable para almacenar sus datos persistentes (no está seguro de cómo las transacciones que acceden a los datos compartidos o manejan el bloqueo). contenciones para poder escalar efectivamente)Darkstar MMO Server - Darkstar es el servidor de juegos MMO de código abierto (multijugador masivo en línea) de Sun que escala las transacciones de una manera transaccional de hilos permitiendo que una transacción determinada solo se ejecute por una cierta cantidad y se comprometa, y si se demora mucho, se revertirá (como en la memoria transaccional del software ). Han estado investigandosoportando una configuración de servidor multi-nodo para el escalado.El bloqueo optimista de Hibernate. - Si está usando Hibernate, puede usar su soporte de concurrencia optimista para apoyarmemoria transaccional del software tipo de comportamientoApache CouchDB se supone que debe "escalar" a muchos DB de lector / escritor en una configuración de malla de forma natural. (¿Hay un buen ejemplo de cómo administra los datos de bloqueo o garantiza el aislamiento de las transacciones?):JCache - Escale las aplicaciones pesadas de "lectura" almacenando en caché los resultados de consultas comunes que puede usar en el Google appengine para acceder a memcached y para almacenar en caché otros datos que se leen con frecuencia.

Terracota parece ser la solución más completa, ya que puede modificar "fácilmente" una aplicación de servidor existente para admitir el escalado (después de definir los objetos @Root y los métodos @ AutoLockRead / Write). El problema es realmente obtener el máximo rendimiento de una aplicación distribuida, la optimización para sistemas distribuidos no es realmente una idea posterior, se debe diseñar con el conocimiento de que el acceso a objetos podría ser bloqueado por la E / S de la red.

Para escalar correctamente, parece que siempre se trata de particionar datos y transacciones de equilibrio de carga, de manera que una "unidad de ejecución" dada (cpu core -> thread -> nodo de aplicación distribuida -> nodo maestro de DB)

Parece que, sin embargo, para hacer que cualquier aplicación se amplíe correctamente agrupando en clústeres, debe poder particionar sus transacciones en términos de sus lecturas / escrituras de acceso a datos. ¿Qué soluciones tienen las personas para distribuir sus datos de aplicaciones (Oracle, Google BigTable, MySQL, Data Warehousing) y, en general, cómo gestionan los datos de partición (muchos maestros de escritura, muchos más DB de lectura, etc.)?

En cuanto a la escala de la capa de persistencia de los datos, ¿qué tipo de configuración escala la mejor en términos de partición de sus datos a muchos lectores / escritores (en general, particionaría mis datos en función de un usuario determinado (o cualquier entidad central que generalmente sea su entidad objeto "raíz") que es propiedad de una sola base de datos maestra)