Al leer la documentación de ActiveMQ (estamos usando la versión 5.3), encuentro una sección sobre la posibilidad de usar un adaptador de persistencia JDBC con ActiveMQ.¿Cuándo debería usar el adaptador de persistencia JDBC en ActiveMQ?
¿Cuáles son los beneficios? ¿Proporciona alguna ganancia en rendimiento o confiabilidad? ¿Cuándo debería usarlo?
En mi opinión, usaría persistencia JDBC si quisiera tener un intermediario de conmutación por error y no podría usar el sistema de archivos. La persistencia de JDBC fue significativamente más lenta (durante nuestras pruebas) que el registro en el sistema de archivos. Para un solo intermediario, el sistema de archivos de diario es el mejor.
Si ejecuta dos intermediarios en una conmutación por error activa/pasiva, los dos intermediarios deben tener acceso al mismo almacén de datos/diario para que el intermediario pasivo pueda detectar y asumir el control si falla el principal. Si está utilizando el sistema de archivos de diario, entonces los archivos deben estar en una unidad de red compartida de algún tipo, utilizando NFS, WinShare, iSCSI, etc. Esto generalmente requiere un dispositivo NAS de gama superior si desea eliminar el uso compartido de archivos como un único punto de falla.
La otra opción es que puede apuntar a ambos intermediarios a la base de datos, a la que la mayoría de las aplicaciones ya tienen acceso. La compensación suele ser la simplicidad al precio del rendimiento, ya que la persistencia de JDBC por diario fue más lenta en nuestras pruebas.
Ejecutamos ActiveMQ en un par de intermediarios activo/pasivo con persistencia de diario a través de un montaje NFS en un dispositivo NAS dedicado, y funciona muy bien para nosotros. Podemos procesar más de 600 mensajes por segundo a través de nuestro sistema sin problemas.
Oye, el uso de JDBC registrado por diario parece ser mejor que utilizar la persistencia JDBC solo porque el diario es mucho más rápido que la persistencia JDBC. Es mejor que solo la persistencia en el diario solo porque tiene una copia de seguridad adicional de los mensajes en el db. Journalled JDBC tiene la ventaja adicional de que los mismos datos en el diario se conservan en el db más tarde y esto puede ser accedido por los desarrolladores cuando sea necesario.
Sin embargo, cuando utiliza la topología ActiveMQ maestro/esclavo con JDBC en conjunto, puede terminar perdiendo mensajes ya que puede tener mensajes en el diario que aún no están en la base de datos.
Si tiene una política de complemento de reentrega en su lugar y utiliza una configuración de maestro/esclavo, el planificador se utiliza para la reentrega.
A partir de hoy, el planificador solo se puede configurar en una base de datos de archivos, no en el JDBC. Si no le presta atención, tomará todos los mensajes que estén en reimpresión fuera del escenario de HA y locales para el intermediario.
https://issues.apache.org/jira/browse/AMQ-5238 es un problema en el rastreador de problemas de Apache que solicita un adaptador de persistencia JDBC para schedulerdb. Puede votar para que esto suceda.
En realidad, incluso en la mejor solución AMQ HA, LevelDB + ZooKeeper, el programador se saca del juego y se documenta que crea problemas (http://activemq.apache.org/replicated-leveldb-store.html al final de la página).
En un escenario JDBC, por lo tanto puede considerarse inseguro y no admitido, pero al menos no está claramente documentado, cómo configurar el almacén de datos para la política de entrega.
Yeap, esa fue exactamente mi experiencia. En nuestras pruebas, la persistencia de JDBC fue mucho más lenta que la opción de creación de journalling. Gracias –