Campamento de código de Orlando
Escalado de aplicaciones .NET con almacenamiento en caché distribuido
Por Iqbal Kan
Presidente y evangelista tecnológico
Sus aplicaciones .NET pueden experimentar cuellos de botella en la base de datos o en el almacenamiento debido al aumento de la carga de transacciones. Aprenda a eliminar cuellos de botella y escalar sus aplicaciones .NET mediante el almacenamiento en caché distribuido. Esta charla cubre:
- Descripción general rápida de los cuellos de botella de escalabilidad en las aplicaciones .NET
- Descripción del almacenamiento en caché distribuido y cómo resuelve los problemas de rendimiento
- ¿Dónde puede usar el almacenamiento en caché distribuido en su(s) aplicación(es)?
- Algunas características importantes en un caché distribuido
- Ejemplos prácticos usando un caché distribuido
La charla de hoy no se trata de NCache, se trata de almacenamiento en caché distribuido. me referiré a NCache como ejemplo, pero los conceptos son generales, por lo que se aplican a todos los cachés.
¿Qué es la escalabilidad?
¡Okey! Primero saquemos algunas definiciones del camino. La primera definición es escalabilidad. La escalabilidad no es el rendimiento de la aplicación. Si tiene cinco usuarios y su aplicación funciona súper rápido, su aplicación no es escalable hasta que pueda tener el mismo buen rendimiento con cinco mil usuarios, cincuenta mil o quinientos mil. Por lo tanto, la escalabilidad se trata de alto rendimiento bajo cargas máximas. La gente a veces confunde rendimiento con escalabilidad. Es posible que su aplicación no tenga un buen rendimiento con cinco usuarios, en cuyo caso el almacenamiento en caché no lo ayudaría, tiene otros problemas que resolver.
Escalabilidad lineal
La escalabilidad lineal es, si su aplicación está diseñada de tal manera que puede agregar más servidores y al agregar más servidores puede aumentar la capacidad de transacción. Nuevamente, la escalabilidad que estamos definiendo en términos de capacidad de transacción en términos de cuántos usuarios y cuántas transacciones por segundo puede manejar su aplicación. Entonces, si su aplicación puede manejar más transacciones linealmente a medida que agrega más servidores, entonces es escalable linealmente y nuestro objetivo es ser una escala lineal para tener una escalabilidad lineal en nuestra aplicación.
Escalabilidad no lineal
Y, definitivamente, no queremos escalabilidad no lineal, que es que su aplicación esté diseñada de tal manera que después de cierto punto, realmente no importa si agrega más servidores, su aplicación no aumentará, de hecho, probablemente lo hará. soltar. Eso significa que hay algunos cuellos de botella en algún lugar que no se han abordado.
¿Qué aplicaciones necesitan escalabilidad?
Entonces, ¿por qué queremos escalabilidad y qué aplicaciones necesitan escalabilidad?
Por lo general, estas son aplicaciones que son aplicaciones del lado del servidor. Estos son ASP.NET ahora ASP.NET core, servicios web, backends IOT, procesamiento de big data. Aunque el procesamiento de big data no es común en el lado de .NET, es más un fenómeno de Java, pero debería poder hacerlo también con .NET, pero las aplicaciones de procesamiento de big data también necesitan escalabilidad y cualquier otra aplicación de servidor. Por ejemplo, usted puede ser un banco y tiene millones de clientes y llaman y cambian de dirección o tal vez emiten o solicitan una nueva tarjeta o tal vez transfieren fondos y usted tiene que procesar todas esas solicitudes en un modo por lotes en noche y hay algunos requisitos de cumplimiento que debe cumplir antes del siguiente día hábil. Por lo tanto, a medida que obtiene más y más de estos, incluso sus otras aplicaciones de procesamiento por lotes deben ser escalables. Entonces, no son solo estas aplicaciones. Cualquier otra aplicación que solo necesite procesar muchas transacciones en un tiempo comprimido y ese tiempo comprimido en estos casos son transacciones por segundo y ese tiempo comprimido en este caso podría estar dentro de ese requisito de cumplimiento. Entonces, si tiene alguna de estas aplicaciones que son de alto tráfico o transacciones, entonces ha venido a la conversación correcta.
Problema de escalabilidad
Entonces, ¿dónde está el problema de escalabilidad? ¿Por qué estamos teniendo esta conversación? Definitivamente no está en el nivel de la aplicación, su nivel de aplicación se escala muy bien, tiene un balanceador de carga y puede agregar más y más servidores. Todo se ve muy bien. El problema realmente está en su base de datos, su almacenamiento de datos. Y con eso me refiero a bases de datos relacionales o datos heredados de mainframe. Y no puede escalarlos de la misma manera que puede escalar el nivel de la aplicación. La razón es porque los datos en este no se distribuyen. La naturaleza de la base de datos es que tiene que estar todo junto. Y lo mismo ocurre con el mainframe. Entonces, la base de datos puede ser muy rápida. Podría estar funcionando en el almacenamiento en caché de la memoria en el extremo del servidor, pero no está escalando y NoSQL databases.
Aunque una de las razones por las que la gente usa NoSQL es para la escalabilidad de las transacciones, el otro es para la escalabilidad de los datos en términos, digamos, tiene terabytes y terabytes de datos que NoSQL es mucho más adecuado para eso. Y, esa tercera razón por la que la gente lo usa porque los documentos JSON brindan esta flexibilidad de esquema. Pero, NoSQL databases no siempre pueden ayudarlo y la razón es porque requieren que mueva los datos de las bases de datos relacionales a una NoSQL database. ¿Qué sucede si no puede hacerlo por una variedad de razones, tanto técnicas como comerciales? Algunos de los datos deben permanecer en sus bases de datos relacionales y en sus datos de mainframe heredados. Aunque, NoSQL databases son geniales y tenemos un NoSQL database que lanzamos el año pasado nosotros mismos llamados NosDB, como mencioné, pero no van a resolver su problema a menos que pueda poner datos en ellos. Entonces, si tiene que trabajar con bases de datos relacionales, debe resolver el problema de escalabilidad que plantean y ahí es donde realmente entra un caché distribuido.
Implementación de caché distribuida
Básicamente, una caché distribuida es un almacén distribuido en memoria.
Lógicamente hablando, es solo entre el nivel de aplicación y el nivel de datos. Físicamente, podría ser un montón de máquinas virtuales separadas o podría estar en la misma caja que la aplicación o parte podría estar aquí, parte podría estar aquí y esas son las cosas de las que hablaremos. Pero lógicamente, está entre el nivel de la aplicación y el nivel de la base de datos. Y, el argumento fundamental es que si almacena datos en caché, no va a la base de datos con tanta frecuencia. Debido a que no va a la base de datos, no recibe toda esa carga, por lo que no se convierte en un cuello de botella. Si el 80% del tiempo puede ir al nivel de almacenamiento en caché y el nivel de almacenamiento en caché no tiene el cuello de botella que tiene una base de datos porque también se distribuye como un NoSQL database un nivel de almacenamiento en caché también está distribuyendo. Es una clave/valor. En realidad, otra palabra para un caché distribuido es en memoria NoSQL almacén de valores clave porque todo lo que pones en el caché de distribución tiene una clave y un valor que es tu objeto. Entonces, al hacer eso el 80 por ciento de las veces vas aquí, el 20 por ciento de las veces vas a la base de datos. Ese 20 por ciento son principalmente actualizaciones.
Hay algunas lecturas, por supuesto, y esas actualizaciones también funcionan más rápido porque no hay competencia con las transacciones de lectura y esto ya no es un cuello de botella. ¿Por qué? Porque una caché distribuida formará un grupo de dos o más servidores. Estas no son cajas caras, no son el tipo de cajas de su servidor de base de datos. Estas son configuraciones típicas de servidor web, como una caja de cuatro u ocho núcleos, solo mucha memoria. Mucho significa 16 a 32 gigas es lo que recomendamos a nuestros clientes. Algunos de nuestros clientes van más de 32 pero casi nunca recomendamos ir más de 64. Es mejor agregar otra casilla que tener más aquí. Porque, si agrega más memoria, entonces la potencia de procesamiento debe actualizarse. ¿Por qué? Debido a que una aplicación .NET tiene esta cosa llamada recolección de basura y cuanta más memoria tenga para recolectar, más recolector de basura o GC tiene que trabajar y la CPU se convierte en un cuello de botella en ese caso y su aplicación comienza a tener problemas. Entonces, el punto óptimo es de 16 a 32 gigas de memoria en estas VM o caja física y la mayoría de nuestros clientes usan VM aquí. Y, alrededor de 8 núcleos como configuración de hardware y generalmente dos tarjetas de red, una tarjeta de red es para el agrupamiento y otra es para que los clientes se comuniquen con ella. La palabra cliente significa su servidor de aplicaciones, por lo tanto, no son sus clientes. Su servidor de aplicaciones es el cliente de caché.
Entonces, un mínimo de dos servidores de caché y luego una proporción de cuatro a uno o cinco a uno entre el nivel de aplicación y el nivel de almacenamiento en caché. Y esa proporción se basa principalmente en lo que hemos visto a lo largo de los años y hemos estado en este espacio durante más de diez años, que si está agregando más servidores aquí para agregar más actividad, entonces por encima de nuestro cuatro a uno o La proporción de cinco a uno le dará una muy buena capacidad. Y, por supuesto, agrega más servidores por una de tres razones. O necesita más almacenamiento porque tiene necesidades de memoria como acabamos de mencionar o necesita más capacidad de transacción porque tenía dos servidores para comenzar y siguió agregando cajas aquí hasta que el descarte se agotó. En una base de datos relacional, si eso sucede, estás atascado. Estás jodido. En este caso, todo lo que debe hacer es agregar una tercera caja hasta que la capacidad de la tercera caja se agote y luego agregue una cuarta y así sucesivamente. Entonces, puedes tener tantas cajas aquí como quieras. Tenemos clientes que, en promedio, tienen de cinco a diez cajas aquí y algunos de nuestros clientes tienen de 40 a 50 cajas aquí en el nivel de aplicación y luego tienen en consecuencia. Entonces, para una caja de diez o para un nivel de aplicación de diez servidores, tendría alrededor de tres servidores en el nivel de almacenamiento en caché. Entonces, así es como haces tu planificación.
Por lo tanto, el objetivo de la charla hasta ahora es convencerlo de que al tener un nivel de almacenamiento en caché ya no tendrá un cuello de botella de escalabilidad. Por lo tanto, sea cual sea el producto, sea cual sea la solución de almacenamiento en caché que utilice, debe incorporar un nivel de almacenamiento en caché en su aplicación. Por lo tanto, debe diseñar su aplicación para tener un caché en su imagen y de esa manera nunca tendrá cuellos de botella.
Casos de uso de caché distribuida
Entonces, ahora que estamos convencidos de que debe usar el caché como desarrollador de .NET, la siguiente pregunta que viene a la mente es ¿dónde debería usarlo? ¿Cómo deberías usarlo?
Y, el primer caso de uso es el almacenamiento en caché de datos de la aplicación del que he estado hablando hasta ahora, que es que tiene datos de la aplicación en una base de datos y los almacena en caché aquí, por lo que no tiene que ir a la base de datos, lo mismo .
Almacenamiento en caché de datos de aplicaciones
Lo único a tener en cuenta sobre este caso de uso es que los datos ahora existen en dos lugares, uno es el maestro, que es la base de datos, y el otro es el caché, que no lo es, que es el otro lugar. Entonces, si sus datos existen en dos lugares, ¿qué saldrá mal? Si tiene dos copias, la mayor preocupación es si el caché estará actualizado, si el caché tendrá la misma versión de datos que la base de datos porque si el caché no tendrá la misma versión de datos, entonces usted se verá obligado a almacenar en caché datos de solo lectura. Y, los datos de solo lectura representan aproximadamente el 10-15 por ciento de sus datos totales. Entonces, realmente no te estás beneficiando bien. Se está beneficiando, pero no en la medida en que debería hacerlo para que su aplicación sea realmente escalable.
Entonces, de hecho, es tanto que si le preguntas a una persona promedio para qué se usa un caché. Dirían, bueno, solo pondré mis datos de solo lectura en él. Todo el mundo tiene miedo de almacenar en caché los datos transaccionales. Datos de tus clientes, tus cuentas o actividades que cambian cada 30 segundos, cada minuto, cada cinco minutos o de forma impredecible. Por lo tanto, la gente tiene miedo de almacenar eso en caché por esta razón porque hay dos copias y qué sucede si el caché no sabe que lo ha cambiado en la base de datos. Entonces, tengamos eso en mente a medida que continuamos.
Almacenamiento en caché específico de ASP.NET
El segundo caso de uso es, si tiene una aplicación ASP.NET, el más conocido es el estado de la sesión. Y eso es también, cualquier cosa en este, el primer ejemplo es el estado de la sesión. Las sesiones son algo que, de forma predeterminada, tiene dos opciones de almacenamiento. Uno es InProc, el otro es SQL, que proporciona Microsoft. En una instalación local también hay un servidor de estado, pero las tres opciones tienen problemas de escalabilidad. El servidor SQL tiene problemas de rendimiento. La misma razón por la que no tendremos almacenamiento en caché para empezar. Cuando almacena sesiones en SQL, se almacenan como blobs. La relación es SQL, como todas las bases de datos relacionales, no fue diseñada para el almacenamiento de blobs, es para datos estructurados. Por lo tanto, no funciona. Hay muchos problemas. La mayoría de nuestros clientes cuando van a NCache, el primer caso de uso es el estado de sesión. Eso debido a que obtiene su beneficio inmediato. Y, lo realmente bueno sobre el estado de la sesión es que no hay programación porque hay un marco que proporciona Microsoft que permite un caché de terceros como NCache para conectar y todo aquí se almacena en el caché.
El otro aspecto de ASP.NET es que si no tiene el marco MVC, si está en el marco anterior a MVC, que es lo que todavía tienen muchas aplicaciones ASP.NET, entonces hay una cosa llamada estado de vista. Y, para aquellos de ustedes que no saben qué es el estado de vista, es una cadena encriptada que su servidor web envía al navegador solo para que se devuelva en una publicación. Entonces, podrían ser cientos de kilobytes de fuerza encriptada que simplemente van y regresan. Y, cuando multiplica eso por millones de transacciones que su aplicación va a procesar, eso es mucho ancho de banda como mínimo. Y, el ancho de banda no es gratuito, por cierto, es bastante caro.
Y, en segundo lugar, por supuesto, pero cuando tiene que enviar una carga tan pesada de su rendimiento, su tiempo de respuesta es más lento. Por lo tanto, sería mucho mejor si simplemente pudiera almacenar en caché el estado de la vista en el extremo del servidor y enviar una pequeña clave, de modo que cuando ocurra la devolución de la publicación, la clave regrese y el estado de la vista se obtenga del caché y se presente. a la página Entonces, ese es el segundo caso de uso. Nuevamente, de la misma manera, no hay programación involucrada, solo conecta un caché de terceros como NCache.
El tercer caso de uso es el Caché de salida de ASP.NET. Este caché es la salida de la página. Si el resultado de la página no cambia, Microsoft ya tiene un marco que lo almacena en caché en un InProc independiente local. Es mejor colocar un tercer caché distribuido en su lugar, de modo que en una granja web, la primera vez que se almacena en caché una salida de página, esté disponible para toda la granja web en lugar de que cada servidor web almacene en caché su propia copia.
Entonces, esos son los tres casos de uso para las aplicaciones ASP.NET además del almacenamiento en caché de datos de la aplicación.
Ahora, la naturaleza del problema aquí es completamente diferente aquí. En este tenías dos copias de los datos. Aquí, el caché es el almacén principal. Entonces, ya no está almacenando sesiones en la base de datos. Ya no está almacenando el estado de vista en ningún otro lugar. Entonces, el caché es el almacén maestro y es un almacén en memoria. Entonces, cuando un almacén en memoria es un almacén maestro, ¿qué podría salir mal? ¡La memoria es volátil! Sí. Entonces, no hay persistencia. Por lo tanto, un buen caché distribuido debe replicar datos en varios servidores para proporcionar confiabilidad de datos, para que no pierda esa sesión. Porque usted puede ser una aerolínea e hizo esta promoción especial de fin de semana para Hawái y tiene dos o tres veces el tráfico en su sitio web y son personas que han realizado todo tipo de búsquedas y están a punto de presiona el botón de enviar y pierden su sesión. Puede perder ese cliente con miles de dólares en ventas por cada cliente. Entonces, definitivamente no querrás perder la sesión. Por lo tanto, no coloque sesiones en un caché a menos que realice la replicación.
Intercambio de datos en tiempo de ejecución
El tercer caso de uso es compartir datos en tiempo de ejecución. Esto es algo que mucha gente no sabía desde hace mucho tiempo. Las personas usan las colas de mensajes para compartir los eventos en varias aplicaciones. Pero, un caché distribuido le brinda un mecanismo de eventos enfocado en datos muy simple y poderoso donde, piense en esto ahora como un bus de servicio o como un bus de mensajes, entonces estas son sus aplicaciones que pueden comunicarse entre sí a través de esto. Entonces, en lugar de usar MSMQ o RabbitMQ, que tienen sus propios beneficios, no hay un caché aquí para reemplazarlos. Pero, si su necesidad está más relacionada con los datos o si su necesidad de mensajería está más relacionada con los datos y dentro del mismo centro de datos, un caché distribuido le brinda una interfaz más simple pero, lo que es más importante, es más escalable. Entonces, si tiene una aplicación de transacción más alta y nuevamente, toda esta charla es sobre escalabilidad.
Entonces, aunque podría hacer todo esto con estas colas de mensajes regulares. Cuando ingresa a un entorno de transacciones muy alto, no se distribuyen de la misma manera que un caché distribuido. Entonces, un caché distribuido te permitirá hacer todo esto. Digamos el tipo Pub/Sub de un intercambio de datos, hay notificaciones de eventos, hay una función de consulta continua que NCache tiene que también tienen los cachés de Java, que Redis no lo hace, con el que puede compartir datos entre aplicaciones de una manera muy fluida. Y, aquí también, el problema es similar a la aplicación de almacenamiento en caché específico de ASP.NET porque, aunque estos datos probablemente existan en una base de datos, pero no en la forma en que los está compartiendo.
Entonces, probablemente lo haya transformado en parte del formulario antes de intentar compartirlo para que el formulario transformado se mantenga en el caché. Por lo tanto, no desea perder esos datos, por lo que un caché debe replicar los datos. En realidad, incluso para el almacenamiento en caché de datos de la aplicación, aunque técnicamente podría hacerlo si pierde algunos datos porque un servidor de caché deja de funcionar y no lo replicó. Técnicamente podría recargar esos datos de la base de datos. No hay problema, excepto que hay un impacto en el rendimiento porque, digamos lo que sea, si perdiste 16 gigabytes de datos, ahora tienes que pasar por 16 gigabytes de hits en la base de datos que no quieres hacer. Por lo tanto, la mayoría de nuestros clientes, incluso para el almacenamiento en caché de datos de aplicaciones, eligen replicar porque la memoria es muy barata. Ni siquiera quieren recibir ese golpe de rendimiento. Con estos dos, por supuesto, tienes que tenerlo, pero en este es bueno tenerlo.
Demostración práctica
Bien, antes de avanzar sobre cómo hacer esto, primero quiero mostrarles cómo se ve un caché. voy a usar NCache como el ejemplo aquí.
Configuración de un entorno
Por lo tanto, tengo en Azure tres máquinas virtuales demo1, demo2 y demo-client. demo1 y 2 van a ser mis VM de servidor de caché y demo-client es mi VM de servidor de aplicaciones. En su caso, digamos que tendrá dos máquinas virtuales de caché y luego una proporción de cuatro a cinco, cuatro a uno o cinco a uno de las máquinas virtuales del cliente.
Por lo tanto, he iniciado sesión en el cliente de demostración y voy a utilizar esta herramienta que NCache ha llamado NCache gerente. Entonces, lo tengo comenzado aquí. Voy a venir aquí y decir crear un nuevo caché en clúster.
Crear una caché en clúster
Todos los cachés en NCache se nombran, así que solo voy a llamarlo democache, no voy a entrar en los detalles de lo que significa cada uno de estos. Hablaré sobre esto en un momento, pero elegiré un topología de réplica particionada. En caso de NCache, una topología significa ¿cómo se almacenan y replican los datos? Una topología de réplica particionada es algo que... si tuviera que volver aquí, pensaría en esto como un clúster de caché de dos nodos que estaría a punto de crear.
Si se trata de una réplica particionada, cada servidor tendrá una partición. Entonces, habrá un total de dos particiones. En caso de NCache, todo el caché tiene alrededor de mil cubos, por lo que aproximadamente la mitad de ellos irán a la partición uno y la otra mitad a la partición dos.
Cada partición se respalda en un servidor diferente que se denomina réplica. La réplica en caso de NCache es pasivo, lo que significa que ningún cliente habla con las réplicas, solo la partición habla con las réplicas. Y, la réplica se activa solo cuando su partición principal o cuando la partición deja de funcionar.
Lo que significa que, digamos, si este servidor se fuera, digamos, si tuviéramos un clúster de tres nodos y una partición, digamos que el servidor tres se cayó, la partición tres se cayó ahora. Por lo tanto, la réplica tres se convertirá automáticamente en la partición tres, para que no pierda ningún dato. Entonces, las réplicas particionadas le brindan estas estrategias de almacenamiento y replicación. Esencialmente le dice que los datos deben ser replicados. También hay una replicación síncrona y asíncrona. Entonces, de todos modos, regresaré a esto, pero solo quería mostrarles lo que eso significa. Entonces, elegiré una replicación asíncrona entre la partición y las réplicas. Luego especificaré mi servidor de caché, por lo que el primero es demo1, el segundo es demo2. Ahora, todo lo que estoy diciendo en caso de NCache, puede escribirlo completamente, para que pueda automatizarse. Dejaré todo por defecto. Ese es el puerto TCP en el que se formaron los clústeres de caché. Voy a especificar cuánta memoria quiero que use el caché en este servidor y el caché no usará más que esta memoria. Entonces, lo que especifique aquí es multiplicado por dos porque. Hay una partición y hay una réplica.
Entonces, este es el tamaño de una partición. Entonces, en su caso, será mucho más que esto, por supuesto, porque si tiene 16 gigas en un servidor de caché, debe dejar entre 2 y 2.5 gigas para el sistema operativo y otros procesos y asignar el resto. Entonces, digamos, de 16 gigas te quedan 13 gigas y media, pero 13 gigas y media dividido por 2 sería un tamaño de partición y luego NCache se asegurará de que no utilice más de esta memoria. Entonces, cuando se consume tanta memoria, el caché se considera lleno en caso de NCache. Y luego NCache tiene una de dos opciones. Uno, puedes decir NCache rechazará cualquier nueva adición de los datos hasta que algunos de los datos caduquen automáticamente o puede hacer lo que se llama desalojo. Asi que, NCache le ofrece tres algoritmos de desalojo LRU, LFU y prioridad FIFO. Entonces, puede decir en este caso, desalojar el 5% del caché.
Ahora quiero hablar un poco sobre esto en el contexto de, digamos que está almacenando en cada uno de los caso de uso aquí. Si está realizando el almacenamiento en caché de datos de la aplicación, el desalojo está perfectamente bien. No hay problema. Acaba de usar la memoria que tenía desalojada de la menos utilizada recientemente y luego deja espacio para nuevos datos. Entonces, se vuelve como una ventana en movimiento, ¿verdad? Entonces, a medida que usa más y más datos, el anterior se elimina y el nuevo. Entonces, ese es el más utilizado. Pero, ¿y si es una sesión? Si el caché se usa para almacenar sesiones, no desea desalojos. ¿Por qué no lo quieres desalojo? Porque la sesión aún podría estar activa. Es posible que no haya pasado por esos 20 minutos o cualquiera que sea su tiempo de espera. Si ese es el caso y aún desalojas la sesión, estás forzando el mismo problema del que acabamos de hablar, que es que un usuario no ha cerrado la sesión pero lo estás pateando. Entonces, lo que debe hacer es planificar su capacidad. En caso de NCache, puede hacerlo muy fácilmente, puede ver cuánta memoria consume una sesión promedio y luego hacer su planificación de capacidad. Extrapolar cuánta memoria se va a utilizar. Tenga la capacidad de que este otro almacenamiento de sesión nunca será desalojado. El almacenamiento de datos de la aplicación o la caché de datos de la aplicación se pueden desalojar, sin problemas. Sin embargo, la memoria caché de la sesión no debe desalojarse. Solo debe caducar cuando el usuario ya no utilice la sesión.
Entonces, solo diré terminar y tengo un clúster de caché de dos nodos. Vendré aquí y agregaré un nodo de cliente. En mi caso solo tengo un nodo cliente como dije. Creo que probablemente no tengo el caché, así que comenzamos. Necesito ese servicio para que el NCache el administrador puede hablar con esto y hacer la configuración. ¡Okey! Ahora que he hecho esto, vendré aquí y diré iniciar el caché. Así que ahora al iniciar el caché, NCache está construyendo un clúster entre estas dos cajas, a ese TCP.
Simule estrés y monitoree estadísticas de caché
Entonces, en realidad no entra en los detalles de qué cajas tienen qué datos y si el clúster. Solo sabes que hay un democache. Siempre que se conecte a ese caché, su aplicación se conectará automáticamente a todos los servidores en caso de réplicas particionadas. Asi que, NCache se ocupa de todos los detalles y voy a venir aquí y decir ver estadísticas y estos son algunos contadores de PerfMon para que pueda ver qué NCache lo hará, pero una vez que comience a usarlo. También iniciaré esta herramienta llamada NCache monitor. Y es como una herramienta de estilo de tablero. Y, en caso de NCache, tiene esta opción de usar una herramienta de prueba de estrés que le permite simular muy rápidamente el uso de su aplicación sin ninguna programación.
Entonces, por ejemplo, voy a decir la herramienta de prueba de estrés democache, así que va a hacer que uno obtenga uno y cosas así. Y de repente, ahora verá que esta herramienta está hablando con ambos servidores de caché y está haciendo alrededor de 700 solicitudes por segundo en cada cuadro, alrededor de 7 a 800 incluso hasta mil. Digamos que quiero aumentar la carga. Entonces, quiero lanzar una herramienta más de prueba de esfuerzo.
Esto es lo que haría con su aplicación. Quiero decir, cuando quiera probarlo, lo hará con su aplicación, ejecutará su aplicación con alguna herramienta de prueba de estrés y luego seguirá agregando más y más estrés y luego querrá ver si todo el sistema funciona. Entonces, en este momento solo está probando el componente de caché. La mayoría de nuestros clientes lo que hacen cuando evalúan NCache, ellos hacen este benchmarking. Entonces, una vez que han configurado todo en su entorno, aunque hayamos publicado nuestros puntos de referencia, no lo hacen. Quiero decir que verifican todo en su propio entorno. Entonces, a medida que agrega más y más de esto, verá que esta carga se ha duplicado.
Déjame ir una herramienta más de prueba de estrés. Verás que sigue subiendo. ¡Allí mismo, mira! Por lo tanto, puedo seguir agregando más y más herramientas de prueba de estrés, hasta que pueda maximizar la CPU de mi cliente. Entonces, llegué a alrededor del 50 por ciento en mi servidor de aplicaciones. Entonces, definitivamente puedo agregar más herramientas de pruebas de estrés. Una vez que maximice ese cliente, agregaré un cliente más. Entonces, así es como puedo. Entonces, incluso en este momento, por ejemplo, estamos haciendo alrededor de 5,000 solicitudes por segundo con solo tres herramientas de prueba de estrés. Entonces, con esto y luego también puede monitorear, por ejemplo, aquí todas estas cosas. Entonces, con esto puedes ver cómo se ve un caché. Y ahora, entremos más desde la perspectiva de un desarrollador.
Almacenamiento en caché específico de ASP.NET
Entonces, ahora que sabe cómo se ve un caché, veamos cómo usar ese caché dentro de su aplicación. Entonces, para ASP.NET, como dije, lo primero que debe hacer es usar el caché para las sesiones. ¿Por qué? Porque es lo más fácil. No hay programación, no hay esfuerzo que puedas hacerlo. Acabo de mostrarte lo rápido que puedes configurar un caché con intereses de NCache, digamos que si viniera aquí y entrara en algunos de los códigos de muestra, ya debería haberlos abierto, pero no lo hago. Entonces, aquí hay una aplicación ASP.NET para que la use NCache con ASP.NET para sesiones. Solo tienes que ir y modificar web.config. Entonces, tengo el web.config. Lo primero que debe hacer es agregar esta línea de ensamblaje en el ensamblaje. NCache, este proveedor de almacenamiento de sesión es NCache ensamblado que ha implementado la interfaz del proveedor del almacén de sesiones de ASP.NET. Entonces, esto es lo que permite NCache para conectarse. Por lo tanto, puede simplemente copiar la línea aquí y luego simplemente llegar a la etiqueta de estado de la sesión, que está justo aquí. En caso de NCache, solo copia esa etiqueta. Asegúrese de que este modo sea personalizado porque eso es lo que permite que se conecte el caché de terceros. El tiempo de espera es lo que usted quiere que sea y luego lo único que necesita en caso de NCache es asegurarse de que se especifica el nombre de caché.
Entonces, una vez que haya instalado NCache luego, en los servidores de caché, instala la parte del servidor, en el servidor de aplicaciones, instala la parte del cliente de NCache, creas el caché como acabamos de hacer y actualizas esto y eso es todo. Ese es todo el esfuerzo que necesitas para empezar a usar NCache y luego cada sesión es un objeto en el caché. Cuando haga eso en ese contador PerfMon, verá cuántas sesiones está viendo. Lo que sucede típicamente, nuestros clientes crean tres cachés. Entonces, acabamos de hacer un caché aquí, ¿verdad? Entonces, nuestros clientes harán tres cachés. Uno de los cachés es para sesiones. Por lo tanto, tienen un caché separado para las sesiones. Uno de los cachés y dos cachés son para datos de aplicaciones. Uno es lo que llaman los datos de referencia. El otro son los datos transaccionales. Los datos transaccionales son algo que cambia con mucha frecuencia. Y, la razón por la que lo hacen es por algunas de las otras características que mencionaré. Pero, en las mismas máquinas virtuales, puede crear más de un caché. Entonces, eso es todo lo que tiene que hacer para el almacenamiento del estado de la sesión, es muy fácil, no necesita programación y luego está listo para comenzar.
Almacenamiento en caché de datos de aplicaciones
Pero, si desea realizar el almacenamiento en caché de los datos de la aplicación, lamentablemente, en el espacio .NET, EF Core ahora finalmente proporciona una arquitectura en la que puede conectar un caché de terceros.
NCache también lo apoya. Pero, hasta EF6, incluido EF6, la arquitectura realmente no admitía la conexión de un caché de terceros. NHibernate durante mucho tiempo apoyó esa arquitectura. Entonces, para NHibernate NCache Se puede enchufar sin ninguna programación. Por lo tanto, incluso el almacenamiento en caché de datos de la aplicación con características mínimas, puede hacerlo sin hacer ninguna llamada a la API. Pero, en su mayor parte, debe estar mentalmente preparado allí para el almacenamiento en caché de datos de la aplicación, tendrá que programar. Pero es una API muy simple. Esta API se parece mucho a un objeto de caché de ASP.NET. Te conectas con el caché con un nombre de caché.
Déjame mostrarte rápidamente cómo se ve esto. Déjame abrir... Me encontré con algunos problemas de Azure VM. Empiezo esta otra cosa otra en este todo abierto. Entonces, digamos que tengo esta aplicación de consola realmente básica. Lo primero que tienes que hacer es enlazar dos de los NCache asambleas, uno es NCache.Runtime, el otro es NCache.Web. NCache.Web es la API real a la que está llamando. Luego vincula estos dos o usa estos dos espacios de nombres nuevamente NCache.Runtime y luego .Web.Caching. Al comienzo de su aplicación, se conecta al caché en función de un nombre y obtiene un identificador de caché como para la base de datos. Por supuesto, en una aplicación ASP.NET probablemente lo haga en global.ASAX en el inicio de la aplicación o en el método InIt. Luego simplemente creas tu objeto y haces Cache.Add. El Cache.Add utilizará una clave, algún tipo de cadena. Esta no es una buena clave, su clave debe ser mucho más específica y luego aquí está su objeto y eso es todo. Haces esa llamada y detrás de escena ahora esto está sucediendo. Digamos, si tuviera esa topología de réplica particionada, lo que sucederá es que su aplicación está conectada. Entonces, cada caja está conectada a todos los servidores de caché. Entonces, acabas de hacer un Cache.Add, ¿verdad? Entonces, Cache.Add irá y mirará el mapa de distribución que es como el mapa de cubo. Cada cubo tiene un rango de valores clave en términos de un rango de valores de clave hash en términos de qué claves pueden entrar en este cubo. Entonces, va a usar ese mapa de depósito para saber a qué servidor debe ir y hablar porque está conectado a todos ellos, ¿verdad?
Y va a ir y digamos que estaba agregando el elemento número tres aquí. Irá y agregará el elemento número tres aquí y, si habilitó la replicación asíncrona, la aplicación regresará y la aplicación estará lista. El caché ahora, esta partición sabe que necesita replicar esto aquí. Por lo tanto, de forma asíncrona, en una operación masiva, replicará esto en el otro cuadro e inmediatamente tendrá ese elemento en dos lugares. Entonces, eso es lo que Cache.Add hizo bajo las sábanas.
Bien, estoy yendo y viniendo porque quería darles una descripción general, pero cómo se ve un caché, cómo crearlo, cómo se ve una API.
Funciones de almacenamiento en caché de datos de la aplicación
Ahora, analicemos cuáles son los problemas que debe resolver al usar el caché para el almacenamiento en caché de datos de la aplicación.
Mantenga el caché actualizado
Hablamos de mantener el caché actualizado, ¿verdad? Entonces, ¿cómo mantienes el caché actualizado? ¿Cómo te aseguras de que un caché esté fresco?
El más común y el que todo el mundo apoya incluyendo Redis es caducidad. La caducidad absoluta. Entonces, cuando agrega algo al caché, digamos, incluso aquí, especifica un vencimiento aquí, que es digamos que está diciendo que expire después de un minuto. Cuando dices esto en caso de NCache, NCache creará índices en el servidor y monitorearemos esos datos y caducará después de un minuto. Entonces, en realidad es eso, en realidad especificará un valor absoluto de fecha y hora que fue dentro de un minuto. NCache sabe que en ese valor de tiempo del día debe caducar ese artículo. Entonces, así es como el caché se encarga automáticamente de asegurarse de que se eliminen los datos. Y, ¿qué significa eso realmente? Eso significa que le estás diciendo al caché que realmente no me siento cómodo manteniendo estos datos por más de un minuto o más de cinco minutos porque creo que alguien los va a cambiar en la base de datos. Por lo tanto, solo es seguro mantenerlo en el caché durante ese tiempo. Hay otro vencimiento llamado vencimiento deslizante que suena igual pero su propósito es totalmente diferente. La caducidad deslizante se utiliza principalmente para la limpieza. Entonces, si tiene sesiones, use la caducidad deslizante para limpiar después de que nadie esté usando esta sesión. Por lo tanto, cuando alguien se desconecte después de 20 minutos de inactividad, la sesión se considerará caducada. Por lo tanto, se eliminará automáticamente.
Uso de dependencias de bases de datosPero eso no tiene nada que ver con mantener el caché actualizado. La caducidad absoluta es la que mantiene fresca la memoria caché. Pero, hay un gran problema con la caducidad absoluta. Y el problema es que está adivinando que es seguro mantener los datos en el caché durante tanto tiempo y esa suposición no siempre es precisa. Entonces, ¿qué haces en ese caso? Entonces, en ese caso, debe tener la capacidad de que el caché se sincronice solo. Si nota un cambio en la base de datos, eso significa que el caché debe saber cuál es su base de datos. Eso significa que el caché debe tener una relación entre el elemento almacenado en caché y algo en algunos datos en la base de datos que debe decirle al caché y ahí es donde está esta cosa llamada dependencia de caché SQL en ADO.NET que NCache uses, que es dependencia de SQL y esto también se llama dependencia de Oracle, que en realidad funciona de una manera muy simple. Pero, es una característica realmente poderosa. Y, venimos aquí. Solo voy a usar la dependencia de SQL. Entonces, cuando agregas algo al caché, haces lo mismo Cache.Add, ¿verdad? Tienes una clave de caché. Ahora, en lugar del valor, especifica el elemento de caché que es NCacheLa propia estructura de datos y allí contiene el valor, pero también contiene esta cosa llamada dependencia de caché de SQL.
Esta dependencia de caché de SQL es NCachepero se asigna a la dependencia de caché SQL de ADO.NET. Tenga en cuenta que tiene una cadena de conexión aquí y luego tiene una declaración SQL. Entonces, la instrucción SQL en este caso se asigna a una fila en la tabla de productos. Entonces, ¿qué está pasando realmente aquí? Quiero decir, en realidad estás ejecutando este código aquí mismo. Su base de datos está aquí, por lo que le está pidiendo al clúster de caché que ahora se conecte con la base de datos en función de la cadena de conexión que acaba de pasar, en función de esa cadena de conexión y está pasando el servidor SQL y está diciendo por favor conectarse con mi base de datos del servidor SQL. Y, supervise el servidor SQL para notificarle, siendo usted el servidor de caché, si se produce algún cambio en este conjunto de datos. Eso significa que si esta fila se actualiza o elimina. Si eso sucede, el servidor SQL envía una notificación de la base de datos al cliente, que en este caso es el servidor de caché. Uno de estos. Y, entonces, ¿qué hace el servidor de caché? El servidor de caché elimina ese elemento del caché. Eliminar significa que, dado que ya no está en el caché, su aplicación se ve obligada a ir y obtenerla de la base de datos que tiene la copia más reciente ahora. Entonces, si bien la caducidad es una suposición fundamentada, esta no es una suposición. Esta es una sincronización predecible real, donde se asegura de que el caché sea siempre consistente con la base de datos.
Ahora bien, en caso de NCache, hay tres maneras diferentes de hacerlo. Una es la dependencia de SQL que usa eventos de la base de datos, que es como en tiempo real. El otro es NCaches propia dependencia de base de datos que usa sondeo y eso es para aquellas bases de datos que no tienen un mecanismo de notificación de eventos o incluso para el servidor SQL, si cree que tiene demasiadas dependencias de SQL y para cada dependencia de SQL se crea una dependencia de caché de SQL en Servidor SQL que es una estructura de datos adicional. Piense si tuviera cientos de miles de estos creados, su servidor SQL se atragantaría. Entonces, tal vez no sea una buena idea si tiene muchas dependencias de SQL para tener esa forma de sincronización. Entonces, tal vez la dependencia de DB sea mucho mejor donde en una llamada puede sincronizar miles de filas porque tiene una tabla de sondeo que monitorea.
Y, hay una tercera forma que es simplemente escribir un procedimiento almacenado CLR para que lo llame su disparador. Por lo tanto, si tiene un activador de actualización, inserción, actualización o eliminación, llame a este procedimiento CLR. Y, el procedimiento CLR toma los datos de esa fila, construye ese objeto .NET que usa su aplicación y lo almacena en el caché. Ahora, aquí es donde una API asíncrona es muy útil porque no desea esperar dentro de la transacción de la base de datos para que se actualice un caché. Simplemente ralentiza las transacciones de la base de datos, lo que tiende a agotarse muy rápidamente. Por lo tanto, es muy recomendable que, si va a implementar este mecanismo, utilice los métodos asíncronos para ir y actualizar los datos.
Entonces, esas son las tres formas en que puede sincronizar el caché. Esta característica es realmente importante porque le permite asegurarse de que el caché siempre estará actualizado, sin lo cual solo está adivinando. Y, de la misma manera, puedes sincronizar el caché con bases de datos no relacionales. Hay una función de dependencia personalizada que NCache tiene cual es tu codigo que NCache llamadas a las que puede ir y monitorear su almacén de datos personalizado. Su fuente de datos personalizada podría ser un almacenamiento en la nube. Podría ser lo que sea, es solo un código que puede ir y verificar. Por lo tanto, mantener el caché actualizado es realmente importante y estas son las formas en que puede garantizarlo.
Lectura y escritura simultánea
Por lo tanto, la siguiente función es la lectura y la escritura simultáneas.
La lectura es básicamente, es nuevamente su código. Ahora, todas estas características de las que estoy hablando NCache los tiene pero no NCache solamente. Todos los cachés de Java los tienen. Redis puede o no tenerlos. Entonces, eso es lo que necesita hacer si quiere hacer un detallado, si quiere saber si qué Redis tiene o no, en caso de NCache solo ven aquí y solo ve a las comparaciones y hay un Redis NCache comparación de características. Esto se basa en su documentación y documentación de cachés. Por lo tanto, puede descargar esto y pasar por todas estas funciones. Entonces, la lectura completa básicamente es su código que se encuentra en el servidor de caché. Entonces, se parece a esto. Entonces, es lo que implementas. Entonces, permítanme mostrarles esa interfaz para que la interfaz de lectura se vea como... Entonces, aquí hay una interfaz de lectura, ¿verdad? Cursor de mano en NCache y hay un InIt que se conecta a su fuente de datos, lo desecha y hay un método de carga. Por lo tanto, la carga le da una clave y le devuelve un objeto en función de los datos que obtuvo. Y luego puede especificar cuándo debe caducar y esas cosas. Lo mismo ocurre con la escritura directa: tiene InIt y desecha y luego hay una escritura en la fuente. Por lo tanto, la escritura podría agregarse, actualizarse o eliminarse. ¿Dónde utiliza la lectura simultánea y la escritura simultánea y por qué son tan importantes?
Leer a través, en primer lugar, por lo que la forma en que funciona, le permite tener un Cache.Get y el caché no tiene los datos. Cache llamará a su lectura para ir y obtenerlo de la base de datos. Ese es un beneficio. El segundo beneficio es que puede combinar la lectura completa con la caducidad y la sincronización de la base de datos. Entonces, en lugar de eliminar eso del caché, vuelve a cargarlo. La escritura simultánea funciona de la misma manera, excepto que hay una escritura posterior, lo que significa que solo actualiza el caché en el que el caché actualiza su base de datos. Entonces, sus actualizaciones también se vuelven súper rápidas. Entonces, donde sea que el rendimiento de la base de datos se convierta en un cuello de botella, tiene un caché para rescatarlo. Una vez que haya implementado la lectura directa y la escritura directa, puede consolidar todo el código de persistencia o la mayor parte en el nivel de almacenamiento en caché y puede beneficiarse de ambas funciones de las que acabamos de hablar.
Agrupación de datos y búsqueda de datos
Entonces, una vez que mantiene el caché actualizado y también está haciendo la escritura directa, ahora está comenzando a almacenar en caché una gran cantidad de datos. Entonces, el caché ya no es solo un almacén de valor clave. Quiero decir que no es conveniente buscar todo como una clave.
Tienes que saber buscar. Tienes que ser capaz de hacer búsqueda SQL. Por lo tanto, debe poder hacer lo que está acostumbrado a hacer con la base de datos.
Si un caché no le permite realizar búsquedas de SQL, entonces se vuelve muy limitante y de la misma manera porque no puede hacer uniones en un caché porque es un caché distribuido, hay otras funciones de agrupación y subagrupación y etiquetas que le permiten agrupar datos y obténgalo todo en una sola llamada.
De nuevo, facilitarle la búsqueda de datos en la memoria caché es muy importante si va a almacenar una gran cantidad de datos en la memoria caché. Entonces, esas características son muy importantes.
Funciones de caché distribuida
Voy a repasar rápidamente algunas, una característica que realmente quería tocar se llama caché cercano o caché del cliente.
Tan pronto como aquellas personas que están acostumbradas a hacer caché InProc independiente, cuando se mueven a un caché distribuido, de repente, su rendimiento cae porque van a través de la red. Tienen que pasar por la serialización y, de repente, el rendimiento ya no es rápido. Muchos de nuestros clientes se quejan, bueno, esperaba que mi rendimiento aumentara, pero en realidad ha disminuido. Y el motivo es que no puede competir con la memoria caché InProc independiente que tiene el objeto almacenado en su montón. Entonces, si tiene una función de caché de cliente que esencialmente es exactamente un caché local que mantiene ese objeto local pero está conectado al caché agrupado.
Una vez más, esta es una característica que NCache tiene y la mayoría de los cachés de Java que realmente le darán el mismo rendimiento rápido sin perder nada.
NCache, puede ir a nuestro sitio web y descargarlo, es un caché de código abierto. Entonces, puede descargar el caché de código abierto o Enterprise Edition y, como dije, puede obtener todas las comparaciones entre NCache y Redis en eso.