Campamento de Código de Ciudades Gemelas
Escalado de aplicaciones .NET con almacenamiento en caché distribuido
Por Iqbal Kan
Presidente y evangelista tecnológico
Vea esta demostración práctica de un caché distribuido y aprenda las mejores prácticas para usar un caché .NET en varios entornos. 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
Gracias a todos por venir. Mi nombre es Iqbal Kan. Es un hermoso día afuera. Estoy aquí desde Tampa. Entonces, mucho mejor temperatura aquí. Esperaba un clima mucho más fresco que el que tenemos aquí. Entonces, gracias por permanecer adentro. Soy un evangelista tecnológico en esta empresa llamada Alachisoft. Somos los creadores de NCache. Solo los próximos uno o dos minutos serán una declaración de marketing. Entonces, tenemos dos productos para el espacio .NET. Uno es nuestro principal producto estrella llamado NCache que es un caché distribuido para .NET. Esa es la experiencia que tenemos. Entonces, hemos estado en este espacio durante aproximadamente 10 años y así es como hemos desarrollado experiencia en este tema específico.
Tenemos otro producto llamado NosDB que es algo que lanzamos a fines del año pasado. es una fuente abierta NoSQL database para .NET. Es como las características de un nivel de MongoDB pero .NET nativo y nuevamente todo de código abierto. NCache también es de código abierto y, por lo tanto, NosDB. Por favor, eche un vistazo a nuestros productos.
Entonces, preferiría tener una discusión más interactiva. Vamos a pasar por una combinación de discusión conceptual arquitectónica y algo de código fuente. Entonces, podemos ver cómo usaría un caché para su aplicación. Entonces empecemos.
Escalabilidad
Vamos a sacar algunas definiciones del camino. El número uno es; que es escalabilidad La escalabilidad no es rendimiento. Por lo tanto, si su aplicación funciona rápido con 5 usuarios, no es escalable a menos que pueda tener el mismo buen rendimiento con 5000, 50,000 500,000 o 5 XNUMX usuarios. Por supuesto, si su aplicación no funciona rápido con XNUMX usuarios, entonces necesita mirar otros aspectos además de los que vamos a hablar.
Escalabilidad lineal
La escalabilidad lineal es más una terminología de arquitectura de implementación. Si su aplicación está diseñada de tal manera que puede agregar más servidores para incrementar su capacidad, su capacidad de transacción, por cierto, cuando uso la palabra escalabilidad, me refiero principalmente a la capacidad de transacción, no hablo de mucho. de datos. Entonces, no estamos hablando de terabytes de datos en términos de escalabilidad. Estamos hablando de si puede manejar muchas transacciones, mucha actividad. Entonces, una escalabilidad lineal significa que puede aumentar su capacidad de transacción simplemente agregando servidores y no hay cuellos de botella y eso es lo que queremos lograr.
Escalabilidad no lineal
No lineal, por supuesto, no es algo que queramos lograr. Esto significa que no importa cuántos servidores agregue, su rendimiento disminuirá después de cierto punto, porque hay un cuello de botella fundamental en la arquitectura de su aplicación en su implementación, que le impide escalar.
¿Qué aplicaciones necesitan escalabilidad?
¿Qué tipo de aplicaciones necesitan escalabilidad? Suelen ser aplicaciones de tipo servidor, ASP.NET, ASP.NET Core ahora, los servicios web, que suelen ser WCF, el backend de IoT, que suele ser servicios web, aunque no es necesario que lo sean. Grandes aplicaciones de procesamiento de datos. Por lo general, se realizan en Java, pero si lo hiciera en .NET, tendría el mismo problema que en Java y cualquier otra aplicación de servidor que necesite procesar muchas transacciones. Podría ser, por ejemplo, un banco o una empresa de servicios financieros con millones de clientes. Lo están llamando para cambiar la dirección, tal vez transferir fondos y por la noche tiene que procesar todo esto ya sea por cumplimiento o por otras razones de SLA. Entonces, a pesar de que tiene, ya sabe, esos son más procesamiento por lotes, procesamiento de back-end, esas son sus otras aplicaciones de servidor que aún necesitarán poder procesar tanta información y si no son capaces de hacerlo entonces, usted sabes, estás en un montón de problemas.
El problema de la escalabilidad
Si tiene estas aplicaciones, lo más probable es que necesiten escalabilidad. Entonces, hablemos ahora de dónde está este problema. ¿Dónde está el problema de escalabilidad que vamos a tratar de abordar? El problema de escalabilidad realmente no está en el nivel de la aplicación. Su aplicación, todas aquellas de las que hablé, generalmente están diseñadas de manera que puede agregar más servidores y no hay ningún problema. El problema es con su almacenamiento de datos. Lo que quiero decir con eso es dónde residen los datos de su aplicación, sus bases de datos relacionales. Esto podría ser servidor SQL, Oracle, MySQL. No es un proveedor específico. El concepto de bases de datos relacionales por diseño no puede escalar. En realidad, tampoco pueden escalar en términos de cantidad de datos. Es por eso NoSQL databaseLos s se han vuelto tan populares, pero, especialmente en el lado de las transacciones y lo mismo si tiene datos heredados de un mainframe. Muchas aplicaciones tienen que acceder a datos heredados. Entonces, ahí es donde ocurre el cuello de botella y, si tiene ese cuello de botella, entonces no importa si este nivel es escalable, no podrá escalar.
NoSQL databaseLos s se han vuelto populares precisamente por la razón de que brindan escalabilidad. Y, ya sabes, y también tenemos un NoSQL database producto, pero muchas veces no abordan el problema. No pueden abordar el problema porque, por una combinación de razones técnicas y comerciales, no puede usarlos. para usar un NoSQL database tienes que poner datos en ellos y no en tu base de datos relacional. Algunos datos que puedes hacer. Definitivamente puedes poner en el NoSQL database pero muchos de sus datos comerciales tradicionales permanecerán en bases de datos relacionales. Entonces, si no puede mover sus datos a NoSQL databases, no son buenos. Entonces, tienes que resolver este problema, teniendo en cuenta que vas a seguir viviendo con bases de datos relacionales, incluso si pones una NoSQL database en la mezcla, eso es solo un subconjunto de los datos. Por lo general, no es un reemplazo de las bases de datos relacionales. Y, siendo un NoSQL database empresa, ya sabes, estoy siendo muy honesto contigo, cuando hablamos con nuestros clientes, no les decimos que dejen de usar relacional, eso nunca va a suceder. Decimos, utilícelo como un aumento de relacional. Entonces, si tienes que quedarte con lo relacional, tienes que resolver ese problema, ya sabes, con eso en la mezcla y ahí es donde un caché distribuido entra en escena, es por eso que estamos teniendo esta conversación.
Implementación de caché distribuida (NCache)
Un caché distribuido, permítanme definir eso un poco. Se distribuye una memoria caché distribuida. Vive en dos o más servidores, aquí. Es un nivel de almacenamiento en caché separado, lógicamente hablando. Físicamente puede estar en el mismo cuadro que la aplicación, pero lógicamente es un nivel de almacenamiento en caché separado. Dos o más servidores y una memoria caché distribuida suelen formar un clúster. Por lo tanto, generalmente es un grupo de estos, los grupos basados en TCP son los más comunes. NCache definitivamente usa TCP para agrupar. Y este grupo significa que todos los recursos, todos estos servidores, la CPU, la memoria, las tarjetas de red, están todos agrupados. Y así es como esto se vuelve escalable. Porque puede agregar más servidores, ya que necesita aumentar la capacidad.
Esto es algo que puedes hacer aquí también. Pero, no se puede hacer aquí. Como dije, puede agregar otra base de datos SQL en la mezcla, pero, ya sabe, necesita tener esto en la imagen. Tan pronto como tenga esto en la imagen, necesitará algo como esto en su mezcla.
Un caché distribuido vive en servidores económicos. No se trata de configuraciones de servidor web típicas de base de datos de gama alta. La mayoría de nuestros clientes tienen una caja de 8 núcleos, es como si fuera una CPU dual, ahora solo usamos la palabra 8 núcleos y 64 bits con mucha memoria. Mucho significa que de 16 a 32 gigas es más o menos el promedio por servidor que vemos. Ni siquiera recomendamos más de 64 gigas en cada caja. Porque, si tiene más de 64 gigas de memoria, .NET requiere recolección de elementos no utilizados. El GC en sí mismo es una tarea que consume bastante tiempo y comienza a convertirse en un cuello de botella por sí mismo. Por lo tanto, es mejor tener más servidores que tener muy pocos servidores. Porque, ya sabes, aunque el caché se distribuye por diseño, ahora el cuello de botella comienza a convertirse en una recolección de basura. Y hemos aprendido esto a través de muchas experiencias dolorosas a lo largo de los años. Ya sabes, teníamos clientes que subieron a 128 gigas y de repente había mucha presión sobre la CPU. Entonces, tuvieron que aumentar bastante su poder de procesamiento y comenzó a parecerse más a una base de datos. Entonces, ya sabes, te recomendamos que lo bajes.
Almacena en caché los datos que residen en la base de datos. Y, el 80 % del tiempo básicamente irá al nivel de almacenamiento en caché, el 20 % del tiempo irá a la base de datos. La memoria caché es ultrarrápida en memoria, mucho más rápida que cualquier base de datos, incluida NoSQL database, incluso más rápido que el nuestro NoSQL database. NCache es al menos un orden de magnitud más rápido que cualquier base de datos. Porque, por el hecho de que, ya sabes, las bases de datos tienen que ir al disco. Pero, por supuesto, todas las actualizaciones tienen que ir a la base de datos real. Entonces, ahí es donde viene el 20% más, por supuesto, algunas de las lecturas.
Ahora, si hace eso, de repente se quita toda la presión de la base de datos. Ahora se realiza. Sus lecturas son mucho más rápidas y las actualizaciones también son mucho más rápidas. Entonces, puede lograr esa escalabilidad, pero también puede, no solo la aplicación es escalable ahora, sino que de repente es más rápida. Aunque, la razón principal para usar un caché no es para mejorar el rendimiento, lo que de nuevo es algo opuesto a lo que la gente ha pensado tradicionalmente, ya sabes, ese caché está ahí para mejorar el rendimiento. Eso es, en una situación independiente, sí, ese es el caso. Incluso las bases de datos utilizan el almacenamiento en caché en memoria. Nuestro NosDB también utiliza el almacenamiento en caché incorporado, pero en realidad es para la escalabilidad, donde debe poder hacerlo porque ese es un problema del que no puede salir. No se puede comprar hardware más caro para obtener escalabilidad. Tiene que diseñar la aplicación y usar la infraestructura correcta, o los componentes correctos como parte de su arquitectura, si va a tener una aplicación escalable.
En el lado de Java, esto se denomina cuadrícula de datos en memoria. En el lado de .NET se llama caché distribuida. Otra palabra para esto es en memoria NoSQL almacén de valores clave. Entonces, quiero decir que hay tres formas diferentes de verlo. Esto no es una NoSQL database es un NoSQL Almacén en memoria de valor clave. Porque, no hace ninguna persistencia, no tiene una tienda permanente.
Entonces, cuando tenga una imagen como esta, arquitectónicamente quiero que esté convencido de que ahora tendrá una aplicación que nunca tendrá cuellos de botella. Si diseña su aplicación para usar esto como para su infraestructura. Cualquier pregunta, hasta ahora antes de pasar a más profundidad.
Supongo que depende de los detalles, ¿cómo sabes si el caché está obsoleto o si actualizas algo fuera del caso? Déjame llegar a eso. Buena pregunta.
Usos comunes de la caché distribuida
Entonces, digamos que estamos convencidos de que necesitamos tener un caché distribuido como parte de la arquitectura de nuestra aplicación, la siguiente pregunta que viene a la mente es ¿cómo se usa? ¿Dónde usa el caché y cuáles son los problemas relacionados con cada tipo de uso? Entonces, como desarrollador de .NET, y nuevamente mi enfoque es .NET, pero los mismos conceptos también se aplican a otras aplicaciones.
Almacenamiento en caché de datos de aplicaciones
El caso de uso más común es el almacenamiento en caché de datos de la aplicación, de eso estaba hablando hasta ahora, donde tiene una base de datos y simplemente almacena datos en caché aquí. Entonces, el objetivo es no ir a la base de datos con tanta frecuencia. Y obtienes todos los beneficios de los que te hablé. Tan pronto como haces eso, ocurre un problema, que es de lo que acabas de hablar. Los datos ahora existen en dos lugares. Uno es el almacén maestro permanente, que es su base de datos, donde siempre debe y el segundo es el caché. Y, de hecho dentro del caché existe en más de un lugar y de eso también hablaré.
Entonces, cuando los datos existen en más de un lugar, ¿qué podría salir mal? Ya sabes, podría perder la sincronización. Entonces, si un caché distribuido no puede manejar esa situación, se ve obligado a almacenar en caché datos de solo lectura. De hecho, la mayoría de las personas, cuando piensan en el caché, la reacción instintiva es que es solo para datos de solo lectura. Porque, si guardo en caché datos que cambian, lo que llamo datos transaccionales. Entonces se desincronizará. Y, si sabes, que ese clásico problema de sacar dos veces un millón de dólares de la misma cuenta bancaria, llega aquí. Entonces, ya sabes, si un caché no soluciona este problema, estás limitado a un subconjunto muy pequeño. Alrededor del 10% al 15% de los datos es todo lo que puede almacenar en caché y eso no es suficiente. Entonces, un buen caché distribuido debe abordar este problema y hablaré sobre eso.
Almacenamiento en caché específico de ASP.NET
El segundo caso de uso es, si tiene una aplicación ASP.NET, hay tres cosas diferentes que puede almacenar en ella. Por supuesto, esto está cambiando a medida que surgen nuevos marcos. Entonces, el más común es el estado de la sesión ASP.NET, que está presente tanto en el ASP.NET core y el marco ASP tradicional. Las sesiones son algo que, de forma predeterminada, almacena In-Proc o las almacena en el servidor SQL. Ambos tienen problemas de escalabilidad. SQL también tiene problemas de rendimiento. Y debido a que las bases de datos relacionales no se diseñaron para almacenar blobs y las sesiones se almacenan como blobs. Y en segundo lugar, por la misma razón por la que querría almacenar en caché los datos de la aplicación y no ir a la base de datos, tampoco desea mantener sesiones en la base de datos. Por lo tanto, este es un caso de uso muy ideal para aplicaciones ASP.NET. Y, ya sabes, eso es lo primero que usa la mayoría de nuestros clientes. Ya sabes, si tienes una aplicación existente y quieres incorporar caché distribuida, el menor esfuerzo requerido para incorporarla son las sesiones. porque ASP.NET framework permite que se conecte un caché de terceros. No se necesita programación. Simplemente haga un cambio en web.config. De hecho, déjame mostrarte eso rápidamente. Voy a saltar de un lado a otro.
Entonces, por ejemplo, tengo esta pequeña aplicación ASP.NET y tengo un archivo web.config aquí y, por supuesto, voy a usar NCache como el ejemplo pero, digamos, para usar NCache como proveedor de estado de sesión, debe colocar estos ensamblajes. Entonces, etiqueta "agregar ensamblaje". Entonces, esta asamblea de NCache ha implementado la interfaz de proveedor de estado de sesión de ASP.NET.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<machineKey validationKey="A01D6E0D1A5D2A22E0854CA612FE5C5EC4AECF24" decryptionKey="ACD8EBF87C4C8937" validation="SHA1" />
<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>
<customErrors mode="RemoteOnly" />
<authentication mode="None" />
<authorization>
<allow users="*" />
</authorization>
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
<!-- For NCache Developer Edition replace 'myPartitionedCache' with 'myCache' or any other local-cache-->
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="1">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" exceptionsEnabled="true" enableSessionLocking="true" emptySessionWhenLocked="false" sessionLockingRetry="-1" sessionAppId="NCacheTest" useInProc="false" enableLogs="false" cacheName="myPartitionedCache" writeExceptionsToEventLog="false" AsyncSession="false" />
</providers>
</sessionState>
<!-- GLOBALIZATION
This section sets the globalization settings of the application.
-->
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<xhtmlConformance mode="Legacy" />
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />
</system.web>
<system.webServer>
<directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension, LongDate" />
</system.webServer>
</configuration>Entonces, así se está cumpliendo con el ASP.NET framework especificación para ser un caché de terceros. Entonces, eso es lo primero que haces y lo segundo es cambiar el espacio de nombres. En realidad, solo usas esta etiqueta. Por lo tanto, asegúrese de que el modo sea personalizado y que el tiempo de espera definitivamente no sea de un minuto. Deberían ser 20. Y volveré sobre esto. Ese es el nombre del caché.
En caso de NCache, todos los cachés tienen nombre. Volveré a esto. Entonces, eso es todo lo que hace y su aplicación comienza a almacenar las sesiones en un caché. Y verá inmediatamente un aumento en el rendimiento, porque está en la memoria, mucho más rápido que SQL. No más rápido que In-Proc pero más rápido que SQL pero más escalable en ambos casos.
El segundo caso de uso para ASP.NET es el estado de vista y es decir, si no está utilizando el marco MVC, si todavía está en ASP.NET heredado, tiene un estado de vista, que puede conocer o no. Un estado de vista, para aquellos de ustedes que no lo saben, es una cadena encriptada que el servidor web envía al navegador solo para regresar cuando hay una publicación. Entonces, esto podría llegar a cientos de kilobytes de tamaño. Multiplique eso por millones de solicitudes que su aplicación tiene que procesar y hay dos cosas malas que están sucediendo, una está consumiendo mucho ancho de banda y el ancho de banda no es gratuito. Cuando aloja su aplicación, tiene que pagar por el ancho de banda. En segundo lugar, el tiempo de respuesta es más lento porque es una carga útil mucho más pesada. Por lo tanto, si pudiera almacenar en caché eso en un extremo del servidor, simplemente eliminaría todo eso y haría que la aplicación fuera más rápida.
El caché de salida es un asp.NET framework lo que le permite almacenar en caché la salida de la página, de modo que, si la salida de la página no cambia, simplemente la tomará de la última ejecución. Entonces, nuevamente, es mejor conectar un caché distribuido en una granja web que mantener copias separadas de ese caché de salida en cada servidor web. Lo que realmente quiere hacer es hacer que estos servidores web sean totalmente apátridas desde la perspectiva de la administración de aplicaciones. Si no tienen estado, puede hacer todos los parches, puede, ya sabe, todas las correcciones de errores, cualquier actualización de su aplicación, son mucho más frecuentes que cualquier actualización del caché en términos de actualizaciones de software. Por lo tanto, si no se mantiene ningún estado aquí, puede eliminar cualquiera de esos cuadros de la granja de servidores web, el usuario ni siquiera lo notará. Porque, todo el estado se mantiene aquí o en la base de datos y, de nuevo, no es algo que toque con tanta frecuencia, así que, de nuevo, almacene eso en caché.
Ahora, en el caso del almacenamiento en caché específico de ASP.NET, hay una cosa buena que todo esto no requiere programación. Entonces, simplemente conéctelos inmediatamente sin ningún esfuerzo. Lo único que haces, por supuesto, es algunas pruebas de cordura. Por ejemplo, el estado de sesión de ASP.NET, si lo conecta y estaba usando sesiones In-Proc, podría descubrir que no todos sus objetos son serializables. Y, no lo sabía y de repente su aplicación comenzará a generar excepciones. Entonces, quiero decir, ya sabes, ese nivel de prueba que necesitas hacer. Pero, ahora hay otro problema peculiar, a diferencia de este donde tienes dos copias de los datos, ahora los datos existen solo en el caché.
Entonces, cuando una tienda en memoria es su tienda maestra, ¿qué podría salir mal? La máquina se cae. Sí, ya sabes, si algún servidor se cae, pierdes datos y no quieres perder ninguno de estos datos, especialmente las sesiones. Por lo tanto, un buen caché distribuido debe abordar esto y esto generalmente se hace a través de la replicación de que los mismos datos existen al menos en dos lugares y si eso no sucede, no coloque ninguna sesión en ese caché, a menos que no lo haga. en realidad no es... no importa si sus usuarios utilizan esta sesión, que no es el caso en la mayoría de las situaciones.
Intercambio de datos en tiempo de ejecución
El tercer caso de uso es uso compartido de datos en tiempo de ejecución a través de eventos. Esto es algo que normalmente la gente hacía con las colas de mensajes, que saben, tienen su propio lugar y un caché distribuido no está aquí para reemplazarlos, pero un caché distribuido es mucho más rápido, más escalable y si los mensajes o si hay intercambio de datos es se está haciendo en la misma ubicación, en el mismo centro de datos, entonces puede usar un caché distribuido en un Pub / Sub manera, usted puede hacer eso. También hay otros tipos de eventos en los que puedes, ya sabes, mostrar interés en ciertos artículos. Diga, si este artículo cambia, por favor notifíqueme. O en caso de NCache hay una función llamada consulta continua donde también podría hacer una declaración SQL y decir, 'SELECCIONE CLIENTES DONDE CLIENTE.CIUDAD = NUEVA YORK'. Si este conjunto de datos se actualiza o elimina alguna vez, o si se agrega, actualiza o elimina un nuevo objeto, notifíquemelo. Entonces, si ese tipo de monitoreo que la aplicación puede hacer y así es como los consumidores pueden ser mucho más inteligentes sobre qué es lo que quieren que se les notifique. Y los productores pueden seguir actualizando el caché.
Entonces, ese es el tercer caso de uso que mucha gente no conoce, pero ahora se está volviendo cada vez más obvio que el caché es un muy buen lugar para hacer esto. Porque ya estás usando el caché por estas dos razones. Entonces, ¿por qué no poner esto? Es muy fácil de incorporar en su aplicación. ¿Alguna pregunta, antes de entrar en los detalles de estos?
De demostración
Entonces, primero les mostraré cómo se ve un caché. Entonces, podemos poner eso en el contexto de todo lo que estamos hablando. usaré NCache como el ejemplo. Entonces, tengo un montón de máquinas virtuales en Azure. Entonces, tengo un demo1, demo2 y un cliente de demostración. Demo1 y Demo2 son mis máquinas virtuales de servidor de caché. El cliente de demostración es la caja del servidor de aplicaciones. Entonces, ese es el cliente de caché. Entonces, tengo todo eso.
Voy a ir e iniciar sesión, digamos, iniciar sesión en el cliente de demostración. Voy a seguir adelante y crear un caché. Entonces, voy a usar NCache gerente, la herramienta gráfica. Seguiré adelante y diré 'Crear un nuevo caché de clúster'.
En caso de NCache, todos los cachés tienen nombre. No voy a explicar todos los detalles. Le daré un nombre a cada caché.
Elegiré una topología del caché. topología es en realidad una estrategia de almacenamiento y replicación. Entonces, una topología, en el caso de NCache, digamos, hay una topología llamada réplica de partición. Entonces, estos dos son servidores de caché aquí y cada servidor tiene una partición. Entonces, digamos en el caso de NCache, NCache crea una partición para cada servidor y cada servidor contiene una réplica de la partición de otro servidor. Cada partición contiene una enésima parte del número total de cubos. En caso de NCache hay 1000 cubos por caché.
Entonces, digamos, si es un clúster de dos nodos, son los 500 cubos cada uno, si es un clúster de tres nodos, es un tercio, un tercio, un tercio.
Réplica de partición, las particiones están activas, las réplicas no están activas, son pasivas. Entonces, el cliente solo habla con las particiones y digamos que si un cliente va y actualiza un elemento aquí, la partición continúa y lo replica en la réplica y esa replicación es asíncrona de manera predeterminada. Porque, para obtener una verdadera escalabilidad, debe ir a este modelo de consistencia eventual. Pero, en algunos casos, sus datos son muy sensibles. Sabes, tienes muchas compañías de servicios financieros como bancos que usan NCache y sus datos son en realidad dinero. Entonces, no pueden hacer consistencia eventual en ese caso. Entonces, ahí tienes que hacer replicación síncrona, lo que significa que la aplicación espera hasta que los datos se actualicen en ambos lugares. Si un servidor se cae, digamos, si tenía un clúster de tres nodos y el servidor 3 se cayó, la partición 3 está caída, la réplica 3 se activará de inmediato.
Entonces, así es como obtiene la alta disponibilidad y ahora, una vez que esté activo, se dará cuenta de que solo hay dos servidores y luego tres particiones, lo cual no es como debería ser. Por lo tanto, se fusionará con la partición 1 y 2 y, una vez hecho esto, se creará aquí una réplica para la partición 2.
Todo eso en caso de NCache se realiza en tiempo de ejecución sin que su aplicación se dé cuenta de lo que está sucediendo. De manera similar, podría tener un clúster de 2 nodos y agregar un tercer servidor y nuevamente todo el mapa cambiará de aquí a aquí automáticamente. Entonces, eso es lo que significaba esa elección.
Entonces, solo voy a elegir réplica de partición como la topología.
Mantendré la replicación asíncrona.
Elegiré mi primer servidor, que es la demostración 1, el segundo servidor, que es la demostración 2.
Tomaré todos los valores predeterminados. Voy a especificar, diré, es solo 1 Giga, voy a especificar el tamaño de la partición.
En su caso, si tiene una máquina de 16 Gigas, debe dejar alrededor de 2 a 2.5 Gigas para el sistema operativo y otros procesos y consumir todo lo demás para el caché y cualquiera que sea la memoria que le quede, la mitad debe ser partición activa, la mitad de ella es para la réplica.
Cuando está haciendo su planificación de capacidad, es muy importante que asigne suficiente memoria para que, en el caso de las sesiones, las sesiones tengan suficientes memorias para permanecer; de lo contrario, cuando la memoria caché haya consumido toda esta memoria, entonces la memoria caché se considerará llena y, entonces solo sucederá una de dos cosas, o bien la memoria caché rechazará cualquier entrada nueva o expulsará algunas de las entradas existentes. NCache le proporciona tres algoritmo. Ya sabes, el más común es el menos utilizado recientemente.
¿Entonces NCache expulsará inmediatamente el 5% del caché, cuando el caché se considere lleno. Entonces, ahora que he creado esto, continuaré y agregaré un nodo de cliente que en este caso es un cliente de demostración y continuaré y diré iniciar el caché.
Entonces, cuando estoy iniciando el caché, suceden muchas cosas detrás de escena. Se está formando un nuevo grupo. Se está formando la pertenencia al clúster que se está propagando al cliente. Entonces, ¿que el cliente sepa cuál es la membresía del clúster? ¿Qué es el mapa de distribución? Entonces, una vez que todo eso está hecho, entonces todo está listo. Entonces, ahora voy a decir estadísticas. Quiero ver algo de PerfMon. Y quiero ejecutar rápidamente esta herramienta llamada herramienta de prueba de estrés, que se ejecuta rápidamente. Rápidamente prueba el caché en su entorno.
Entonces, de esa manera no tienes que hacer ninguna programación para hacer esto. Entonces, así es como se ve el caché. Instalarás algo como esto. Digamos que instalas NCache. Solo se necesita este tiempo para obtener un clúster de 2 nodos con un servidor de aplicaciones configurado. En tu caso tendrás más de un cliente por supuesto. La configuración más común es de 5 a 8 clientes y un clúster de caché de 2 a 3 nodos. Y luego, ya sabes, a medida que agregas más clientes, agregas más servidores.
Entonces, ahora que tiene este caché en ejecución, ahora volvamos a nuestros temas reales. Entonces, ahora todo lo que hacemos, debe tener en cuenta cómo creamos este caché con nombre. Y ya le mostré el estado de sesión específico de ASP.NET.
Descripción general del almacenamiento en caché de datos de aplicaciones (API)
Entonces, ahora entremos en el almacenamiento en caché de datos de la aplicación, que es la riqueza de mi charla de hoy. Entonces, en el caso de un almacenamiento en caché de datos de la aplicación, hay una API que debe programar. porque ASP.NET core ahora tiene una interfaz llamada IDistributed Cache a la que puede llamar esa API y luego, en segundo plano, puede conectar una caché de terceros. Por el lado de Java tienen como estándar una API muy potente llamada JCache, pero por el lado de .NET no hay nada. Por lo tanto, en la mayoría de los casos, necesitará programar la propia API de caché. Pero, la API es muy sencilla.
- Conexión de caché
ICache cache = CacheManager.GetCache("myCache"); cache.Dispose(); - Recuperacion de datos
Employee employee = cache.Get<Employee>("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); Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
En caso de NCache esto se parece mucho al objeto de caché de ASP.NET, si se da cuenta. Entonces, lo que estás haciendo básicamente es hacer un caché. Obtener, obtienes el objeto, ya sabes, agregar, insertar, eliminar o también hay versiones asíncronas del mismo. Asíncrono significa que no espere a que se actualice la memoria caché simplemente, ya sabe, devuelva el control y puede especificar la devolución de llamada en ese caso.
Permítame mostrarle rápidamente cómo es una aplicación. Entonces, tengo esta aplicación de consola muy simple que usa NCache.
using System;
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.sample.data;
namespace BasicOperations
{
public class BasicOperations
{
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...
Por lo tanto, lo primero que debe hacer es asegurarse de hacer referencia a los ensamblajes de caché que, en caso de NCache son dos. Hay NCache.Tiempo de ejecución, NCache.Web y luego necesita usar los espacios de nombres que nuevamente son dos en caso de NCache. NCache.Tiempo de ejecución, NCache.Web.caching. Y, luego, al comienzo de su aplicación, que en el caso de la consola está justo ahí. En el caso de la aplicación ASP.NET, esta es probablemente su global.asax. Necesitas conectarte al caché y aquí es donde entra el nombre de tu caché, cualquiera que sea el nombre que le hayas dado a tu caché. Eso es lo que entra aquí. Y, ahora que tiene un identificador de caché, puede continuar con la aplicación, puede crear sus objetos y puede hacer caché.Agregar. Usted especifica una clave basada en cadenas y la clave tiene que ser única. Por cierto, esta no es una buena clave. Su clave debe ser mucho más específica y aquí está su objeto. Y, quiero decir, así es como y luego puedes hacer caché.Obtener y puede obtener su objeto del caché.
Ahora, esta llamada que hiciste en realidad resultó en el caso de NCache, entonces, cuando lo hiciste caché.Agregar, básicamente fue, desde aquí fue a la partición en la que se suponía que iban a entrar los datos. Entonces, hizo caché. Agregue allí y esta partición luego replicó esos datos en su réplica. Si se trataba de una aplicación asincrónica, solo se actualizaba esta partición y se recuperaba el control. Si realizó una llamada asíncrona, incluso esta partición e incluso ni siquiera esperó a que se actualizara la partición. Pero solo ese caché.Agregar llamada dio como resultado que todo este trabajo se hiciera.
Y, de manera similar, cuando haces un caché.Obtener el cliente va directamente donde están los datos. Por lo tanto, utiliza el mapa de distribución debajo para saber dónde están los datos y va directamente a dónde los obtiene. Digamos que si quisieras el artículo número 3, irías a buscarlo directamente desde allí.
Entonces, este código está detrás de escena, eso es lo que realmente está sucediendo. A la base de datos. Cual es tu. Es solo el caché. En realidad, hablaré de eso en un momento también. Entonces, ¿serializó / deserializó automáticamente los datos? Sí, de hecho, incluso más que eso. Entonces, antes de que los datos se envíen de aquí a aquí, el objeto debe serializarse. En caso de NCache, NCache lo mantiene en forma serializada, en el caché. Y, cuando haces un caché. Obtenerlo regresa y luego se deserializa en el propio cliente. Y, para cuando lo obtienes, todo está deserializado. Por lo tanto, la API parece muy sencilla para usted, pero hay mucho trabajo por hacer.
Funciones de almacenamiento en caché de datos de la aplicación
Ahora, sobre el almacenamiento en caché de datos de la aplicación, la mayor preocupación era que los datos existen en dos lugares, ¿verdad? Y, si un caché no aborda esa preocupación, realmente limitará su beneficio. Entonces, ¿cómo aborda un caché esa preocupación?
Vencimientos absolutos
El numero uno se llama Expiraciones y esta el Caducidad absoluta lo que significa que expira este objeto, digamos dentro de 10 minutos. Entonces, lo convierte en una suposición informada para cada objeto en términos de cuánto tiempo es seguro mantener ese objeto en el caché. Y, al final de ese tiempo, el caché elimina automáticamente ese objeto.
Déjame mostrarte cómo se ve eso en el código. Entonces, en caso de NCache si observa la misma llamada cache.Add, el tercer argumento es un argumento de fecha y hora que tiene el valor de un minuto a partir de ahora.
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...Entonces, básicamente le está diciendo al caché que caduque este objeto dentro de un minuto. No importa si lo necesita o no, después de un minuto, ese objeto se eliminará del caché. ¿Por qué? Porque no te sientes cómodo manteniéndolo en el caché más de un minuto. Y, ¿por qué no te sientes cómodo? Porque crees que va a cambiar en la base de datos. No es seguro mantenerlo en el caché.
Vencimientos deslizantes
Hay otro tipo de vencimiento llamado Caducidad móvil, que tiene un propósito totalmente diferente. No es para mantener el caché fresco, es más para la limpieza. Entonces, en el caso de sesiones, por ejemplo, NCache usa una caducidad deslizante, que dice básicamente, especificas un intervalo y dices 10 minutos, 20 minutos, 5 minutos, dices. Entonces, durante ese tiempo si nadie toca ese objeto NCache elimina ese elemento del caché.
Entonces, el vencimiento deslizante, aunque el nombre todavía es vencimiento, tiene un propósito totalmente diferente. Es la caducidad absoluta que necesita para el almacenamiento en caché de datos de la aplicación para mantener el caché actualizado. Casi todos los cachés tienen la caducidad absoluta. Incluido Redis, todo el mundo lo tiene.
Sincronizar caché con base de datos
Pero, el problema con la caducidad absoluta es que solo estás haciendo una conjetura. ¿Qué pasa si esa suposición es incorrecta y los datos realmente cambian en la base de datos? Entonces, ¿qué sucede? Tenemos que idear un mecanismo. Entonces, ya sabes, si tienes la capacidad de sincronizar la caché con la base de datos donde puede decirle a la memoria caché que supervise la base de datos en busca de cambios para este conjunto de datos muy específico, sea lo que sea.
NCache, por ejemplo, utiliza esta característica de dependencia de caché SQL de ADO.NET. Donde, si especifica, si usa esta función, déjeme mostrarle cómo se usa. Si utiliza esta función, entonces NCache monitorea la base de datos y le pide a la base de datos que notifique NCache cuando esos datos cambian. Entonces, digamos, tengo el ejemplo de dependencia de SQL. Entonces, nuevamente estoy haciendo el mismo caché. Agregar, aquí. Entonces, estoy haciendo el mismo caché. Agregar. Tengo una llave. Ahora, en lugar de tener el objeto, tengo un elemento de caché que es una estructura que contiene el objeto real y algunas otras cosas. Entonces, por ejemplo, contiene una declaración SQL de una sola fila en la tabla de productos. Dado que estoy almacenando en caché un producto en una base de datos Northwind, esta instrucción SQL, NCache luego úsalo.
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);
}Entonces, hay un SQLCacheDependency clase en NCache que es nuestra propia clase, pero detrás de escena luego se asigna a la dependencia de caché de ADO.NET SQL. Ahora, está haciendo esta llamada en la realidad y entonces, está haciendo la llamada, necesita llamar aquí. Y esa llamada llega a los servidores de caché y el servidor de caché ahora realiza la llamada ADO.NET contra la base de datos de su servidor SQL. Y, ahora el servidor de caché se convierte en un cliente de su base de datos. Y, le dice a la base de datos, dice, por favor notifíqueme si este conjunto de datos cambia.
Y, el servidor SQL tiene el tipo de mecanismo de notificación de base de datos de oráculo. Al menos contra estas dos bases de datos puede usar esta característica. Y, la dependencia de caché de SQL le permite esencialmente asegurarse de que si no puede adivinarlo, puede estar seguro de que sus datos se mantendrán consistentes con la base de datos.
¿Alguna pregunta sobre esto? Por lo tanto, tiene componentes del marco. Asi que, NCache también tiene un complemento para EF, EF6 y ahora también EF Core, hasta EF Core. Antes de EF Core, EF realmente no tenía una arquitectura conectable. Por lo tanto, tuvimos que implementar un proveedor ADO.NET personalizado y almacenar en caché las consultas SQL.
SQL Core es una arquitectura mucho más flexible. Entonces, ahora podemos proporcionar un caché L2. NHibernate, que es algo que existe desde hace mucho tiempo. NHibernate ha tenido esa arquitectura durante mucho tiempo. NCache proporcionó el caché L2 para NHibernate y también para Hibernate para el cliente Java. Pero, ahora EF Core tiene esa arquitectura. Entonces, el beneficio de EF Core es que no tiene que hacer estas llamadas. La desventaja es, por supuesto, que es un subconjunto muy pequeño del caché que usa, en términos de características. Porque todas estas otras cosas, por ejemplo, la parte de dependencia de SQL es algo que NCache proporciona y puede configurar eso a través de los archivos de configuración, pero también muchas otras características de las que hablaré que necesita usar, que si solo pasa por una arquitectura conectable, tienen que pasar por el enfoque del mínimo común denominador. Por lo tanto, su API, independientemente de lo que usen, no puede usar muchas de las funciones sofisticadas, pero ahora todos los cachés las proporcionan. Entonces, y deben ser flexibles para todos. Mientras que, si desea beneficiarse, por ejemplo, del lado de Java, casi todos los cachés tienen todas estas características de las que estoy hablando. En el lado de .NET, casi ninguno de ellos tiene otra cosa que NCache. Entonces, no es realmente un NCacheLo importante es el hecho de que, ya sabes, .NET no es tan avanzado o maduro como la comunidad de Java en el uso de estas mejores prácticas. Entonces, cada vez es más. El hecho de que ahora .NET Core ha pasado por un cambio tan grande, es una buena indicación de cómo van a mejorar las cosas.
Pero, a día de hoy, si quieres mantener la caché sincronizada con los vencimientos de la base de datos no es suficiente. Tienes que ir más allá de los vencimientos. Tienes que sincronizar el caché con la base de datos. Y, si la base de datos no admite notificaciones, puede repasar el enfoque de sondeo, que es algo que NCache ha implementado.
Hay un tercer enfoque que consiste en que puede usar un procedimiento almacenado CLR para agregar directamente los datos de la base de datos al caché. Entonces, al igual que estás invirtiendo todo el paradigma. Ahora, la base de datos está alimentando el caché. Entonces, ya sabes, por ejemplo, tienes un activador que puede hacer que... Voy a acelerar, de lo contrario no podré completar todos los temas. Por lo tanto, esta es una característica muy importante sin la cual realmente no puede beneficiarse y también puede sincronizar el caché con fuentes de datos no relacionales. Por ejemplo, en caso de NCache hay una característica de dependencia personalizada que es su código que puede hacer llamadas. Digamos que sus fuentes de datos son una nube y es un método web llamado cada vez, para saber realmente cuáles son los datos. Entonces nada de eso funciona y esta dependencia personalizada es algo que funciona. Entonces, la dependencia personalizada es su código que vive en el caché y es llamado por el caché para verificar la fuente de datos.
Entonces, una vez que haya logrado este objetivo, puede comenzar a almacenar en caché más y más datos y realmente beneficiarse. Dependencia de DB, porque estoy trabajando con el mainframe en este momento, la dependencia de SQL o la dependencia de Oracle no funciona. Entonces, con qué frecuencia debería ser una encuesta, porque estoy trabajando con datos de producción con transacciones de varios millones de registros en un minuto. Entonces, con qué frecuencia. Entonces, ¿cómo lo sabes, con qué frecuencia lo encuestas? El sondeo es un intervalo configurable y es su código el que será llamado. Entonces, luego determina en cada encuesta, cuántos datos va a ver. Porque, en el caso de una dependencia personalizada, realmente irá y verificará una clave específica y verá si esa clave se actualizó en su mainframe heredado o no. Entonces, es básicamente para cada tecla cuando dice que está bien, verifique esta tecla, verifique esta tecla. En caso de dependencia personalizada. En el caso de la dependencia de la base de datos, no es una clave, es el conjunto de datos completo y tenemos otra función en NCache llamado actualizador de datos. Hay un cargador de caché, es un actualizador de caché que es otro servicio donde vive su código. Entonces, hay una característica llamada cargador de caché en NCache, que en realidad no mencioné todas esas funciones aquí, pero hay una función llamada cargador de caché que es su código que puede, cuando inicia el caché, puede ir y cargar el caché, precargar el caché desde su fuente de datos. Entonces, ese podría ser su mainframe. Pero, también hay una función llamada actualizador de caché que llama automáticamente a su código cada intervalo configurable y ese código puede ir y verificar toda la fuente de datos y buscar actualizaciones basadas en su lógica personalizada y cualquier dato que haya cambiado o cualquier dato nuevo que haya. ocurrió o cualquier dato que se eliminó, eso es algo que también puede actualizar el caché. Entonces, el caché permanece sincronizado con su fuente de datos. De forma predeterminada, se llaman a intervalos de aproximadamente 15 segundos. Pero, puede ser más rápido. Puede ser más frecuente o puede ser menos frecuente, eso depende de tus necesidades. ¿Respondí tu pregunta? Tengo más, pero me saltearé eso. Podemos hablar de eso más adelante.
Lectura y escritura simultánea
Entonces, una vez que logre ese objetivo, comenzará a almacenar en caché más y más datos. Luego, lo siguiente es, bien, ahora que tienes, ¿qué otros beneficios puedes lograr? La siguiente cosa más importante es la lectura directa, escritura directa. ¿Qué es la lectura? Es nuevamente su código el que se encuentra en el servidor de caché. Entonces, cuando haces un caché. Obtener, digamos, una lectura completa es tu código, en caso de NCache implementas esta interfaz llamada IReadThruProvider. Tiene tres métodos.
...
// 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;
}
...Hay un Init que se llama cuando se inicia el caché, se elimina cuando se detiene el caché, pero lo más importante es esta carga. Entonces, la carga se llama pasa. Entonces, el caché te llama este método. NCache llama a este método y pasa su clave. Y, en función de esa clave, va a su base de datos y obtiene ese elemento. Entonces, cuando hace eso ahora, el efecto neto para el cliente, la aplicación es, cada vez que hace una caché.Obtener, el caché siempre tiene los datos. Por supuesto, si no desea que se llame a la lectura directa, también puede hacerlo, puede tener detalles. Pero, el caché siempre tiene los datos. Entonces, ese es un beneficio. Entonces, está consolidando su capa de persistencia en un nivel de almacenamiento en caché. Entonces, si tiene varias aplicaciones que usan el mismo nivel de almacenamiento en caché, la aplicación se vuelve más simple porque no tienen que mantener el mismo código de persistencia. solo hacen un caché.Obtener y obtienen el objeto de dominio o el objeto de entidad del caché. Entonces, el caché se parece mucho más a un EF ahora. La lectura completa en sí puede estar basada en EF.
La otra cosa que puede hacer con la lectura es que puede combinar esto con vencimientos y sincronización de bases de datos. Entonces, cuando suceden esas dos cosas en lugar de eliminar esos datos del caché, ¿por qué no volver a cargarlos? Porque, cuando lo elimine, la aplicación tendrá que volver a cargarlo de todos modos, la próxima vez que lo desee. Y, en muchos casos, esos datos pueden usarse con mucha frecuencia. Entonces, realmente desea volver a cargarlo en el caché. Por lo tanto, una lectura completa no solo consolida el código, sino que también mejora su rendimiento porque su base de datos no se ve afectada. En muchas de las situaciones de comercio electrónico, se puede acceder a los mismos datos con tanta frecuencia que tan pronto como los elimine del caché, miles de solicitudes llegarán a la base de datos para obtener los mismos datos y hemos visto a los clientes quejarse de eso. Eso sigue sucediendo con tanta frecuencia porque hay millones de elementos de datos, ya que cada elemento de datos caduca, la base de datos se ve afectada. Entonces, en general, incluso después de tener el caché, estaban viendo muchos resultados en la base de datos. Entonces, la respuesta a eso fue recargar en lugar de caducar. Entonces, la recarga significa que los datos nunca salen del caché, solo se actualizan. Por lo tanto, la base de datos nunca se toca, excepto por una llamada a la base de datos que realiza el caché. Por lo tanto, la lectura completa es muy importante en ese sentido.
El otro es el de escritura simultánea, que funciona igual que la lectura simultánea, excepto que se encarga de la escritura. Y, la escritura significa que puede agregarse, actualizarse o eliminarse. Ahora, la escritura tiene otra característica. Una de las ventajas de la escritura simultánea es la misma que la de la lectura simultánea, que es la consolidación del código.
escribir detrás
El segundo beneficio se llama escritura posterior. Ya sabes, las actualizaciones de la base de datos, al igual que las lecturas de la base de datos, no son rápidas. Las actualizaciones de la base de datos tampoco son rápidas. Por lo tanto, si sus datos no son tan confidenciales, si no es algo que deba esperar a que se actualice la base de datos, simplemente puede actualizar el caché. Entonces, todas las instancias de la aplicación tienen los mismos datos ahora y permiten que el caché actualice los datos en la base de datos de manera asíncrona. Y, de repente, el rendimiento de su aplicación mejora porque no está esperando que se actualice el caché. Por lo tanto, la escritura posterior tiene este beneficio adicional. Entonces, construye la cola. En caso de NCache esa cola se replica en varios servidores, pero nuevamente la función de lectura y escritura es muy importante. Y esto también es algo que es su código que vive en el servidor de caché.
Quiero que tenga esto en cuenta todo este cargador de caché, el actualizador, la dependencia personalizada, la lectura, la escritura, todo lo que es código de servidor que vive en él. Lo cual es algo que... de nuevo, estas características también existen en el lado de Java. Entonces, no es solo algo que NCache inventado, pero no obtendrá estas características en ninguna de las otras cachés básicas de .NET.
Entonces, una vez que comienza, una vez que tiene todo esto, una vez que hace esto, ahora pone una gran cantidad de datos en el caché. Realmente empezando a beneficiarse. Y, si un caché es solo acceso de valor clave, ya sabes, no es muy, muy amigable. Por lo tanto, un caché debe adaptarse a formas amigables de obtener datos.
Agrupación de datos
Entonces, en caso de NCache hay muchos datos que puedes hacer grupo y subgrupo, etiquetas, etiquetas de nombre. También puede buscar en base a SQL o LINQ. Entonces, puedes hacer algo como, 'SELECCIONE CLIENTES DONDE CLIENTE.CIUDAD = NUEVA YORK'. Y, ahora, de repente, muchos de sus conjuntos de datos, especialmente los datos de referencia que necesita leer una y otra vez de una manera más filtrada, puede obtenerlos directamente del caché. Y, ahora tiene el beneficio de que los datos que desea hacer.
Una cosa tenga en cuenta, cada vez que realiza una búsqueda SQL, el conjunto de datos completo debe existir en el caché. Porque esto no irá a la base de datos. Por lo tanto, solo buscará en el caché. Digamos, si dijiste dame todos los clientes basados en Nueva York. Si todos los clientes no están en el caché, si todos los clientes de Nueva York no están en el caché, el NCache o cualquier caché no le devolverá el conjunto de datos correcto. Entonces, es importante tener en cuenta que la gente a menudo confunde eso bien si busco, si espero, si no está en el caché, iremos y lo obtendremos de la base de datos. Pero, las consultas SQL no son las consultas SQL de la base de datos. Estas son consultas propias de la memoria caché.
Ahora una gran cantidad de datos, puede mantener todo el conjunto de datos en el caché, especialmente los datos de referencia y ahí es donde los usaría. Pero, al menos también dentro de los datos transaccionales, hay subconjuntos que se pueden mantener por completo en el caché. Entonces, así es como esperas. Entonces, al tener todo eso en cuenta, ahora está comenzando a beneficiarse del caché.
Caché de cliente
Voy a entrar en una cosa más que es esta característica llamada Caché de cliente. Una de las cosas que más sorprenden a las personas cuando comienzan a usar un caché distribuido es que, si antes usaban un caché In-Proc, que es independiente, su rendimiento en realidad disminuye. Entonces, muchos clientes nos llaman y dicen, ya sabes, estabas diciendo esto, el rendimiento aumentará, la escalabilidad mejorará, nuestro rendimiento en realidad disminuyó. Y la razón es que inicialmente solo tenían un caché independiente. Tenía un tamaño limitado, pero el caché estaba en forma de objeto, los objetos se mantuvieron en su montón y ahora tienen que ir a un clúster de caché, hay una serialización, una deserialización, hubo un viaje de red, es mucho más lento.
Entonces, para trabajar para solucionar ese problema, muchos de los cachés, nuevamente uso la palabra muchos porque todos los cachés del lado de Java lo tienen, el lado .NET NCache lo tiene Tienen esta función llamada caché de cliente. En el lado de Java se llama caché cercano. Esta es la misma memoria caché independiente que tenía anteriormente, los mismos medios son similares, pero ahora es consciente del hecho de que es parte de esta memoria caché agrupada. Por lo tanto, cualquier dato que conserve, se mantendrá sincronizado con el clúster de caché. Entonces, simplemente se conecta sin que usted haga ninguna programación.
Entonces, con la ayuda de un caché de cliente, puede lograr ese rendimiento de caché independiente In-Proc y es realmente bueno para muchos de los datos en los que está haciendo muchas más lecturas que escrituras. No querrás usar esto para algo como sesiones. Porque, en las sesiones, haces una lectura y una escritura. Por lo tanto, debe hacer muchas más lecturas que escrituras para beneficiarse.
Clúster de caché dinámica
Entonces, desde el punto de vista arquitectónico, ya sabes, debes ver que el caché es como la base de datos ahora. Vive en su centro de datos, su entorno de producción y si su aplicación tiene una necesidad de alta disponibilidad, entonces el caché también debe ser de alta disponibilidad, de lo contrario, tiene un problema. Y, la única forma de hacerlo es si el caché garantiza que tiene un tiempo de actividad del 100 %. Entonces, un buen caché, en caso de NCache que tiene una clúster de caché dinámico. Es una arquitectura peer-to-peer. Puede agregar o eliminar cualquier servidor y todo está bien, nada se detiene. El caché no se detiene, la aplicación no se detiene.
Escalabilidad lineal con replicación
Hablamos de la partición y luego de la topologías ya. La replicación tiene que hacerse de manera inteligente. Entonces, en el caso de la réplica de la partición, solo hace una copia. Entonces, los datos existen solo en dos lugares y no más de dos porque cada vez que haces copias cuesta más tiempo o esfuerzo. Ralentiza las cosas.
Replicación WAN de caché distribuida
También hay una característica llamada Replicación WAN. Mucha gente tiene múltiples centros de datos ahora. Si espera que su base de datos pueda manejar múltiples centros de datos, ¿por qué no el caché? Esta es una característica que la mayoría de los cachés de Java tienen, NCache también lo tiene pero solo en el lado .NET.
NCache vs Redis
Rápidamente, una última cosa, ya que, en el lado de .NET, en realidad solo hay dos opciones. Uno es NCache, uno es Redis. Redis en realidad es más de un caché basado en Linux pero, desde que Microsoft se asoció con ellos en Azure, sin duda, ya sabes, se han vuelto mucho más populares. Entonces, quería dar una comparación justa.
Por cierto, si solo visita nuestro sitio web y va a la página de comparaciones e ir a comparación detallada característica por característica basado en su documentación y nuestra documentación y ver todas las cosas. Y, esto no es un, ya sabes, no estamos escupiendo esto en absoluto y puedes ser un buen juez de eso tú mismo. Es solo para hacer que su trabajo sea más fácil de preparar.
Pero, ambos son de código abierto, pero NCache es .NET nativo para personas de .NET, ya sabes, toda tu pila es .NET. NCache le permite tener código .NET en el lado del servidor que no puede hacer con Redis. Y, ya sabes, si estás en Azure, Redis está disponible solo como un caché como servicio, mientras que, intencionalmente, no hemos elegido ese modelo. Porque, en caché como servicio, el caché es una caja negra. Por lo tanto, no tiene ninguna de las funciones del lado del servidor de las que acabamos de hablar. Y con el modelo VM tienes el control total.
La mayoría de nuestros clientes son empresas de alto nivel que realmente no quieren perder el control. Es como una base de datos SQL versus un servidor SQL. Entonces, con NCache, ya sabes, controlarás todo tu entorno y, como viste, es bastante sencillo de hacer. Pero obtienes todas estas características del lado del servidor con NCache, que no porque con Redis porque no tienes acceso.
Por lo tanto, nuevamente tome una decisión, pero como mínimo use un caché distribuido en su arquitectura. Asegúrese de que esté listo para escalar. Ese es todo el objetivo. Muchísimas gracias.