Mensajería .NET Pub/Sub escalable usando NCache
Seminario web grabado
Por Ron Hussain y Edward Bator
En este seminario web, aprenderá cómo puede usar la poderosa mensajería Pub/Sub para aplicaciones .NET de alto tráfico y superar los cuellos de botella de rendimiento. NCache es un caché distribuido escalable para .NET que proporciona un amplio conjunto de funciones de mensajería Pub/Sub.
Uno de nuestros arquitectos de soluciones sénior lo guiará a través de todas las funciones de Pub/Sub y sus casos de uso, y le mostrará cómo puede incorporarlas en su aplicación .NET.
Este seminario web cubre:
- Introducción a la mensajería Pub/Sub en general
- Entender NCache Funciones de Pub/Sub
- Configurar Pub/Sub en NCache
- Uso práctico de Pub/Sub en sus aplicaciones .NET
- Demostración de mensajería Pub/Sub a través de NCache
- NCache alta disponibilidad y escalabilidad para Pub/Sub
El tema de hoy será sobre la mensajería dentro de las aplicaciones .NET y usaremos NCache como producto de ejemplo. El enfoque principal va a ser Mensajes de publicación/suscripción. El modelo de suscriptor del editor. ¿Por qué es importante? Dónde exactamente lo usas y por qué NCache se ajusta mejor en comparación con otras opciones que ve para su .NET y .NET core aplicaciones? Entonces, tenemos mucho que cubrir. Comencemos rápidamente con esto y chicos, si hay alguna pregunta, como Eddie sugirió, usen la pestaña de respuesta de preguntas y hagan todas las preguntas que necesiten. Entonces, comencemos rápidamente.
¿Qué es Pub/Sub?
Las primeras diapositivas se centran en la parte de introducción. ¿Qué es Pub/Sub? Estoy bastante seguro de que todo el mundo lo sabe, pero solo por el bien de la exhaustividad, voy a repasar el paradigma de mensajería Pub/Sub.
Entonces, es un modelo de suscriptor de editor. Tiene principalmente tres componentes. Tenemos editor, que envía mensajes, difunde esos mensajes al canal de comunicación. Luego tenemos suscriptores, que podrían ser otra aplicación, que recibe esos mensajes y luego tenemos una comunicación, bus un corredor, un servicio, un proceso dentro de un componente intermedio de editor y suscriptor que ayuda a transmitir esos mensajes de los editores a los suscriptores. En algunos casos, puede almacenar mensajes, puede procesar mensajes. Esta podría ser la base de tiempo, esto podría basarse en sus destinatarios.
¿Cómo funciona Pub/Sub?
Por lo tanto, hay diferentes opciones que puede ajustar cuando planea usarlo. Pero, en general, existen algunas pautas, algunas reglas que son comunes a la plataforma típica de mensajería Pub/Sub. Está débilmente acoplado. Editor y suscriptores, pueden trabajar de forma independiente sin tener ninguna dependencia entre sí. También pueden ignorarse por completo entre sí y el sistema debería funcionar sin problemas. La idea general es que el editor simplemente envía mensajes al canal de comunicación y luego el canal de comunicación transmite esos mensajes y los suscriptores reciben esos mensajes. El editor no necesita conocer la identidad o la información sobre las aplicaciones del suscriptor y, de manera similar, los suscriptores no necesitan saber cuál es la información del editor. Simplemente pueden lidiar con los mensajes, ese es el principal punto de interés y la idea general es que cada componente funcione de forma independiente. Los editores no tienen ninguna dependencia del canal de comunicación o de los suscriptores y viceversa.
La mayoría de los modelos de suscriptores de editores, los modelos Pub/Sub le permiten tener una separación de preocupaciones, donde puede tener temas, canales o transmisiones. Estos se utilizan para separar los mensajes. Por lo tanto, los mensajes de naturaleza similar que tienen un solo propósito simple, se pueden colocar en un tema específico y puede tener múltiples temas, múltiples transmisiones, múltiples canales, dentro de un paradigma de mensajería Pub/Sub y puede recibir esos mensajes. Los editores se conectan a los temas y luego esto transmite esos mensajes a un tema determinado y luego los suscriptores también pueden conectarse a un tema dentro del canal de comunicación y luego recibir esos mensajes y funciona absolutamente bien, utilizando este enfoque basado en temas.
Aquí hay un diagrama, que destaca los detalles arquitectónicos.
Tenemos un tema, este es el canal de comunicación, esta es la aplicación de editor que tenemos aplicaciones de suscriptores. Puede haber varios editores. Del mismo modo, podría haber varios suscriptores y luego, dentro del canal de comunicación, también puede tener varios temas. Por ejemplo, puede tener un tema relacionado con la información de procesamiento de pedidos. Podría haber otro tema relacionado con la información del cliente, etc. Entonces, según el propósito del mensaje, según el tipo de mensaje, estos son los requisitos de carga, puede distribuir mensajes en temas y luego este Suscriptor se conecta al Tema A, mientras que el Suscriptor 2 está conectado al Tema A como así como a B y luego el Suscriptor 3 solo está conectado al Tema B. Entonces, el editor envía estos mensajes y aquellos suscriptores que están conectados a los temas respectivos, reciben esos mensajes sin problemas.
Casos de uso comunes de Pub/Sub
Muy bien, entonces, vamos a lo siguiente. ¿Cuáles son los casos de uso comunes de Pub/Sub? Ha estado en el mercado durante bastante tiempo, todo este paradigma de mensajería Pub/Sub y también se ha utilizado en muchas aplicaciones de alto tráfico. Tiene mucha tracción.
Por lo tanto, tenemos sistemas back-end, principalmente, que pueden beneficiarse de la mensajería Pub/Sub que se ocupa del procesamiento de datos asíncrono. Podrían ser algunos flujos de trabajo, algunas tareas en segundo plano, algunos procedimientos que necesita, algunos cálculos que está haciendo. Por lo tanto, los sistemas de back-end utilizan principalmente esta plataforma de mensajería.
Aplicaciones de chat, esto podría ser la industria de los juegos, que puede tratar con millones de usuarios, millones de mensajes que se transmiten a los usuarios. Por ejemplo, uno de nuestros clientes usaba Pub/Sub para compartir información cuando había diferentes torneos en su sitio de juegos. Entonces, estaban compartiendo mucha información relacionada con torneos entre usuarios.
La industria financiera, el comercio electrónico, las reservas, todo lo que sea público y necesiten realizar algún procesamiento de pedidos backend, algún procesamiento de reservas o, en general, proporcionar alguna interacción entre los diferentes componentes de la aplicación.
Plantas de automatización y fabricación. Pero, por lo general, podría ser el caso de uso más importante, sería un caso de uso técnico, sería el microservicios caso de uso Donde tenemos diferentes microservicios, que representan una gran aplicación, pero estos componentes tienen un único propósito independiente. Es muy difícil implementar la capa de comunicación para esos microservicios. Tendría que tener un canal de comunicación separado que actúe nuevamente como un microservicio, que no tiene capacidad para otros microservicios y esa es la idea general donde le gustaría tener una capa de microservicios que sea independiente, las instancias de microservicio son independientes entre sí. Una instancia tiene un solo propósito y no depende de otra y viceversa. Entonces, para esas aplicaciones de microservicios, donde tenemos microservicios dentro de la aplicación, implementar el canal de comunicación es muy difícil y complicado y tiene mucha dependencia, también ralentiza las cosas. Por lo tanto, tiene mucho sentido usar una plataforma de mensajería Pub/Sub, donde el canal de comunicación es administrado por la propia plataforma y luego los microservicios actúan como publicadores y suscriptores y luego comparten información entre ellos. Por lo tanto, eso debería ayudar a aliviar la carga, así como los problemas de arquitectura que normalmente ve con Pub/Sub, las aplicaciones de plataformas de microservicios que usan su propio canal de comunicación. Deberían usar Pub/Sub para ayudar a aliviar eso.
El problema: Problemas de escalabilidad con las plataformas Pub/Sub
Hay muchas plataformas Pub/Sub, pero por lo general hay cuellos de botella y eso es lo que vamos a cubrir a continuación. Tenemos las típicas plataformas de mensajería tradicional. Son muy buenos en términos del lado arquitectónico de las cosas. Envías un mensaje, ese mensaje se va a transmitir a todos los suscriptores, todo funciona bien. Pero, por lo general, esto funciona muy bien con poca carga. Cuando tenga menos usuarios, cargue también menos solicitudes o menos mensajes que se transmiten de ida y vuelta a su aplicación. En cuanto a la carga, cuando la carga de la aplicación crece, por ejemplo, hay muchos usuarios, hay mucho procesamiento y luego hay mucha carga de mensajes de los editores a los suscriptores, por lo general, hemos visto que nuestra mensajería tradicional plataforma, como base de datos, se convierten en un cuello de botella. Aquí hay un diagrama que ilustra esto.
Tenemos aplicaciones de editor, suscriptor. Esto podría ser una aplicación web, algún .NET o .NET Core back-end Algunos flujos de trabajo. Podría ser cualquier tipo de .NET o .NET Core aplicación o incluso una aplicación Java, conectada a una plataforma de masa tradicional, como una base de datos o una cola de mensajería. En primer lugar, estos no son tan rápidos como la tienda en memoria, ¿verdad? Entonces, eso es algo en lo que debes trabajar. Pero el problema principal es que cuando su carga de mensajes crece, cuando tiene muchos usuarios, las cosas comienzan a ralentizarse porque su carga de mensajes puede ahogar la plataforma en sí porque es una fuente única. No tiene la capacidad de agregar más y más servidores para ayudar a acomodar la mayor carga que están poniendo sus aplicaciones.
Entonces, ese es el problema principal y ¿cuál sería el impacto en el usuario final? Por ejemplo, un mensaje no se transmitió a tiempo, tomó mucho tiempo y eso contribuyó a la latencia en el lado de la aplicación. Por ejemplo, el usuario final estaba esperando que se realizara un procesamiento y ese procesamiento dependía de una plataforma de modelo Pub/Sub y la plataforma era lenta. Entonces, eso a su vez afectaría la solicitud del usuario final también y perderá negocios si hay, digamos, un factor de milisegundos o unos pocos segundos de retraso, entonces eso puede afectar al usuario final y eso a su vez afectará su negocio como bueno, y eso es muy difícil de manejar, porque no hay forma de que puedas cambiar nada dentro de la arquitectura de la aplicación para ayudar a resolver ese problema. Hay un problema, que está fuera de la arquitectura de la aplicación con la capa de la base de datos, ¿verdad? Entonces, ¿cómo abordar ese escenario en particular?
La solución: caché distribuida en memoria
La solución es muy simple, utiliza una plataforma de mensajería Pub/Sub en memoria que se distribuye por naturaleza, como NCache. Es súper rápido, eso es lo que lo diferencia de las plataformas de mensajería tradicionales. Puede tener menos funciones, lo admito. Ya que, NCacheEl enfoque principal es tener almacenamiento en caché de objetos, almacenamiento en caché de datos, almacenamiento en caché de sesiones, está ahí para el procesamiento de datos y el almacenamiento y la mejora del rendimiento. Pub/Sub es una de las características. Hay productos como colas de mensajería, por ejemplo, servicio de mensajería Java, cola MSM, esos son más elaborados. Pero lo que hace NCache aparte de estos productos es que NCache es el en memoria. Por lo tanto, es súper rápido de poner en marcha.
Entonces, si tiene, digamos, cinco usuarios y tiene menos carga de mensajes, esos usuarios verán una experiencia súper rápida en comparación con las plataformas de mensajes tradicionales. Entonces, está en la memoria. Entonces, eso es una gran ventaja y luego tenemos varios servidores que alojan esa plataforma de mensajería. Puede ver un servidor de equipo unido en una capacidad lógica que formula la plataforma de mensajería y tiene un mecanismo Pub/Sub implementado encima, a la derecha. Por lo tanto, las aplicaciones de su editor pueden conectarse a este caché y dentro del caché puede tener temas separados. Les mostraré cómo funciona esto, más adelante y luego los suscriptores, que por cierto también pueden ser editores, también están conectados al mismo canal de comunicación que ofrece NCache como en forma de caché de distribución y luego ese canal de comunicación ofrece toda la información relacionada con la comunicación a estos editores y suscriptores. Esto puede transmitir mensajes y esto podría tener todos estos diferentes tipos de exploraciones, algún tipo diferente de persistencia y características diferentes que resaltaré más adelante.
Lo bueno de esta plataforma es que puede agregar tantos servidores como necesite y no tiene que preocuparse de que su plataforma sea un cuello de botella de escalabilidad como se ve aquí. Por lo tanto, ya no es un cuello de botella de escalabilidad. Puede agregar más servidores sobre la marcha y de dos a tres servidores aumenta por un factor correcto y de tres a cuatro servidores, casi duplica la capacidad de cuántas solicitudes puede manejar, cuántos mensajes puede manejar por segundo y sin comprometiendo el rendimiento, le brindaría mejoras de escalabilidad lineal para la entrega de su mensaje y eso ayudaría mucho en el lado de la aplicación. Los usuarios finales se beneficiarían mucho, ya que verían un tiempo de respuesta más rápido, baja latencia y alto rendimiento para su aplicación y sus usuarios.
¿Alguna pregunta hasta ahora? Esto explica por qué debería considerar usar NCache en comparación con la tradicional y cuáles son los problemas con la plataforma de mensajería Pub/Sub tradicional. ¿Alguna pregunta hasta ahora? Las próximas diapositivas se centran en los detalles arquitectónicos de NCache Mensajes Pub/Sub y luego hablaremos sobre las diferentes características que se ofrecen como parte de esto. Hola Ron, tenemos una pregunta. ¿Cuáles son las opciones de monitoreo disponibles? OK, creo que es en lo que respecta a NCache, sí, esa es otra ventaja de que tengo un segmento hacia el final alineado solo para esto. Pero creo que sería muy bueno si espero hasta esa parte y les doy la demostración práctica del producto y, como parte de eso, también les mostraré las capacidades de monitoreo. Entonces, revisaré esta pregunta, una vez que esté en esa parte. Espero que esté bien.
NCache Mensajería de publicación/suscripción
Bien, NCache Mensajería de publicación/suscripción. Es muy similar a lo que has visto aquí. Es una plataforma de mensajería Pub/Sub tradicional. Aquí está el desglose de la arquitectura. Contamos con canal de mensajería ofrecido por NCache y tenemos un equipo de servidores aquí y dentro de ese canal de mensajería tenemos el Tema 1, el Tema 2 y luego tenemos el editor que podría ser cualquier .NET, .NET Core aplicación y luego tenemos suscriptores que son de nuevo cualquier .NET o .NET Core, incluso la aplicación Java, que está conectada a él.
Se puede formular un caché dedicado para esto y luego el mensaje es algo que se transmite desde el canal de comunicación utilizando el mecanismo típico de Pub/Sub, donde se envía un mensaje del editor a los suscriptores. Aquí hay un fragmento de código simple.
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
...
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic orderTopic = cache.MessagingService.CreateTopic("orderTopic");
Message orderMessage = new Message(payload);
// Publish message to all registered subscribers
// Register delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);Solo para tener una idea de que construye su carga útil, que es el objeto de interés, inicializa el caché, lo que significa conectarse a él, asígnele un nombre, puede crear un clúster de caché con diferentes servidores, luego crea un tema o se conecta a un tema existente. El tema es un canal, un medio separado para mensajes similares y luego construyes un mensaje y luego lo publicas y eso es todo. Así de simple es para el caso de uso básico.
En el lado del suscriptor, nuevamente debe conectarse a un tema o crear un nuevo tema y luego convertirse en suscriptor usando el método de creación de suscripción y luego hay una devolución de llamada que se invoca cada vez que se recibe un mensaje y esta es una llamada asíncrona -espalda.
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic productTopic = cache.MessagingService.GetTopic(topicName);
ITopicSubscription prodSubscriber = prodTopic.CreateSubscription(MessageReceived);
private void MessageReceived(object sender, MessageEventArgs args)
{
// Perform operations
}Una demostración práctica
Debería darle rápidamente la demostración del producto y luego creo que sería mucho más fácil de entender una vez que hayamos hecho la demostración. Seguiría adelante y, como parte de esto, también respondería las opciones de monitoreo. Muy bien, entonces, rápidamente seguiría adelante y te mostraría el NCache herramienta de administrador, que viene instalada con él.
Crear un caché
Voy a crear un nuevo caché.
Llamémoslo, PubSubCache y voy a agregar Windows Win al final. Todos los cachés deben tener un nombre. Puede nombrar su caché de Pub/Sub, algo que sea significativo para su aplicación. Puedes crear un caché, NCache le permite crear un caché en el entorno de Windows, servidores de Windows, así como en servidores Linux y también tenemos la versión mono de Windows, que también está disponible. Entonces, con Linux necesitas usar .NET Core y en Windows puedes usar .NET así como .NET Core lanzamientos de NCache. Por lo tanto, voy a seguir adelante con los servidores de Windows. Elija caché de réplica de partición porque quiero tener varios servidores que contribuyan a la capacidad de manejo de solicitudes.
Por lo tanto, Partitioned y Partitioned Replica son muy buenas opciones. La memoria caché con particiones le permite particionar datos en varios servidores, mientras que la réplica con particiones es similar a la partición con particiones, pero también tiene copias de seguridad. Entonces, depende completamente de ti. Si desea que los mensajes sean importantes por naturaleza, si un servidor se cae, no desea perder los mensajes que todavía están en el canal de comunicación, entonces puede usar Réplica con particiones; de lo contrario, la caché con particiones es más excéntrica. .
Hay otras dos topologías, pero son para configuraciones más pequeñas y nuestra NCache webinar de arquitectura cubre todos los detalles en torno a estas topologías de manera muy eficaz. Por lo tanto, le recomendaría que los visite, revise ese seminario web si necesita saber más sobre estas topologías. Mantendré todo simple. Elija Async como opción de replicación.
Eso es entre la partición activa y la copia de seguridad en otro servidor y aquí especifico el equipo de servidores que van a alojar mi clúster de caché. Puedo tener dos para comenzar y puedo agregar más servidores en cualquier momento, como se discutió anteriormente. Este es un puerto TCP por cierto. Toda comunicación entre NCache se maneja a través de TCP/IP y el tamaño es algo que es el tamaño por servidor. Entonces, según la carga de mensajes, según la carga de datos, le recomendamos que configure un tamaño relevante para sus aplicaciones. Mantendré todo simple. Inicie este caché en inicio automático, de modo que cada vez que se reinicie el servidor, el caché se inicie automáticamente y eso es todo.
Así de simple es configurar este caché y luego, te mostraré cómo ejecutar la aplicación, pero necesitaría un paso más antes de pasar a eso. También está comenzando, por lo que está tardando un poco, está bien, ahí lo tienes.
Supervisar estadísticas
Entonces, hubo una pregunta sobre las opciones de monitoreo, creo que debería abordar eso ahora. Voy a agregar mi caja como cliente, desde donde voy a ejecutar la aplicación de editor y suscriptor. Estos también pueden ejecutarse desde cualquier servidor que tenga acceso a este caché. Agregué mi caja como cliente, así que esa es esencialmente la caja del cliente. Puedo agregar otro cuadro y desde ese también puedo ejecutar aplicaciones. Notará que hay algunas opciones de ventana de estadísticas que están disponibles en la herramienta del administrador, pero para Pub/Sub, lo que haría inicialmente, lanzaría NCache herramienta de monitoreo y luego también le mostraría algunos de los contadores que están disponibles específicamente para Pub/Sub.
Por ejemplo, este es mi guión de Pub/Sub. Voy a seguir adelante y esto es NCache herramienta de monitor que viene con la instalación NCache. Creo que necesito, 1 por 3 es bueno. Muy bien, primero que nada, si notas que tenemos estadísticas de temas. Luego tenemos algunos mensajes publicados por segundo, digamos, conteo de mensajes y luego tenemos mensajes que caducan por segundo. Creo que esa es buena. Por cierto, también puedes agregar más. Hay muchos aquí y luego hay contadores PerfMon que también están disponibles. Permítame habilitarlos también y luego ejecutaré una aplicación para mostrarle cómo funciona. Solo necesito mostrarle los contadores y nuestra herramienta de monitoreo también usa contadores PerfMon. Entonces, lo que está viendo aquí también está disponible en el monitor y viceversa. Muy bien, entonces, estamos listos. Entonces, tenemos algunos contadores aquí también. Por ejemplo, recuento de mensajes, entrega por segundo vencido. Entonces, puede ver la vista numérica, la vista numérica y luego también tenemos una vista gráfica en el monitor.
Ejecutar un publicador
Ahora, ejecutaría una aplicación que viene instalada con ella, pero la modifiqué un poco, para poder publicar tantos mensajes como sea necesario. Entonces, esta es la configuración de la aplicación uno para el editor y luego esta es una configuración de la aplicación para el consumidor, la suscripción. Muy bien, entonces, ejecutaría esta aplicación. En primer lugar, iniciará la aplicación de publicación y le mostrará cómo funciona. Déjame revisar esto, tal vez no guardé. Muy bien, solo dame un minuto, necesito poner un bucle alrededor. En realidad, hay un bucle. Muy bien, déjame depurarlo. Entonces, no tengo información para conectarme a este caché. Entonces, averigüemos esto. He agregado mi caja, así que tengan paciencia conmigo. Déjame arreglar este problema muy rápido, tomará un par de minutos. Aunque agregó, tal vez hubo un error tipográfico. Ahí tienes Estaba especificando nuestro nombre de caché incorrecto, mi error. Déjame revisar el nombre aquí. Es pubsubcachewin.
Estaba usando el nombre del caché de ayer, que era un caché de demostración. Sucede. Muy bien, me alegro de haber podido arreglarlo rápidamente, de lo contrario, habría sido un desastre total. Entonces, creo que estamos bien. Entonces, esto iniciará el programa, que será el editor.exe y publicará diez mensajes. Estoy publicando los mismos mensajes una y otra vez. En este punto se inicia el editor, el suscriptor aún no se ha iniciado. Entonces, déjame mostrarte los detalles de monitoreo.
Hay algunas solicitudes que están llegando, por supuesto, en torno a esto. Pero si te fijas, ahí estaba mi tema, ese es el nombre 10.
Los elementos están allí y luego debería ver esos mensajes caducados después de que haya transcurrido el tiempo de caducidad y creo que estoy poniendo cinco minutos de caducidad o más en eso. Ahora seguiría adelante y publicaría algunos más. Ahí tienes y deberías tener 10 artículos aquí, más agregados. Por lo tanto, 20 elementos en total y puede ver cómo aumenta el número de mensajes.
Entonces, ese es el gráfico y también puede ver las mismas opciones en el monitor de rendimiento de Windows, donde ahora tenemos el tamaño y el número de mensajes de 20 a 12. Principalmente, porque algunos han caducado. Creo que ya estoy usando menos caducidad como parte de eso. Déjame ver, creo, el recuento de mensajes no se muestra correctamente, déjame ver, creo que esto es, debería ser 20 según mi monitor.
Ejecutar suscriptores
Repasemos esto con la ayuda de los suscriptores. Veamos cuántos mensajes recibe y, por cierto, les mostraré el código una vez que termine con la demostración.
Entonces, se supone que debe recibir los mensajes existentes y creo que los ha recibido todos de forma aleatoria. Esta es una invocación asíncrona de mensajes. No garantiza que los mensajes se entreguen en ese orden. Por lo tanto, puede recibir el primer mensaje en una etapa posterior y así sucesivamente.
Y si vuelvo aquí, el recuento de mensajes se reducirá a cero. Creo que este contador, repasemos esto una vez más. No estoy seguro de si esto representa los mensajes de un tema determinado o los mensajes generales que se publican. Muy bien, entonces, no muestra el valor correcto, mientras que esto debería mostrarse. Creo que esos mensajes fueron recibidos. Entonces, necesito cerrar el suscriptor para lograr eso. Voy a ejecutar otro suscriptor. Entonces, verá que los mensajes se envían a varios y creo que lo concluiremos y le mostraremos el código de ejemplo. Voy a ingresar algunos mensajes más, siga haciéndolo y luego, en el lado del suscriptor, puede ver que este recibe 10 mensajes y luego recibe algunos más. Si hay dos opciones de entrega, puede optar por transmitir mensajes a todos estos suscriptores oa cualquiera. Correcto, entonces, en función de quien lo reciba, un mensaje también caducará del caché. Entonces, esa fue una demostración rápida. Ahora, les mostraré los detalles de lo que implica publicar un mensaje. ¿Cuáles son las características en el lado del tema? ¿Cuáles son las características del lado del editor y cuáles son las características del lado del suscriptor? Si hay alguna pregunta en este punto, por favor hágamelo saber. Estaría feliz de responder esas preguntas por usted ahora mismo, de lo contrario, continuaré y le mostraré el lado arquitectónico detallado de las cosas.
Principales interfaces Pub/Sub en NCache
Estas son las interfaces principales dentro NCache.
Tema
Tenemos tema. Una vez más, es un canal de comunicación. Contiene una lista de suscriptores y transmite mensajes publicados a sí mismo a los suscriptores conectados.
Mensaje
Entonces tenemos un mensaje que es la carga útil principal. El punto de interés, el objeto de interés para los suscriptores. Es una carga útil serializable. Podría ser cualquier objeto, podría ser cualquier mensaje que desee entregar, cualquier dato para ser precisos.
Publisher
Publisher es el que es una aplicación que publica mensajes y también puede recibir una notificación de estado de entrega opcional. El estado de entrega es algo que puede optar por activar, pero como se decidió anteriormente o como se discutió anteriormente, el editor no necesita esperar a que se entregue el mensaje. Puede seguir adelante. Por lo tanto, el estado de entrega opcional es algo que puede activar según sea necesario o puede desactivarlo.
Suscriptor
Los suscriptores se registran para un tema específico y reciben todos los mensajes.
Entonces, repasemos estos uno por uno y el diagrama ilustra todo lo que acabamos de discutir.
Publisher crea mensajes, registra eventos, envía mensajes, temas y almacena mensajes, almacena suscriptores y envía mensajes. Los suscriptores se suscriben y luego reciben notificaciones de mensajes.
NCache Interfaz de tema Pub/Sub
Entonces, revisemos la interfaz del tema. Entonces, en primer lugar, puede crear un NCache Tema de Pub/Sub y luego puede conectarse a un tema existente también o puede eliminar un tema también. Entonces, veamos qué está involucrado en esta interfaz aquí. Entonces, si voy a este editor aquí mismo, primero necesito ir al programa y, si se dan cuenta en este programa, estoy obteniendo el nombre del caché. Obtengo el nombre del tema, que podría ser cualquier tema que pueda elegir y obtengo un contador de mensajes, que es un mensaje aleatorio y luego tengo el método publisher.start, que he implementado y dentro de eso estoy inicializando el caché, lo que significa que voy a conectarlo al caché y luego obtendré una interfaz de creación de tema y si vuelvo aquí, tenemos IMessagingService. Entonces, si te muestro rápidamente esto aquí.
IMessagingService Interface for managing Topics in NCache
namespace Alachisoft.NCache.Web.Caching
{
public interface IMessagingService
{
ITopic CreateTopic(string topicName);
void DeleteTopic(string topicName);
ITopic GetTopic(string topicName);
}
}Tenemos la interfaz IMessagingService, que tiene un método CreateTopic, un método DeleteTopic para eliminar un tema y luego GetTopic. Repasemos estos uno por uno. Entonces, servicio de mensajería, hemos creado un tema o simplemente podemos conectarnos a un tema existente. Lo que realmente hace es, también puede habilitar la entrega de mensajes, la notificación de falla de entrega, si eso es algo que le gustaría hacer. Por ejemplo, puede configurar una devolución de llamada aquí mismo y esa devolución de llamada puede, a su vez, ser invocada, pero es opcional. No necesariamente necesita esto, si no desea habilitarlo. Entonces, como dije antes, las notificaciones de entrega de mensajes son opcionales, por lo que no es necesario que las habilites como una obligación. Depende completamente de su caso de uso, si desea habilitarlos, puede continuar y hacerlo.
Luego tenemos un método de publicación, que es un método personalizado para esta aplicación, un contenedor para esto y luego dentro de eso, lo que realmente estamos haciendo es construir un mensaje y luego estamos usando el mensaje topic.publish. Entonces, esto devuelve un mensaje, un tema. Una especie de identificador de ese tema y luego topic.publish es su método real, si les muestro rápidamente aquí. Esta es una interfaz de ITopic, que tiene un nombre, puede tener un recuento de mensajes, puede tener un tiempo de caducidad, que le mostraré en un momento y luego también tiene algunas devoluciones de llamadas sobre temas eliminados, fallas en la entrega de mensajes y luego le permite tener una suscripción para el tema y luego publicar mensajes en él también y este es el primer método que quería mostrar, es que puede usar topic.publish y luego, si nota que hay una opción de entrega como bien. Puede tener entregar a todos como un deber oa cualquiera. Entonces, ese es el nivel de mensaje, entonces, esa es una opción de entrega para los mensajes entregados o enviados a ese tema y luego hay un último booleano opcional aquí, veamos esto, ¿qué sugiere? Para este, si desea tener alguna notificación de falla o no. Entonces, en este caso, estoy configurando esto en verdadero, pero puede desactivarlo y, si lo hace, invocaría la devolución de llamada en el lado del editor en consecuencia.
Entonces, vimos dos métodos aquí. Puede crear un tema y, de manera similar, también puede obtener un tema. Entonces, ese es otro método que puede usar, alternativamente. Pero, dado que estoy ejecutando esto por primera vez, estoy usando crear tema, publicando mensajes en el tema y luego también puedo eliminar el tema, si es necesario. Entonces, estos son algunos de los escenarios y, como puede ver, estas diapositivas muestran los mismos ejemplos junto con eso.
Create Topic: Code snippet to create a new topic in distributed cache
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.CreateTopic(topicName);Por lo tanto, si elimina el tema, se invocará la devolución de llamada eliminada del tema y la devolución de llamada eliminada del tema es desde donde puede notificar a sus usuarios finales o cualquier información que necesite publicar.
Delete Topic: Deletes an existing Topic distributed
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.DeleteTopic(topicName);
OnTopicDeleted callback: If registered, it will be triggered upon the Delete Topic call.
using (Subscriber subscriber = new Subscriber())
{
// Subscribes on it, using the provided cache-Id and the topic-name.
subscriber.OnTopicDeleted = TopicDeletedCallback;
}
static void TopicDeletedCallback(object sender, TopicDeleteEventArgs args)
{
Console.WriteLine("Topic '{0}' deleted.", args.TopicName);
}NCache Interfaz de mensajes Pub/Sub
Echemos un vistazo a la interfaz de mensajería y aquí discutimos que hay una opción de invalidación de mensajes, notificaciones de mensajes recibidos, falla o recepción, notificación de falla y luego se admite el cifrado y la compresión como parte de eso. Entonces, echemos un vistazo a la interfaz IMessage para el caso. Por lo tanto, tenemos un mensaje aquí.
namespace Alachisoft.NCache.Runtime.Caching
{
public class Message : IMessage
{
public Message(object payload, TimeSpan? timeSpan = null);
public static TimeSpan NoExpiration { get; }
public string MessageId { get; }
public TimeSpan? ExpirationTime { get; set; }
public object Payload { get; }
public DateTime CreationTime { get; }
}
}Veamos qué hay disponible como parte de eso. Entonces, antes que nada, tenemos un TimeSpan, puede elegir NoExpiration o puede tener un TimeSpan ExpirationTime aquí mismo para especificarlo como una opción de mensaje y si vuelvo aquí, si nota que estamos configurando un vencimiento basado en el tiempo en eso también, si nota que esto se está transmitiendo aquí mismo y tenemos un período de tiempo. Entonces, esto está siendo llamado por el propio programa. Entonces, estamos dando “Lapso de tiempo.DesdeMinutos(5)”. Entonces, eso significa esencialmente que cualquier tema que no se entregue, si no hay un suscriptor o los suscriptores se desconectaron, ese mensaje permanecerá en el canal de comunicación durante el período de tiempo especificado. Es una especie de persistencia, pero dado que va en contra de la plataforma Pub/Sub persistir mensajes indefinidamente, entonces la base de tiempo es la opción correcta, donde persistes los mensajes durante cierto tiempo y luego purgas la tienda. Esos mensajes tampoco caducan individualmente del canal de comunicación y esta caducidad puede estar en el nivel de tema en sí. El tema en sí puede tener su vencimiento o los mensajes también pueden tener su vencimiento individual adjunto. Entonces, eso es algo que haces y, por cierto, si el editor y los suscriptores están conectados, el editor publica los mensajes y se transmiten de inmediato. No espera a que se produzca la caducidad. No lo guardará, si el mensaje ha sido entregado. Entonces, una vez que se ha entregado el mensaje, sale del caché de inmediato. Entonces, así es como configuras la caducidad.
Entonces también tienes alguna notificación recibida sobre los mensajes. Esos son algo que les he mostrado anteriormente. Por ejemplo, puede ver la entrega, “Publisher.MessageDeliveryFailure” notificación y luego también puede generar un mensaje, el estado de éxito del mensaje también. Entonces, esa es otra opción que puede activar como parte de esto y luego también se puede hacer el cifrado y la compresión de mensajes y eso es algo que es una opción sin cambio de código. Todo lo que tienes que hacer es ir al caché en sí, ir a las opciones porque todo está controlado por NCache sí mismo. Por lo tanto, puede habilitar la compresión y puede hacer clic derecho y elegir configuraciones de aplicación en caliente.
La compresión es para objetos que son más grandes en tamaño. La carga útil del mensaje es más grande en tamaño, por lo que debe activar la compresión automáticamente y el cifrado es otra opción aquí. Requerirá que habilite el cifrado y para eso primero debe detener el canal de comunicación, detener el caché y luego habilitar el cifrado. Hay muchos proveedores entre los que puede elegir y todos los mensajes se cifrarán y luego se enviarán de vuelta al editor y los suscriptores. Espero que haya sido sencillo. Entonces, el ejemplo de mensaje está aquí.
//Payload containing OrderId to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with payload and expiration time set to 150 seconds
Message message = new Message(payload);
message.ExpirationTime = new TimeSpan(0, 0, 150);Puede usar order, construir un mensaje, configurar un tiempo de vencimiento y luego usar “tema.publicar” y proporcione ese mensaje al tema correcto.
Notificación de mensaje recibido
Entonces, el mensaje recibió la notificación. En el lado del suscriptor, quiero mostrarte eso también.
Callback invoked when a message is published on the topic
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
//Get Order topic
ITopic orderTopic = cache.MessagingService.GetTopic(topicName);
//Register subscribers for Order topic
ITopicSubscription ordSubscriber = orderTopic.CreateSubscription(messageReceivedCallback);
private void messageReceivedCallback(object sender, MessageEventArgs args)
{
//perform operations
if (args.Message.Payload is Order ord)
{
//perform operations
}Desde el punto de vista del suscriptor, todo lo que tiene que hacer es conectarse al caché para comenzar. Conéctese al tema usando “_cache.Servicio de mensajería.GetTopic”. Este fue el método que le mostré anteriormente o puede crear un tema, si existe y luego crear una suscripción que le permita recibir un mensaje en una devolución de llamada y aquí está el mensaje recibido en una devolución de llamada. Creo que debería estar aquí mismo en el programa. Mensaje recibir devolución de llamada. Entonces, esto se invocará cada vez que se reciba un mensaje. Entonces, eso completa el ejemplo aquí.
Paso a paso: Publicar mensaje en un tema
Entonces, paso a paso una vez más. Inicializas el clúster de caché de Pub/Sub, creas un tema dedicado o te conectas a uno existente. Registre eventos de entrega de mensajes si es necesario, eso es opcional. Cree un mensaje y publíquelo en un tema separado. Habilite la caducidad, habilite las opciones de entrega según sea necesario y ese es un código que ayudaría a justificar eso.
public void PublishMessages()
{
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
ITopic orderTopic = cache.MessagingService.CreateTopic(topicName);
//Register message failure notification
orderTopic.MessageDeliveryFailure += FailureMessageReceived;
//Register topic deletion notification
orderTopic.OnTopicDeleted = TopicDeleted;
//Payload to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with Order and expiration time set to 150 seconds
Message orderMessage = new Message(orderPayload);
orderMessage.ExpirationTime = new TimeSpan(0, 0, 150);
//Publish message to all registered subscribers
//and register message delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);Y luego, en el lado del suscriptor, se conecta al caché, obtiene un tema existente o crea uno nuevo. Crear suscripción para el tema para la recepción de mensajes. Registre eventos para recibir, que serán eventos asíncronos y luego cancele la suscripción del tema y también elimínelo, si es necesario, y el evento puede ser parte de él.
NCache Supervisión para Pub/Sub
Las próximas diapositivas se centrarán en el lado de la supervisión. Repasemos estos en su totalidad. Ya hemos cubierto los detalles básicos dentro del soporte de contador de PerfMon para NCache, tenemos diferentes opciones dentro del tablero. Vamos a crear otro tablero.
Añadamos todos estos. Entonces, también tenemos algunas estadísticas de temas. Por ejemplo, tenemos estadísticas de temas, que ya les mostré. Recuento de temas, número de temas que tienes. Cuenta de mensajes. Tamaño del almacén de mensajes, que son el tamaño total y los bytes para el tema y esto es muy importante para el desarrollo de capacidades. Si está tratando de comprender cuántos mensajes se entregan o publican, puede arrastrar y soltar el mensaje publicado por segundo y el mensaje entregado por segundo y luego puede tener algún estado de caducidad del mensaje, así como parte de eso. Entonces, estos son algunos de los contadores. Si ejecuto la aplicación de muestra una vez más, verá actividad en todos estos. Muy bien, voy a seguir poniendo algo de carga presionando Intro varias veces y si vuelvo aquí, podrás ver las actividades en todos ellos.
Hay 220 mensajes. El número de temas es 1 en este punto. El recuento de mensajes es de aproximadamente 220. También se muestran los tamaños de almacenamiento de mensajes. Los mensajes se publican. Pero no hay ningún mensaje que se haya entregado y no hay mensajes que hayan caducado y si solo ejecuto un suscriptor, será muy rápido, verán que esos mensajes también se recibirán. Ahí tienes y si vuelvo aquí mismo, ahora deberías ver actividad aquí también. También se reciben mensajes.
Entonces, esto completa el proceso. Puede registrar estos contadores para ver la capacidad, para ver los temas generales que están allí, los mensajes allí, el tamaño de la tienda y la caducidad de esos mensajes también y puedo crear tantos temas como sea necesario. en mis requisitos. Los mismos contadores también están disponibles en Windows PerfMon. Entonces, tiene el mismo conjunto aquí y, además, también tiene algunos cmdlets de PowerShell. Por ejemplo, si va a nuestra documentación aquí mismo, déjeme abrirla muy rápido. Entonces, tenemos tres opciones diferentes, PerfMon Counters, NCache Supervisión y cmdlets de PowerShell. En algunos casos, solo desea confiar en las herramientas. Entonces, para ese propósito, puede usar nuestra documentación y dentro de nuestra guía de PowerShell, veamos si puedo buscarla rápidamente. Me dio un enlace general, así que déjame ver algunas opciones de monitoreo aquí. Entonces, puede ver "Get-Topics", que es un Cmdlet de PowerShell, que le permite obtener nombres de temas basados en el nombre de caché. Por ejemplo, si abro PowerShell aquí mismo. Puedo usar este comando, déjame abrirlo de este lado para que quede claro. Muy bien, entonces, por ejemplo, puedo ejecutarlo desde cualquier cuadro aquí y luego pubSubCachewin es el nombre del caché. No me daría nada. Necesito ejecutarlo en el propio servidor porque creo que no lo es, pubSubCachewin, ahí lo tienes. Mi tema, suscriptores, publicador y número de mensajes.
La razón para empezar a trabajar desde mi caja es porque necesita una dirección IP para saber dónde existe el caché. Por lo tanto, hay algunas herramientas en el lado de PowerShell que le permiten ver algunas estadísticas según sea necesario. Entonces, eso completa la parte de demostración. Por favor, hágamelo saber si hay alguna pregunta. Voy a dedicar algo de tiempo hacia el final para obtener detalles sobre la arquitectura o lo que se ofrece como parte de este canal de comunicación. NCache como plataforma de mensajería y por qué NCache es un mejor ajuste?
Arquitectura de caché distribuida
En primer lugar, NCache es de código abierto. Entonces, puede comenzar y Pub/Sub está disponible incluso en una versión de código abierto de NCache. Es linealmente escalable, ese es el punto número uno y antes de eso está en la memoria. Ese es el principal punto de interés para las aplicaciones que solo buscan rendimiento y no buscan requisitos de alta carga para comenzar. Entonces, si hay un problema de rendimiento NCache de nuevo se ajusta mejor en comparación con las plataformas de mensajería Pub/Sub convencionales.
Es linealmente escalable, lo que esencialmente significa que puede agregar tantos servidores como necesite. Dos servidores son lo suficientemente buenos. Pero si alcanzan la capacidad porque la capacidad puede verse afectada por NCache servidores también. El problema inicial que vio con la base de datos. no estamos diciendo eso NCache no vería este problema. Con un servidor, puede alcanzar una capacidad y, de hecho, puede tener más servidores, pero esos más servidores también podrían agregar capacidad. Por ejemplo, esos dos servidores se están maximizando y ese es el momento adecuado porque sabe de antemano los requisitos de carga o la carga alta en su aplicación. Por lo tanto, puede adelantarse a esto agregando más servidores y haciendo una mejor planificación de la capacidad. Por lo tanto, se pueden agregar más servidores sobre la marcha y esa es la belleza de esto, donde es linealmente escalable.
Luego, la tercera característica importante es que, si lo necesita, también puede tener soporte de replicación y eso garantizaría la confiabilidad. Ya tiene alta disponibilidad y la caída de su servidor no tendrá un impacto en los clientes finales o la plataforma del editor o suscriptor funcionará sin ningún problema. Siempre que tenga un nodo sobreviviente en el clúster de caché, la plataforma Pub/Sub permanecerá en funcionamiento y ¿por qué puede hacer esto? Es altamente disponible porque es de naturaleza dinámica.
Es un clúster de caché con arquitectura 100% peer-to-peer. Eso le permite agregar tantos servidores como necesite y esos servidores son de naturaleza independiente. Contribuyen a la capacidad de manejo de solicitudes mediante la distribución de la carga, pero funcionan con una capacidad 100% independiente. Cualquier servidor que se caiga o que se agregue un nuevo servidor no tendría ningún impacto en el caché. No es necesario detener la plataforma para eso. Puede continuar funcionando y luego los clientes no necesitan ser detenidos o reiniciados. Ese es el problema con las fuentes convencionales, donde si un servidor falla, es posible que deba reiniciar los clientes para comenzar a usar los nodos supervivientes. Entonces, esa es una naturaleza dinámica en la que los clientes se ajustarían automáticamente y el clúster en sí tiene un tiempo de actividad del 100% con un mecanismo de autorreparación. Si se agrega un servidor, el clúster se ajusta a eso distribuyendo la carga al servidor recién agregado y notificando a los clientes al mismo tiempo.
De manera similar, el caso de mantenimiento o el caso de caída del servidor, donde un servidor se cae o falla en ese caso, el clúster de caché permanece en funcionamiento. Necesita un nodo sobreviviente para que esto funcione y los clientes reciban una notificación en tiempo de ejecución. La compatibilidad con la conmutación por error de la conexión está integrada en el protocolo del lado del cliente. Por lo tanto, los clientes detectan fallas y luego realizan la conmutación por error y comienzan a usar los nodos de supervivencia automáticamente y eso garantiza un tiempo de actividad del 100% en el lado del caché y también para sus clientes finales que están conectados a él. Entonces, es de naturaleza dinámica. Tiene una arquitectura 100% peer-to-peer. El soporte de conmutación por error de la conexión está integrado y el clúster se repara automáticamente dentro de sí mismo. Es un mecanismo integrado en el protocolo. Eso garantiza un tiempo de actividad del 100 %, un escenario de caché de alta disponibilidad.
Topologías de almacenamiento en caché: caché con particiones
La topología de los canales de comunicación.
La plataforma Pub/Sub puede tener particiones de datos. Puede tener datos particionados en el Servidor 1 así como en el Servidor 2. Estos son elementos de datos que representan sus mensajes. Entonces, tenemos algunos mensajes entregados por el Servidor 1 y otros por el Servidor 2. Es completamente aleatorio, basado en nuestro algoritmo de distribución y su editor y suscriptores están conectados a todos los servidores. Entonces, algunos están conectados al Servidor 1, algunos están conectados al Servidor 2, pero si nota que cada servidor tiene, en realidad están conectados a todos ellos, pero algunos mensajes son entregados por el Servidor 1 y otros por el Servidor 2 y así sucesivamente adelante. Por lo tanto, la carga de mensajes se distribuirá y esto se realizará de manera excéntrica, donde utiliza completamente toda la capacidad de memoria de estos servidores, para servir los mensajes, para almacenar los mensajes, para su tiempo de vencimiento y también une su poder computacional en una capacidad lógica. así como. Por lo tanto, todos estos servicios contribuyen a la capacidad de manejo de solicitudes y esta es la razón por la que si agrega más servidores obtiene más capacidad del sistema y es por eso que le recomendamos que use la topología de réplica de operación de partición porque puede escalar linealmente, si Necesitar.
Topologías de almacenamiento en caché: caché de partición-réplica
Esta es la caché de réplica de partición, que también tiene soporte para copias de seguridad.
Tenemos la partición activa del Servidor 1, respaldo en (servidor) 2. Entonces, todos los servidores formulan una partición activa y una partición de respaldo de otro servidor, que es una réplica para otro servidor. El servidor 1 es una copia de seguridad activa en el servidor 2, el servidor 2 es una copia de seguridad activa en 3 y el servidor 3 es una copia de seguridad activa en 1 y el clúster aún puede administrar esto si un servidor deja de funcionar. Porque, si el Servidor 1 falla, la copia de seguridad del Servidor 1 estaba en 2, por lo que esta copia de seguridad se activa y se fusiona con los Servidores 2 y 3 y el clúster se cura solo y formula una copia de seguridad activa de 2 nodos, mecanismo pasivo activo donde la copia de seguridad del Servidor 1 está activada. La copia de seguridad del servidor 2 está en el servidor 1. Y es completamente transparente para sus usuarios finales. No tiene que preocuparse de que los usuarios finales se vean afectados por eso. Entonces, con un tiempo de actividad del 100 % NCache asegura todo esto.
Muy bien, esto nos lleva hacia el final de nuestra presentación. Por favor, hágamelo saber, podemos centrarnos hacia el final en algunas de las preguntas que puedan tener. Entonces, se lo entregaría a Eddie en este punto. Eddie, puedes recogerlo desde aquí. De nuevo, muchas gracias por su tiempo. Esperemos que haya sido beneficioso y esperamos verlo nuevamente en nuestro próximo seminario web. Mientras tanto, si necesita revisar el seminario web existente, que acaba de revisar en línea en alachisoft.com/recursos De nuevo un recordatorio, NCache es la única aplicación nativa en el mercado actual para el máximo rendimiento. Espero verte de nuevo pronto. Gracias.