DDS 2017 Londres

Escalado de aplicaciones .NET con almacenamiento en caché distribuido

Por Iqbal Kan
Presidente y evangelista tecnológico

Si está aumentando el volumen de transacciones de datos, el volumen de sesiones o el tamaño de los objetos, esta charla es para usted. Aprenda a aumentar el rendimiento de las aplicaciones mediante una caché distribuida entre sus aplicaciones y su base de datos. 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

General

Hola a todos, mi nombre es Iqbal Khan. Soy un evangelista tecnológico en Alachisoft. Somos los creadores de NCache. ¿Cuántas personas han oído hablar de NCache ¿antes de? Bien, buen número. El tema de hoy es escalar aplicaciones .NET con almacenamiento en caché distribuido. no se trata de NCache, se trata en general del problema de escalabilidad que enfrentan las aplicaciones .NET y cómo resolver este problema.

Prefiero una discusión más interactiva. Entonces, en lugar de esperar hasta el final para hacer preguntas, levante la mano si tiene alguna pregunta mientras estoy hablando. Voy a pasar por una combinación de arquitectura y luego código real y también les mostraré NCache como un ejemplo de cómo se ve un caché.

¿Qué es la escalabilidad?

Entonces, saquemos algunas definiciones del camino. Estoy seguro de que la mayoría de ustedes ya saben esto, pero ¿qué es la escalabilidad? La escalabilidad no es el rendimiento de la aplicación. Es el rendimiento de la aplicación en cargas máximas. Por lo tanto, si tiene una aplicación que funciona muy rápido con 5 usuarios, no es necesariamente escalable a menos que funcione muy rápido con 5,000 o 50,000 500,000 o 5 XNUMX usuarios. Por supuesto, si su aplicación no funciona rápido con XNUMX usuarios, entonces tiene otros problemas además de la escalabilidad.

Escalabilidad lineal frente a escalabilidad no lineal

La escalabilidad lineal es más una arquitectura de implementación. ¿Está su aplicación diseñada de tal manera que puede seguir agregando más servidores en un entorno de carga equilibrada y luego, a medida que agrega más servidores, aumenta la capacidad de transacción? Por cierto, cuando uso la palabra escalabilidad, me refiero a la escalabilidad de transacciones, no a los datos de escalabilidad. No estamos hablando de grandes cantidades de datos. No estamos hablando de terabytes o petabytes de datos. Estamos hablando de mucha actividad. Por lo tanto, si su aplicación está diseñada de manera que pueda agregar más servidores y, a medida que agrega más servidores, su capacidad aumenta de manera lineal, entonces es linealmente escalable.

Si no, entonces tiene una curva más logarítmica, para aquellos de ustedes que todavía recuerdan sus cálculos de la universidad y el problema con esta curva es que verán un aumento, pero después de cierto punto, agregar más servidores en realidad no tiene ningún beneficio. en realidad reduce el rendimiento porque hay algunos cuellos de botella en su aplicación que simplemente no desaparecen. Entonces, definitivamente no quieres ser no lineal.

¿Qué aplicaciones necesitan escalabilidad?

Entonces, ¿qué aplicaciones necesitan escalabilidad? Estas suelen ser aplicaciones de servidor, por supuesto. Aplicaciones Web, ASP.NET, ahora ASP.NET Core además. Servicios web. Nuevamente, puede hacerlo a través de WCF. Podrías hacerlo ASP.NET web API o ASP.NET Core API web. Y, es decir, los servicios web suelen ser el backend de Internet de las cosas, que es un espacio emergente bastante rápido en estos días.

Estas también son aplicaciones de procesamiento de big data. Entonces, si tiene una gran cantidad de datos, ahí es donde viene la parte de escalabilidad de los datos, pero incluso allí no se trata de los datos, se trata de qué tan rápido puede procesarlos. Entonces, si tiene una aplicación de procesamiento de big data, necesita escalar. La mayoría de las aplicaciones de procesamiento de big data generalmente no están en .NET. Están más en el lado de Java y mi enfoque está más en la aplicación .NET. Pero, conceptualmente hablando, las aplicaciones de procesamiento de big data también son algo que necesita escalabilidad.

Y, finalmente, cualquier otra aplicación de servidor. Puede ser una institución financiera, puede ser un gran banco, tiene millones de clientes, llaman, cambian su dirección, emiten una nueva tarjeta o lo que sea y necesita procesar, tal vez quieren transferir fondos y necesita procesar todas esas solicitudes dentro de un cierto período de tiempo para fines de cumplimiento. Por lo tanto, tiene muchos de estos procesos por lotes de back-end en curso y necesitan procesar más y más transacciones dentro de ese período de tiempo muy pequeño, pequeño en términos de solo unas pocas horas que obtiene cada noche. Entonces, cualquier aplicación de servidor. Entonces, si tiene alguna de estas aplicaciones y necesita escalabilidad, entonces está en el lugar correcto hoy.

El problema de la escalabilidad

Entonces, ¿cuál es el problema de escalabilidad? Bueno, el nivel de la aplicación no es el problema. En la mayoría de estas aplicaciones que mencioné, el nivel de aplicación parece funcionar perfectamente bien. Puede agregar más servidores. Por lo general, tiene un entorno de carga equilibrada. Si tiene, digamos, una aplicación ASP.NET, tendrá un balanceador de carga en la parte superior y tendrá un grupo de servidores a los que el balanceador de carga envía el tráfico y cuando necesita más tráfico, cuando necesita manejar más usuarios, solo agrega más servidores. Entonces, es muy simple.

Pero el problema es que su base de datos, ya sea relacional o datos de mainframe, se convierte en el cuello de botella. Y, relacional no significa ninguna base de datos específica. Podría ser un servidor SQL, podría ser Oracle, MySQL, Db2, cualquiera de estos. Todas las bases de datos relacionales tienen esta debilidad inherente que no pueden escalar. Entonces, eso es exactamente por qué NoSQL comenzó el movimiento y, de hecho, incluso tenemos un producto en el espacio .NET llamado NosDB que es una fuente abierta NoSQL database pero el NoSQL databases no son siempre la respuesta. Quiero decir que definitivamente resuelven el problema de escalabilidad. Técnicamente hablando, si usas un NoSQL database no tendrá cuellos de botella de escalabilidad. Sin embargo, el problema es que, por una combinación de razones técnicas y comerciales, no puede mover todos sus datos fuera del mainframe relacional o heredado a NoSQL.

Por lo tanto, la NoSQL es más de algo de lo que llamamos los nuevos datos, ya sabes. Los datos comerciales tradicionales todavía residen en bases de datos relacionales por una variedad de razones. Entonces, lo que eso significa es que tiene que resolver este problema mientras vive con bases de datos relacionales. No puede decir que solo voy a eliminar la base de datos relacional de mi imagen. De hecho, incluso ninguno de nuestros clientes se muda completamente a una NoSQL. Mueven algunos de los datos a NoSQL. Incluso jugadores más grandes como MongoDB, tienen la misma historia que las personas que se mudan a NoSQL database mover algunos de los datos a NoSQL y aún conservan los datos tradicionales en la base de datos relacional.

Implementación de caché distribuida (NCache)

Entonces, necesita resolver el problema con las bases de datos relacionales en la imagen y ahí es donde un caché distribuida entra. En realidad le da el mismo beneficio a menudo NoSQL database. De hecho, si lo piensas bien, es un NoSQL Almacén de valor clave en memoria. Entonces, ya sabes, si has investigado NoSQL databases, está la base de datos de documentos JSON, está el almacén de valores clave y está la base de datos de gráficos y están los otros tipos. Entonces, el almacén de valor clave, si es un... Lo único que tiene un caché de distribución es que no tiene persistencia, todo está en la memoria. Es el almacén de valor clave. Y se distribuye en varios servidores, por lo que le brinda el mismo beneficio, se escala porque puede agregar más servidores. Entonces, piense en esto como el nivel de aplicación aquí arriba. Justo aquí está el nivel de la aplicación y luego, por lo general, un equilibrador de carga aquí en alguna parte. Y, a medida que agrega más servidores en este nivel, la base de datos estará cada vez más bajo presión a menos que coloque un nivel de almacenamiento en caché en el medio.

El nivel de almacenamiento en caché escala igual que el nivel de aplicación. No tiene cuellos de botella, porque simplemente sigues agregando más y más cajas. Los datos se distribuyen en varios servidores. Estos son servidores de bajo costo por cierto. Estos no son servidores de base de datos de gama alta. De hecho, nuestros clientes... La configuración típica es de unos 16 GB de RAM, una caja de 8 núcleos, como una caja típica de servidor web pero con más memoria. 16 gigas, 16 a 32 gigas, ni siquiera recomendamos ir más de 32. De hecho, 64 gigas es prácticamente el máximo que recomendaremos a nuestros clientes. Diremos, agregue más servidores. ¿Porqué es eso? Porque, si aumenta demasiado la memoria, .NET tiene esta cosa llamada recolección de basura. Y la recolección de elementos no utilizados requiere mucha potencia de procesamiento. Entonces, cuanta más memoria tenga, más recolección de basura necesita hacer y más rápido debe volverse su CPU y luego su caché no se está volviendo más y más como una base de datos y se está volviendo más caro y todo el asunto. Por lo tanto, es mejor tener más servidores que tener algunos servidores de gama alta.

Entonces, un caché distribuido esencialmente forma un grupo de servidores. Este suele ser un clúster basado en TCP y ese clúster significa que todos los servidores del clúster se conocen entre sí y agrupan los recursos en una capacidad lógica. Tener el clúster significa que cuando necesite aumentar la capacidad, simplemente agregue otro servidor al clúster. O, cuando necesite disminuir la capacidad, deje caer un servidor. Y, cuando tiene este nivel de almacenamiento en caché, es un almacenamiento en memoria porque no necesita conservar los datos. No es una tienda permanente. El almacén permanente sigue siendo la base de datos y, dado que es un almacén en memoria, también necesita proporcionar replicación de datos.

El objetivo en toda esta imagen es esencialmente ir al caché aproximadamente el 80% del tiempo. Entonces, si pudiera imaginarse, si fue al caché el 80% del tiempo, su base de datos estará totalmente libre de estrés, ya sabe. Realmente podría aumentar bastante la escalabilidad.

Pregunta: ¿La aplicación todavía no tiene que hablar demasiado con la base de datos?

No lo hace, en realidad. Entonces, depende de los datos. Pero, la mayoría de los datos de la aplicación se encuentran entre la categoría de datos de referencia o datos transaccionales que no cambian cada pocos segundos. Cambia tal vez cada pocos minutos. Entonces, para todos esos datos, haces muchas más lecturas que escrituras. Entonces, la primera lectura va a la base de datos e incluso hay características como NCache tiene una función en la que puede precargar el caché con datos. Por lo tanto, puede calentar el caché con todos los datos que cree que va a tener y luego incluso ese tráfico no se ve afectado, la base de datos no se ve afectada. Pero, depende de los datos. Por ejemplo, si tiene otro tipo de datos, digamos, si fuera a almacenar sesiones en él, entonces por cada lectura hay una escritura. Entonces, depende y repasaré esos detalles, pero esa es una buena pregunta.

Bueno, la razón por la que no lo estarías es porque el caché carga los datos y los mantiene en el caché. Entonces, el tráfico entre el caché y la base de datos es muy poco frecuente. Nuevamente, como dije, el 80 % de las veces se realizan las lecturas y el caché tiene los datos. Entonces, cuando lo almacena en caché, lo está almacenando en caché durante un cierto período de tiempo y durante ese tiempo, el caché no va a la base de datos cada vez. Pero, la aplicación llega cada vez al caché. Entonces, aunque tenga mucho tráfico, todo llega al caché y, de repente, la base de datos es muy liviana.

En realidad, hay particiones para que cada caja almacene datos diferentes y también hay algo de redundancia integrada para la confiabilidad, pero hablaré de eso con más detalle.

Por lo tanto, esta imagen (Fig. 1) pretende convencerlo de que, en el entorno actual de alta escalabilidad, la caché distribuida es algo así como la mejor práctica de facto. Entonces, si diseña su aplicación, tenga en cuenta un caché. No importa qué caché. Esa es una discusión aparte. La primera discusión es que necesita diseñar la aplicación de manera que vaya a un caché distribuido. Si hace eso y puede estar seguro de que cuando la empresa necesite que su aplicación funcione, la aplicación no se ahogará.

Y, si no lo planifica con anticipación, la verdadera desventaja de no poder escalar es que este problema ocurre cuando el negocio realmente está funcionando bien. Imagínese si usted es una aerolínea y acaba de ejecutar esta promoción de fin de semana en algún lugar de vacaciones y millones de nuevos usuarios ingresan a un sitio web para buscar vuelos y tal vez comprar boletos. Si el rendimiento de su sitio web comenzó a ralentizarse cada clic fue un minuto, perderá clientes. Y si empeora aún más y su aplicación comienza a bloquearse porque la base de datos se atascó, perderá mucho negocio. Por lo tanto, debe planificar con anticipación. A pesar de que no enfrenta ese problema hoy y, nuevamente, esto no se trata de rendimiento.

Mucha gente piensa, use el caché porque va a mejorar el rendimiento. Mejora el rendimiento, pero las bases de datos son bastante rápidas en estos días. Si solo tienes esos cinco usuarios. No he escuchado a nadie quejarse de que la base de datos sea lenta. Entonces, el problema no es el rendimiento. El problema es la escalabilidad, porque solo hay un servidor de base de datos y puede agregar más servidores en el nivel de la aplicación y, de repente, la base de datos se convierte en un cuello de botella.

Pregunta: ¿Deberíamos usar máquinas virtuales o cajas físicas para los clústeres de caché?

Muy buena pregunta. Iba a hablar de eso y se me olvido y que bueno que preguntes. Entonces, estas podrían ser cajas físicas. Todavía tenemos clientes que tienen cajas físicas, pero cada vez más de nuestros clientes se están mudando a máquinas virtuales y ahora la nueva tendencia son los contenedores. Entonces, como mínimo, tendrá máquinas virtuales. Entonces, cada servidor de caché es una máquina virtual. Por lo tanto, tiene un mínimo de dos máquinas virtuales de servidor de caché. Como dije de 16 a 32 gigas cada uno. Por supuesto, no desea tener ambos VMS en la misma caja física. Porque entonces pierde ese beneficio de alta disponibilidad. Porque, si esa caja falla, ambos VMS desaparecerán.

Una pregunta más. Entonces, ¿los datos físicos se almacenan en la memoria?

En memoria. Exactamente. Todo es almacenamiento en memoria. Y, debido a que es un almacenamiento temporal, lo almacena durante unos minutos, unas horas, unos días, unas semanas, ya sabe, no lo almacena de forma permanente. El almacén permanente sigue siendo la base de datos. Sea lo que sea. Eso podría ser, como dije, podría ser un mainframe heredado, podría ser relacional, podría ser NoSQL.

Incluso con NoSQL database, debe utilizar una memoria caché distribuida. Porque NoSQL no es tan rápido como un caché distribuido y porque tenemos los dos productos que conocemos. Hacemos los puntos de referencia. Todavía es 10 veces más rápido.

No estoy familiarizado con NoSQL database, así que me preguntaba, ¿por qué funciona mejor que una base de datos relacional?

Se escala más porque también se distribuye en varios servidores. Entonces, al igual que un caché distribuido puede tener 5, 10, 15, 20 servidores, puede hacer lo mismo con un NoSQL database. No puede tener 20 servidores para SQL. Puede tener tal vez 2, para activo-pasivo o activo-activo, pero eso es todo. Ya sabes, realmente no puedes escalar. Entonces, es por razones de escalabilidad.

Por lo tanto, las máquinas virtuales o los contenedores se están volviendo cada vez más populares para la administración y esto podría ser en las instalaciones o en la nube, en cualquier entorno.

Usos comunes de la caché distribuida

Entonces, espero que esta imagen (Figura 1) los convenza de que necesitan usar el almacenamiento en caché. Entonces, ahora estás convencido, digamos. La siguiente pregunta que surge es, bueno, ¿cómo lo uso? ¿Dónde lo uso, sabes? Entonces, hay tres lugares comunes en los que usa el almacenamiento en caché.

Almacenamiento en caché de datos de aplicaciones

El número uno es de lo que he estado hablando hasta ahora, que son los datos de la aplicación, que era exactamente esta imagen. Guarde los datos en caché aquí, para que no tenga que ir a la base de datos. Lo único a tener en cuenta en almacenamiento en caché de datos de la aplicación es que ahora los datos existen en dos lugares. Uno es el caché, uno es la base de datos. Cuando los datos existen en dos lugares, ¿qué podría estar mal? Sincronización. Entonces, ese es un problema tan grande que la mayoría de las personas tienen miedo de usar el caché, para cualquier otra cosa que no sean datos de solo lectura. Si le preguntas a una persona promedio, ¿has pensado en usar el caché o estás haciendo algún almacenamiento en caché? Las personas a veces construyen estas tablas hash o algunas en el almacén de memoria, solo colocan datos de solo lectura. Datos que nunca cambian en la totalidad de la aplicación o en un marco de tiempo realmente muy cómodo. Bueno, los datos de solo lectura o los datos de referencia son solo el 10-15 % de los datos totales. Por lo tanto, le brinda muchos beneficios, pero el beneficio real es si puede almacenar en caché todos los datos. Eso significa que realmente necesitas ser capaz de manejar...

Un buen caché distribuido debe manejar la sincronización. Por lo tanto, debe asegurarse de que el caché esté siempre actualizado. Entonces, que tenga esa confianza en el caché de que lo que sea que esté leyendo del caché es la última copia de esos datos.

Y, si no tiene esa confianza, estará restringido a datos de solo lectura, lo que realmente minimiza o reduce el valor del caché.

Almacenamiento en caché específico de ASP.NET

Entonces, el segundo beneficio es el Almacenamiento en caché específico de ASP.NET. No voy a entrar en ASP.NET Core en este momento, pero lo mencionaré brevemente. Pero, el almacenamiento en caché de ASP.NET, hay tres lugares donde haces esto y dos al menos ahora. Si tiene el marco MVC, entonces no tiene el estado de vista, pero las sesiones de cada aplicación ASP.NET tienen sesiones y las sesiones deben almacenarse en algún lugar. De forma predeterminada, se almacenan en la memoria, que es In-Proc, que se encuentra dentro del proceso de trabajo de la aplicación ASP.NET o el servidor SQL. El servidor de estado no está disponible en la nube, solo está en las instalaciones y todos tienen problemas. Algunos tienen problemas de escalabilidad. En realidad, todos tienen problemas de escalabilidad. Algunos también tienen problemas de rendimiento. Al igual que la base de datos SQL, también tiene problemas de rendimiento.

Entonces, un caso de uso muy bueno para el caché distribuido es simplemente poner esas sesiones en el caché. Ya sabes, esas sesiones se almacenan... si las almacenas en SQL, se almacenan como blobs. Además, las bases de datos relacionales no están diseñadas para el almacenamiento de blobs. Pero, NoSQL o almacenes de valor clave, el valor es el blob. Por lo tanto, encaja muy bien en un caché distribuido. Por supuesto, también tiene que resolver... cada vez más personas recurren a múltiples bases de datos o múltiples centros de datos para la recuperación ante desastres o para el equilibrio de carga, el equilibrio de carga geográfica. Por lo tanto, también debe resolver ese problema.

Un estado de vista es algo que ya no está en ASP.NET, pero si es anterior, creo que ASP.NET 5. Si está en ASP.NET 4, entonces vea el estado o pre MVC, el estado de vista existía. Todavía existe en la mayoría de las aplicaciones ASP.NET que se desarrollaron durante todo ese tiempo.

Para aquellos de ustedes que no saben qué es un estado de vista, un estado de vista es una cadena encriptada que el servidor web envía al navegador, solo para regresar cuando ocurre una publicación. Entonces, esta cadena podría tener cientos de kilobytes y viaja al navegador, se almacena en el navegador y luego regresa. Multiplique eso por millones de transacciones que su aplicación tiene que procesar y tiene dos problemas, uno consume mucho ancho de banda, que no es un ancho de banda barato, tiene que pagar por el ancho de banda. En segundo lugar, ralentiza el tiempo de respuesta porque se trata de una carga útil pesada que viaja. Por lo tanto, es un caso ideal para almacenar en caché eso en el servidor y simplemente enviar una pequeña clave y, cuando vuelva la próxima vez, el estado de vista se obtiene del caché y se sirve en la página. Una vez más, el estado de vista es solo una cuestión si no está utilizando el marco MVC y definitivamente ni siquiera está allí en ASP.NET Core porque ASP.NET Core es MVC.

La caché de salida de ASP.NET también es algo que forma parte de ASP.NET framework, no en el ASP.NET Core donde prácticamente almacena en caché los resultados de la página. Entonces, si su página no cambia en la próxima solicitud, ¿por qué ejecutarla nuevamente? Entonces, ASP.NET almacena en caché la página, por lo que la próxima vez que la solicitud llegue con los mismos parámetros, igual todo, se entregará a la página una salida de la última ejecución.

Entonces, ese marco ya está allí y es realmente bueno usar un caché distribuido para él, de modo que, en un entorno de múltiples servidores, una vez que se almacena en caché, está disponible de inmediato para todos los servidores. ÁSPID.NET Core solo tiene sesiones para el almacenamiento en caché y no hay estado de vista ni caché de salida. Pero, hay otra cosa llamada almacenamiento en caché de respuesta. Entonces, ASP.NET Core se ha estandarizado ahora con las aplicaciones web generales donde el almacenamiento en caché de contenido ocurre fuera del servidor. Entonces, ese también es un buen candidato para el almacenamiento en caché. Entonces, ASP.NET Core tiene este un concepto de middleware de almacenamiento en caché de respuesta. Entonces, hay un middleware incorporado que puede usar y luego puede hacer un middleware de terceros. Me gusta NCache proporcionará uno muy pronto.

Entonces, de todos modos, para el almacenamiento en caché de ASP.NET y eso es algo importante a tener en cuenta ahora, es que ya no está almacenando estos datos en el caché. Entonces, a diferencia de los datos de la aplicación donde los datos existen en dos lugares, ahora los datos existen solo en un lugar y ese es el caché y es un caché en memoria. Entonces, cuando la tienda en memoria es su única tienda, ¿qué podría salir mal? Sí. Quiero decir, si esa caja se cae, estás jodido. Porque la memoria es volátil. No es persistente. Entonces, la forma de manejar eso, por supuesto, es hacer la replicación. Tener esos datos en más de un servidor. Pero, de nuevo, dos problemas muy diferentes a resolver. Una buena caché distribuida debe realizar una replicación inteligente. Si va a almacenar con confianza sesiones ASP.NET, por ejemplo. De lo contrario, ¿qué va a pasar? Volvamos a eso, ya sabes, la aerolínea. Acabo de ir a ese sitio web. Voy a comprar $5,000 en boletos. Hice toda mi búsqueda de vuelos, todo tipo de combinaciones y estoy a punto de... Ingresé mi información de pago y estaba a punto de enviar y, de repente, envié de vuelta a, ya sabes, la página de inicio, lo que sea, porque mi sesión es perdió. Porque cuando presioné enviar, fue al servidor web, ese servidor web no estaba allí, se bloqueó y la sesión desapareció. Entonces, definitivamente no es una buena imagen.

Intercambio de datos en tiempo de ejecución a través de eventos

El tercer caso de uso es un uso compartido de datos en tiempo de ejecución a través de eventos. Esto es algo que mucha gente no sabe, ahora se está volviendo cada vez más popular que un caché distribuido una vez que lo tiene en su entorno, es una plataforma realmente poderosa para compartir datos entre múltiples aplicaciones a través de un Pub / Sub modelo u otro intercambio de datos basado en eventos.

Por ejemplo, es posible que tenga varias aplicaciones que necesiten compartir datos. Una aplicación produce algo, lo coloca en el caché, activa algunos eventos, hay suscriptores para ese evento. Entonces, hay otras instancias de aplicaciones u otras aplicaciones, muchas veces tienes algún tipo de flujo de trabajo en las aplicaciones. Ese algo se hace primero y luego, en base a eso, se hace algo más. Y, en ese caso, están estos suscriptores de esos eventos. Esas solicitudes serán notificadas.

Piensa ahora en esta imagen (Figura 1 y XNUMX) aquí. No vea esto como un caché entre la aplicación y la base de datos. Piense en eso como un bus de mensajes y todas estas aplicaciones están conectadas al bus de mensajes. Una aplicación de este servidor pone datos en el caché, dispara un evento. Es posible que otras aplicaciones en algunos de estos servidores sean notificadas e inmediatamente consumirán los datos. Manera muy poderosa.

Algunas personas usan colas de mensajes. Para muchos de esos mensajes, las colas tienen un propósito definido. Un caché distribuido no está aquí para reemplazarlos por completo, sino un subconjunto de los casos. Cuando todo el intercambio de datos está dentro del mismo centro de datos, no es un entorno muy distribuido y es un entorno de alto tráfico. Una cola de mensajes no es escalable, a diferencia de una caché distribuida. Porque una cola de mensajes no tiene un clúster como este. Realmente no puedes agregar más. Entonces, si tenía millones de transacciones y parte de eso también era información de mensajes, las colas de mensajes no pueden manejar esa carga, pero un caché sí.

Por lo tanto, compartir datos en tiempo de ejecución es una forma realmente poderosa y tocaré eso. Nuevamente, en el intercambio de datos en tiempo de ejecución, los datos generalmente solo existen en el caché. Aunque, podría existir una forma diferente en la base de datos. Porque se leyó de la base de datos, se transformó a través de alguna otra forma y luego se colocó en el caché para compartir.

Por lo tanto, algunas de las funciones son comunes en todos los cachés. Algunos son solo NCache en el lado de .NET pero todo lo que es NCache en el lado de .NET no es una función propietaria de .NET. Porque ve las mismas características en el lado de Java y en todos los cachés de Java. Entonces, Java es un mercado mucho más avanzado o mucho más maduro porque Java ha sido la tecnología del lado del servidor durante más tiempo que .NET. Entonces, ves que... En el lado de Java. En el lado de .NET, lo verá en algunos de los cachés, no en todos. Por ejemplo, AppFabric, creo que no lo tenía. Redis tiene algo de eso, no todo. NCache tiene un completo soplado como los cachés de Java.

Entonces, estos son los tres casos de uso. ¿Alguna pregunta sobre esto, antes de profundizar en cada uno de ellos?

Demostración práctica

Antes de entrar en cualquiera de estos, primero déjame mostrarte cómo se ve un caché. por supuesto voy a usar NCache como el ejemplo, pero el propósito es darle una idea de cómo se ve realmente un caché. Entonces, por ejemplo, tengo tres máquinas virtuales en Azure. Están corriendo. Demo1 y demo2 son mis máquinas virtuales de servidor de caché. Entonces, voy a tener un clúster de caché de 2 nodos.

El cliente de demostración es mi servidor de aplicaciones. Entonces es una máquina virtual de cliente de caché.

Crear una caché en clúster

He iniciado sesión en la máquina virtual del cliente de demostración aquí. Seguiré adelante y crearé un caché agrupado. En caso de NCache, usaré esta herramienta llamada NCache Manager , que es una herramienta gráfica. Vendré aquí y diré, primero déjame asegurarme de que el caché no existe ya. Está bien, no lo hace. Está bien, vendré aquí y diré crear un nuevo caché agrupado.

En caso de NCache todos los cachés tienen nombre. Entonces, mi caché se llama caché de demostración. Voy a dejar todo por defecto. No voy a entrar en los detalles de esto. Mantendré… Hablaré solo de aquellas partes que son importantes.

Lo primero que elegirá es lo que llamamos un topología de almacenamiento en caché en NCache y aquí es donde uno de ustedes hizo la pregunta sobre la partición. ¿Los datos están realmente distribuidos o existen los mismos datos en todos los servidores? Entonces, la réplica de partición es una topología que NCache te dio.

Por ejemplo, voy a saltar rápidamente esto y hablaré rápidamente sobre cuál es esa topología. Entonces, una topología de réplica de partición... Entonces, esta es una topología particionada, esta es una réplica de partición.

En una partición, cada servidor tiene una enésima parte de los datos. Entonces, si tienes, digamos, en caso de NCache, cuando crea una memoria caché en clúster, crea mil cubos. Entonces, si tiene un clúster de dos servidores, cada servidor 500. Si tiene tres, cada servidor es un tercio de mil.

Entonces, esos cubos son esencialmente como cubos de tablas hash. A cada cubo se le asigna un rango de valores clave. Por lo tanto, hay una función de mapa hash que transforma sus claves en valores hash y caerán en los cubos en los que deberían caer en función de las claves. Entonces, una réplica particionada tiene una partición en cada servidor. Digamos, si vinieras aquí. Digamos, aquí hay un clúster de tres servidores, entonces, las tres particiones y cada partición tiene una copia de seguridad o una réplica en un servidor diferente.

En caso de NCache la réplica no está activa. es pasivo Entonces, solo la partición habla con las réplicas. La aplicación habla con las particiones. Entonces, digamos que cada cliente de caché, cada servidor de aplicaciones se conecta a todos los servidores de caché. Se conecta y obtiene toda la información de membresía del clúster. El mapa de distribución es ese mapa de cubo. Entonces, ¿obtiene el mapa de cubos que le dice dónde está cada cubo? En base a eso, sabe, está bien, si necesito agregar el elemento número tres, debo ir al servidor 2. Porque ahí es donde vive la partición 2, que se supone que tiene la clave para el elemento número 3. Entonces, va directamente a ese servidor y puede hacer eso.

Y, luego, si un servidor se cae, entonces, digamos, la partición 3 se cae, por lo que la réplica 3 se activará de inmediato. Entonces, se convertirá en una partición ahora. Se transformará de una réplica a una partición. Porque, no sabes, quieres continuar. El caché debe ejecutarse, la aplicación debe continuar. Es alta disponibilidad, a la derecha. Entonces, y luego esta partición tres se da cuenta de que solo hay dos servidores, entonces, necesita fusionarse en estas dos particiones y desaparecer, desaparecer. Entonces, se fusiona en las otras dos particiones y luego, una vez hecho esto, se crea aquí una réplica para la partición dos.

Entonces, nuevamente, solo para brindarle una descripción general de lo que significa esa topología y así es como ocurre la distribución para garantizar que a medida que agrega más servidores, tenga más y más almacenamiento y así es también como ocurre la replicación para que todos los datos existan en dos servidores. . Por lo tanto, no hay pérdida de datos si algún servidor deja de funcionar.

Una vez más, la teoría de la alta disponibilidad dice que dos servidores no dejarán de funcionar simultáneamente. Las posibilidades de que dos servidores se caigan simultáneamente son astronómicamente bajas en comparación con cualquier servidor que se caiga. Por supuesto, como dije, si dos servidores están en la misma fuente de alimentación, esa fuente de alimentación se cae, entonces asumo que todo es redundante. Entonces dos cosas no fallarán al mismo tiempo. Entonces, es por eso que solo tener dos copias es más que suficiente.

Volvamos. Entonces, esa fue la réplica de la partición. Luego elegiré una replicación asíncrona.

Entonces, hay dos modos. La mayoría de los cachés distribuidos hacen esto llamado consistencia eventual. Lo que significa que debido a la distribución, si tuviera que realizar una sincronización inmediata, todo se ralentizaría. Pero la mayoría de los datos que puede permitirse, se ponen en cola y tienen actualizaciones asincrónicas. Entonces, el asíncrono es lo que se tomará como predeterminado aquí.

Elegiré el cliente de demostración o la demostración 1 es el primer servidor. Elegiré la demostración 2 como segundo servidor.

Vendré aquí, solo tomaré los valores predeterminados.

Especificaré cuánta memoria debe usar cada servidor.

Por supuesto en tu caso será mucho más. Entonces, digamos, si tiene 16 gigas de memoria en cada cuadro, necesita asignar algo para la partición y algo para la réplica. Entonces, digamos, se deben dejar de 2 a 3 gigas para el sistema operativo y otros procesos y quedan alrededor de 13 gigas. Entonces, por 7.5 o 6.5 gigas, uno para partición uno para réplica. Y, porque especifica ese tamaño para asegurarse de que el caché no consuma más que esto. Debido a que es un almacén en memoria, la memoria siempre es limitada y en ese cuadro puede haber otras aplicaciones ejecutándose. Por lo tanto, desea limitar la cantidad de memoria que debe usar el caché y una vez que el caché haya usado esa memoria...

Entonces, entonces la página siguiente sería. Digamos que has usado toda esa memoria. Entonces, ahora el caché está lleno. Entonces, solo pueden pasar dos cosas. Primero, expulsa algunos de los datos más antiguos u otros, o segundo, rechaza las nuevas inserciones. Entonces, tienes que elegir esos dos. Por supuesto que desea hacer su planificación de capacidad, donde están los datos, si los datos de la aplicación, está bien desalojarlos porque siempre puede volver a cargarlos desde la base de datos. No está bien desalojar sesiones. Por lo tanto, desea hacer su planificación de capacidad de manera que estas sesiones nunca se desalojen. Ahora tiene suficiente memoria, suficiente RAM y suficientes servidores para que siempre tenga memoria para las sesiones. Y desea hacer caducar las sesiones, no desalojar el tema. Desalojar significa que las sesiones aún no habían expirado pero no queda memoria, por lo que está desalojando a la fuerza. Caducidad en caso de NCache significa que especificó que una sesión es buena solo para, digamos, 20 minutos de inactividad. Después de eso, la sesión debe ser limpiada. Entonces, eso es caducidad. Por lo tanto, la caducidad está bien, no hay problema, pero el desalojo es algo que no debe hacer con la sesión, está bien hacerlo con los datos de la aplicación.

Entonces, ¿qué haces en caso de NCache, crea un caché para las sesiones y crea un caché para los datos de la aplicación. Entonces, así es como se separan los dos. Entonces, digamos que acabo de crear este caché. Entonces, es un caché de dos nodos. Continuaré y agregaré un nodo de cliente que es mi cuadro, el cliente de demostración y ahora simplemente iniciaré el caché.

Simule estrés y monitoree estadísticas de caché

Entonces, como puede ver, es bastante sencillo. Es una especie de interfaz de estilo Explorer. Desde un lugar, puede continuar y crear una memoria caché multiservidor, administrarla, monitorearla y luego, una vez que haya hecho eso, lo que sucede es, digamos, ahora que lo hizo, veré algunos contadores de PerfMon y voy a ejecute esta herramienta llamada herramienta de prueba de estrés que viene con NCache, que le permite simular muy rápidamente el uso de la aplicación.

Entonces, digamos que acabo de hacer eso y ahora está empezando a... Entonces, está haciendo alrededor de 500 a 800 transacciones por servidor. Entonces, eso es aproximadamente 2 veces, esa es la carga. Quiero aumentar la carga. Entonces, quiero agregar una herramienta más de prueba de estrés. Nuestros clientes usan esto bastante porque casi todos quieren ver cómo funciona el caché en su entorno. Ya sabes, tenemos todos los puntos de referencia publicados y todo, pero quieren verlo en su entorno. Entonces, en lugar de programar y aplicar para hacerlo, esto puede simular muy rápidamente. Entonces, digamos, ejecuté dos de ellos y ahora la carga aumentó. Entonces, puedo seguir agregando más y más de estos hasta maximizar estos dos servidores. Entonces, ahí es donde viene la escalabilidad.

Estos dos servidores están funcionando súper rápido en este momento. Pero, a medida que aumento la carga, después de cierto punto se maximizarán, que es lo que le sucede a una base de datos. La única diferencia es que puede venir aquí y agregar otro nodo. Entonces, si tuviera una tercera máquina virtual, simplemente venga aquí y agregue eso aquí y tan pronto como lo haga, de repente la carga se distribuirá y tenemos esa imagen donde, ya sabe, donde le mostré dónde comenzó con los dos servidores y ahora estos dos se agotaron, desea agregar un tercero. Entonces, solo obtiene otra VM y la agrega y ahora se convierte en un servidor de tres y NCache reajustará automáticamente todo, repartiremos o redisHomenaje al mapa del cubo. Entonces, hay un tercer servidor agregado en tiempo de ejecución. Entonces, de repente no tienes ese problema de capacidad.

Sí, entonces, lo que haces es instalar el NCache software de servidor, en todas estas máquinas virtuales. En el caso de la nube, generalmente tiene una imagen de VM preconfigurada que crea las instancias y, por lo tanto, simplemente lanza una nueva VM, tiene NCache software en ejecución y simplemente lo agrega a este clúster.

Pero, de nuevo, el punto principal es que, a diferencia de una base de datos en la que una vez que alcanzas ese estado máximo, estás agotado, ya sabes. ¿A qué te dedicas? Ya sabes, está bien, quiero comprar uno más caro. Bueno, entonces tienes que ir y comprar otra caja y derribar esta caja y es una pesadilla. Aquí solo agregas otra caja.

Usar NCache con sesiones ASP.NET

Entonces, voy a ir a eso ahora. Entonces, ahora que sabemos cómo se ve un caché. Entonces, ahora vemos que… en caso de NCache, todos los cachés tienen nombre. Entonces, siempre que sepa el nombre del caché, simplemente conéctese al caché. Entonces, ¿cómo te conectas al caché para las sesiones? Eso es lo más fácil. Una vez más, la mayoría de nuestros clientes, lo primero que hacen con NCache lo usan para sesiones. ¿Por qué? Porque no se necesita programación. Lo único que debe asegurarse en el caso de las sesiones es que todos los objetos que esté poniendo en la sesión sean serializables. Si ya está almacenando la sesión en SQL, entonces ya se ha asegurado de eso. Si está almacenando sesiones en modo In-Proc, es posible que no lo haya asegurado. Entonces, ya sabes, esa es la única prueba que tienes que hacer. Pero, después de eso, es bastante sencillo.

Solo les mostraré una pequeña muestra aquí. Entonces, por ejemplo, aquí hay una muestra llamada muestra de proveedor de almacén de sesiones. Entonces, tengo una aplicación ASP.NET. Voy a ir a la web.config. Supongamos que estoy en esta caja del servidor de aplicaciones, ya sabes. Si ves esa foto aquí. De hecho, déjame volver aquí. Entonces, aquí está el servidor de caché, pero mi aplicación se está ejecutando en este cuadro. Entonces, en este cuadro, creé dos clústeres de servidores y agregué un cliente a esto, a la derecha. Entonces, ahora lo que sucedió con ese cliente es que, en caso de NCache, ups no no aquí. Bien, en caso de NCache en realidad crea en la carpeta de configuración que hay un cliente.ncconf, por lo que crea una entrada. Entonces, así es como la aplicación sabe a qué servidor conectarse.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <ncache-server connection-retries="3" retry-connection-delay="0" retry-interval="1" command-retries="3" command-retry-interval="0.1" client-request-timeout="90" connection-timeout="5" port="9800" local-server-ip="10.2.0.5" enable-keep-alive="False" keep-alive-interval="0"/>
    <cache id="demoCache" client-cache-id="clientCache" client-cache-syncmode="optimistic" skip-client-cache-if-unavailable="True" reconnect-client-cache-interval="10" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
      <server name="10.2.0.5"/>
      <server name="10.2.0.6"/>
    </cache>
  </configuration>

Nuevamente, estos son solo la lista inicial de servidores. No es la lista final. ¿Por qué? Porque, para un entorno de alta disponibilidad, ¿qué pasaría si agregara ese tercer servidor en tiempo de ejecución? Eso no está en esta lista, ¿verdad? Entonces, digamos, eso fue el punto ocho (.0.8), algo. Entonces, esta es solo la lista inicial. Una vez que la aplicación reconoce alguno de ellos, se conecta a él. Lo primero que le sucede a la aplicación, una vez que se conecta, recibe la información de membresía del clúster y también cada vez que cambia la membresía del clúster y agrega otro servidor y la membresía del clúster actualizada se envía al cliente y todo se mantiene en la memoria. Todo está oculto para su aplicación. Todo está gestionado por el NCache parte del cliente, pero así es como la aplicación sabe cómo conectarse a su caché.

Entonces, en caso de sesiones, solo ven aquí. Entonces, en las sesiones, lo que haces es agregar primero el ensamblaje.

...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
    <compilers>
		<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
	</compilers>
	<assemblies>
	<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" /></assemblies>
</compilation>
...

En caso de NCache simplemente... esta asamblea implementa el interfaz de proveedor de estado de sesión eso es parte de la ASP.NET framework y al hacer eso NCache se convierte en un tercero, un almacenamiento personalizado. Entonces, esto es solo copiar y pegar y luego los cambios reales en la etiqueta de estado de la sesión. Entonces, lo que haces aquí te aseguras de que el modo sea personalizado.

...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
    <providers>
        <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
    </providers>
</sessionState>
...

Entonces, los modos son, está In-Proc, el servidor de estado, el SQL y está el personalizado. Así que hay cuatro modos que tienes. Por lo tanto, si el modo es personalizado, también debe asegurarse de que el tiempo de espera sea el que desee que sea el tiempo de espera de la sesión y luego copie los detalles del proveedor. Que es, en caso de NCache es esta línea y lo único que tienen que cambiar es el nombre del caché. Entonces, por ejemplo, aquí el nombre del caché ya está cambiado. Tú haces ese cambio, eso es todo. Y, tan pronto como realice ese cambio, ASP.NET reinicia su proceso de trabajo de todos modos y verá que cada sesión se guardará como un objeto en el caché e inmediatamente verá un gran aumento en el rendimiento. Porque ahora no los estás guardando en SQL.

Entonces, la forma más rápida de beneficiarse de un caché distribuido como NCache es solo ponerlo para sesiones. Porque, para objetos para el almacenamiento en caché de datos de aplicaciones, hay más trabajo. Por supuesto, ya sabes, quieres hacer eso y eso es lo que voy a abordar, pero el primer caso de uso es la especificación ASP.NET.

¿Alguna pregunta sobre esto? Entonces, lo que hemos visto, por ejemplo, algunos de nuestros clientes de alto nivel tienen alrededor de 50 a 100 servidores en el nivel de aplicación. Para eso, digamos, mantener una proporción de 1 a 5 es lo que suele suceder. Entonces, para una configuración de 100 servidores, tendrán 20 servidores de caché. Más de 50, son muy pocos, ya sabes, realmente tienes que tener mucho tráfico para tener más de 50 servidores en un entorno de carga equilibrada. La mayoría de los clientes tienen entre 4 y 12 servidores. Y recomendamos tener una proporción, como dije, de 4 a 1 o de 5 a 1, según la naturaleza de la aplicación. A veces, incluso puede ser más de 5 a 1, pero quiero decir que esto es como el caso de uso promedio. Entonces, si tiene un 5 a 1 y tiene 12 servidores en el nivel de aplicación, tiene un nivel de almacenamiento en caché de tres servidores. Entonces, no tantas conexiones, sí.

Teóricamente, sí. Si continúa agregando más y más servidores, tendrá muchos servidores redundantes. Pero, los casos de uso de los que estamos hablando, no fallan. El procesamiento de big data puede tener 50 o 100 servidores, pero en ese caso no hay clientes y un procesamiento de big data es solo del servidor. Porque todo se ejecuta en el propio servidor. Pero, en el caso de una aplicación web o una aplicación de servicios web, lo que llamamos comercio electrónico, el modelo de negocio en línea. Quiero decir que eso es bastante. Creo que puede suponer que en la mayoría de los casos tendrá menos de 20 servidores y un porcentaje muy pequeño de clientes tendrá más de 20 y más de 50 es muy pequeño.

Sí, definitivamente. Entonces, por ejemplo, si tuviera que venir aquí, simplemente voy a... si tuviera que venir aquí. no estoy usando el Paquete NuGet aquí pero podría venir aquí e ir a NuGet y podría decir aquí NCache, por ejemplo, y obtendrá un NCache SDK, NCache Servicios de sesión para empresas y profesionales y también hay un código abierto, también hay NHibernate. Entonces, hay un montón de NuGets. Entonces, un típico... para las sesiones solo incluirá este paquete NuGet de sesión. Para el almacenamiento en caché de datos de la aplicación, solo incluya el SDK y eso incluirá todo lo que necesita en esto.

Descripción general del almacenamiento en caché de datos de la aplicación (API)

¿Entonces almacenamiento en caché de datos de la aplicación es algo en lo que tienes que programar. Entonces, ves el caché como una base de datos. Te conectas al caché. En caso de NCache tenemos este método llamado Inicializar caché.

Conexión de caché

Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();

Recuperacion de datos

Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");

Escribir datos

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");

Puede tener otros métodos para otros cachés y hay un nombre de caché en caso de NCache como hablamos y esto le da un identificador de caché.

Entonces, entremos en una aplicación. Nuevamente, entraremos en... Esta es una aplicación de consola simple. Lo que hace es, si hubiera incluido el paquete NuGet, todo esto se hará por usted. Harías referencia a algunos NCache Ensambles. Entonces, solo hay dos ensamblajes a los que debe hacer referencia, NCache.Tiempo de ejecución y NCache.Web. NCache.Web es la API pública real en caso de NCache. Luego, en su aplicación, incluye el espacio de nombres. Entonces, tienes la NCache.Tiempo de ejecución y NCache.Web.caching como los espacios de nombres.

Luego, al comienzo de la aplicación, obtiene el nombre del caché de, digamos, App.config y luego inicializa el caché y obtiene un identificador de caché. Entonces, aquí está el identificador de caché que necesita usar en todas partes de la aplicación.

Ahora, entremos en ese identificador de caché. Entonces, puedes hacer caché.Agregar, especificar clave. La clave es como dije, generalmente una cadena. El objeto es su objeto real, sea lo que sea. Es cualquier objeto .NET, NCache en realidad lo serializará y lo enviará al clúster. Entonces, todo esto sucede en el lado del cliente, en el servidor de aplicaciones.

// Alachisoft (R) NCache Sample Code.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Web.Caching;
using System;
using System.Configuration;

namespace Alachisoft.NCache.Samples
{
    /// <summary>
    /// Class that provides the functionality of the sample
    /// </summary>
    public class BasicOperations
    {
        private static ICache _cache;

        /// <summary>
        /// Executing this method will perform all the operations of the sample
        /// </summary>
        public static void Run()
        {
            // Initialize cache
            InitializeCache();

            // Create a simple customer object
            Customer customer = CreateNewCustomer();
            string key = GetKey(customer);

            // Adding item synchronously
            AddObjectToCache(key, customer);

            // Get the object from cache
            customer = GetObjectFromCache(key);

            // Modify the object and update in cache
            UpdateObjectInCache(key, customer);

            // Remove the existing object from cache
            RemoveObjectFromCache(key);

            // Dispose the cache once done
            _cache.Dispose();
        }

        /// <summary>
        /// This method initializes the cache
        /// </summary>
        private static void InitializeCache()
        {
            string cache = ConfigurationManager.AppSettings["CacheID"];

            if (String.IsNullOrEmpty(cache))
            {
                Console.WriteLine("The CacheID cannot be null or empty.");
                return;
            }

            // Initialize an instance of the cache to begin performing operations:
            _cache = NCache.Web.Caching.NCache.InitializeCache(cache);

            // Print output on console
            Console.WriteLine(string.Format("\nCache '{0}' is initialized.", cache));
        }

        /// <summary>
        /// This method adds object in the cache using synchronous api
        /// </summary>
        /// <param name="key"> String key to be added in cache </param>
        /// <param name="customer"> Instance of Customer that will be added to cache </param>
        private static void AddObjectToCache(string key, Customer customer)
        {
            TimeSpan expirationInterval = new TimeSpan(0, 1, 0);

            Expiration expiration = new Expiration(ExpirationType.Absolute);
            expiration.ExpireAfter = expirationInterval;

            //Populating cache item
            CacheItem item = new CacheItem(customer);
            item.Expiration = expiration;

            // Adding cacheitem to cache with an absolute expiration of 1 minute
            _cache.Add(key, item);

            // Print output on console
            Console.WriteLine("\nObject is added to cache.");
        }

Y, una vez que hayas hecho eso, también puedes hacer _caché.Obtener y recuperar ese mismo objeto. Entonces, si viera eso en términos de la API, aquí está cache.Obtener, Obtener, Contiene, Agregar, Insertar, Quitar y los tres tienen una versión asíncrona, lo que básicamente significa que la aplicación no espera a que se actualice el caché, el control vuelve inmediatamente. Pero, la clave suele ser una cadena. Por lo general, es algo como esto. Tienes el nombre del tipo. En caso de NCache eso depende. Si ha utilizado esta característica llamada caché del cliente. Entonces, solo voy a saltar a eso.

Caché del cliente (caché cercano)

Entonces, por defecto asumirá que cada vez que haga una caché.Obtener, en realidad vas al nivel de almacenamiento en caché. Pero hay una cosa interesante de la que la mayoría de la gente no se da cuenta, y es que, si ha estado usando un caché In-Proc, como un objeto de caché ASP.NET y decidió pasar a algo como NCache porque dijimos que mejorará su rendimiento y escalabilidad. Bueno, es una especie de mejora de la escalabilidad, pero de repente su rendimiento va a disminuir. Tenemos muchos clientes que nos llaman y nos dicen: mi aplicación se ha ralentizado desde que me conecté. NCache. Entonces, ¿por qué realmente lo necesito? Realmente no es bueno, es un-ya sabes. Entonces, tenemos que explicarles que cuando haces un caché In-Proc, no hay serialización, no hay comunicación entre procesos entre la aplicación y el caché, ya sea que esté en el mismo cuadro o en un cuadro separado, por lo general es un caja separada, derecha. Entonces, si el objeto se mantiene en su montón en forma de objeto, es súper rápido, ¿verdad? Solo ve y consigue una referencia. Nada puede igualar ese rendimiento. Pero, la razón por la que pasa a un caché distribuido es porque ese modelo In-Proc tiene muchas limitaciones. No puede escalar. No puede agregar más y más datos, es solo un proceso y si tiene más de un proceso, la duplicación no se sincroniza. Por lo tanto, hay muchos otros problemas por los que te mueves a un caché distribuido, pero pierdes ese beneficio, ¿verdad? Entonces, lo que hicimos fue crear algo llamado caché de cliente que en el lado de Java se llama caché cercano y en el lado de .NET por el tiempo y el caché es el único que lo tiene.

Entonces, lo que esto hace en realidad, en realidad crea un caché local In-Proc dentro de la aplicación. Por lo tanto, mantiene ese objeto en forma de objeto en su montón. Por lo tanto, obtiene el mismo rendimiento al que está acostumbrado dentro de la memoria caché In-Proc independiente. La única diferencia es que este caché sabe que es parte de un caché agrupado. Entonces, sea lo que sea que esté guardando en su copia local, tiene un enlace al nivel de almacenamiento en caché. Le ha dicho al nivel de almacenamiento en caché que, ya sabes, tengo este objeto, avísame si alguien cambia ese objeto. Entonces, si hay alguno, digamos, si este cliente tiene el número de artículo otro cliente y, por supuesto, ese artículo número uno también está en este nivel de almacenamiento en caché. Entra otro cliente y actualiza ese artículo número uno. El nivel de almacenamiento en caché sabe que estos cachés de clientes tienen el elemento número uno, por lo que lo notifican a través de eventos, ya sabes. En caso de NCache son eventos bastante rápidos. Estos no son eventos .NET, son comunicaciones a nivel de socket. Entonces, el caché del cliente se actualiza inmediatamente. Entonces, estamos hablando de un retraso de un milisegundo.

Entonces, de esa manera, está seguro de que, lo que sea que obtenga, es correcto todo o la mayor parte del tiempo. Técnicamente, existe una pequeña probabilidad de que tal vez sea una copia anterior. En caso de NCache, si está demasiado preocupado por eso, puede usar lo que llamamos el modo de sincronización pesimista donde cada vez que obtiene algo, ya sabe, NCache comprueba internamente el nivel de almacenamiento en caché para ver si tiene una copia más reciente. Si no es así, lo proporciona a partir de los datos del caché del cliente; de ​​lo contrario, lo obtiene del nivel de caché. Pero, no necesita eso para la mayoría de los casos. En la mayoría de los casos, está bien arriesgarse tanto. Entonces, eso le da el aumento de rendimiento de la memoria caché In-Proc. Pero, nuevamente, su aplicación no sabe que todo eso está sucediendo.

En caso de NCache su aplicación lo sabe. La aplicación cree que solo está hablando con el nivel de almacenamiento en caché. Solo hay un caché con el que está hablando. Se llama mi caché o lo que sea. Es el caché de demostración y el caché de demostración puede tener un caché de cliente conectado a través de la configuración en caso de NCache. ¿Alguna pregunta sobre esto?

API JCache (JSR 107)

Entonces, quiero decir que así es como se ve un caché típico. Es bastante fácil hacer esta programación. Lo que está sucediendo ahora en el lado de Java, sigo elogiándolos porque están mucho más avanzados en esto. Tienen una API estándar completa llamada JCache. Entonces, la API de JCache es una característica muy... tiene todas las características de las que acabo de hablar o de las que estoy hablando. Entonces, JCache es un estándar que cada caché de Java debe implementar si quiere ser compatible con la industria.

API de caché distribuida

En el lado de .NET todavía no existe tal cosa. Hay un objeto de caché ASP.NET que hasta hace poco no se podía conectar. Entonces, si programa en caché ASP.NET, no puede conectarse NCache en lugar de eso. Por lo tanto, no puede conectar un caché de terceros. Es solo un caché independiente. En .NET 4.0, iniciaron un caché de .NET que nunca funcionó. Ahora en ASP.NET core tienen un iDistributedCache interfaz. Lo cual es nuevamente, un método de entrada muy básico.

Entonces, el problema con la API estándar sería que no podrá aprovechar todas las características que debe brindarle un buen caché. Estás realmente limitado a la entrada de obtención básica. Pero, de nuevo, la mayoría de nuestros clientes encapsulan el nivel de almacenamiento en caché de todos modos. Entonces, incluso si están haciendo todo el NCache llamadas, toda la aplicación no está expuesta a ella. Entonces, de todos modos, así es como se ve la API.

Funciones de almacenamiento en caché de datos de la aplicación

Ahora, veamos algunas de las características que son importantes. Entonces, la mayoría de ellos... adelante. Sólo una pregunta sencilla. ¿Hay diferencia entre insertar y agregar? Sí, insertar significa agregar o actualizar. Si los datos ya existen, actualícelos, si no, agréguelos. Agregar fallará si los datos ya existen. Y, nuevamente, esa es una API de caché de ASP.NET a la que nos apegamos, porque queremos estar lo más cerca posible del estándar en ese momento. No, no, no lo es. Quiero decir, lo hemos mantenido. El objeto de caché ASP.NET ya no está porque ahora, como dije, en ASP.NET Core ya no está, ASP.NET todavía lo tiene pero ASP.NET Core no lo hace

Vencimientos absolutos

Entonces, lo primero que debe tener en cuenta es mantener el caché actualizado del que hablamos, ¿verdad? ¿Cómo se hace esa técnica número uno? Expiraciones. Expiraciones se parece a esto, volvamos a esto. Entonces, digamos que tengo... ¿Pueden ver esto? ¿Puedes ver esto? ESTÁ BIEN. Digamos que tengo una clave y un valor o algún objeto. Quiero agregarlo al caché y especificaré un vencimiento de 1 minuto. Entonces, esto se llama el caducidad absoluta.

public static void AddObjectToCache(string key, Customer customer)
    {
        DateTime expirationInterval = new DateTime();
        expirationInterval.AddMinutes(1);
        //Adding item with an absolute expiration of 1 minute
        _cache.Add(key, customer, expirationInterval, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
        Console.WriteLine("\nObject is added to cache");
    }

La caducidad absoluta significa que después de que haya pasado 1 minuto caducará esto pase lo que pase. Eso significa que le estoy diciendo al caché, realmente no me siento cómodo guardando esto en caché por más de un minuto. Porque supongo que es seguro mantener esto en el caché durante un minuto.

Vencimientos deslizantes

La expiración deslizante, por otro lado, tiene un propósito totalmente diferente. Es para la limpieza de cosas como sesiones. No tiene nada que ver con la sincronización o mantener el caché actualizado. Entonces, la expresión absoluta es algo que tienen casi todos los cachés. De hecho, incluso la ASP.NET Core IDistributed Cache Interface tiene la expresión absoluta.

Sincronizar caché con base de datos

Pero, ¿qué hay de malo en que la expresión sea la única forma de crear un caché o mantenerlo actualizado? Es que estás adivinando que estos datos no van a cambiar. ¿Qué pasa si lo hace? ¿Qué pasa si hay otras aplicaciones, hay otras secuencias de comandos que modifican los datos que en cualquier empresa, generalmente hay más de un lugar desde donde se actualizan los datos? Por lo tanto, si no puede predecir la frecuencia con la que se actualizarán los datos, las expresiones son solo un punto de partida. Tienes que pasar a la siguiente etapa, que es sincronizar el caché con la base de datos. Entonces, básicamente, al sincronizar el caché con la base de datos en caso de NCache usamos esta característica que es parte de ADO.NET .NET llamada dependencia de SQL.

Dependencia de SQL esencialmente, déjame mostrarte cómo se ve. Entonces, en caso de una dependencia de SQL, estoy haciendo el mismo caché. Agregar, correcto. Tendré la clave y en lugar de tener el valor, tendré un elemento de caché que es nuestra propia estructura dentro de la cual colocamos el objeto real y ahora tenemos esto y luego especificamos esta cosa llamada dependencia SQL, dependencia del servidor SQL que es esta variable la que esencialmente crea la instrucción SQL.

private static void AddProductToCacheWithDependency(Product product)
    {
        // Any change to the resultset of the query will cause cache to invalidate the dependent data
        string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);

        // Let's create SQL depdenency
        CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);

        CacheItem cacheItem = new CacheItem(product);
        cacheItem.Dependency = sqlServerDependency;

        // Inserting Loaded product into cache with key: [item:1]
        string cacheKey = GenerateCacheKey(product);
        _cache.Add(cacheKey, cacheItem);
    }

Este código se está ejecutando en el cuadro del cliente, aquí mismo.

Habla con el servidor de caché. Le dice al servidor de caché que use la función de dependencia SQL de ADO.NET para conectarse a mi base de datos. Entonces, en realidad me da una cadena de conexión a la base de datos. Entonces, ahora la aplicación le dice al caché, aquí está mi base de datos para este elemento almacenado en caché, aquí está la instrucción SQL que representa los datos correspondientes en la base de datos.

Entity Framework/Integración principal de Entity Framework

Buena pregunta. En el caso de Entity Framework, la implementación que tenemos para Entity Framework, la hemos implementado en el interior. Incluso con Entity Framework hay dos formas de usar un caché. O usted, en el caso de EF Core, ahora la nueva arquitectura permite que el caché de terceros se conecte, pero hasta EF6, no había forma de conectar un caché. Por lo tanto, tendría que realizar estas llamadas a la API de todos modos. Entonces, digamos que obtuvo una colección de entidades y, a medida que las almacena en caché, puede especificar la dependencia de SQL. ¿Entendiste lo que quise decir?

En caso de NCache estás diciendo NCache aquí está mi declaración SQL. NCache Usaremos ADO .NET para conectarnos a su base de datos y usaremos la función de dependencia SQL de ADO.NET para luego monitorear ese conjunto de datos. Asi que, NCache le dice al servidor SQL, avíseme si este conjunto de datos cambia. Luego, el servidor SQL envía una notificación de base de datos a NCache porque NCache no es un cliente de la base de datos y luego NCache ahora sabe que estos datos han cambiado en la base de datos. Entonces, a pesar de que tenía EF, es como pasar por alto eso y ahora eso NCache sabe que estos datos han cambiado NCache tiene dos opciones. Uno puede eliminar ese elemento del caché y, cuando lo elimine, ya sabe, la próxima vez que alguien lo necesite, no lo encontrará en el caché, por lo que tendrá que ir a buscarlo a la base de datos. Entonces, de alguna manera lo estás haciendo fresco o NCache puede recargar esos datos desde la propia base de datos para usted y eso no es posible a menos que use otra característica llamada lectura, llegaré a eso.

Por lo tanto, la dependencia de SQL básicamente garantiza que si no puede predecir cuándo pueden cambiar los datos, simplemente dígaselo. NCache o su caché, por favor controle la base de datos por mí.

La dependencia de SQL tiene la limitación de que no puede tener uniones en ellos. Entonces, es una cosa de una sola mesa. Hay otras formas de monitorear. Por ejemplo, en caso de NCache hay una función llamada Dependencia personalizada, que es su código. NCache llama a su código y dice, vaya y controle su fuente de datos y vea si los datos han cambiado. Entonces, eso es como una encuesta. Asi que, NCache sondeará a través de su dependencia personalizada y luego podría ser una estructura compleja.

Si, exacto. En realidad, cuando haces la dependencia de SQL, el caché no se comunica con la base de datos con tanta frecuencia, porque solo... Entonces, la base de datos es la que inicia la comunicación porque hay un evento. Es una arquitectura impulsada por eventos. Entonces, la base de datos envía un evento cada vez que los datos cambian.

En realidad, el servidor SQL tiene esta función en la que supervisa el conjunto de datos y luego envía notificaciones de la base de datos a los clientes. Asi que, NCache se convierte en un cliente de base de datos.

Entonces, una opción era eliminar ese elemento del caché. La otra es simplemente recargarlo. Bueno, recargar significa que NCache tiene que tener una forma de saber cómo ir y obtener esos datos y eso significa que existe esta característica llamada lectura, que es el código que escribe y registra con el servidor de caché, el clúster de caché. Te mostraré rápidamente cómo se ve ese código.

Caché de lectura

No, en realidad es solo su código personalizado. Entonces, incluso usted puede hacer las llamadas ORM dentro de ese código también. Entonces, todo ese código se ve así. Entonces, hay una interfaz IReadThruProvider, aquí mismo.

...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
    object connString = parameters["connstring"];
    sqlDatasource = new SqlDatasource();
    sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}

// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
    sqlDatasource.DisConnect();
}

// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
    ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
    cacheItem.ResyncOptions.ResyncOnExpiration = true;
    // Resync provider name will be picked from default provider.
    return cacheItem;
}
...

Entonces, hay una interfaz IReadThruProvider. Tiene tres métodos. Hay un Init que se llama solo cuando se inicia el caché. Por lo tanto, se supone que debe conectarse a su fuente de datos. Hay un triturador que está al final y hay una carga. Entonces, la carga te da una clave y se supone que debes devolver un elemento de caché.

Entonces, según esa clave, su código necesita saber a dónde ir porque ya se ha conectado a su fuente de datos. Entonces, ya sea que use ORM, ya sea que haga llamadas EF, llamadas NHibernate, llamadas ADO.NET, ese es todo su código y luego irá y lo cargará, digamos, irá y cargará ese objeto de la base de datos y lo pones y pones vencimientos o cualquier otro metadato que quieras con él y lo devuelves NCache. NCache luego lo almacenará en caché, antes de devolverlo a la aplicación.

Entonces, todo el propósito de la lectura completa... permítanme llegar a esta lectura completa. La lectura completa es una forma en que el caché puede cargar datos de su base de datos. Entonces, en realidad está moviendo parte de su código de persistencia al nivel de almacenamiento en caché. Y, si tiene varias aplicaciones que desean compartir un caché, es perfecto tener un mecanismo de lectura y escritura simultáneas. Porque estás consolidando, estás haciendo las aplicaciones, algo así como menos código, ya sabes. Por lo tanto, tendrán menos código porque cada vez más código de persistencia va al nivel de almacenamiento en caché. Ese es un beneficio. Ya sabes, encapsulación y consolidación.

El segundo beneficio de la lectura completa es lo que acabamos de hablar sobre la recarga. Entonces, la recarga ocurre en dos casos. Uno en sincronización de base de datos, el otro en caducidad. La caducidad también es un gran caso si tiene una aplicación de mucho tráfico que, digamos, tiene algún tipo de tabla de búsqueda o tabla de precios que cambia y recibe miles de solicitudes, si no tiene la luego, cuando los datos caduquen, miles de esas solicitudes irán y llegarán a la base de datos. Y todos cargarán el mismo objeto en el caché. Lo que finalmente es solo mucho tráfico a la base de datos. Si multiplica eso por miles de elementos que podría tener, su base de datos verá mucho tráfico innecesario.

De hecho, uno de nuestros clientes es un cliente de comercio electrónico de alto nivel en el negocio de las flores en los EE. UU. que tenía ese problema. Entonces, cuando implementaron la función de recarga de repente, todo el problema desapareció porque ahora ese elemento nunca se elimina del caché. Entonces, las copias antiguas se mantienen hasta cierto punto y la nueva copia se actualiza encima. Por lo tanto, la aplicación nunca tiene que ir a la base de datos. Entonces, porque incluso en la exploración solo actualiza la nueva copia. Entonces, es un montón de... Entonces, esos son los dos beneficios que se pueden combinar con esta sincronización.

Caché de escritura simultánea

El otro aspecto es la escritura directa, que funciona igual que la lectura directa, excepto que es para escribir y una escritura puede agregarse, insertarse, eliminarse o eliminarse. Nuevamente, de la misma manera que tiene Init, tiene Dispose y ahora tiene Escribir en fuente de datos. Dice cuál es la operación y también tiene los datos y vas y actualizas la base de datos. Entonces, escribir a través significa que actualiza el caché, el caché actualiza la base de datos.

Entonces, ¿cuál es el beneficio de la escritura simultánea? Bueno, un beneficio es el mismo que la lectura completa. Consolidas toda la persistencia. En segundo lugar, el beneficio es la escritura posterior. Porque, las actualizaciones de la base de datos no son tan rápidas como, ya sabe, y si confía en que la actualización de la base de datos tendrá éxito, simplemente actualice el caché y deje que el caché actualice la base de datos de forma asíncrona. Por supuesto, puede recibir una notificación si algo falla, pero puede continuar y hacer otras cosas y eso también mejora el rendimiento de actualización de su aplicación. Entonces, ahora no tiene que esperar a que se completen las actualizaciones de la base de datos porque están todas en cola. Entonces, esa es la parte de escritura posterior. Y la cola de escritura diferida se vuelve a replicar en más de un servidor. Por lo tanto, si un servidor deja de funcionar, ninguna de sus operaciones se pierde, en caso de NCache.

Pero ese es tu código. quiero decir NCache llama el tuyo. Entonces, todo esto es su código. Asi que, NCache te llama y te das cuenta de lo que significa la escritura o lo que significa la lectura.

Por lo tanto, la lectura directa y la escritura directa son otra característica muy poderosa que puede combinar con la caducidad y la sincronización. Por lo tanto, debe asegurarse de que el caché se mantenga actualizado y luego debe asegurarse de usar la lectura y la escritura simultáneas. Ahora que comienza a hacer eso, puede almacenar en caché una gran cantidad de datos. Y ahora ese caché comienza a parecerse a la base de datos. Eso significa que realmente no puedes obtener, ya sabes, la clave no es suficiente ahora. Tienes que ser capaz de hacer búsquedas. Tienes que ser capaz de buscar cosas de una manera más inteligente. Entonces, ahí es donde debería poder hacer consultas de tipo SQL en el caché. Por ejemplo, algo así como seleccionar clientes, donde el punto del cliente Ciudad es igual a Londres. Le brinda una colección de todos los objetos del cliente que coinciden con ese criterio. Y el caché indexa esos objetos según, digamos, el atributo de la ciudad. Entonces, así es como te permite buscar.

Entonces, si no puede hacer esto, su aplicación se vuelve más compleja porque solo puede buscar cosas en las claves y, ya sabe, está acostumbrado a hacer muchas otras cosas con la base de datos que no puede hacer con el caché.

No hay uniones en un caché, pero puede hacer agrupaciones. Y ese tipo de servicio sirve para el propósito de que puede obtener datos y luego agruparlos y luego, en función de esos grupos, puede decir dame todo lo que pertenece a estos grupos, subgrupos, etiquetas, etiquetas de nombre. Por lo tanto, hay otras cosas que puede hacer para agrupar cosas de forma lógica y los datos en sí que está almacenando en caché pueden venir a través de uniones. Es solo que el caché no puede ser... el caché no es un motor de base de búsqueda. Entonces, si tiene datos de unión, simplemente agrúpelos.

Dependencias de caché

Entonces, hay una función y otra vez porque hay mucho de esto que realmente no puedo cubrir en este momento. Entonces, hay una característica llamada dependencia de caché que por cierto proviene del objeto de caché ASP.NET, NCache también ha implementado lo que permite... Le dices al caché que este elemento depende de este elemento. Si este elemento se actualiza o elimina alguna vez, se eliminará automáticamente. Entonces, al crear esas relaciones, puede tener uno a muchos, digamos, si tuviera una relación de uno a muchos donde el lado de muchos no puede existir sin el lado de uno. Digamos que es un cliente y un pedido. Entonces, si elimina al cliente, también desea eliminar el pedido. Entonces, puede dejar que el caché se encargue de eso por usted. De manera similar, cuando almacena en caché, digamos que tiene una colección de objetos, puede almacenar en caché toda la colección como un objeto o puede dividirlos en un solo objeto. Si los divide, entonces querrá hacer las dependencias de caché. Entonces, si se elimina un objeto, esa colección ya no es válida.

Sí, entonces, ese es todo un tema sobre el que tengo una charla, que puede visitar nuestro sitio web. Déjame mostrarte rápidamente. Entonces, hay toda una charla sobre eso. Creo que es Manejo de datos relacionales en una caché. Entonces, eso va sobre todo el uno a muchos, uno a uno, muchos a muchos, eso va sobre colecciones que todas esas cosas de las que acabas de hablar. Solo ve y echa un vistazo a eso. Voy a pasar rápidamente porque no nos queda tiempo.

Entonces, traté de argumentar por qué debería usar un caché y cómo debería usarlo y maximizar el beneficio a través de él. me voy a saltar el uso compartido de datos en tiempo de ejecución parte, creo que he cubierto lo suficiente. Puede visitar nuestro sitio web y obtener más información al respecto. He hablado sobre la memoria caché del cliente, he hablado sobre la alta disponibilidad a través de la partición y todo eso.

Replicación WAN de caché distribuida

También hay varios centros de datos. Ya sabes, esperas que tu base de datos pueda manejar múltiples centros de datos, entonces, ¿por qué no el caché? Entonces, de nuevo, NCache le proporciona esta función. En el lado de Java, tiene cachés que hacen esto. En el lado de .NET NCache es el único Por lo tanto, puede tener un centro de datos activo-pasivo o activo-activo y los cachés están sincronizados. Nuevamente, no puede tener un clúster que abarque la WAN, porque el rendimiento simplemente muere. Debe realizar una replicación asíncrona o sincronización a través de la WAN porque cuando tiene dos centros de datos, es posible que no estén en la misma ubicación.

Uno de nuestros clientes es Ryanair, que es una gran aerolínea aquí y tienen un centro de datos en Dublín, Londres y Frankfurt. Por lo tanto, deben asegurarse de que puedan sincronizarse. En caso de NCache también tenemos replicación de WAN. También existe un concepto de sesión de varios centros de datos en el que la sesión se puede mover de un centro de datos a otro. Pero, de todos modos, su caché debe poder admitir múltiples centros de datos. Por lo tanto, asegúrese de investigar eso.

NCache vs Redis

La mayoría de la gente de .NET conoce Redis. NCache, lo siento, Microsoft los seleccionó como su opción para Azure a pesar de que Redis proviene de un entorno Linux. Creo que la razón principal por la que Microsoft los eligió es porque querían tener varios idiomas. Asi que, Redis cubre una gran cantidad de idiomas. NCache está bastante centrado en .NET. También tenemos API de Java pero NCache en sí mismo está enfocado en .NET. Quiero hacer una descripción general muy rápida de los dos solo para que pueda ver lo que esto significa y luego puede visitar nuestro sitio web y, de hecho, es como un completo comparación. Puedes hacer una comparación de características aquí. Y, entonces también puedes descargar esto. Entonces, echa un vistazo a esto. Se basa en su documentación y la nuestra. Entonces, no es nada más que… no hay giro en esto.

NCache también es de código abierto, por lo que es Redis. En caso de NCache tienes el... puedes venir a nuestro sitio web y puedes descargar ya sea Enterprise Edition o el código abierto o también puede ir a GitHub, donde está NCache? Justo aquí en GitHub y luego puedes ver NCache aqui tambien.

Por lo tanto, esta edición empresarial es totalmente compatible. En caso de Redis Microsoft portado Redis de Linux a Windows. Entonces, uno pensaría que Microsoft estaría usando el puerto en Azure, pero no es así. Entonces, el puerto que tienen tiene muchos problemas. Muchos clientes se han quejado con nosotros al respecto.

Entonces, si usa Redis en Azure usan la versión de Linux, es estable, no hay problema con eso, pero pierdes todas las funciones de las que acabamos de hablar. Si desea realizar un soporte local, NCache le dará el código abierto, todo es gratis, la empresa es algo en lo que obtiene más funciones de las que paga por el soporte también. Si desea en las instalaciones con Redis, las únicas opciones que tiene es ir con la versión de Linux de Redis laboratorios Ahora también tienen esto en la ventana acoplable. Por lo tanto, puede ejecutarlo técnicamente en Windows pero aún así en el entorno Linux para ellos. El on-prem de Windows es de Microsoft, que como dije es inestable y sin soporte.

En Azure Redis le da un modelo de servicio de caché, NCache le da un modelo de máquina virtual. El modelo VM te da mucho más control. Todas estas cosas de las que acabamos de hablar sobre lectura, escritura, cargador de caché, sincronización de base de datos, obtienes todo ese control y solo hay una API de cliente.

Esa es solo una descripción general rápida de los dos. Quería mencionar algo. Básicamente, NCache es el caché más antiguo en el espacio .NET. Tenemos toneladas y toneladas de clientes usando NCache. También muchos de ellos están en el Reino Unido. El Reino Unido es nuestro segundo mercado más grande y si tiene una aplicación .NET, espero que prefiera que toda la pila sea .NET. NCache te da esa pila .NET, Redis no lo hace

¿Alguna pregunta antes de concluir esta charla? Pero entonces estás exponiendo la partición tú mismo. Porque, en una base de datos relacional, debe programar la aplicación de manera que los datos residan en uno u otro. Me refiero a que todo el concepto de No SQL es que hacen la fragmentación por ti porque todo se basa en la clave. En un relacional, tiene muchas más complejidades y, hasta ahora, ninguna de las bases de datos relacionales ha podido abordar el problema de la escalabilidad. Se han esforzado mucho y han mejorado enormemente el rendimiento. Hay muchas opciones en memoria, por lo que también tienen bases de datos en memoria y hacen muchas tablas en memoria y otras cosas. Por lo tanto, el rendimiento ha mejorado bastante, pero el rendimiento no es el problema aquí. Ya sabes, el problema es la escalabilidad. Puedes manejar esa carga y hasta ahora no pueden.

Entonces, la razón por la que tenemos la indexación es para que pueda buscar esos atributos. Entonces, podría hacer una declaración SQL y buscar en esos atributos del objeto en el que estaba indexado.

Entonces, lo que hacemos es que no le permitimos hacer una búsqueda a menos que haya creado el índice. Entonces, si haces una búsqueda NCache lanzará una excepción que dice que este atributo no fue indexado. Entonces, de una manera más dolorosa, sí. Pero, lo que les decimos a nuestros clientes es que, independientemente de lo que intente buscar, debe crear un índice. Y, a diferencia de una base de datos donde todo es SQL, aquí no todo pasa por SQL. Nuevamente, está haciendo muchas cosas solo a través de la API y luego algunas de las cosas son a través de SQL.

¿Te refieres al nombre del caché? Existe una convención de que la clave debe tener la información de tipo y luego en función de cierto, digamos, si es un objeto individual y el tipo y el valor de la clave principal o el nombre del atributo de la clave principal y luego el valor, ese es el algo común y luego, si está guardando toda la colección, digamos, está guardando todos los demás pedidos para el cliente y luego puede querer buscarlo en función del cliente, entonces la clave puede ser cliente, ID de cliente, mis pedidos o algo así así, ya sabes. Por lo tanto, las claves deben ser significativas en función de cómo desea obtener los datos.

Sí, todas esas son opciones que puedes elegir. Si ve mi video de manejo de datos relacionales, analizo todas esas opciones. Y, de nuevo con el almacenamiento en caché, digamos que tiene una relación de muchos a muchos en la base de datos. No hay muchos a muchos en el nivel de aplicación. En la aplicación o te acercas desde este lado o desde este lado. Siempre es uno a muchos. Entonces, son cosas así que de repente la perspectiva cambia.

No está intentando recrear toda la base de datos en la memoria. ¿Puedes resumir los beneficios de usar un caché distribuido? Dijiste que era la escalabilidad. ¿Hay otros? Creo que el beneficio más importante es la escalabilidad. El beneficio secundario es el rendimiento y nuevamente para los casos de uso, para los casos de uso específicos de ASP.NET, las sesiones, hay un gran beneficio. Porque las alternativas a un caché distribuido son todas muy lentas o no escalables. Entonces, si haces un In-Proc, no es escalable. Porque tienes que ir al mismo proceso cada vez.

También estoy grabando esto y creo que también lo está la SDD Conf. Tendremos esta charla en YouTube y si viene a nuestro stand y nos permite escanearlo, podemos enviarle por correo electrónico el enlace a la charla y luego puede compartirlo con sus colegas. Muchas gracias chicos por su paciencia.

¿Qué hacer a continuación?

• NCache Detalles
• Descargar NCache
• Solicite una demostración EN VIVO personalizada