java singleton websphere cluster-computing

java - Singleton en entorno Cluster



websphere cluster-computing (9)

¿Cuál es la mejor estrategia para refactorizar un objeto Singleton en un entorno de clúster?

Usamos Singleton para almacenar en caché alguna información personalizada de la base de datos. Es principalmente de solo lectura, pero se actualiza cuando ocurre algún evento en particular.

Ahora nuestra aplicación necesita ser implementada en un entorno Clustered. Por definición, cada JVM tendrá su propia instancia de Singleton. Por lo tanto, la memoria caché puede estar desincronizada entre las JVM cuando se produce un evento de actualización en un solo nodo y su memoria caché se actualiza.

¿Cuál es la mejor manera de mantener sincronizados los cachés?

Gracias.

Edición: el caché se usa principalmente para proporcionar una lista de autocompletado (razones de rendimiento) a la IU y usamos Websphere. Así que cualquier consejo relacionado con Websphere es bienvenido.

Estoy con el Sr. Vest Hansen en este caso, muévase lo más lejos posible de singletons. Después de estar plagado de la pesadilla que es SAAJ y JAXP y de obtener versiones compatibles que funcionen en JBoss, he terminado con singletons y fábricas. Un mensaje SOAP no debería necesitar una fábrica para crear una instancia.

De acuerdo, disculpa, ¿qué pasa con memcache o algo similar? ¿Qué tipo de afinidad necesitas para tu caché? ¿Es malo si alguna vez está desactualizado, o existe alguna flexibilidad en cuanto a qué tan desactualizados pueden llegar los datos?

Hay productos para tener una memoria caché distribuida en la memoria (como memcache) que puede ayudar en esta situación.

Una solución mejor, si es posible, puede ser que los singletons no sean realmente solteros, pero que la aplicación tolere tener instancias separadas (digamos que todos reconocen cuándo deben actualizarse) pero no que tengan que estar sincronizados entre las JVM que puede convertir su caché en un cuello de botella.

Hay varias maneras de manejar esto, dependiendo de 1) qué tan fuera de los datos están los datos, y 2) todas las instancias deben tener los mismos valores todo el tiempo.

Si solo necesita datos que estén razonablemente a la altura de los datos, pero no es necesario que cada JVM tenga datos coincidentes, simplemente puede hacer que cada jvm actualice sus datos en el mismo programa (por ejemplo, cada 30 segundos).

Si la actualización debe realizarse aproximadamente al mismo tiempo, puede hacer que un jvm envíe un mensaje al resto de ellos diciendo "es hora de actualizar ahora".

Si cada jvm siempre necesita la misma información, debe hacer una sincronización, donde el maestro dice "actualizar ahora", todos los cachés bloquean cualquier consulta nueva, actualizan e informan al maestro que ya están listas. Cuando el maestro recibe una respuesta de cada miembro del clúster, envía otro mensaje que le dice que proceda.

Los enfoques más simples son:

  1. Agregue un temporizador de caducidad a su caché de singleton para que de vez en cuando la caché se purifique y las llamadas subsiguientes obtengan los datos actualizados de la fuente (por ejemplo, una base de datos)

  2. Implemente un mecanismo de notificación para el caché utilizando algo como un tema JMS / tibRV. Haga que cada instancia de caché se suscriba y reaccione ante cualquier mensaje de cambio transmitido sobre este tema.

Me enfrento a una situación similar, pero estoy usando WebLogic y Coherence de Oracle.

Estoy trabajando en una aplicación web que utiliza un hashmap con datos almacenados en caché de la base de datos (texto que se muestra en las etiquetas de los formularios web ). Para lograr esto, los desarrolladores utilizaron una instancia de singleton donde almacenaron toda esta información. Esto funcionó bien en un entorno de servidor único, pero ahora queremos entrar en la solución de clúster y estoy enfrentando este problema con esta instancia de Singleton.

Por lo que he leído hasta ahora, esta es la mejor solución para lograr lo que quiero . Espero que esto te ayude con tu problema, también.

O algo como memcached

http://www.danga.com/memcached/

¿Qué es memcached? memcached es un sistema de almacenamiento en caché de objetos de memoria distribuida de alto rendimiento, de naturaleza genérica, pero diseñado para acelerar las aplicaciones web dinámicas al aliviar la carga de la base de datos.

Danga Interactive desarrolló memcached para mejorar la velocidad de LiveJournal.com, un sitio que ya tenía más de 20 millones de visitas dinámicas a la página por día para 1 millón de usuarios con una gran cantidad de servidores web y un montón de servidores de bases de datos. memcached redujo la carga de la base de datos a casi nada, lo que produjo tiempos de carga de página más rápidos para los usuarios, una mejor utilización de los recursos y un acceso más rápido a las bases de datos en caso de pérdida de memcache.

Reemplace su caché de singleton con un caché distribuido.

Uno de esos caché podría ser JBoss Infinispan, pero estoy seguro de que existen otras tecnologías de caché y cuadrícula distribuidas, incluidas las comerciales que probablemente estén más desarrolladas en este momento.

Para objetos singleton en general, no estoy seguro. Creo que trataría de no tener singletons en primer lugar.

Si es posible, use el soporte de su servidor de aplicaciones para esto, si es posible (algunos lo tienen, otros no). Por ejemplo, usamos el soporte de JBoss para un "HA Singleton" que es un servicio que solo se ejecuta en el nodo maestro del clúster. No es perfecto (tienes que manejar el caso en el que ocasionalmente se desmaya), pero es lo suficientemente bueno.

Si falla, puede ser capaz de diseñar algo utilizando JGroups, que proporciona autodescubrimiento y negociación de nodo de clúster, pero no es trivial.

Como último recurso, puede usar el bloqueo de la base de datos para administrar los singletons de clúster, pero eso es muy frágil. No recomendado.

Como alternativa a un singleton de clúster, podría usar un caché distribuido en su lugar. Recomiendo JBossCache (que no necesita el servidor de aplicaciones JBoss para ejecutarse) o EhCache (que ahora proporciona un mecanismo de distribución). Tendrá que rediseñar su caché para que funcione de manera distribuida (no funcionará mágicamente), pero probablemente será una solución mejor que un singleton de clúster.