Campamento 2017 del código del sur de la Florida
Escalado de aplicaciones .NET con almacenamiento en caché distribuido
Por Iqbal Kan
Presidente y evangelista tecnológico
Sus aplicaciones .NET pueden experimentar cuellos de botella en la base de datos o en el almacenamiento debido al aumento de la carga de transacciones. Aprenda a eliminar cuellos de botella y escalar sus aplicaciones .NET mediante el almacenamiento en caché distribuido. Esta charla cubre:
- Descripción general rápida de los cuellos de botella de escalabilidad en las aplicaciones .NET
- Descripción del almacenamiento en caché distribuido y cómo resuelve los problemas de rendimiento
- ¿Dónde puede usar el almacenamiento en caché distribuido en su(s) aplicación(es)?
- Algunas características importantes en un caché distribuido
- Ejemplos prácticos usando un caché distribuido
Hoy voy a hablar sobre cómo puede escalar aplicaciones .NET con almacenamiento en caché distribuido. Esta charla no se trata de NCache. Aunque me referiré a NCache pero el objetivo principal es educarlo sobre cuáles son los problemas y cómo puede resolverlos con el almacenamiento en caché.
¿Qué es la escalabilidad?
¡De acuerdo! Solo para fines de exhaustividad, repasemos algunas de las definiciones que estoy seguro de que ya conoce, pero primero definamos qué es la escalabilidad. La escalabilidad no es alto rendimiento. El alto rendimiento sería algo si tuviera cinco usuarios, tiene un tiempo de respuesta realmente bueno, eso es un alto rendimiento. La escalabilidad es si puede mantener ese mismo alto rendimiento bajo cargas máximas. Entonces, si su aplicación no tiene un alto rendimiento con cinco usuarios, entonces tiene otros problemas. Más de lo que podemos resolver allí.
Escalabilidad lineal
En segundo lugar, qué es la escalabilidad lineal. La escalabilidad lineal es más una definición de implementación.
Cuando implementa su aplicación en un entorno de varios servidores, digamos, si tiene un entorno de carga equilibrada, su aplicación es linealmente escalable si simplemente puede agregar más servidores para obtener capacidad de transacción adicional. Entonces, si tiene mil usuarios con dos servidores, tiene un tercer servidor, obtiene, digamos, 1500 usuarios y luego, a medida que agrega más servidores, obtiene 500 usuarios cada uno. Solo digo hipotéticamente, pero esa es una escalabilidad lineal. Si puede lograr eso, entonces ese es el objetivo porque entonces nunca se encontrará con problemas, para los cuales estoy seguro de que estuvo aquí para abordarlos.
Escalabilidad no lineal
La escalabilidad no lineal es justo lo contrario de eso, que es que tienes una arquitectura de aplicaciones en la que simplemente no puedes comprar hardware más caro o más servidores para resolver ese problema.
Tiene algunos cuellos de botella fundamentales, por lo que a medida que agrega más servidores, su aplicación, durante un cierto tiempo, el rendimiento o la capacidad de transacción aumenta, pero luego se ralentiza, incluso si agrega más servidores. Entonces, definitivamente no desea escalabilidad no lineal.
¿Qué tipo de aplicaciones necesitan escalabilidad?
Suelen ser aplicaciones del lado del servidor.
Estas son aplicaciones web, ASP.NET, estos podrían ser servicios web WCF, estos podrían ser el back-end para cualquier aplicación IOT. Tenemos muchos dispositivos IOT diferentes que se comunican con algún tipo de back-end. Estas podrían ser aplicaciones de procesamiento de big data, aunque el procesamiento de big data es más una actividad de Java. Debido a Hadoop, .NET no es un procesamiento de big data muy grande, pero si estuviera realizando un procesamiento de big data, definitivamente necesitaría escalar y cualquier otra aplicación de servidor que no encaje en esta categoría. Quiero decir que puede tener mucho procesamiento por lotes, si es una gran corporación, es posible que deba actualizar una cierta cantidad de cosas antes de la medianoche o antes del siguiente día hábil y, a medida que tiene más y más clientes, tiene millones y millones de clientes, por supuesto, necesita escalar eso.
Entonces, incluso esas aplicaciones de back-end, un buen ejemplo podría ser que los clientes, su banco y los clientes estén transfiriendo fondos de una cuenta a otra, que generalmente se procesa en el back-end en un modo por lotes por la noche. Por lo tanto, debe hacerlo por contrato dentro de un período de tiempo determinado. Entonces, todas estas aplicaciones, si no tienen escalabilidad, tienes grandes problemas.
¿Cuál es el problema de escalabilidad?
Afortunadamente, el nivel de la aplicación no es donde está el problema. Si tiene la mayoría de estas aplicaciones, el nivel de aplicación puede agregar más servidores, no hay problema. Es el almacenamiento de datos que es el problema. Y, cuando uso la palabra almacenamiento de datos, me refiero a bases de datos relacionales, datos heredados de mainframe. Ahí es donde reside la mayoría de sus datos y ellos son los que no pueden escalar de la misma manera que lo hacen las aplicaciones. Ahora, NoSQL databases existen para uno de los casos de uso es a escala, pero, el problema con NoSQL databases, y de nuevo, tenemos un NoSQL database de nuestro propio llamado NosDB. Es una base de datos de código abierto. Entonces, la limitación de NoSQL database es que simplemente no puede mover todos los datos porque requieren que los mueva lejos de su mainframe o sus bases de datos relacionales, lo que por una variedad de razones, tal vez técnicas, tal vez comerciales, es posible que no pueda hacerlo.
Por lo tanto, las bases de datos relacionales seguirán siendo su principal fuente de datos maestros. Hay muchos casos de uso en los que puede poner muchos de los nuevos datos en NoSQL databases y cuando lo hace, resuelven el cuello de botella de escalabilidad. Pero, en la mayoría de los casos, solo puede hacer eso para un subconjunto de sus datos. La mayoría de los datos aún debe permanecer en sus bases de datos relacionales o en sus fuentes de datos de mainframe heredadas. Entonces, cualquier problema que tenga que resolver, esta escalabilidad, debe resolverlo mientras continúa trabajando con bases de datos relacionales o con su mainframe heredado. Y ahí es donde un caché distribuido realmente resuelve ese problema. Le permite continuar usando sus datos de mainframe de bases de datos relacionales mientras elimina todos esos cuellos de botella.
Implementación de caché distribuida
Entonces, aquí hay una imagen, si la tuviera, si estos son sus datos heredados de bases de datos relacionales, puede colocar una capa de almacenamiento en caché entre la aplicación y la base de datos.
Cuando haces eso, comienzas a almacenar en caché datos que vas a usar con frecuencia. Y, alrededor del 80 por ciento de las veces, ni siquiera necesita ir a la base de datos. Y, el caché, debido a que es un caché distribuido, puede agregar más y más servidores, se escala de la misma manera que el nivel de la aplicación. Entonces, tiene un mínimo de dos servidores de caché aquí y luego mantiene una proporción de cuatro a uno o cinco a uno entre el nivel de aplicación y el nivel de almacenamiento en caché. Ahora, esa proporción puede cambiar según la naturaleza de sus operaciones. Si cada uno de sus, digamos, si tuviera una aplicación web, por cada clic de usuario hace cientos de llamadas de caché, entonces, por supuesto, la proporción cambiaría, pero la mayoría de las veces no hace cientos de llamadas de caché.
Un servidor de caché típico es solo un servidor de bajo costo. Es un tipo de configuración de servidor web, CPU dual, tipo de caja de cuatro núcleos, simplemente tiene mucha memoria. Mucha memoria significa que de 16 a 32 gigas es bastante estándar, más de 32 gigas normalmente no es necesario. Aunque tenemos muchos clientes que suben a 64 gigas, recomendamos que, en lugar de tener mucha más memoria en cada caja, agregue más cajas. Y, la razón es porque mientras más memoria tenga en cada caja, el procesador más potente que debe tener y entonces su caja comienza a parecerse cada vez más a una base de datos, lo cual no es la intención. Desea mantener este costo tan bajo como sea posible.
Ahora, un caché distribuido es una infraestructura que desea colocar para todas sus aplicaciones. Entonces, al igual que tiene una base de datos que es prácticamente una infraestructura común, la nueva mejor práctica es tener un caché distribuido en memoria. También se llama en memoria NoSQL almacén de valores clave. Y tenga eso como parte de sus aplicaciones de infraestructura y arquitectura para que siempre vaya a esta tienda. Entonces, revisa la tienda antes de ir a la base de datos. Una vez que tenga esa infraestructura, todas sus aplicaciones se volverán automáticamente escalables. Por lo tanto, nunca tendrá que preocuparse de que las bases de datos se conviertan en un cuello de botella. Y, el mayor problema con la escalabilidad o no poder escalar es que es cuando su negocio está haciendo mucha actividad.
Digamos que eres una aerolínea y acabas de hacer una promoción especial para Hawái. Todo el mundo está ingresando a su sitio web el miércoles, no sé, para comenzar a comprar boletos. Entonces, van a buscar vuelos y van a comprar boletos y tienes como cinco veces más tráfico que antes y de repente el sitio se ralentiza, tal vez se bloquea y puede bloquearse, por supuesto. , si su base de datos se satura pero, incluso si se ralentiza más allá de los límites aceptables, su costo para el negocio es muy alto porque la gente simplemente se irá. Por lo tanto, realmente debe asegurarse de planificar la escalabilidad para que nunca tenga esa situación en la que su empresa quiere hacer más actividad, puede generar negocios pero no puede procesar dentro de la aplicación. Y, si tiene la infraestructura adecuada, nunca tendrá ese problema.
Solo estoy configurando el caso de por qué debería usar un almacenamiento en caché distribuido. Qué problema se resuelve y luego entraremos en los detalles de cómo lo usa realmente. Además de tener más memoria, normalmente tienes, como decía, CPU dual, configuración de cuatro núcleos, 2 tarjetas de red de un gigabit o más cada una. En caso de NCache estas son cajas de Windows, en caso de Redis estas son cajas de Linux, dependiendo de si tiene una aplicación .NET o Java. Mi enfoque aquí es .NET, pero para Java también tiene cachés distribuidos. Los llaman cuadrícula de datos en memoria, en el lado de .NET se llama caché distribuida.
Casos de uso comunes de caché distribuida
¡De acuerdo! Entonces, ahora que hemos construido el caso sobre por qué necesita tener caché distribuida como parte de su infraestructura de mejores prácticas, tanto desde una perspectiva de TI como, lo que es más importante, desde una perspectiva de desarrollo, desea diseñar la aplicación. La primera pregunta que me viene a la mente también, ¿cómo uso este caché? ¿Cuáles son los casos de uso? ¿Dónde los uso? Quiero decir, sé qué tipo de aplicaciones voy a usar, pero ¿qué tipo de datos voy a almacenar en caché?
Entonces, hay tres categorías principales. El número uno es lo que todos entienden, que es el almacenamiento en caché de datos de aplicaciones.
Almacenamiento en caché de datos de aplicaciones
Entonces, en el almacenamiento en caché de datos de la aplicación, está almacenando en caché los datos que existen en su base de datos, los está almacenando en caché, eso es de lo que acabamos de hablar. Entonces, cuando haces eso, en realidad estás creando dos copias de los datos. Uno está en la base de datos del maestro y el otro está en el caché, que es la copia temporal. Cuando eso sucede, ¿cuál es la principal preocupación? ¿Qué podría salir mal cuando tienes dos copias? Podrían perder la sincronización. De hecho, ese es un temor tan grande en la mente de las personas que la mayoría de las personas cuando les preguntan para qué usan el almacenamiento en caché, dicen bien para datos de solo lectura, no puedo arriesgarme con mis datos transaccionales, con datos que cambia porque, ¿y si eso sale mal? ¿Qué pasa si mi cliente retira ese dinero dos veces de esa misma cuenta, entonces qué va a pasar?
Bueno, si no puede almacenar en caché los datos transaccionales, entonces el valor de un caché distribuido disminuye bastante porque los datos de referencia son solo el veinte o el treinta por ciento de los datos. El 80 por ciento o el 70 al 80 por ciento de los datos son sus clientes, sus cuentas, las actividades, sus datos transaccionales, los datos que cambian cada quizás 30 segundos, cada minuto, datos que puede guardar en el caché para un tiempo muy muy corto. Entonces, si no puede usar un caché para datos transaccionales, entonces realmente se ha restringido. Por lo tanto, un buen caché distribuido debe garantizar que el caché y la base de datos estén siempre sincronizados. Entonces, una vez que tenga esa comodidad, esa tranquilidad de que el caché siempre está sincronizado con la base de datos, puede almacenar en caché prácticamente todo y cuando lo hace, realmente ve muchos de los juegos.
Y voy a entrar en muchos más detalles sobre eso.
Almacenamiento en caché específico de ASP.NET
El segundo caso de uso es cuando tiene una aplicación ASP.NET, hay ciertas cosas específicas de ASP.NET que puede almacenar en caché. Y lo bueno de esta categoría es que no se necesita programación de su parte porque Microsoft tiene un marco en el que simplemente se conecta un caché. El número uno es el estado de la sesión. Cada aplicación ASP.NET tiene que tener un estado de sesión, más o menos. Algunas personas especialmente programadas para no usarlo, lo cual no es una buena idea. Deberías usar una sesión que te haga la vida mucho más fácil.
Una sesión es un muy buen candidato para el almacenamiento en caché porque si almacena una sesión en la base de datos, se encuentra con los mismos problemas que las bases de datos no están diseñadas para almacenar blobs, que es lo que es una sesión. Entonces, el rendimiento es realmente lento y, lo que es más importante, la escalabilidad simplemente desaparece. Por la misma razón por la que desea realizar el almacenamiento en caché de datos de la aplicación, también desea colocar las sesiones en la base de datos. Desea ponerlos en el caché distribuido.
El segundo es un estado de vista. Si no está utilizando el marco MVC, si todavía está en el antiguo ASP.NET framework luego ver el estado. Para aquellos de ustedes que no saben qué es un estado de vista, un estado de vista es una cadena encriptada que puede ser tan pequeña como cien bytes o cientos de kilobytes que se generan y se envían al navegador solo para regresar. cuando haces un post de vuelta. Entonces, es un viaje bastante caro. Por supuesto, ralentiza su rendimiento porque se transfieren muchos más datos. Y también aumenta sus costos de ancho de banda porque cuando aloja su aplicación, la tubería por encima de esta no es gratuita. Entonces, cuando sus clientes acceden a su aplicación web, aquí está pagando por el ancho de banda. Entonces, un estado de vista, cuando multiplica eso por los millones y millones de solicitudes o las transacciones que sus usuarios o clientes van a realizar, es un costo adicional en el que no desea incurrir. Entonces, ese es un muy buen candidato para el almacenamiento en caché. Entonces, lo almacenó en caché en el servidor y solo envió una pequeña clave que la próxima vez que ocurra una publicación incorrecta, la clave regrese y antes de que se ejecute la página, el estado de vista se obtiene del caché.
El tercero es el caché de salida que es otra parte de ASP.NET framework que si la salida de su página no cambia, ¿por qué ejecutarla la próxima vez? Porque cada vez que ejecuta la página, consumirá CPU, memoria y todos los demás recursos, incluidas sus bases de datos. Por lo tanto, es mucho mejor simplemente devolver el resultado de la última ejecución que podría ser la página completa o podría ser parte de la página. Entonces, para estos tres, simplemente conecte un caché distribuido sin ninguna programación. Ahora te mostraré eso. Pero, la naturaleza de este problema es muy diferente a la aplicación.
En los datos de la aplicación teníamos dos copias de los datos, ¿verdad? Entonces, el problema era la sincronización. Aquí, solo tiene una copia y se mantiene en un almacén en memoria. Entonces, ¿cuál es la mayor preocupación cuando guardas algo así en un almacén en memoria y esa es la única copia? ¡Eso también! O, si algún servidor se cae, acaba de perder ese caché. Entonces, para que algo de esto se almacene en el caché. Solo imagine la misma aerolínea por la que acabo de pasar y pasé media hora buscando la combinación perfecta de aerolíneas y estoy a punto de presionar enviar y la sesión se pierde, no es una buena experiencia porque el servidor web se cayó.
Entonces, para esto, ¿cómo resuelves ese problema cuando tienes un in-memory y tienes esa preocupación? Tienes redundancia. Tiene más de una copia de los datos. Por lo tanto, un buen caché distribuido debe permitirle realizar la replicación de datos. Sin la replicación de datos de manera inteligente y de alto rendimiento, su caché vuelve a ser mucho menos útil.
Intercambio de datos en tiempo de ejecución a través de eventos
El tercer caso de uso es algo que la mayoría de la gente no sabe o que está comenzando a volverse más popular y es que puede usar, tiene esta infraestructura en memoria muy escalable. Puede usarlo para compartir datos en tiempo de ejecución a través de eventos, dice algo así como un mensaje pero una versión mucho más simplificada y está en un tipo de centro de datos único de un entorno donde puede hacer que varias aplicaciones usen el caché como una forma de hacer Tipo Pub/Sub de un intercambio de datos. Entonces, una aplicación pone algo en el caché, activa un evento y los consumidores que están interesados en esos datos reciben ese evento y pueden ir y consumir esos datos.
Entonces, en lugar de poner eso en la base de datos o ponerlo en una cola de MSM, escriba una situación que tenga su propio propósito. Un caché no está allí para reemplazar la cola de MSM pero, en muchas situaciones, es una infraestructura mucho más simple y especialmente mucho más rápida y escalable para compartir datos basados en eventos. Por lo tanto, si tiene una necesidad en la que tiene varias aplicaciones que necesitan compartir datos entre sí en tiempo de ejecución, definitivamente debería considerar esto como una característica, una característica muy importante.
Almacenamiento en caché específico de ASP.NET
Voy a mostrarles rápidamente el almacenamiento en caché de ASP.NET, cómo hacerlo. Es muy, muy simple y en realidad voy a usar... Entonces, tengo un código de muestra. Entonces, por ejemplo, si tuviera que... Entonces, tengo esta aplicación ASP.NET. Todo lo que tienes que hacer es ir a la web.config, en caso de NCache y de nuevo va a ser más o menos lo mismo para todos los cachés. Lo primero que tienes que hacer es agregar un ensamblado. Entonces, este ensamblado es el proveedor de estado de la sesión. Entonces, ASP.NET framework tiene una interfaz de proveedor de estado de sesión que debe implementar una memoria caché distribuida. NCache lo ha implementado y esto carga el ensamblado en su aplicación.
Entonces, una vez que haya hecho eso, lo siguiente que debe hacer es ir a la etiqueta de estado de la sesión. De hecho, y asegúrese de que el modo sea personalizado y que el tiempo de espera sea el que desee. En caso de NCache entonces simplemente pones esta línea. Otros cachés tienen un tipo de información similar. Entonces, solo tienes... En caso de NCache todo lo que necesita hacer es asegurarse de que su caché tenga un nombre y realmente le mostraré lo que eso significa. Pero, con solo este cambio en su aplicación, básicamente puede comenzar a almacenar sus sesiones. Entonces, realiza ese cambio en cada web.config en el nivel de la aplicación, por supuesto, se asegura de que exista un caché. Y luego, una vez que haya hecho eso, puede comenzar a poner sesiones en el caché.
Demostración práctica
Voy a mostrarles rápidamente un clúster de caché. Entonces, por ejemplo, tengo estos... eh, tengo estas máquinas virtuales de Azure donde tengo demo1 y demo2 como son mis máquinas virtuales de servidor de caché y el cliente de demostración es como el servidor de aplicaciones. Entonces, esos son los clientes. Un cliente de caché es su caja de servidor de aplicaciones. Entonces, voy a…
Crear un clúster de caché
Y, he iniciado sesión, digamos, he iniciado sesión en el cliente de demostración y voy a usar esto, en caso de NCache y de nuevo voy a usar esta herramienta llamada NCache gerente. Es una herramienta gráfica. Vamos a configurar los cachés desde un solo lugar. Vendré aquí y diré crear un nuevo caché agrupado. Todos los cachés se nombran en NCache. Entonces, voy a nombrar mi caché como caché de demostración. No voy a entrar en ninguno de los detalles de estas propiedades.Elegiré mi estrategia de replicación para que sea una réplica particionada. Y elegiré una replicación asíncrona. Hago mi primer servidor de caché. Haré mi segundo servidor de caché aquí. Entonces, voy a construir un clúster de caché de dos nodos. Voy a recoger todo. Entonces, ese es el puerto TCP en el que se forma el clúster de caché, puede cambiarlo si hay un conflicto de puerto. Voy a especificar cuánta memoria usará mi servidor de caché para el caché. Lo tengo como un concierto, por supuesto, el tuyo va a ser mucho más.
Entonces, por ejemplo, déjame mostrarte rápidamente lo que esto significa. Solo voy a ir a esta parte.
Entonces, piense en esto como un servidor de caché y tiene otro servidor de caché. Entonces, la partición 1 existe aquí. La partición 1 es esencialmente una colección de cubos. La partición 2 tiene su propia caja. Entonces, hay un caso de NCache son alrededor de miles de cubos que se distribuyen entre cuántas particiones tiene. Cada servidor tiene una partición y cada servidor, la partición se replica en un servidor diferente. Entonces, si tenía tres servidores, verá que la partición 1 está respaldada aquí. La partición 2 está respaldada aquí. La partición 3 está respaldada aquí. Las réplicas no están activas en caso de NCache. Se activan solo si la partición principal se cae.
Entonces, lo que estoy especificando allí es el tamaño de una partición. Entonces, en el caso de la réplica de partición, si especifico, digamos, 1 giga aquí, en realidad usará 1 giga para la partición y 1 giga para la réplica. Entonces, un total de 2 conciertos. Entonces, si tiene, digamos, 16 gigas de memoria, lo que quiere hacer es dejar alrededor de dos o dos gigas y media para el sistema operativo y otros procesos y el resto lo puede usar. Entonces, para 16 gigas puedes usar fácilmente 13 gigas. Entonces, haz mitad y mitad. Por lo tanto, es un tamaño de partición de seis gigas y medio y, por supuesto, puede tener 32 gigas y, de nuevo, deja tres gigas y tiene un tamaño de partición de 29 gigas, medio y medio, 14 gigas y medio. Y, luego, cuando desee más almacenamiento, en lugar de agregar más memoria solo agregue más servidores porque es más fácil de administrar. Mantiene las cosas mucho más escalables. Entonces, voy a presionar siguiente aquí.
La siguiente es mi política de desalojo. No voy a entrar en esos detalles. Y ahora voy a agregar el nodo cliente. Una vez que haya hecho eso, voy a iniciar un caché. Voy a iniciar un caché y quería mostrarles esta parte porque eso es lo que tendrá sentido en el resto de la charla. Entonces, está iniciando estos dos nodos de caché.
Simule estrés y monitoree estadísticas de caché
Entonces, voy a abrir un montón de herramientas de monitoreo y voy a ejecutar esta herramienta llamada herramienta de prueba de esfuerzo.
Es una línea de comando. Es una consola que realmente comienza a hacer actividad en el caché. Ahora, esto es como si estuviera simulando su aplicación. Entonces, si lo mira, su aplicación está poniendo sesiones en el caché, cada sesión es un objeto. Entonces, estás agregando. Entonces, el conteo de caché obtuvo 177, en este cuadro 172 y 35. Entonces, va a ser casi uniforme y luego es mejor hacer una copia de seguridad en otro...
Este está respaldado aquí. Este está respaldado aquí. Entonces, como puede ver, la replicación se realiza automáticamente. Su aplicación no tiene que preocuparse. Todo lo que hizo fue crear este clúster y, en el nivel de la aplicación, simplemente modificó Web.config y todo lo demás sucede automáticamente. Por supuesto, puede monitorear estas cosas, pero el caché tiene nombre. Entonces, en nuestro caso, nombré el caché como caché de demostración. Puede nombrarlo, de hecho, puede tener varios cachés. La configuración más común que hemos visto con nuestros clientes es que tienen tres cachés. Un caché lo llamarán, digamos, caché de objetos. Por lo tanto, es su caché transaccional principal. Un caché lo llamarán caché de sesión. Entonces, pondrá todas las sesiones en ese caché. Al tercer caché lo llamarán caché de referencia. Entonces, pondrán más datos de referencia en el caché de referencia.
Y, la razón por la que crean un caché separado para los datos transaccionales frente a los datos de referencia es porque para los datos de referencia desea utilizar esta función llamada Client Cache donde desea almacenar en caché.
Caché de cliente para un rendimiento aún mejor
De hecho, estoy saltando por todas partes, así que perdónenme si confundo las cosas. Si tiene datos de referencia, déjeme retroceder uno más. antes de tener cachés distribuidos, la gente tenía este objeto de caché ASP.NET. El objeto de caché de ASP.NET era una caché de InProc local. Fue dentro del proceso de solicitud, súper rápido, ¿verdad? Si guarda cosas en su propio montón, nada puede igualar ese rendimiento. Tan pronto como ingresa a un caché distribuido, es diferente, es un caché de proceso automático. Lo que la gente no se da cuenta es que tu rendimiento en realidad cae.
Tenemos muchos clientes que inicialmente se desconcertaron y dijeron, bueno, se suponía que debía obtener un aumento de rendimiento y mi rendimiento se redujo desde un caché ASP.NET allí arriba, ahora es mucho más lento, porque tienen que serializar el objeto. Si tiene un objeto grande, la serialización es un costo bastante significativo y ese es un costo en el que debe incurrir independientemente de cualquier caché específico. Y, tan pronto como sale de la memoria caché de proceso, su rendimiento es mucho más lento que el de una memoria caché InProc local. Pero, sigue siendo más rápido que la base de datos. Es casi 10 veces más rápido que la base de datos, pero casi se puede decir 10 veces más lento que el caché de InProc.
Entonces, lo que sucede es que la gente quiere obtener ese beneficio de ese caché InProc. Bueno, para los datos que no cambian con mucha frecuencia, hay una función llamada Client Cache. Algunas personas lo llaman Near Cache, especialmente en el lado de Java.
Esta característica, esencialmente, es un caché local. Es como su caché InProc ASP.NET. Se encuentra dentro del proceso de la aplicación o puede ser solo caché local de OutProc, que no es tan rápido como InProc pero aún más rápido que ir al nivel de almacenamiento en caché. Pero la diferencia es que este caché conoce el nivel de almacenamiento en caché. Esta caché de cliente es la caché encima de la caché y está sincronizada. Por lo tanto, no tiene que preocuparse por el mayor problema del que hablamos, que es cómo mantener el caché sincronizado con la base de datos. Bueno, ahora tienes tres copias de los datos. Uno en la base de datos, uno en el nivel de almacenamiento en caché, uno en el caché del cliente. Por supuesto, Client Cache es un subconjunto del nivel de almacenamiento en caché. El nivel de almacenamiento en caché es un subconjunto de la base de datos. Pero, sea lo que sea, tiene que estar sincronizado. Entonces, al tener un Client Cache, es nuevamente un InProc, mantiene las cosas en forma de objeto en lugar de una forma serializada. Lo mantiene en su montón. Por lo tanto, obtiene el mismo beneficio del objeto de caché local InProc ASP.NET pero con todos los demás beneficios de la escalabilidad porque este caché de cliente será un pequeño subconjunto. Puede especificar qué tan grande debe ser. Nunca cruzará ese umbral.
Entonces, puede tener un giga en cada caché de cliente y puede tener 32 gigas en el nivel de almacenamiento en caché y la base de datos probablemente tenga mucho más que eso. De todos modos, incluso teniendo un concierto porque es una ventana móvil, ¿verdad? Entonces, hagas lo que hagas, lo mantienes. Algunos de los datos permanecerán durante mucho tiempo, algunos de los datos permanecerán tal vez durante unos minutos, pero dentro de ese tiempo realizará cientos de llamadas y no tendrá que ir al nivel de almacenamiento en caché y, por supuesto, no tendrá que hacerlo. ir a la base de datos. Por lo tanto, una caché de cliente es una característica realmente poderosa cuando está activada. Haces eso para obtener más datos de referencia. Entonces, en caso de NCache, puede especificar una caché de cliente a través del cambio de configuración. No hay programación adicional, pero está asignada a un caché específico. Entonces, es por eso que nuestros clientes suelen tener tres cachés; caché de objetos, caché de sesión y caché de referencia. Para el caché de referencia, usan un caché de cliente, para los otros dos no.
Caché de cliente fácil de configurar
Ahora, ¿por qué no hacen un Client Cache con el caché de la sesión? En realidad, porque el rendimiento se ralentiza. La razón es que esto solo es mejor si haces muchas más lecturas y escrituras. Porque, ¿qué pasa en caso de una escritura? Escribes aquí y luego escribes aquí y luego escribes en la base de datos. Entonces, estás escribiendo en tres lugares. Por lo tanto, no agrega ningún valor si tiene que hacer más escrituras. Actualiza su copia y luego actualiza esto solo y luego esto notifica a todos los demás Cachés de Cliente para que vayan y se actualicen. Es una actualización retrasada, no es que solo se retrase un milisegundo o dos, pero sigue siendo una actualización retrasada en el caso de una caché de cliente. No hay replicación entre las cachés de clientes. La caché de cliente solo se sincroniza con el nivel de almacenamiento en caché y el nivel de almacenamiento en caché luego propaga las actualizaciones a otras cachés de cliente. Solo si el otro caché tiene esos datos. Porque, en el caso de Client Cache, cada Client Cache tiene datos diferentes según su patrón de uso.
Dónde usar la caché del cliente
Entonces, retrocedamos, en el caso de los datos de referencia, cada Client Cache tiene su propio conjunto de datos. Entonces, digamos 1 a 1000, 500 a 1500 y así sucesivamente. Entonces, hay cierta superposición entre cada uno, pero no son copias idénticas. Lo que es común es que todos son subconjuntos de este caché. Entonces, cuando actualizo el número de elemento, digamos, 700 en este caché, se actualizará en el caché y el caché sabrá qué otros cachés de cliente tienen esos elementos y se actualizarán inmediatamente en sus otros cachés. Pero, solo si todos lo tienen. Por lo tanto, en realidad no se replica porque no son copias idénticas en el caso de Client Cache. En el caso de las sesiones, lo que en realidad estaba tratando de explicar es que, en el caso de la sesión, tendrá que actualizar la caché del cliente y la caché agrupada, dos lugares sin valor agregado porque para las sesiones hace una lectura y una escritura. Entonces, en el momento de la solicitud web, haces la lectura al final de la página, haces la escritura.
Entonces, la escritura ahora debe realizarse en dos lugares y la lectura se realizará en el caché del cliente. Por lo tanto, el rendimiento realmente disminuye si usa Client Cache con sesiones o con otras operaciones intensivas de escritura, pero el rendimiento mejora enormemente si lo usa para operaciones más intensivas de lectura. ¿Eso tenía sentido?
Entonces, el mayor valor de un caché distribuido, cuanto más rápido y más grande, es el estado de la sesión. Casi todas las aplicaciones lo tienen. Acabo de crear un clúster de caché de dos nodos y vio cuánto tiempo tomó, tal vez dos minutos, en caso de un NCache. Entonces, es realmente fácil crear un clúster de caché, por supuesto, desea hacer sus pruebas y esas cosas. Pero, es muy fácil. No hay esfuerzo de ingeniería. Cuando no hay esfuerzo de ingeniería, sus horarios son mucho más fáciles de manejar. Solo tienes que hacer pruebas de cordura para pasar. Recomiendo enfáticamente, si va a comenzar a usar un caché distribuido, úselo para el estado de las sesiones al principio como primer paso y luego salte al almacenamiento en caché de objetos del que hablaremos en un minuto.
Almacenamiento en caché de datos de aplicaciones
Entonces, hemos hablado sobre el almacenamiento en caché de la sesión. Pasemos rápidamente al almacenamiento en caché de datos de la aplicación. Esto es lo que es un típico NCache API parece que se parece mucho a la memoria caché de ASP.NET si nota que hay una conexión.
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Entonces, te conectas con el caché según el nombre y simplemente creas un caché con el nombre. Por eso te di esa demostración para que entendieras lo que eso significaba. Y, este identificador de caché es algo que conservas solo como preservarías un identificador de base de datos. Y, luego, usa ese identificador de Caché para hacer un Cache.Get. Cada Get, cada operación, tiene una clave. Una clave es una cadena en caso de NCache y luego formateas la clave según lo que estás haciendo con ella. Entonces, en el caso de un objeto individual, una buena práctica es simplemente especificar el nombre de la clase, tal vez el nombre del atributo y el valor. Y luego puedes conseguir eso. Entonces, hay Get y Get.Contains, Add, AddAsync. Asíncrono significa no esperar.
Bueno, lo que sucede es que, debajo de eso, está ocurriendo una deserialización en el extremo del cliente. Entonces, el cliente, vamos a hacer un Cache.Add, digamos, le estás dando un objeto, es un objeto de empleado, lo serializará en función de la serialización estándar de .NET o la personalizada. NCache publicación por entregas. Y luego créelo en una matriz de bytes y envíe la matriz de bytes a la memoria caché. NCache hace más que eso porque es posible que necesite indexar ciertos atributos. Extrae los valores de aquellos. Sí, lo hará. Va a. inmediatamente. ¡Sí! Cada objeto que almacena en caché tiene que pasar por serialización.
Entonces, tan pronto como encienda la aplicación, arrojará excepciones. Si está utilizando un objeto de caché ASP.NET, no tiene que serializar. Por lo tanto, puede almacenar prácticamente todo en caché y muchas veces lo que sucede es que sus propios objetos pueden ser más fáciles de serializar, pero es posible que esté utilizando un tercero. Digamos que anteriormente el objeto de la tabla de datos no se serializaba, pero ahora sí. Entonces, si está utilizando objetos de terceros que no son serializables, no tiene control. Por lo tanto, no puede atraparlos si va a usar un caché distribuido. En caso de NCache, tenemos nuestra propia serialización personalizada donde puede identificar esos objetos. NCache luego crea el código de serialización para usted en tiempo de ejecución y lo compila en la memoria. Entonces, eso le permite usar también aquellos objetos que no son serializables. Pero, esta serialización ocurre de inmediato. Por lo tanto, su aplicación no funcionará si no utiliza la serialización adecuada.
Async esencialmente dice que no espere a que se actualice el caché. Entonces, puedo continuar. Confío en que el caché agregará esta cosa. Por lo tanto, no desbloquean la base de datos donde las actualizaciones pueden fallar por problemas de integridad de datos. Un caché no tiene problemas de integridad de datos. Solo falla cuando tienes accidentes. Cuando te quedas sin memoria o sucede algo más. Por lo tanto, puede estar seguro de que lo que sea que esté agregando, lo más probable es que lo agregue en el caché. Entonces, Async todavía te da un impulso adicional. Entonces, la API parece muy sencilla como puede ver.
Mantener el caché actualizado
Entonces, cuando realiza el almacenamiento en caché de datos de la aplicación, ¿cómo mantiene el caché actualizado? Esto es realmente muy importante. Hay diferentes formas de almacenar en caché.
Uso de vencimientos basados en el tiempo
Vencimientos, casi todos los cachés admiten vencimientos. Hay una caducidad absoluta en la que obtienes esta especificación para cada elemento, este es el tiempo que me siento cómodo para que permanezca en el caché, esto podría ser desde 15 segundos hasta horas, días y semanas. Y eso es para el almacenamiento en caché de datos de la aplicación. Hay otro vencimiento llamado vencimiento deslizante que no es para sincronizar el caché con la base de datos. Es para limpieza. Entonces, ese ASP.NET, todos los datos transitorios de los que hablamos, bueno, ¿qué sucede cuando terminas con esos datos? No deberías tener que preocuparte por limpiarlo. Por lo tanto, puede especificar un vencimiento variable y decir si nadie usa estos datos durante tanto tiempo, digamos, en el caso de sesiones de 20 minutos, si nadie usa la sesión durante esos 20 minutos, elimínelos del caché. Entonces, eso es más una limpieza.
¿Cuáles son los riesgos en la caducidad? La caducidad es en realidad, estás haciendo una conjetura. Está diciendo, creo que estoy bien con cinco minutos, pero no hay garantía de que nadie vaya a actualizar esos datos en la base de datos en ese tiempo, especialmente si tiene otras aplicaciones u otros procesos actualizando la base de datos. Por lo tanto, los vencimientos son buenos solo en casos de uso limitado.
Uso de las dependencias de la base de datos
Otra característica muy importante es que puede tener actualizaciones inesperadas o impredecibles en la base de datos. Si ese es el caso, entonces el caché debería tener la capacidad de sincronizarse con la base de datos. Entonces, el caché debe saber acerca de su base de datos. Debe convertirse en un cliente de su base de datos y monitorear su base de datos en busca de cambios. Hay una función en ADO.NET llamada dependencia de SQL. ¿Alguien ha visto eso?
Entonces, la dependencia de SQL es lo que NCache utiliza para convertirse en un cliente de su servidor SQL o su base de datos Oracle. Entonces, en el caso del servidor SQL, puede usar la dependencia de SQL, la función ADO.NET del servidor SQL que NCache utiliza para obtener eventos de la base de datos. el caché, NCache se convierte en un cliente de su base de datos. Recibe eventos y luego, en base a eso, hace lo suyo. En algunos casos no tienes eventos. Entonces, digamos, si tuviera db2 o MySQL, no tienen eventos. Entonces, el caché debería poder hacer sondeos. NCache también es compatible con la encuesta basada. Entonces, haces lo mismo, almacenas este elemento en el caché y dijiste que esto se asigna a esta fila en esta tabla y luego NCache hará el sondeo y luego, si esos datos cambian, los eliminará nuevamente del caché o recargará una nueva copia. Pero, esta característica, te da mucha comodidad.
Nuevamente, lo mismo de lo que estaba hablando es que desea asegurarse de que Cache esté siempre sincronizado con la base de datos. La caducidad es lo suficientemente buena solo para un pequeño subconjunto de los casos de uso.
Por lo tanto, obtendrá una pérdida de caché si no realiza una recarga automática. Entonces, cuando se activa la dependencia de SQL, se elimina, NCache elimina el elemento de la memoria caché. Entonces, si su aplicación lo quiere, será una pérdida de caché y luego se verá obligado a ir y obtener una nueva copia de la base de datos. Si no desea que se pierda la memoria caché que se encuentra en muchas de las aplicaciones de comercio electrónico porque leen datos con tanta frecuencia que no querían que nada aumentara la carga en la base de datos, entonces, en realidad usaría la dependencia de SQL con esta característica llamada lectura completa.
En realidad, necesito mostrarte un código, de lo contrario, comienza a ser muy aburrido. Entonces, déjame mostrarte rápidamente. Entonces, solo tengo una aplicación de consola muy simple. En caso de NCache, todo lo que tiene que hacer es agregar algunos ensamblajes aquí. Entonces, hay NCache.Tiempo de ejecución y NCache.Web. Luego especifica algunos espacios de nombres estos dos y luego se conecta a Cache y tiene su identificador de Cache y luego crea un objeto y luego hace Cache.Add. Y usted especifica la clave. Esta no es una buena clave. Tenía la intención de cambiarlo, pero su clave debería tener el valor real. Entonces, haces un Cache.Add y especificas el objeto.
En este caso, también estoy usando una caducidad absoluta de un minuto. Entonces, especifica el vencimiento absoluto y eso es todo. Eso es todo lo que tiene que hacer para agregar esto a la memoria caché. La próxima vez que lo necesite, simplemente hará un Cache.Get, especifique la misma clave y recuperará el objeto. Muy, muy sencillo para una expiración absoluta. Podría hacer lo mismo para el vencimiento deslizante. Aunque, en lugar de especificar un valor absoluto, debe especificar un intervalo como 10 minutos o 20 minutos. La dependencia de SQL es lo que quería mostrarte. Lo que parece. ¡Ahí! Entonces, el mismo tipo de aplicación. Solo necesita agregar estos dos aquí y especificar los espacios de nombres y luego, cuando va y agrega las cosas al caché, es cuando especifica la dependencia de SQL.
Permítanme ir a la definición de la misma. Entonces, voy a agregar esto al caché aquí. Entonces, tengo mi llave que es la que te mostré la última vez. Ahora, en lugar de agregar el objeto, voy a agregar un elemento de caché. eso es un NCache estructura. Entonces, almacena el objeto real y también almacenará una dependencia de SQL. Asi que, NCache tiene un objeto de dependencia de caché. Entonces, hago una nueva dependencia de SQL Cache. eso es un NCache clase que se asigna internamente a la dependencia de SQL de los servidores SQL. Entonces, le pasa una cadena de conexión y la cadena de conexión es su cadena de conexión del servidor SQL y le pasa una declaración SQL. Entonces, aquí en mi caso, especifiqué seleccionar esto donde la identificación del producto es cualquiera que sea mi valor. Entonces, solo lo estoy asignando a una fila en la tabla de productos. Y, al especificar esto tanto, acabo de decir ahora NCache para convertirse en un cliente del servidor SQL. Y elimine este elemento si esto cambia, si esta fila cambia en la base de datos.
Entonces, depende de cuál sea la declaración SQL. Entonces, si el método de secuencia contiene solo una fila, se asigna para hacer solo una fila y eso es lo que será. Por lo general, no puede hacer uniones en esto y esa es la limitación de la función de dependencia de SQL en ADO.NET pero, para una sola tabla, puede hacerlo fácilmente. Entonces, así es como harías el...
Entonces, el servidor SQL tiene esta cosa llamada corredor de SQL. Entonces, en realidad, crea un conjunto de datos o una estructura de datos en el extremo del servidor SQL para monitorear estos conjuntos de datos. Entonces, todas las dependencias de SQL que crea, el servidor SQL crea estructuras de datos para ir y monitorear los conjuntos de datos. Y, en base a eso, le envía una notificación de SQL.
Por lo tanto, debe configurar esto en el extremo del servidor SQL porque también es una cuestión de seguridad, por lo que su base de datos debe involucrarse en la configuración del servidor SQL, pero es bastante sencillo. Quiero decir que no se necesita programación ni nada en el servidor y solo una configuración. Todo el asunto está a cargo del lado del cliente.
Lectura y escritura
¡De acuerdo! Entonces, hemos hecho la dependencia de SQL. Quería mostrarle que si no desea eliminar este elemento del caché, puede volver a cargarlo mediante una lectura completa. Por lo tanto, la lectura es otra característica muy, muy poderosa.
Read-through es un código del lado del servidor. En realidad, la lectura completa es su código que se ejecuta en el clúster de caché. Entonces, en realidad registra su código y se ejecuta en el clúster de caché. se llama bi NCache. Y, el valor de una lectura completa... primero déjeme mostrarle cómo se ve la lectura completa y le mostraré cuál es el valor, es decir, por qué quiere hacer la lectura completa. Entonces, así es como se ve una lectura completa típica. Es una interfaz IReadThrough. Haces un InIt para que puedas conectarte a tus fuentes de datos. Se desecha, por supuesto, y luego hay una carga desde la fuente. Pasa su clave y espera que se le devuelvan los elementos del caché. Entonces, el elemento de caché contiene su objeto y un montón de otras cosas que puede especificar vencimientos y otras cosas dentro de él. Interfaz muy simple.
Esto es llamado por NCache Entonces, implementa esta interfaz y registra su ensamblaje. En caso de NCache, registra su ensamblaje con Cache y ahora, cuando hace un Cache.Get y ese elemento no existe en el caché, el caché en realidad, NCache llamará a su lectura para ir y obtenerlo de sus fuentes de datos. Su fuente de datos podría ser una base de datos, podría ser un mainframe, cualquier fuente de datos. Por lo tanto, al tener una lectura completa, puede asegurarse de que un caché siempre tenga los datos y lo que ve la aplicación. Entonces, ese es un beneficio.
El segundo beneficio es la recarga que... Entonces, en realidad puedes combinar la lectura completa. Por lo tanto, puede hacerlo en la sincronización de la base de datos y la caducidad, cuando el elemento se eliminaría de la memoria caché y no desea que se elimine porque, de todos modos, lo volverá a cargar. Entonces, ¿por qué no hacer que el caché lo vuelva a cargar de esa manera porque si, solo piensa en esto, tienes millones de elementos en el caché y todos caducan todo el tiempo, verdad? Porque así es como lo has configurado. Y tiene una aplicación de comercio electrónico y un tráfico realmente alto y cada vez que algo caduca, tiene muchas solicitudes simultáneas. Todos irán a la base de datos. Entonces, de repente, el tráfico de la base de datos ha aumentado sin motivo, a pesar de que simplemente no lo necesita en el caché de todos modos.
Entonces, dado que eso sigue sucediendo todo el tiempo, verá un gran aumento en el tráfico de la base de datos a pesar de tener caché. Entonces, ahí es donde, al tener una recarga significa que nunca se elimina del caché. Solo se actualiza. Por lo tanto, sus aplicaciones nunca irán a la base de datos. Seguirán obteniendo la copia anterior y hasta el punto en que la actualice. Entonces, de repente eliminó o solucionó ese problema en el que, aunque tenía el caché, veía muchos picos en el tráfico de la base de datos debido a los vencimientos o la sincronización de la base de datos. Entonces, al hacer que el caché vuelva a cargar esto a través de la lectura, realmente lo hace muy poderoso.
El otro beneficio de la lectura completa, por supuesto, es que está centralizando, está simplificando el nivel de la aplicación porque cada vez más el acceso a la base de datos lo realiza el caché. Por lo tanto, si tiene varias aplicaciones que acceden a los mismos datos, realmente puede centralizar el acceso a los datos dentro del nivel de almacenamiento en caché. Por supuesto, no puede hacerlo con todos los datos, pero sí con muchos de ellos.
La escritura simultánea funciona de la misma manera que la lectura simultánea. Permítanme ir a la escritura directa. Funciona de la misma manera. Tiene un proveedor de escritura simultánea, nuevamente InIt, eliminado y ahora, en lugar de cargar, es una escritura en la fuente de datos y tiene otro tipo de escritura masiva. La escritura directa, un beneficio es el mismo que la lectura completa, que centraliza todo. El segundo beneficio es que puede hacer una escritura posterior, que es que actualiza el caché que es, como dije, diez veces más rápido que la base de datos y luego le pide al caché que actualice la base de datos. Y, la escritura en segundo plano es esencialmente lo mismo que la escritura simultánea, pero se realiza de forma asíncrona. Es una cola que se crea y se procesa. Esa cola también se replica en caso de NCache. Por lo tanto, ninguna de las actualizaciones se pierde si algún servidor deja de funcionar. Pero, la escritura en segundo plano realmente acelera la aplicación porque, quiero decir, ya lo hizo más rápido almacenando en caché para hacer todas las lecturas, ¿verdad? Entonces, alrededor del 70 al 80 por ciento de las lecturas son ahora o las transacciones van a la memoria caché de todos modos. ¿Por qué no acelerar también las escrituras? Si puede hacerlo de manera de escritura posterior, si puede permitirse el lujo de hacer una escritura asíncrona. Si los datos son demasiado confidenciales y no puede pagarlos, haga una escritura simultánea y solo obtendrá el primer beneficio, que es la centralización del código. El segundo beneficio de un rendimiento más rápido se presenta solo si puede hacer async.
Conclusión
La idea general es que cuando comience a almacenar en caché, no piense en un caché que es solo un valor clave simple aquí, quiero decir, todo mi propósito de esto fue primero convencerlo de que realmente necesita un caché distribuido como parte de su infraestructura y la arquitectura de la aplicación. Si desea escalar las aplicaciones, debe incorporar esto independientemente del producto de almacenamiento en caché que utilice, quiero decir, simplemente debe tenerlo. Actualmente para la gente de .NET, las opciones en el mercado son NCache que es de código abierto y también comercial. hay Redis que Microsoft ha puesto a disposición en Azure al menos. En Azure, es un servicio de caché administrado, fuera de él, debe instalarlo y se instala principalmente en Linux, a menos que use la versión de código abierto no compatible. En el lado de Java, hay muchas más opciones en el almacenamiento en caché. Entonces, ese fue el primero de todos.
Segundo objetivo que debe comprender, no es un valor clave simple. Desea asegurarse de que puede almacenar en caché todo tipo de datos y manejar todo tipo de situaciones, ahí es donde obtiene el beneficio real. Y ni siquiera llegué a la otra parte porque en realidad me estoy quedando sin tiempo, que fue, por ejemplo, cómo se comparten los datos en tiempo de ejecución y cuáles son algunas de las cosas arquitectónicas que desea asegurarse de que el caché siempre es dinámico para que pueda configurar las cosas. Es parte de su centro de datos, es parte de su entorno de producción. Por lo tanto, cualquier caché que no le permita realizar cambios en tiempo de ejecución no es un buen caché para elegir porque. Entonces tendrá muchos tiempos de inactividad, tenemos clientes que han programado tiempos de inactividad una vez al año, ya sabe. Entonces, algunos de nuestros clientes ni siquiera tienen eso porque tienen una disponibilidad muy alta.
Quieren incluso actualizar el caché en sí mismo a una nueva versión sin tiempo de inactividad. Entonces, quiero decir, depende de cuáles sean los requisitos de su negocio. Pero, todas esas cosas deben tenerse en cuenta, muchas personas ahora tienen múltiples centros de datos. Al menos para propósitos de recuperación ante desastres y luego también para balanceo de carga geográfica, si tiene eso, espera que su base de datos se replique, ¿verdad?
Entonces, ¿por qué la memoria caché no debería ser compatible con varios centros de datos? Porque, cuanto menos pueda hacer un caché, más tendrá que hacer. Esa es la conclusión. Debido a que las necesidades de su aplicación no cambiarán, el caché debe adaptarse. Entonces, ten todo eso en mente.
Entonces, hay una comparación entre NCache y Redis.
Ambos son de código abierto. NCache también tiene Enterprise Edition. Básicamente, si su .NET, NCache encaja muy bien. En el NCache, N significa .NET, en resumen, quiero decir que así de comprometidos estamos con .NET.