NCache Arquitectura

Hoy voy a hablar de NCache Arquitectura. NCache es un almacén distribuido en memoria para aplicaciones .NET y Java. Es extremadamente rápido y escalable. Y puede usarlo en sus aplicaciones de servidor de alta transacción para aumentar el rendimiento y la escalabilidad de su aplicación.

Usos comunes de NCache

Caché distribuida

Las dos formas comunes NCache se utiliza. El número uno es como Caché distribuida donde almacena en caché los datos de la aplicación para reducir esos costosos viajes a la base de datos y, el número dos es un Mensajería y transmisiones plataforma. Repasaré ambos brevemente antes de entrar en la arquitectura.

  • Almacenamiento en caché de datos de aplicaciones
    Entonces, en el caché distribuido, el almacenamiento en caché de datos de la aplicación significa que se utiliza un NCache La API generalmente solo almacena en caché los datos de su aplicación, por lo que no tiene que ir a la base de datos con tanta frecuencia porque la caché es mucho más rápida que la base de datos. También es más escalable porque está en la memoria, por lo que es rápido. Está cerca de su aplicación, por lo que es rápido y está distribuido, por lo que es escalable. Y, si tiene una aplicación .NET y está usando EF Core, puede usar NCache también a través de EF Core y también de NHibernate y EF 6. Si tienes aplicaciones Java puedes usar NCache como caché de segundo nivel de hibernación. También puede usarlo como Spring Cache o puede programarlo contra JCache.
  • Almacenamiento en caché de aplicaciones web
    La segunda parte del uso de la caché distribuida es que, si tiene aplicaciones web, puede almacenar su sesiones en NCache y luego NCache replica estas sesiones en múltiples servidores, de modo que si hay alguno NCache servidor que se cae y no se pierde ningún dato, pero estas sesiones son muy escalables porque es una tienda distribuida y obviamente es súper rápida. También hay una función de sesión multisitio disponible en todos los lenguajes .NET, Java, Nodejs, etc. Además de las sesiones, por ejemplo, para .NET 6, ASP.NET Core Las aplicaciones pueden almacenar sus Caché de respuesta en NCache y también pueden utilizar NCache como el plano posterior para SignalR. SignalR es para aplicaciones web en vivo donde la aplicación web tiene que enviar eventos a los clientes. Y luego, si estás usando .NET 4.8, también puedes almacenar tu estado de sesión, Ver estado, Caché de saliday también SignalR.

NCache para aplicaciones de misión crítica

Déjame mostrarte rápidamente lo que NCache parece. Esto es lo que es un caché distribuido para aplicaciones de misión crítica. Utilizo la palabra misión crítica porque en la mayoría de los casos vemos que los clientes utilizan NCache en aplicaciones muy sensibles que están orientadas al cliente y son muy importantes para su negocio. Entonces, NCache es, ya sabes, parte de su infraestructura muy crítica en ese caso.

NCache Arquitectura
NCache para aplicaciones de misión crítica

Y estas son, como dije, aplicaciones de servidor que generan altas transacciones. Estas son aplicaciones web. Se trata de microservicios, API web u otras aplicaciones de servidor. Obviamente, puedes hacerlo con .NET, Java, Node.js o Python. Y estas aplicaciones están intentando acceder a su base de datos, ya sea como SQL Server, Oracle, Db2, MySQL o cualquier otra base de datos relacional, o están accediendo tal vez a sus datos de mainframe heredados o tal vez están usando un NoSQL database como Mongo DB, Cosmos DB, Cassandra u otros. En esta situación, NCache se convierte en un caché distribuido por... usas NCache como dos o más servidores como un nivel de almacenamiento en caché independiente, aunque no es necesario tener un nivel de almacenamiento en caché independiente, su aplicación puede ejecutarse en el mismo cuadro que NCache y funciona perfectamente bien, pero la arquitectura de implementación más popular es tener un nivel de almacenamiento en caché separado, esa es simplemente una forma más limpia de usar NCache.

Entonces, digamos que comienzas con un clúster de caché de 2 servidores, NCache clúster, NCache agrupa la memoria, la CPU y los recursos de la tarjeta de red de todos estos servidores en una capacidad lógica y, digamos, está poniendo más carga de transacciones a través de sus aplicaciones en NCache y estos dos servidores están al máximo, puedes agregar fácilmente un tercer servidor, un cuarto servidor, un quinto servidor y así sucesivamente. NCache nunca se convierte en un cuello de botella. Esto es algo que no puede hacer con sus bases de datos. Las bases de datos no escalan. NoSQL escala pero, en la mayoría de los casos, descubrimos que las personas tienen que usar bases de datos relacionales por una variedad de razones comerciales y también tienen mainframes heredados. Entonces, debido a que la capa de almacenamiento de datos no escala NCache ayuda a que su aplicación crezca al permitirle almacenar en caché tantos datos como sea posible. El objetivo general es tener alrededor del 80% del tiempo necesario para encontrar los datos de NCache en lugar de ir a su base de datos. Si puede lograr esa proporción, entonces habrá quitado la presión a las bases de datos y su aplicación escalará.

Mensajería y transmisiones

El segundo caso de uso común, o uso de NCache es usarlo como una plataforma de mensajería y transmisiones donde puede tener múltiples aplicaciones que pueden comunicarse entre sí a través de Mensajería de publicación/suscripción, A través Consulta continuao NCache Eventos basados. Déjame mostrarte cómo se ve eso. Entonces, por ejemplo, si tiene una aplicación de servidor de transacciones altas que necesita realizar muchos mensajes en tiempo real o procesamiento de transmisiones, puede usar NCache. Ahora lo mismo NCache lo que era un caché distribuido ahora se convierte en una plataforma de mensajería y streaming. Nuevamente, es una tienda distribuida en memoria. Se escala linealmente. Replica los mensajes en varios servidores. De hecho, NCache también tiene persistencia.

Mensajería y transmisiones: procesamiento en tiempo real
Mensajería y transmisiones: procesamiento en tiempo real

Entonces, con eso, puedes tener diferentes aplicaciones, por ejemplo, la mensajería Pub/Sub es una forma muy popular, es una metodología, es un paradigma en el que tienes múltiples editores y múltiples suscriptores que pueden comunicarse entre sí de forma desacoplada. Desacoplado significa que el editor no sabe quién es el suscriptor, simplemente publica mensajes sobre ciertos temas y estos suscriptores pueden recibirlos. Las consultas continuas son del mismo modo. Entonces, esas son las dos formas comunes. NCache se utiliza.

Aplicaciones .NET frente a Java

Ahora hablemos de cómo NCache maneja aplicaciones .NET frente a Java. NCache tiene una capacidad multiplataforma nativa única que encontrarás muy interesante, déjame entrar en eso.

Edición .NET

NCache intenta proporcionarle una solución nativa tanto para .NET como para Java. Y con eso quiero decir que cuando tienes una aplicación .NET, toda tu pila de aplicaciones experimenta .NET, no estás usando nada más que .NET. Así por ejemplo, NCache tiene un cliente .NET nativo que es lo que su aplicación utilizará en su aplicación. Esto se ejecuta en su servidor de aplicaciones y NCache lo ha desarrollado en 'C Sharp' (C#), 100%.

NCache Arquitectura
NCache Edición .NET: solución nativa para aplicaciones .NET

De manera similar, si tiene código del lado del servidor como lectura, escritura, derecho detrás, cargador/actualización que haya escrito en .NET, NCache ejecutará ese código en su propio proceso .NET CLR. Déjame enseñarte como. Y volveré a este diagrama de un lado a otro. Entonces, por ejemplo, aquí hay un NCache arquitectura, aquí tiene una aplicación .NET que puede ejecutarse en Windows o Linux. tiene un nativo NCache Cliente .NET. Y esto es hablar con un NCache clúster que es una edición .NET NCache Grupo. Entonces, eso significa que el código del lado del servidor también es .NET.

ahora el camino NCache está diseñado y es por eso que lo que lo hace realmente poderoso para el soporte nativo multiplataforma es que hay un proceso de caché, hay un proceso de administración, que están separados del proceso de código del lado del servidor. Y hay un RPC de muy alto rendimiento. Es un RPC en memoria que NCache usos, que NCache ha desarrollado su propio RPC patentado que es súper rápido. Entonces, así es como el caché se comunica con el código del lado del servidor. Entonces, por ejemplo, si tiene que llamar al controlador de lectura, su controlador de lectura se ejecutará dentro de este proceso .NET CLR para ir a su base de datos para obtener los datos y luego los pasa al caché. Y lo mismo ocurre con la escritura directa, el cargador y el actualizador. Entonces, toda la experiencia que tiene su aplicación es .NET.

Edición Java

Bueno, pasemos al lado de Java. De nuevo, de la misma manera, tienes un código del lado del servidor Java. NCache tiene un Cliente 100% Java que se ejecuta en su servidor de aplicaciones y luego de la misma manera que .NET. Aquí está la edición Java. Digamos que tiene una aplicación Java que probablemente se esté ejecutando en Linux, o tal vez incluso en Windows, tal vez Docker, tal vez Kubernetes. Entonces, esa aplicación incorporará el NCache Cliente Java, que es, como dije aquí, 100% Java nativo, y luego este Cliente Java es básicamente idéntico al Cliente .NET. También habla con el NCache Agrupe de la misma manera que lo hace el cliente .NET usando NCacheEl propio protocolo de socket propietario y el NCache El servidor está diseñado para que el código Java del lado del servidor se ejecute en su propia JVM.

NCache Arquitectura
NCache Edición Java: solución nativa para aplicaciones Java

Por lo tanto, todo el desarrollo, las pruebas y la depuración que realizará se realizarán en procesos nativos de JVM. Y este proceso de caché llamará, digamos, al controlador de lectura directa que ingresará, digamos, tal vez a Oracle o Db2, o incluso a la base de datos de SQL Server, obtendrá los datos y los entregará al proceso de caché. Nuevamente se utiliza el mismo RPC en memoria de alto rendimiento. Entonces, al tener una arquitectura que encapsula el código .NET y Java en sus propios procesos nativos, NCache es capaz de ofrecerle una pila nativa tanto para Java como para .NET.

Y, nuevamente, en el caso de una aplicación Java, es posible que desee realizar el desarrollo en Windows o Mac OS y NCache lo admite completamente, o incluso Linux, y entonces es más probable que uses Docker y Kubernetes que la gente de .NET. NCache le proporciona las imágenes de Docker y también soporte completo para Kubernetes, Azure AKS, AWS EKS, Google GKE o Red Hat OpenShift. Puedes usarlo de una manera muy fluida.

¿Entonces NCache es muy singular. Le brinda una experiencia .NET nativa y al mismo tiempo una experiencia Java nativa. Por lo tanto, si usted es una tienda Java, no sentirá que está usando un producto que no es Java y si es una tienda .NET, no sentirá que está usando un producto que no sea .NET. Producto NETO. Esa es la belleza de NCache la forma en que está diseñado.

Clúster dinámico

Bien, entremos ahora en el Agrupación dinámica parte de NCache Arquitectura que es para alta disponibilidad. Y un segundo, está bien. Entonces, la primera parte es el Clúster Dinámico. Cuando uso la palabra clúster no me refiero a Kubernetes Cluster, ni a ningún otro clúster a nivel de sistema operativo. Esto es NCacheSu propio clúster basado en TCP. Y este clúster tiene una arquitectura de igual a igual. Lo que significa peer-to-peer es que no hay amo ni esclavo. El problema maestro/esclavo es que si el maestro deja de funcionar, el esclavo deja de funcionar o se vuelve limitado, mientras que en una arquitectura peer-to-peer, todos los nodos tienen la misma capacidad. Obviamente, hay un nodo coordinador del clúster, que es el nodo más antiguo y, si ese nodo alguna vez deja de funcionar, el siguiente más antiguo se selecciona automáticamente como coordinador del clúster. El coordinador del grupo es miembro del grupo. Gestiona el mapa de distribución, el estado del clúster y muchas otras cosas sobre las que repasaré algunas de ellas.

Clúster de caché dinámica
Clúster de caché dinámica

La agrupación en clústeres dinámica significa que puede agregar o eliminar servidores al clúster en tiempo de ejecución sin detener el caché o la aplicación. No hay interrupción. Y, cuando, digamos, agrega un nuevo servidor al clúster, la membresía del clúster obviamente se actualiza en tiempo de ejecución y esa información de tiempo de ejecución luego se propaga a los clientes. Y hablaré un poco más sobre eso en la siguiente diapositiva.

También hay una función de conmutación por error de conexión de clúster. Debido a que estos son sockets, aunque los servidores del clúster generalmente están en la misma subred bastante cerca uno del otro, puede que no siempre sea así. Tenemos clientes que incluso tienen servidores implementados en diferentes regiones y funciona perfectamente bien, aunque recomendamos que en la mayoría de los casos, el NCache Los servidores deben estar bastante cerca unos de otros. Sin embargo, aún podría haber una falla en la conexión. Si ese es el caso NCache tiene una lógica de reintentos y hay tiempos de espera. Hay una lógica de latidos, todo eso es para garantizar que todo sea dinámico.

Clientes dinámicos y configuración dinámica

Conexiones dinámicas de clientes

La otra parte de la arquitectura dinámica son los Clientes Dinámicos. Entonces, de esta manera, el clúster tenía la capacidad de agregar o eliminar servidores en tiempo de ejecución y también tiene la capacidad de agregar o eliminar clientes en tiempo de ejecución. ¿Qué significa un cliente? Un cliente es el NCache Cliente que se ejecuta en su servidor de aplicaciones, su servidor web, esa es la parte con la que habla su aplicación. Entonces, puede agregar un cliente en tiempo de ejecución y puede eliminar un cliente en tiempo de ejecución sin detenerse. NCache, el caché o su aplicación sin tener ninguna interrupción. Entonces, esa es la primera parte.

Clientes dinámicos y configuración dinámica
Clientes dinámicos y configuración dinámica

Configuración dinámica

La segunda parte es la Configuración Dinámica. Entonces, como mencioné en la última diapositiva, cuando agrega un servidor al clúster, la membresía del clúster cambia. Bueno, eso se propaga a todos los clientes existentes que están conectados, de modo que ahora sepan que hay un nuevo servidor al que deben conectarse. Por lo tanto, si eligen hacerlo según la topología de almacenamiento en caché, también pueden conectarse a ese servidor. Además, dependiendo de la topología puede haber un Mapa de Distribución. Un mapa de distribución es más para caché particionada y caché de réplica particionada. Pero, a medida que agrega un servidor, este se actualiza y se propaga en tiempo de ejecución. Y también muchos otros cambios de configuración. Hay una función de aplicación activa que puede realizar y que se propaga en tiempo de ejecución. Entonces esa es la segunda parte.

Conmutación por error de la conexión del cliente

La tercera parte es que nuevamente hay una conmutación por error de la conexión del cliente que es de la misma manera que la conmutación por error de la conexión del clúster. Pero, en realidad, esto es aún más necesario porque los clientes probablemente no siempre estarán muy cerca de los servidores del clúster. Y puede haber algunos enrutadores o firewalls en el medio. Por lo tanto, es más probable que se rompa la conexión entre los clientes y el clúster. Entonces, NCache tiene una capacidad de reintento bastante inteligente, tiempo de espera. También existe la capacidad de mantener vivo, de modo que el cliente permanece conectado incluso si la conexión se interrumpe, el cliente se vuelve a conectar a la red. NCache Grupo.

Detección y recuperación de cerebro dividido

Otro tema importante del aspecto dinámico de NCache La arquitectura es el cerebro dividido. El cerebro dividido es un fenómeno que puede ocurrir en el cúmulo.

El cerebro dividido ocurre cuando se rompe la conexión

Y el cerebro dividido ocurre cada vez que, digamos, si tiene un grupo saludable de seis servidores, se produce un cerebro dividido cuando la conexión entre algunos de estos servidores se interrumpe por algún motivo y, en cualquier momento que tenga conexiones de red, estas pueden interrumpirse. Y eso lo vemos todo el tiempo. Entonces, cuando eso sucede, se forman subgrupos. Digamos que en este caso hay una división 1, una división 2 y una división 3. Cada subgrupo cree que es el superviviente. Entonces, crea su propio coordinador de clúster y se convierte en un clúster independiente.

Detección y recuperación de cerebro dividido
Detección y recuperación de cerebro dividido

Detección de cerebro dividido

Sin embargo, todas estas divisiones recuerdan que solían ser parte de un clúster saludable y estos servidores no se fueron voluntariamente, no se fueron sin problemas. No hiciste un 'nodo de salida' desde el NCache Herramienta de administración en cambio, la conexión se rompió. Por lo tanto, seguirán buscando estos servidores para ver si se restablece la conexión de red. Y, la mayoría de las veces, tal vez cinco, diez minutos, media hora, una hora más tarde, lo más probable es que se restablezca la conexión.

Recuperación de cerebro dividido

Cuando eso sucede, se realiza una recuperación del cerebro dividido. Y ahí es donde se fusionan estas divisiones. Estos subgrupos se fusionan de forma iterativa de mayor a menor y, obviamente, hay cierta pérdida de datos porque se convirtieron en grupos independientes y ahora algunos de los datos deben perderse. Pero todo se hace automáticamente según las reglas que usted especifique.

Hay más detalles sobre el cerebro dividido en un artículo separado. video pero esto te da una visión general. Es una característica muy importante que garantiza que su NCache El grupo se mantiene sano y puede recuperarse cada vez que se produce una división del cerebro.

Topologías de almacenamiento en caché

Bien, ahora pasemos a Topologías de almacenamiento en caché. Las topologías de almacenamiento en caché son esencialmente almacenamiento de datos, estrategias de replicación y también estrategias de conexión del cliente. Hay cuatro topologías: una es caché particionada, réplica de partición, caché replicada y caché reflejada. Vayamos con la caché particionada.

Caché con particiones

Caché con particiones Básicamente es que todo el caché se divide en particiones, cada servidor tiene una partición. Y existe este concepto de cubos. Entonces, cada partición tiene depósitos. Un total de 100 depósitos para todo el caché. Entonces, dependiendo de cuántas particiones tenga, esos depósitos se dividirán equitativamente entre ellos.

Caché con particiones
Caché con particiones

Y estas particiones se crean en tiempo de ejecución, esa es la parte importante en esto. Entonces, cuando agrega un servidor, se crea una partición. Digamos que comienzas con un servidor, solo hay una partición y los 100 depósitos están en esa partición. Si agrega un segundo servidor en tiempo de ejecución, no solo se actualiza la información de membresía del clúster que mencioné en las diapositivas anteriores, sino que ahora también se actualiza el mapa de distribución. Un mapa de distribución es esencialmente un mapa de qué partición contiene qué depósitos. Entonces, digamos que si agregó una segunda partición, el mapa de distribución ahora cambiará. Un mapa de distribución es, en realidad, un mapa hash que se asigna a depósitos. El valor del mapa hash varía hasta depósitos. Y esto no cambia según la cantidad de datos que haya agregado, cambia solo cuando cambia la cantidad de servidores, la cantidad de particiones o realiza el reequilibrio de datos. Entonces, las particiones son dinámicas.

Equilibrio de datos dinámico

La segunda parte es que hay un equilibrio dinámico de datos. Entonces, debido a que todo esto se basa en un mapa hash, es muy posible que, según el tipo de claves que utilizó, algunos de los depósitos obtengan más datos que otros. Y terminará con algunas particiones casi llenas y otras casi vacías. Y, cuando eso sucede, NCache tiene esta característica donde puedes establecer un umbral. Digamos que si una partición se llena en más del 80%, elimine el 20%, el 10% o el 5%. No eliminarlo, me refiero a equilibrarlo dinámicamente. Entonces, el equilibrio de datos significa tomar esos depósitos de la partición 1 y copiarlos a otra, o moverlos a otras particiones. Por lo tanto, el equilibrio de datos garantiza que los datos y todas las particiones sean bastante uniformes.

El cliente se conecta a todas las particiones

En Partitioned Cache cada cliente se conecta a todas las particiones o a todos los servidores. La razón por la que lo hace es porque quiere acceder directamente a cualquier elemento que desee en una sola llamada. Si solo estuviera conectado a un servidor, digamos, y quisiera el elemento número 3, hablará con el servidor 1, el servidor 1 irá al servidor 2 y lo obtendrá. Y esa es una operación de dos saltos que no está tan optimizada como si el cliente pudiera ir directamente a donde estaban los datos. Y el cliente lo sabe gracias a un mapa de distribución. Es por eso que el mapa de distribución se crea para ayudar a los clientes a saber dónde están los datos, para que puedan ir y obtenerlos directamente desde allí.

El cliente se conecta a todas las particiones
El cliente se conecta a todas las particiones

Entonces, la caché particionada no tiene replicación. Entonces, si algún servidor falla, perderá esos datos. No hay manera excepto si usas 'Persistencia', de la que hablaré más adelante. Entonces, incluso la caché particionada no pierde ningún dato.

Caché de réplica de partición

Réplicas de Particiones (Dinámicas)

La siguiente topología es la caché de réplica de partición. Por cierto, esta es nuestra topología más popular porque ofrece lo mejor de ambos mundos. Te proporciona la partición, que es la escalabilidad. Y también le brinda replicación, que es la alta disponibilidad. Por lo tanto, no hay pérdida de datos. Entonces, por ejemplo, es la misma manera que la caché particionada, todo es igual pero cada partición ahora tiene una réplica en un servidor diferente. Entonces, la partición uno está en el Servidor 1, entonces su réplica se llama Réplica 1, que está, digamos, en este caso en el Servidor 2. Entonces, al igual que las particiones se crearon dinámicamente en el momento, las réplicas también se crean en tiempo de ejecución, cuando las particiones se agregan o eliminan. Y, obviamente, siempre están ubicados en un servidor diferente.

Caché de réplica de partición
Caché de réplica de partición

La otra parte es que todas las réplicas son pasivas. Pasivo significa que ningún cliente les habla directamente. Los clientes significan que estos solo hablan con las particiones y las particiones luego actualizan su réplica. Entonces, cada vez que actualiza algo en la partición, la partición lo actualiza en la réplica. Y esa actualización de forma predeterminada es asincrónica. Asíncrono es, para que pueda ser más rápido. En primer lugar, el cliente no tiene que esperar a que se realice la replicación; en segundo lugar, puede realizar una replicación masiva. Por lo tanto, puede combinar cientos o miles de esas actualizaciones y moverlas o enviarlas a la réplica a la vez. Porque el costo de este viaje de red es mucho más rápido o mucho más costoso que combinar datos.

Replicación asíncrona/sincronizada

Sin embargo, la replicación asíncrona obviamente no siempre es consistente. En última instancia, es consistente, lo cual es lo suficientemente bueno tal vez entre el 95 % y el 99 % de las veces y, tal vez, hay entre el 1 y el 5 % de los casos en los que se trata de datos muy confidenciales. Por lo tanto, no desea una replicación asincrónica, desea una replicación sincrónica. Entonces, hay una función llamada Sincronización de replicación que puede activar y, cuando lo hace, cada vez que el cliente actualiza elementos en la partición, esa operación no se completa hasta que la partición actualiza la réplica primero. Entonces, si esa replicación falla, la operación falla. Entonces, así es como, si la operación tuvo éxito, la replicación también tuvo éxito. Entonces, esa es una característica muy importante de esto.

Y finalmente, al igual que la topología particionada, la topología de caché particionada también tiene equilibrio dinámico de datos en las réplicas. Entonces, cuando las particiones tienen datos equilibrados dinámicamente, las réplicas deben coincidir con eso porque las réplicas son siempre una copia idéntica de la partición. Por lo tanto, también pasarán por un equilibrio de datos.

Particionamiento dinámico

Veamos ahora rápidamente cómo ocurre realmente la partición dinámica. Entonces, digamos, si tuviera un clúster de dos servidores y tuviera 6 elementos en él y quisiera agregar un tercer servidor, no agregaré más datos todavía porque ese es otro caso de uso, así es como están los datos. se desplaza a otras particiones a medida que agrega otro nodo.

Digamos que agregas un nodo. Ahora hay un tercer servidor. Entonces, se crea la Partición 3 y la Partición 3 ahora obtiene datos de la Partición 1 y la Partición 2. Entonces, obtiene algunos datos de 1 y otros de 2. Entonces, digamos, digamos que toma el Elemento 3 de la Partición 1, el Elemento 4 de la Partición 2. y se convierte en la Partición 3.

Partición dinámica: agregar un nodo
Partición dinámica: agregar un nodo

Ahora que se convirtió en la Partición 3, su réplica tiene que estar en un servidor diferente, entonces, digamos, se coloca en el Servidor 1. Entonces, el Servidor 1 solía tener la Réplica 2, se convierte en la Réplica 3 y luego la Réplica 2 se mueve. en el Servidor 3. Entonces, por ejemplo, ahora la Réplica 3 contendrá 3, 4 en lugar de 4, 5, 6, y la Réplica 2 contendrá 5, 6. Todo eso se hará dinámicamente en tiempo de ejecución sin que su aplicación vea cualquier interrupción.

Lo mismo sucede al revés que si un servidor se cae, digamos que tenías una partición de tres. NCache El clúster y el servidor 3 cayeron, o lo bajaste tú o se cayó, tan pronto como eso sucede, porque la partición 3 ya no está disponible, la réplica 3, como puedes ver, cambié su color, se activa. Normalmente, como dije, las réplicas no están activas, ¿verdad? Sólo las particiones están activas, pero ahora esto se convierte en una partición. Pero es sólo temporal porque no desea tener dos particiones en el mismo cuadro y luego ninguna réplica.

Partición dinámica: eliminar un nodo
Partición dinámica: eliminar un nodo

Entonces, ahora esto se fusiona aquí con la Partición 1, entonces, digamos, el Elemento 3 va a la Partición 1, el Elemento 4 va a la Partición 2, y su situación es así aquí y esta Réplica 3 ahora se convierte en Réplica 2. Entonces, la Pasa lo mismo al revés, todo en tiempo de ejecución, Particionamiento Dinámico, muy muy flexible, muy dinámico. Esta dinámica añade el poder de alta disponibilidad de NCache.

Modo de mantenimiento

Bueno, aunque esa partición dinámica es muy útil y muy poderosa, hay algunos casos en los que no desea volver a particionar y uno de esos casos es el mantenimiento programado. Digamos que está aplicando un parche al sistema operativo y ese parche hará que el servidor caiga durante cinco o diez minutos. Bueno, ya sabes, todo tu clúster de caché puede tener decenas de gigabytes de datos. Por lo tanto, no desea reparticionar solo durante esos cinco minutos y luego volver a particionar cuando vuelva a activar ese nodo. Por lo tanto, puede activar una función de mantenimiento programado de NCache en cuyo caso, cuando desactiva este nodo, nuevamente tiene que desactivarlo a través de su herramienta de administración, lo que provoca que esta réplica se active pero no se vuelva a particionar.

Caché de réplica de partición (modo de mantenimiento)
Caché de réplica de partición (modo de mantenimiento)

Por lo tanto, permanece como una configuración de dos servidores con la Partición 1, Réplica 3, la Partición 2, Réplica 1 y esta Réplica 3 es en realidad la Partición 3, lo que significa que está activa y funciona. Obviamente, no es alta disponibilidad porque aunque la partición 1 está respaldada aquí. La partición 2 no tiene copia de seguridad y la réplica 3 no tiene copia de seguridad. Pero esto es sólo temporal porque sólo lo necesita durante 5 o 10 minutos. Entonces, una vez que este servidor vuelve a funcionar, vuelve al estado anterior y se convierte nuevamente en una réplica cuando vuelve a convertirse en una partición. Entonces, así es como funciona la función de mantenimiento programado de NCache funciona

Caché replicado

La siguiente topología se llama Caché replicado. En esta topología puede tener dos o más servidores donde cada servidor tiene una copia completa del caché y cada servidor está activo, lo que significa que cada servidor tiene clientes conectados. Pero aquí cada cliente solo se conecta a un servidor. Porque ese servidor tiene todo el caché. Por lo tanto, no es necesario conectarse a dos servidores como partición o réplica de partición.

Caché replicado
Caché replicado

En esta topología, todas las lecturas son súper rápidas porque todo el caché está ahí, pero las actualizaciones deben realizarse de forma sincrónica. Debido a que ambos son servidores activos, el mismo elemento podría actualizarse aquí y aquí simultáneamente y obviamente no desea entrar en un problema de integridad de datos. Entonces, se hace de manera sincrónica donde hay un esquema de indexación, hay un índice, en realidad se emite como un número de secuencia y cada elemento se actualiza en la misma secuencia. Entonces, eso permite que las actualizaciones se realicen siempre de forma correcta. Sin embargo, el costo es que una actualización sincrónica significa que si tiene un cliente que actualiza el Elemento 1, este Servidor notificará al Elemento 2 para que actualice el Elemento 1. Cuando ambos servidores hayan actualizado el Elemento 1 exitosamente, la actualización será exitosa y el control vuelve. Entonces, eso significa que no es tan rápido como la topología de Partición o Réplica de Partición, pero se garantiza que la operación lo será, si esa actualización se realiza correctamente, eso significa que siempre se realiza en todos los servidores.

Esta topología es buena para operaciones de lectura intensiva. Para un clúster de dos servidores, incluso las escrituras son bastante rápidas, no tan rápidas como la réplica de partición, pero razonablemente rápidas para la mayoría de las situaciones. Sin embargo, a medida que agrega más servidores, el rendimiento de las actualizaciones disminuye. En realidad, se vuelve más lento porque es necesario actualizar más servidores de forma sincrónica. Entonces, esta topología tiene sus propios usos, por eso la mantenemos. Muchos de nuestros clientes lo utilizan en situaciones especiales.

Caché reflejada

La cuarta topología se llama Caché reflejada. Esta es nuevamente una topología muy específica. Es solo una topología de 2 nodos. Hay un nodo Activo y uno Pasivo. Nuevamente, el nodo activo tiene todo el caché y una copia del caché se encuentra en el nodo pasivo. Todos los clientes se conectan al nodo activo y actualizan el nodo activo para todas las cosas, y las actualizaciones se reflejan o replican de forma asincrónica en el nodo pasivo. Y eso asíncrono significa que también es bastante rápido, al igual que Partition Replica.

Caché reflejada
Caché reflejada

En esta topología, si el nodo activo alguna vez deja de funcionar, el nodo pasivo se activa automáticamente y todos los clientes se mueven automáticamente al nodo pasivo o al nodo recientemente activo. Y de esa manera no hay tiempo de inactividad, no hay interrupciones y eso se llama soporte automático de conmutación por error, eso es lo que quise decir con eso. Y luego, obviamente, cuando el nodo activo vuelve a activarse, vuelve a estar activo y sucede lo mismo a la inversa.

Por tanto, la topología espejo también es muy útil para casos especializados. No es escalable más allá de estos dos servidores, pero tiene su propio uso debido al hecho de que todos los clientes se conectan aquí y luego puedes hacer una réplica en una caja diferente. Quiero decir que esto podría usarse, por ejemplo, en caso de una situación de recuperación ante desastres, por ejemplo.

Persistencia en vivo

Otra característica muy poderosa de NCache se llama Persistencia en vivo. Live Persistence está disponible solo para topologías de partición y réplica de partición, y está activo, lo que significa que a medida que actualiza el caché en tiempo de ejecución, el almacén de persistencia también se actualiza inmediatamente. La actualización del almacén persistente es asíncrona. Por lo tanto, no interfiere con el rendimiento de su aplicación o NCache actuación. Así es como su aplicación puede ser muy rápida. La persistencia se realiza a nivel de depósito. Entonces, hay 100 depósitos que representan todo el caché que se guardan en un NoSQL almacén de documentos. Es un almacén basado en archivos, por lo que no es un almacén basado en servidor. No es un NoSQL database servidor, es un NoSQL almacén de documentos que NCache usos. Puede usarlo en una ubicación común que sea común a todos los servidores del NCache clúster, y de esa manera todos pueden confiar en el mismo almacén persistente.

Persistencia en vivo
Persistencia en vivo

Algunos de los beneficios de esto son, y la razón por la que se proporciona esta característica, el número uno: sea lo que sea que persista, puede, por ejemplo, conservar todo el caché, y todo el caché siempre se conserva. Puedes decir que cualquier cosa que estés actualizando en el caché, ya sabes, con la diferencia de unos pocos milisegundos, también se mantiene en el almacén persistente. Entonces, puede tomar eso y recargarlo en un caché diferente, o si todos los servidores fallaran, siempre puede reiniciarlos desde los almacenes persistentes. No pierde ningún dato, excepto una cantidad muy pequeña de datos. O tal vez quieras llevar el caché de un entorno a otro, puedes hacerlo fácilmente.

El otro beneficio es que en realidad agrega más alta disponibilidad a las topologías de partición y réplica de partición. Bueno, topología de partición, y hablaré de eso aquí. Entonces, la caché particionada, como mencioné anteriormente, no tiene ninguna replicación, por lo que, si alguna partición o servidor falla, se pierde esa partición, ¿verdad? Bueno, si tienes perseverancia entonces no la tienes. Porque también se guarda una copia de esos datos en estos depósitos. Entonces, si este servidor dejara de funcionar, los depósitos en la memoria se reasignarían, pero obviamente sin datos, a otros servidores y ahora esos servidores saben que estos son depósitos vacíos cuyos datos existen en el almacén de persistencia, por lo que recargarán esos datos desde la persistencia. almacenar.

Persistencia en vivo (sin pérdida de datos)
Persistencia en vivo (sin pérdida de datos)

Así es como no se pierde ningún dato incluso si un servidor falla, aunque esté usando Partitioned-Cache. Y tiene el mismo beneficio que una réplica de partición que un caché particionado.

El beneficio que obtendrá aquí es que podrá utilizar más memoria. Puede almacenar más datos en el caché porque aquí tiene que asignar más memoria para la réplica, que no tiene que asignar aquí, pero sí debe asignar el almacén de persistencia. Entonces, ese es el beneficio de la caché particionada. También hay beneficios en Partition-Replica. Y es algo interesante que, aunque esto ya le brinda alta disponibilidad, la alta capacidad ocurre solo si un servidor deja de funcionar en cualquier momento dado, pero, digamos, si dos servidores caen simultáneamente sin la persistencia. en Partition-Replica perderías datos. Porque, ya sabes, solo hay una copia de cada partición y si dos servidores fallaran, entonces perderías más servidores de los que puedes permitirte. Bueno, con la persistencia no tienes ningún problema, simplemente puedes recargar todos esos datos desde el almacén de persistencia.

Obviamente, en ambos casos, debes tener en cuenta que cada vez que cargas datos desde el almacén de persistencia tenías tres servidores y ahora tienes dos. Bueno, los datos pueden valer demasiado para caber en los dos servidores, lo que puede ser otro problema con el que tenga que lidiar: asegurarse de tener suficiente memoria en estos dos servidores restantes para que puedan acomodar el equivalente de los tres. servidores. Entonces, esa es la única limitación. De lo contrario, la persistencia realmente agrega valor tanto al caché particionado como al de réplica de partición.

Caché de cliente

Bien, otra característica muy importante de NCache se llama Caché de cliente. Le brinda una velocidad InProc en un entorno de tienda distribuida. Entonces, por ejemplo, tienes un distribuido NCache clúster, su aplicación se ejecuta aquí, esto generalmente es un caché encima de su base de datos o cualquier otra cosa que esté haciendo, un caché de cliente generalmente se usa cuando tiene un escenario de caché distribuido, y un caché de cliente es un caché encima de este clúster de caché y se encuentra muy cerca de su aplicación. Se encuentra en el servidor de aplicaciones o en el NCache cuadro de cliente. E incluso puede ser InProc o OutProc según sus preferencias. Una caché InProc es súper rápida porque en realidad mantiene los datos en forma de objeto deserializado en su montón. Entonces, es como tener ese objeto en tu montón. Puede ser más rápido que eso.

Caché de cliente
Caché de cliente

Entonces, un caché InProc es súper rápido pero al mismo tiempo lo bueno es que está sincronizado con el NCache grupo. Y la forma en que se sincroniza es lo que se guarda en la caché del cliente que el clúster conoce. Entonces, si algo que se mantuvo en esta caché de cliente se actualiza en otro cliente en el clúster, el clúster notifica a esa caché de cliente que se actualice. Y luego ese Client Cache se actualiza de forma asincrónica. Obviamente, hay un retraso de unos pocos milisegundos, pero eso es, como dije, la consistencia final es el modelo en la mayoría de los casos, y eso generalmente es aceptable para el 99% de los casos.

Si eso no es aceptable entonces NCache le proporciona... y la sincronización optimista es la predeterminada, que es donde hay un retraso de unos pocos milisegundos y técnicamente podría haber una situación en la que tenga datos obsoletos, lo cual está bien, como dije, el 99% de las veces. Pero, digamos, si no estuviera bien y sus datos fueran muy confidenciales pero aún quisiera usar la caché del cliente, entonces podría usar una capacidad de sincronización pesimista donde se asegure de que antes de que su aplicación obtenga algo de la caché del cliente, el cliente La caché solo verifica si hay una versión más nueva de esos datos, eso es una llamada más rápida que obtener los datos en sí porque, NCache luego mantiene información de versiones múltiples. Y luego, si hay una versión más nueva de esos datos, la caché del cliente la recupera; si no, simplemente la devuelve desde la caché del cliente.

Un caché de cliente que puedes usar sin ningún cambio de código. Simplemente se conecta a su entorno y es bueno para situaciones de lectura intensiva. Cuando haces muchas más lecturas, al menos 5:1, 10:1 es ideal, pero cuando hay 1:1, digamos, en el caso de sesiones web, Client Cache en realidad no ayuda en absoluto. De hecho, no es nada recomendable.

Replicación WAN

Multizona/Multiregión

Bien, otra parte de NCache es el donde NCache sí Replicación WAN para manejar la implementación multizona o multirregional de sus aplicaciones. Entonces, por ejemplo, podría implementar su aplicación en dos sitios diferentes para DR, para recuperación ante desastres, uno activo y otro pasivo. Y tienes esta aplicación, una NCache ejecutándose con él, y aquí tiene una aplicación que no se está ejecutando. Pero desea asegurarse de que, si este sitio alguna vez deja de funcionar, podrá recuperar la carga de inmediato. Entonces, puedes poner un puente. Un puente es un clúster de 2 nodos que puede estar en las mismas cajas que el NCache principal, o podría ser uno dedicado por separado, depende de usted. Y luego, todo lo que actualice en este caché se replica de forma asincrónica a través de la WAN al otro caché. Entonces, ese es el activo-pasivo.

Replicación WAN de NCache
Replicación WAN de NCache

Puedes hacer lo mismo con un activo-activo. Digamos que si tiene una situación en la que incluso este sitio está activo, puede hacer exactamente lo mismo con un activo-activo donde ambos sitios pueden actualizarse entre sí. En ese caso, también existe una situación en la que el conflicto puede resolverse, puede surgir. Y lo que significa un conflicto es que el mismo elemento, la misma clave, se actualiza en ambos sitios simultáneamente. Si eso sucede, el puente aplica de forma predeterminada la lógica de "última actualización gana". Entonces, gana quien tenga la marca de tiempo posterior a la actualización. Pero, por ejemplo, si lo desea, también puede proporcionar una resolución de conflictos y un controlador de resolución de conflictos, que es su código .NET o Java al que llamará el puente, y pasará ambas copias de los datos o del objeto a ese controlador de resolución. y luego puedes analizar el contenido para determinar cuál es más correcto, y luego dices, está bien, esta actualización gana y luego esa actualización se aplica a ambos sitios. Mientras eso se aplique a ambas partes, no habrá conflicto.

El NCache tiene la capacidad de brindarle tres o más sitios en modo activo-activo, activo-pasivo, o alguna combinación de ellos. Entonces, por ejemplo, necesita al menos uno activo, pero todos podrían ser pasivos o todos podrían ser activos o podría ser una combinación de activo o pasivo. Y, nuevamente, de la misma manera, cuando hay más de uno activo, esto podría ser la resolución de conflictos.

3+ Activo Activo
Replicación WAN de NCache (3+ Activo-Activo)

Contenedores (Docker y Kubernetes)

Finalmente, los contenedores Docker y Kubernetes se han vuelto muy populares. Entonces, NCache Obviamente los admite porque son más populares en el lado de Java y Linux que en el lado de .NET y Windows todavía, pero estoy seguro de que eso va a cambiar, ya sabes, con el tiempo. Entonces, de cualquier manera, NCache es totalmente capaz de manejarlo en ambos entornos. Entonces, por ejemplo, aquí hay un típico Implementación de Kubernetes de NCache.

Implementación de Kubernetes de NCache
Implementación de Kubernetes de NCache

Aquí hay un NCache despliegue. hay NCache obtuvo su propio servicio Discovery. Estos son pods que se pueden escalar y luego tienes aplicaciones dentro del clúster de Kubernetes que son NCache clientes y podría ser Azure, AKS, AWS, EKS, Google GKE o Red Hat OpenShift. Red Hat OpenShift suele ser otra nube como AWS, Azure o Google o tal vez otra nube, pero NCache apoya a todos ellos. Y este Pod podría ser Linux, que es el caso más común en Kubernetes, y NCache Funciona perfectamente bien. Y la aplicación también puede ser Linux o Windows. Entonces, podrían ser Linux o Windows, Linux o Windows.

Docker / Kubernetes (multizona)

De la misma manera que se activa la replicación WAN, si lo desea, digamos, debido a la nube, puede tener múltiples zonas de disponibilidad. Querías hacer un Kubernetes multizona.

Implementación de Kubernetes multizona de NCache
Implementación de Kubernetes multizona de NCache

Entonces, la forma que recomendamos es crear un clúster de Kubernetes, tener dos NCache implementaciones, estas podrían ser activa-activa o activa-pasiva. Y entonces el puente puede estar completamente aquí o completamente aquí. O incluso puede dividir un puente donde una parte está en esta zona y otra en esa zona y luego la replicación se produce de forma asincrónica.

Creo que eso cubre bastante bien el tema de hoy. Le recomiendo encarecidamente que visite nuestro sitio web y eche un vistazo a NCache Patio de juego al aire libre que es realmente una manera muy rápida y fácil desde su navegador de usar una copia en vivo de NCache, e incluso puedes obtener un 2-Nodo NCache Clúster con todas las herramientas sin ningún esfuerzo de instalación. O si estás listo, simplemente ven aquí y registrarse y descargar ya sea NCache Enterprise para la edición .NET o NCache Enterprise para la edición Java. Como dije, puede obtener .tar.gz para Linux, .msi o también puede obtener Docker. Puedes simplemente extraer una imagen de Docker de NCache. Ese es el final de mi presentación. Muchas gracias.

¿Qué hacer a continuación?

© Copyright Alachisoft 2002 - Todos los derechos reservados. NCache es una marca registrada de Diyatech Corp.