Código de Boston Campamento 27
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
Mi nombre es Iqbal Kan. Soy un evangelista tecnológico en Alachisoft. Somos una empresa de software con sede en el Área de la Bahía de San Francisco. Estoy basado personalmente en Tampa pero tenemos este producto llamado NCache. Es un caché distribuido .NET. Hoy voy a hablar sobre cómo puede escalar aplicaciones .NET con almacenamiento en caché distribuido. Esto no es una charla sobre NCache, se trata del problema de la escalabilidad y de cómo puede resolverlo con el almacenamiento en caché distribuido. ¿Qué debes hacer? ¿Cómo deberías usarlo? ¿Cuáles son algunas de las mejores prácticas? Si tiene alguna pregunta, no dude en detenerme. Para que podamos tener una discusión más interactiva. Déjame empezar.
¿Qué es la escalabilidad?
Entonces, saquemos algunas definiciones del camino. El número uno es la escalabilidad. La escalabilidad no es rendimiento. Puede tener una aplicación que funciona muy bien con cinco usuarios, pero solo es escalable si va a funcionar de la misma manera con 5,000 o 50,000 500,000 o 5 XNUMX usuarios. Por lo tanto, la escalabilidad es un rendimiento realmente alto bajo cargas máximas. Si su aplicación no funciona bien con XNUMX usuarios, debe asistir a otras charlas.
Escalabilidad lineal y escalabilidad no lineal
La escalabilidad lineal es más un concepto de implementación de aplicaciones. Cuando implementa su aplicación, si puede agregar más servidores a la implementación y al agregar más servidores si puede aumentar la capacidad de transacciones de forma lineal, entonces la arquitectura de su aplicación es escalable linealmente; de lo contrario, es escalable no lineal.
Lo que eso significa es que después de una cierta cantidad de servidores, agregar más servidores en realidad empeora las cosas, eso significa que hay algunos cuellos de botella en algún lugar de su aplicación que no se resuelven simplemente agregando más servidores. Definitivamente no desea escalabilidad no lineal y definitivamente desea escalabilidad lineal en su aplicación.
¿Qué tipo de aplicaciones necesitan escalabilidad?
¿Qué tipo de aplicaciones necesitan escalabilidad? Estas son aplicaciones ASP.NET. Estos son servicios web. Estos son back-end de IOT que, de nuevo, son en su mayoría servicios web. Estas son aplicaciones de procesamiento de big data, que no son tan comunes en .NET, cada vez más se están haciendo en Java, pero sin embargo, estas son las aplicaciones que también necesitan escalabilidad y cualquier otra aplicación de servidor. Por ejemplo, puede que esté trabajando para un gran banco que tiene millones de clientes y ellos, ya sabe, los clientes llaman para hacer cambios de dirección o tal vez quieren que se emita una nueva tarjeta o tal vez están transfiriendo fondos de una cuenta a la otra y todas esas transacciones deben procesarse dentro de un marco de tiempo predeterminado para fines de cumplimiento. Por lo tanto, nuevamente tiene que manejar millones de solicitudes dentro de un período de tiempo que quizás no pueda hacer desde una sola computadora. Por lo tanto, debe poder escalar incluso en ese caso. Entonces, si tiene alguna de estas aplicaciones que necesitan escalabilidad, esta es una charla adecuada a la que ha venido.
El problema de la escalabilidad
Entonces, definamos también el problema de escalabilidad. ¿Cuál es el problema de escalabilidad? Bueno, el nivel de la aplicación se escala de forma lineal. Puede tener una aplicación web ASP.NET o servicios web. Tendrá un equilibrador de carga frente a él que enrutará el tráfico de manera uniforme a todos los servidores. Puedes agregar más servidores, no hay problema. Todo funciona perfectamente bien. Estuve hablando con alguien antes acerca de que la base de datos se convirtió en un cuello de botella y no estaban de acuerdo conmigo. Entonces, creo que esta es una buena oportunidad para tener esa discusión.
Entonces, la base de datos en sí funciona súper rápido. No hay problema con el rendimiento. Las bases de datos son muy inteligentes, hacen mucho almacenamiento en memoria caché en su propio servidor, pero la escalabilidad es algo que, por diseño, no pueden lograr porque puede agregar, por ejemplo, puede agregar 10, 20, 30, 40, 50 servidores en este nivel. Tenemos clientes con 50 o más servidores en su nivel de aplicación porque tienen muchos usuarios. Imagina que eres un gran banco o eres una aerolínea. Tienes millones de personas que visitan tu sitio web. Hiciste esta gran promoción para un boleto a Hawái o algo así. Todo el mundo va a venir, van a hacer la búsqueda de vuelos, quieren comprar los billetes. Puede agregar más servidores aquí sin problema. La base de datos funcionaba súper rápido y el software es excelente, pero por diseño, la base de datos no es una base de datos distribuida. Se mantiene en un solo lugar. Tal vez pueda tener un grupo de dos servidores, activo-activo, activo-pasivo, pero realmente son más por confiabilidad que por escalabilidad.
Entonces, realmente no puedes tener 10 servidores aquí, a menos que sea un NoSQL database, entonces tú puedes. Pero, para una base de datos relacional, cualquiera de ellos podría ser un servidor SQL, Oracle, Db2, MySQL, son súper rápidos. Es posible que incluso estén haciendo mucho procesamiento en la memoria, pero se convertirán en el cuello de botella a medida que necesite escalar más y más. Y básicamente, cuando tienes mil o más usuarios simultáneos o simultáneos, empiezas a notar problemas de rendimiento ya medida que creces de 1,000 a 5,000, de 5,000 a 10,000 1000, ahí es donde empiezas a ver más. Entonces, lo que hemos visto es, si tiene 5,000 usuarios, puede o no usar el almacenamiento en caché, pero a medida que crece a 10,000, 15,000 XNUMX, XNUMX XNUMX usuarios, definitivamente siente el dolor y termina con esta escalabilidad. cuellos de botella
Ahora las bases de datos relacionales o las bases de datos heredadas de mainframe tienen este problema. es una de las razones NoSQL databaseEl movimiento que comenzó fue por eso. Aunque, también tiene otros beneficios y tenemos un producto. Permítanme ir rápidamente para fines de referencia. Entonces, tenemos un producto de almacenamiento en caché, pero también tenemos un NoSQL base de datos de documentos. Al igual que Document DB, es una base de datos de código abierto.
¿Entonces NoSQL database definitivamente no tiene los problemas de escalabilidad. Pero, no siempre es la respuesta. ¿Porqué es eso? Porque para que sea una respuesta, un NoSQL database quiere que almacene todos los datos en él. Entonces, a menos que almacene sus datos en un NoSQL database lo que significa que deja de usar la base de datos relacional para al menos esa parte de los datos, no va a resolver su problema. Entonces, en muchos casos, puede mover algunos de los datos, muchos de los datos a un NoSQL database y eso es lo que está impulsando el NoSQL movimienot. Pero, las bases de datos relacionales, los datos de mainframe heredados, están aquí para quedarse. No son algo que pueda desear desaparecer por razones técnicas y comerciales. Entonces, cualquier problema de escalabilidad que tenga que resolver, debe resolverlo con bases de datos relacionales en la imagen. Es por eso NoSQL database no siempre es la respuesta.
La solución: caché distribuida en memoria
Y, la forma de resolver ese problema es, es una nueva mejor práctica que ha surgido en los últimos cinco a diez años, que es el caché distribuido en memoria. Algunas personas también lo llaman cuadrícula de datos en memoria. Microsoft solía llamar al tejido de datos. Aunque, siguen cambiando sus definiciones. Pero es un almacén de clave-valor distribuido en memoria y ahora es una parte esencial de su arquitectura. Si desea una aplicación escalable, necesita programar, debe desarrollar sus aplicaciones con un caché distribuido en mente. Entonces, puede asegurarse de que la aplicación nunca se convierta en un cuello de botella.
Ahora, ¿qué es un caché distribuido? Es esencialmente dos o más servidores de bajo costo. Estos no son servidores de base de datos de gama alta, son cajas de tipo servidor web. Por lo general, una CPU dual, una configuración de 8 núcleos es bastante típica. 16 gigas de RAM es bastante promedio. Vemos que de 16 a 32 conciertos es como el punto óptimo de la memoria. Más de 64 gigas, ni siquiera lo recomendamos a nuestros clientes. Decimos agregar otra caja en lugar de hacer que esta caja sea más fuerte. Porque, si agrega más de 64 gigas, una aplicación .NET tiene esta cosa llamada recolector de basura que requiere mucha potencia de procesamiento. Entonces, cuanta más memoria tenga, más rápida debe ser la CPU para que el recolector de basura pueda recolectar toda esa memoria.
Por lo tanto, es mejor tener más servidores que tener pocos servidores realmente de gama alta. Mínimo de 2 por supuesto, porque quieres confiabilidad. En caso de que algún servidor se caiga, pero luego de esa proporción de 4 a 1 o de 5 a 1, por lo general, tendría, digamos, 2, 3, 4 o 5 servidores en el nivel de aplicación. Lo más común que vemos es entre 4 y 10 y luego, por supuesto, hay muchos clientes que usan más de 10, pero 4 y 10 es más o menos lo que vemos como este punto óptimo. Y, para eso, usa un clúster de 2 servidores. A medida que creces más de 10 o 12, agregas un tercero o un cuarto y así sucesivamente. Y, debido a que un caché distribuido es un almacén de valor clave, está distribuido. Replica datos a través de múltiples servidores de manera inteligente, para que obtenga confiabilidad pero al mismo tiempo no pierda mucho tiempo replicando. Por ejemplo, si cada parte de los datos tuviera que replicarse en todos los servidores, eso es mucho procesamiento adicional que no necesita. Entonces, es ese tipo de replicación inteligente lo que necesita hacer. A veces, necesita tener replicación de esa manera, pero esos son casos especializados. Entonces, un caché distribuido cuando lo tiene en su lugar, irá a él aproximadamente el 80% del tiempo. Todas las lecturas se realizarán desde él y todas las actualizaciones y algunas de las lecturas se realizarán en la base de datos y también en el caché. Entonces, si puede atrapar aproximadamente el 80% del tráfico de su base de datos en su caché, de repente su base de datos es muy liviana. No tiene mucho que ver. Entonces, lo que sea que tenga que hacer, lo hará mucho más rápido. Por lo tanto, el rendimiento mejorará, así como la escalabilidad.
Este caché de distribución en memoria, ya sea NCache, si eso es Redis en el lado de .NET, en el lado de Java hay más jugadores, cualquiera que sea el producto que elija, el caché distribuido es una buena práctica ahora. Tienes que incorporar esto en tu arquitectura.
¿Alguna pregunta sobre esto hasta ahora, antes de continuar? Entonces, sí, un caché lógico puede abarcar varios servidores. En caso de NCache puede tener varios cachés en los mismos servidores. Por lo tanto, cada caché se convierte en su propio contenedor con fines de aislamiento, pero cualquier caché puede abarcar los cinco servidores. Cuando digo intervalo, significa que algunos datos están en un servidor, algunos en los otros, ya sabes, y luego la replicación es una parte separada que puede o no hacerse según sus preferencias. Pero sí, todos los servidores se utilizan para almacenar ese caché y el caché debe ser coherente. Tiene que ser siempre correcto o puede decir que tiene que ser eventualmente correcto pero bastante cerca de ser siempre correcto. Independientemente de lo que almacene en el caché, si actualiza, no le importa dónde están los datos, probablemente ni siquiera sepa dónde están los datos. Todo lo que sabe es que este grupo tiene mis datos y cada vez que los busco, podría haberlos almacenado en este servidor y estoy tratando de leerlos aquí inmediatamente después y debería poder obtener la misma copia. Si puedo hacer eso, entonces esto se convierte en un caché consistente o coherente. Por lo tanto, siempre garantiza esa integridad de datos para las actualizaciones.
Esa es su preferencia y entraré en eso con más detalle en términos de cómo usa realmente el caché. Entonces, una cosa que deberías... quiero decir, el objetivo principal hasta ahora es convencerte de que si quieres escalabilidad, debes tener esto como parte de tu arquitectura.
Usos comunes de la caché distribuida
Entonces, ahora que, digamos, estamos de acuerdo en que necesita un caché distribuido, la primera pregunta que le viene a la mente es ¿cómo lo usa? ¿Dónde lo usas? Para que lo usas? Qué datos se guardan en él y todas las cuestiones relacionadas con esos datos.
Almacenamiento en caché de datos de aplicaciones
Entonces, hay tres casos de uso de alto nivel. El número uno es el almacenamiento en caché de datos de la aplicación, que es de lo que acabo de hablar, que es que tienes datos en la base de datos, los obtienes y los almacenas en caché. Entonces, en el almacenamiento en caché de datos de la aplicación, el objetivo es... pero acabo de mencionar que no desea ir tanto a la base de datos, desea reducir el tráfico de la base de datos para que su aplicación se escale. Pero, los datos ahora existen en dos lugares. Existe en el caché y existe en la base de datos. Entonces, cada vez que existen datos en dos lugares, ¿cuál es la primera preocupación que te viene a la mente? Sincronización entre los dos. Entonces, ¿es consistente? Porque, si los datos no van a ser consistentes, estará limitado a usar el caché para datos de solo lectura. De hecho, la mayoría de las personas cuando les preguntas, ¿para qué usas un caché? La reacción instintiva son datos de solo lectura. Sabes, no me siento cómodo usando el caché para ningún dato que realmente vaya a cambiar, ya sabes, en tiempo real o en tiempo de ejecución. Pero, si no puede usar el caché para los datos transaccionales, término que uso para los datos que cambian con frecuencia, esos datos son probablemente del 80 % al 90 % de sus datos. Entonces, eso significa que del 80% al 90% del tiempo ni siquiera puedes usar el caché y si ni siquiera puedes usar el caché, entonces se vuelve como un NoSQL database. No siempre es la respuesta, ya sabes. Y desea que sea la respuesta, así que ya sabe, por lo que un buen caché distribuido debe brindarle la confianza de que todo lo que almacene en caché será coherente con la base de datos. Si no es así, entonces ese caché no es el caché adecuado para usted. Entonces, eso es lo primero, ese es el primer caso de uso.
Almacenamiento en caché específico de ASP.NET
El segundo caso de uso es si tiene aplicaciones ASP.NET.
- Caché de sesión ASP.NET
Puede almacenar sus sesiones en el caché. Ya sabes, las sesiones son algo que tienen casi todas las aplicaciones ASP.NET. Se mantienen en modo In-Proc o en el modo de servidor SQL. El servidor SQL no es un lugar adecuado para mantener sesiones por dos razones, una, por supuesto, la primera razón que es que cuanto más se guardan datos en la base de datos, mayor es el cuello de botella de escalabilidad que se tiene. La segunda es que las sesiones se mantienen como blobs y las bases de datos relacionales no se diseñaron realmente para blobs. Fueron diseñados para datos más estructurados que puede indexar y buscar. Mientras que, un caché distribuido el valor de la clave, el valor es siempre un blob. Por lo tanto, estas sesiones encajan muy bien con un caché distribuido.
- ASP.NET View State Almacenamiento en caché
El segundo tipo de datos ASP.NET es, si no está utilizando el marco MVC, que muchas de las aplicaciones ASP.NET existentes aún no utilizan, entonces tiene esto llamado Ver estado y un estado de vista no es más que una cadena cifrada que se guarda y se envía desde el servidor web al navegador, solo para volver al servidor web y puede crecer bastante. Puede ser cientos de kilobytes fácilmente, por lo que consume mucho ancho de banda adicional. Se necesita más tiempo para viajar. Cuando multiplica eso por millones de solicitudes que está procesando, su costo de consumo de ancho de banda también aumenta bastante. Por lo tanto, es un caso ideal para almacenar en caché en el lado del servidor y solo enviar una clave pequeña. Entonces, la próxima vez que se supone que se debe usar View State, la clave se devuelve y View State se obtiene de la memoria caché.
- Almacenamiento en caché de resultados de ASP.NET
El tercer ejemplo de almacenamiento en caché específico de ASP.NET es la salida de página. Es parte de la ASP.NET framework se llama caché de salida que le permite almacenar en caché la salida de una página si no va a cambiar y puede usar un caché distribuido para almacenarlo en caché en lugar de mantenerlo en cada servidor web por separado, lo que luego se convierte en varias copias que deben sincronizarse. Por lo tanto, estos tres casos de uso o tres ejemplos son para el caso de uso de almacenamiento en caché específico de ASP.NET.
Ahora, a diferencia del almacenamiento en caché de datos de la aplicación aquí, la naturaleza del problema es muy diferente. Aquí los datos solo existen en el caché. Quiero decir que todos estos datos ya no se almacenan en ningún otro lugar. Por lo tanto, no se almacena en la base de datos. Entonces, ya no tiene ese problema de sincronización entre la base de datos y el caché. Pero ahora tienes otro problema. Si tiene un caché en memoria, ese es el único almacén de sus datos. ¿Cuál es la mayor preocupación? ¿Qué podría salir mal con eso? Desaparece. Sí, puede desaparecer. Si algún servidor se cae y los servidores se caen, incluidas las ventanas. Entonces, cuando un servidor se cae, pierdes datos y especialmente algunos de los, me refiero a View State y Session State, me refiero a la caché de salida, incluso si la pierdes, solo vuelves a ejecutar la página pero estos dos. Por ejemplo, Estado de sesión, acaba de tener este cliente de una aerolínea que realizó todo tipo de búsquedas de vuelos y está a punto de realizar el pedido y el servidor falla y su sesión se pierde, tiene que iniciar sesión de verdad. Sabes, puedes perder ese cliente. Entonces, definitivamente no quieres perder. Por lo tanto, no desea que estos datos desaparezcan. Entonces, en esto, la sincronización fue el gran problema aquí, es la confiabilidad.
Entonces, la confiabilidad se maneja a través de la replicación. Cualquier caché que no haga replicación no puede almacenar sesiones en él. Por cierto, lo bueno del almacenamiento en caché específico de ASP.NET es que no se necesita programación. Encaja completamente dentro del ASP.NET framework. Desafortunadamente, tiene que programar para el almacenamiento en caché de datos de la aplicación. En el lado de Java, no tiene que hacerlo o, de hecho, están surgiendo más estándares. Hay un estándar llamado JCache que, si lo programa, cualquiera de los cachés de terceros simplemente se conecta y luego no tiene que apegarse a ningún caché. Más aún, si usa un motor de mapeo OR como Hibernate o en el caso de .NET NHibernate, puede conectar un caché. Entity Framework hasta el núcleo de EF o hasta antes del núcleo de EF, no permitía que un caché de terceros se conectara automáticamente. Aunque habíamos implementado un proveedor ADO .NET para EF6. Eso fue más de almacenamiento en caché a nivel de ADO.NET, por lo que estaba almacenando consultas en caché, lo cual es mejor que no almacenar en caché, pero no es tan poderoso como el almacenamiento en caché a nivel de entidad donde también puede realizar un seguimiento de las actualizaciones.
Entity Framework o almacenamiento en caché de EFCore
El nuevo EF7 o EF Core tiene una arquitectura mucho más flexible. Le permite conectar un caché de terceros. Entonces, cuando cambie a EF Core, podrá conectar un caché distribuido como NCache sin ninguna programación. Entonces, solo estaba haciendo su programación estándar y los complementos de caché. Pero aparte de eso, tiene que hacerlo. Pero, incluso en ese complemento, no puede usar todas las funciones de las que hablaré. En ASP.NET específico, al menos, esta es la victoria más fácil. Cuando trae un caché, dado que no hay programación involucrada, solo necesita realizar algunas pruebas básicas de cordura y su aplicación de repente ve un gran aumento en el rendimiento y la escalabilidad.
¿Alguna pregunta, antes de continuar? ¿En términos de aplicación o en términos de caché? En términos de caché. Un caché es como una base de datos. Al igual que hace llamadas a la base de datos y luego tiene manejo de excepciones. Si algo sale mal en el caché, el caché generará una excepción, lo detectará y luego deberá tomar las medidas adecuadas. Sin embargo, a diferencia de una base de datos donde una actualización puede fallar en la integridad de los datos porque puede tener restricciones de verificación u otras restricciones de integridad referencial, ninguna de esas restricciones existe en el caché. Un caché aceptará todos los datos que le des. La única vez que fallará una actualización u operación de caché es cuando algo va mal con el sistema. Sí, algo catastrófico. Por lo tanto, no tiene que preocuparse de que el caché no actualice sus cosas en una operación normal.
Seguridad
Entonces, eso depende del producto de caché que use. NCache tiene todas esas funciones integradas. Puede activar EN LINEA, por lo que todo usuario que utilice la caché debe estar autenticado/autorizado. También tiene muchas otras medidas de seguridad, como el cifrado incorporado. Por lo tanto, si la aplicación que tiene es muy confidencial, puede cifrar los datos antes de que se almacenen en caché y todo eso lo hace automáticamente el caché sin que usted haga ningún esfuerzo adicional. Porque, como dije, uno de los mayores usuarios de NCache es la industria de servicios financieros. Porque tienen mucha banca en línea. Una gran cantidad de comercio electrónico ocurre allí y sus datos son muy confidenciales. Entonces, eso depende del producto que elijas.
Intercambio de datos en tiempo de ejecución a través de eventos
El tercer caso de uso es uso compartido de datos en tiempo de ejecución a través de eventos. Al igual que usa las colas de mensajes, MSMQ es uno, RabbitMQ es otro. Tienen muchas más funciones en términos de mensajería para un entorno distribuido en más de una ubicación. Si su aplicación está en un solo centro de datos y necesita hacer Pub / Sub tipo de intercambio de datos, una caché distribuida es mucho más escalable que cualquier otra cola de mensajes. Puede que no tenga tantas funciones como ellos, pero es posible que no necesite todas esas funciones. Pero, es mucho más rápido y mucho más escalable y eso es cierto para NCache eso también es cierto para otros cachés distribuidos que brindan esta función. Porque, de nuevo, todo este grupo se convierte en un bus de mensajes. Entonces, si está realizando mucha actividad, los eventos se propagan muy rápidamente porque hay más de un servidor para manejar esos eventos y puede agregar más servidores a medida que crece la carga.
Entonces, muchas de estas aplicaciones de servidor en estos días tienen flujos de trabajo integrados, ya sabes. Donde una aplicación hace algo y una vez hecho eso, otras aplicaciones hacen otra cosa. De ahí viene el concepto Pub/Sub o productor/consumidor. Hay una función de notificación de eventos. NCache tiene esta característica llamada consulta continua que es una característica muy poderosa, que también existe en el lado de Java, pero ninguno de los otros cachés de .NET la tiene.
Por lo tanto, el uso compartido de datos en tiempo de ejecución también es algo que debe considerar realizar a través de un caché distribuido, lo que hace que su vida sea mucho más simple en lugar de incorporar muchos otros productos. Incluso aquí, la naturaleza del problema suele ser la misma, que es que los datos que intenta compartir solo existen en la memoria caché. Puede existir en la base de datos pero en una forma diferente, porque lo ha construido, lo ha producido, ya sabe, ha reunido una gran cantidad de datos y en esta forma final o intermedia lo está compartiendo con alguien. más. Entonces, si pierde esos datos, debe rehacer todo. Entonces, aunque no es tan malo como las sesiones, todavía tiene muchas implicaciones de rendimiento. Por lo tanto, no desea perder esos datos. Entonces, nuevamente aquí, la preocupación es asegurarse de que el caché sea confiable.
Entonces, esos son los tres casos de uso de alto nivel que proporciona un caché distribuido. Como dije, un caché distribuido es esencialmente una base de datos en memoria distribuida, un almacén de valor clave.
Demostración práctica
Antes de pasar a más detalles sobre cómo puede hacer esto, le mostraré rápidamente cómo se ve un caché distribuido. Entonces, puede ver cómo sería si lo usara en su aplicación. por supuesto voy a usar NCache como el ejemplo. NCache es un caché de código abierto. Por lo tanto, puede usarlo sin comprarlo si no tiene el dinero o no tiene el presupuesto. Si su proyecto es más sensible al negocio, entonces, por supuesto, compre la Enterprise Edition. Entonces, configuré algunas máquinas virtuales en Azure que voy a usar. Voy a usar un clúster de caché de 2 nodos, así que tengo 'demo1' y 'demo2' como mis servidores de caché y 'demo-client' es mi caja de servidor de aplicaciones. Entonces, esa es su caja de servidor ASP.NET. Entonces, un NCache El cliente es realmente su servidor de aplicaciones.
Estoy conectado a, digamos, cliente de demostración. Entonces, lo primero que voy a hacer es crear un nuevo caché. Entonces, voy a usar esta herramienta llamada NCache gerente. Entonces, es una herramienta de estilo explorador. Solo voy a decir crear un nuevo caché agrupado. En NCache todos los cachés tienen nombre.
Elegiré una estrategia de almacenamiento o de replicación.
Voy a seguir adelante y especificar mi primer servidor de caché aquí. Especificar mi segundo.
Voy a continuar y diré aquí la cantidad de memoria que debe consumir mi servidor. En tu caso, va a ser mucho más. Acabo de especificar un concierto.
Entonces, si se consume esa memoria, puede especificar políticas de desalojo. Por lo tanto, digamos que la política utilizada al menos recientemente significa desalojar algunos de los elementos que se usaron menos recientemente.
Entonces, acabo de recibir eso. Continuaré y agregaré un nodo de cliente, que es mi casilla, y continuaré e iniciaré el caché.
Entonces, ¿en qué máquina estás configurando esto? Este es un azul. Entonces, estos dos son mi demo1 y demo2. Entonces, en realidad estoy conectado a este cuadro y estoy usando NCache manager aquí y estoy creando un grupo de demo1 y demo2 aquí.
Entonces, ahora que comencé esto, puedo continuar y puedo ver las estadísticas. Entonces, puedo ver algo de actividad en el contador PerfMon. También puedo lanzar esta herramienta de monitoreo de NCache eso me permite ver cosas y luego ejecutaré rápidamente esta herramienta llamada Stress Test Tool. Le permite probar rápidamente el caché en su entorno para ver cómo va a funcionar.
Entonces, esa herramienta es como su aplicación. Puede usarlo para simular diferentes tipos de carga, diferentes tipos de operaciones. Por ejemplo, estoy haciendo alrededor de 600 solicitudes por segundo aquí y alrededor de 700 a 800 cada una.
Permítanme ejecutar una instancia más de Stress Test Tool, aquí mismo. Entonces, verás que esa carga se duplicará. Entonces, a medida que sigo agregando más y más instancias de la aplicación, la carga en el caché aumentará hasta el punto en que estos dos servidores se maximizarán y luego solo agregará un tercero.
Y puede hacer todo eso en tiempo de ejecución sin detener nada. Entonces, de repente su infraestructura... Piense en esto, si su base de datos comenzó a atascarse, ¿realmente puede agregar otro servidor y salir de ese problema? no puedes Porque, por la naturaleza de eso y no se trata de una base de datos específica, son todas bases de datos relacionales. Pero, en el caso de un caché, simplemente agregue otro servidor y ahora el caché está funcionando.
Entonces, así es como se ve un caché. Es así de fácil de usar y configurar como puede ver. Quiero decir que lo único que no hice es instalarlo. Que era solo un instalador de Windows que, ya sabes, no lleva tanto tiempo. Entonces, aparte de eso, para calcular un clúster de dos nodos, me llevó unos cinco minutos.
Y, ahora que tengo todo esto configurado, puedo especificar este nombre de caché en las aplicaciones que se ejecutan en este cuadro. Entonces, si tuviera más cajas de clientes, las seguiría agregando aquí.
En tu caso para estos dos probablemente tengas 8 o 10 de estos. Entonces, los agregaría a todos y luego, una vez que haga este caché, el caché de demostración está disponible allí y luego simplemente va y actualiza su cosa.
Entonces, ahora que sabemos cómo se ve un caché, permítanme pasar rápidamente al siguiente tema. Entonces, como dije, la forma más fácil de usar el caché es usarlo para las sesiones. ¿Cómo puedo hacer eso? Entonces, tengo la aplicación ASP.NET. Entraría y abro web.config y haré dos cosas. Primero iré y agregaré el ensamblaje.
...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=1448e8d1123e9096" />
</assemblies>
</compilation>
...En caso de NCache esa es la asamblea que implementa el Proveedor de estado de sesión de ASP.NET. Así es como NCache se conecta al ASP.NET framework. Cualquier caché de terceros tendría que hacer eso. Entonces, solo agrega esa línea en los ensamblajes y, en segundo lugar, solo va a la etiqueta de sesiones y especifica esto específico para el caché distribuido que elija.
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...En caso de NCache simplemente copia esto y hay un par de cosas de las que debes asegurarte. Primero debe asegurarse de que el modo sea 'personalizado'. Entonces, porque personalizado significa almacenamiento de terceros. Y, luego, 'tiempo de espera', asegúrese de que sea lo que desea que sea y todo lo demás que pueda mantener como predeterminado y simplemente especifique un nombre de caché aquí, allí mismo. Entonces, debería ser solo 'demoCache'. Tan pronto como realice este cambio y vuelva a ejecutar la aplicación o, de hecho, tan pronto como guarde esto, sabrá que el proceso de trabajo de ASP.NET se recicla. recogerá NCache configuración y de repente verá que cada sesión será una cuenta. Entonces, todos esos, ya sabes, ese recuento que estábamos viendo en NCache en este PerfMon aquí.
Por lo tanto, se almacenarían 540 sesiones y, por supuesto, a medida que agregue más sesiones, aumentará el conteo.
Entonces, con este pequeño esfuerzo, puede darle un gran impulso a su aplicación de inmediato. Lo mismo ocurre con el estado de vista. Con el caché de salida hay un poco más de configuración involucrada, pero el estado de la vista y la sesión se pueden hacer en cuestión de minutos, sin ningún esfuerzo y, de repente, las aplicaciones usan un gran impulso.
Descripción general del almacenamiento en caché de datos de aplicaciones (API)
Así que ahora, pasemos al almacenamiento en caché de datos de la aplicación, que es de lo que trata la mayor parte de esta charla. Entonces, si necesita usar el caché para el almacenamiento en caché de datos de la aplicación, debe programar su API. Eso es porque todavía no hay una API estándar. Entonces, lo que hicimos fue elegir nuestra API para que estuviera lo más cerca posible del objeto de caché de ASP.NET.
Conexión de cachéCache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");NCache ha existido desde 2005, entonces, son como casi 11 años y medio ahora. Pero se parece mucho al objeto de caché de ASP.NET. Hay algunas cosas adicionales, así que digamos que te conectas al caché por un nombre de caché. Obtienes un identificador de caché. Entonces ese identificador de caché es lo que usas para hacer caché.Obtener. Obtener contiene Agregar, Insertar, Eliminar y hay una versión Async de él, lo que significa que no espere a que se actualice el caché y, por supuesto, cuando llame a Async, puede especificar una devolución de llamada. Por lo tanto, se llama a su devolución de llamada en caso de que algo salga mal.
Déjame mostrarte cómo se ve esto en una imagen, como en una aplicación adecuada. Entonces, si tuviera una... Esta es una aplicación de consola estándar. Debería hacer referencia al ensamblado de su caché. En caso de NCache, son solo estas dos asambleas, Alachisoft.NCache.Tiempo de ejecución, Alachisoft.NCache.Web. Usted especifica los mismos espacios de nombres aquí y luego al principio de la aplicación que, en el caso de ASP.NET, probablemente estará en el global.asax en el método Init o el método de inicio de la aplicación. Pero, aquí digamos, te conectas con el caché basado en el nombre del caché y el nombre del caché, como sabes, así es como, al menos en NCache así es como se reconoce el caché y obtienes un identificador de caché. Luego creas tus objetos y haces un caché.Agregar. Usted especifica la clave. Esta no es una buena clave. debería tener más singularidad en él. Pero, digamos, que especifica la clave y aquí está su valor, el objeto real.
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");
...Caducidad de datos
Y, en este caso NCache está haciendo esta cosa llamada caducidad absoluta. Así que déjame, vamos a eso. Entonces, hablamos sobre el almacenamiento en caché de datos de la aplicación que desea mantener el caché actualizado. Por lo tanto, si no puede mantener el caché actualizado, debe usarlo para datos de solo lectura. Entonces, ¿cómo mantienes el caché actualizado? Hay más de una forma. La primera forma, que prácticamente todos los cachés tienen, se llama vencimiento absoluto. Aquí es donde especifica cuánto tiempo desea mantener esto en el caché. Entonces, le dices a la memoria caché Me siento cómodo solo por un minuto que no creo que estos datos deban permanecer en la memoria caché por más de un minuto porque, creo que si se mantuvieran en la memoria caché por más de un minuto alguien más lo va a actualizar y el caché quedará obsoleto. Por lo tanto, está haciendo una suposición informada sobre cuánto tiempo el caché debe tener sus datos. Y, por supuesto, todos los datos que almacena en caché deben tener algún tipo de vencimiento. Más o menos... Me refiero a algunos datos que puede suponer que nunca caducan, por lo que puede decir que no caducan. Pero, el 99% de los datos o algo más del 90% de los datos deben tener vencimientos. Por lo tanto, la caducidad absoluta es lo que mantiene el caché actualizado en función de una conjetura informada.
Hay otro vencimiento llamado vencimiento deslizante. Su propósito es totalmente diferente. Aunque usa el mismo nombre llamar caducidad. La caducidad deslizante dice caducar esto si nadie toca este objeto durante tanto tiempo, digamos durante 10 minutos, durante 20 minutos. Y, esto se usa para más datos transitorios. Entonces, esto se usa para más datos específicos de ASP.NET, donde en realidad solo está limpiando. Estás diciendo, ya sabes, nadie más lo necesita. Entonces, si un usuario ya no usa la sesión durante 20 minutos, está diciendo que este usuario cerró la sesión de todos modos, así que elimine la sesión. Entonces, esa es una caducidad de limpieza. Luego, la caducidad absoluta, que es un propósito de sincronización. El propósito de la caducidad absoluta es la sincronización. Y de nuevo puedes hacerlo, puedes caducar cosas en 10 segundos, 15 segundos, 1 minuto, 5 minutos, 10 minutos. La caducidad más común probablemente sea de uno o dos minutos.
Pero, hay un problema con la caducidad. Es que estás haciendo una conjetura. Estás diciendo que creo que está bien almacenarlo en caché durante tanto tiempo. Pero, no hay garantía. En algunos casos puede haber, pero en muchos casos no hay garantía. ¿Qué pasa si hay otra aplicación que también está accediendo a la misma base de datos y van y actualizan esos datos? Es posible que se estén ejecutando algunos scripts. Entonces, cada vez que sucede algo así, los vencimientos no son suficientes. Y ahí es donde necesita el caché para tener esta capacidad de monitorear cambios en la base de datos.
Si puede especificar una asociación entre lo que está en la memoria caché y los datos correspondientes en la base de datos y puede decirle a la memoria caché, controle este conjunto de datos. Si este conjunto de datos cambia, continúe y elimine ese elemento del caché.
Dependencia de la base de datos
Déjame mostrarte cómo se hace eso. Entonces, hay una característica llamada dependencia SQL en ADO.NET que NCache usos. Que permite NCache convertirse en cliente de su base de datos. Y, esto podría ser una base de datos SQL, esto podría ser Oracle. Y entonces NCache le dice a la base de datos que le notifique cuando ese conjunto de datos cambia y ese conjunto de datos es una declaración SQL que usted especificó. La mayoría de las veces corresponderá a una o más filas de una tabla que se usaron para construir este objeto que almacenó en caché. Entonces, por ejemplo, aquí, entonces, si tuviera que ir a la dependencia de SQL, nuevamente lo mismo. Tiene un identificador de caché y luego, cuando está agregando, este caché.Agregar, ahora está especificando, en caso de NCache esta cosa llamada elemento de caché que es una especie de estructura que contiene el valor más algunos otros metadatos. Uno de los metadatos que contiene se denomina dependencia de caché de SQL, que es un NCache clase que se asigna a la dependencia de caché SQL de ADO.NET en el extremo del servidor. Le pasa una cadena de conexión y le pasa una declaración SQL.
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);
// Let's create SQL depdenency
CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlServerDependency;
// Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
_cache.Add(cacheKey, cacheItem);
}Entonces, diga algo como 'Seleccione algunas columnas de los Productos donde el Id. del producto sea el valor que sea'. Entonces, este es un producto al que está asignando esto. Entonces, le estás diciendo a NCache use esta declaración SQL, use esta cadena de conexión y monitoree ese conjunto de datos o solicite al servidor SQL que monitoree ese conjunto de datos. En realidad, este código se está ejecutando aquí, a la derecha. Porque, ahí es donde el NCache .
Entonces, esto luego habló con el clúster de caché y el servidor de caché luego hace la llamada ADO.NET y el servidor de caché ahora habla con la base de datos y se convierte en un cliente. Y, el servidor de caché es el que recibe la notificación. Y, el servidor de caché es el que realmente elimina ese elemento del caché, si la base de datos le notifica que estos datos cambiaron. Entonces, al tener esa función incorporada, de repente tiene la flexibilidad de poder mantener datos en el caché que ni siquiera puede predecir cuándo podrían cambiar, ya sabe. Pero, solo sabe que puede cambiar de manera impredecible, por lo que puede usar la dependencia específica de SQL.
Esta es una característica realmente poderosa. Esta es la función que permite que un caché le permita almacenar en caché datos transaccionales. Incluso cuando no tiene control sobre las actualizaciones todo el tiempo y debido a eso almacenará en caché todo tipo de datos porque ese caché se volverá realmente útil. Y, esto se puede hacer de varias maneras si la base de datos subyacente admite la notificación de la base de datos, que es el caso en el caso del servidor SQL y Oracle, entonces utilizará la función de dependencia de SQL o de Oracle, si no, el NCache al menos tiene un mecanismo de sondeo incorporado donde también puede permitirle especificarlo. … Hay un mecanismo en el que especificas una tabla especial NCache lo supervisa y cualquier fila que cambie en él hay un elemento de caché correspondiente que luego elimina.
Y, una tercera opción es que realmente haga llamadas de caché desde dentro de un procedimiento CLR. Entonces, cada vez que cambia un dato, hay un disparador de base de datos que llama al procedimiento, que llama al caché. Y eso puede agregar datos, actualizar datos o eliminar datos del caché. Lo único que ocurre con el procedimiento CLR es que no desea realizar... Quiero decir, desea realizar llamadas asíncronas. Porque, como sea que la llames, en realidad tu base de datos ahora se ha convertido en un cliente de la memoria caché como al revés, a la derecha. Entonces, está tratando de actualizar algo que irá aquí y luego podría replicarse. Entonces, todo eso sucede dentro de una transacción de la base de datos y, como saben, las transacciones de la base de datos se agotan con bastante rapidez. Por lo tanto, al realizar llamadas asíncronas, puede realizar inmediatamente la llamada de caché y luego devolver el control.
Entonces, esas son las tres formas en que puede asegurarse de que un caché se mantenga sincronizado con su base de datos relacional. Por supuesto, la misma lógica se aplica a lo no relacional. ¿Qué sucede si sus datos están en una nube, en algún lugar? O está en mainframe. Ya sabes, tienes una llamada de método web para ir a buscarlo siempre. Entonces, en caso de NCache al menos, puede tener una función de dependencia personalizada donde su código está registrado en el clúster de caché, NCache lo llama cada, digamos, 15 segundos y dice adelante y verifique su fuente de datos y vea si esos datos han cambiado. Si es así, active un evento y luego se activa la misma lógica.
Entonces, de nuevo mantener el caché fresco es lo más importante en una caché distribuida. Si no puede mantener el caché actualizado, su uso es muy limitado.
Lectura y escritura
Hay otra característica llamada Lectura y escritura. Read-Through es una característica que nuevamente es una característica muy útil y muy poderosa. Es esencialmente nuevamente su código el que se ejecuta en el servidor de caché. ¿Dónde está? Aquí. Entonces, digamos que implementa una interfaz de lectura en caso de NCache. Ahora read-through/write-through es un concepto implementado por NCache. Muchos de los reproductores de Java también lo implementan, pero en el lado de .NET. NCache es el unico que lo tiene. Entonces, la interfaz de lectura es esencialmente su código. Tiene un método Init, un método Dispose, así que Connect and Disconnect y luego el método Load.
...
// 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;
}
...Le da una clave y, según la clave, se supone que debe averiguar dónde ir y obtener los datos. Y no solo devuelve los datos, sino que también devuelve algunos de los metadatos, como los vencimientos y otras cosas. ¿Cuál es el valor de la lectura directa? Entonces, nuevamente, este código es algo que implementas y te registras en... Entonces, es este código el que se ejecuta aquí en el servidor de caché. Entonces, hemos hablado de una dependencia personalizada. Entonces, si tiene una fuente de datos personalizada, ese es un código que se ejecuta en el servidor de caché y la lectura también es algo que se ejecuta en el servidor de caché.
¿Para qué sirve la lectura? ¿Por qué debería utilizar una lectura directa? Hay dos o tres beneficios. Número uno, está consolidando todo su código de persistencia en un solo lugar. Entonces, si tiene múltiples aplicaciones usando el caché, digamos, tiene múltiples aplicaciones, no es necesario que todas implementen ese código una y otra vez. Por lo tanto, se mantiene dentro del propio servidor de caché. Ese es el primer beneficio. El beneficio número dos es que cuando caduca algo, digamos, caduca algo debido a la caducidad o debido a la sincronización de la base de datos, en lugar de eliminar ese elemento del caché, ¿por qué no simplemente recargarlo? Porque, si lo quita, la próxima vez que la aplicación lo quiera, lo volverá a cargar de todos modos. Por lo tanto, puede asignar la lectura completa con esto y decir dónde el caché dice que está bien si este elemento caduca o si se vuelve... si se sincroniza automáticamente y necesito eliminarlo, simplemente llamaré a la lectura completa. Entonces, ¿por qué es bueno llamar a la lectura completa? Quiero decir, ¿cuál es el problema? ¿Por qué no simplemente recargarlo con la aplicación? Bueno, si tiene una aplicación de alto tráfico, es probable que muchos usuarios soliciten los mismos datos. Tienes cientos de miles de estos artículos y todos caducan a su debido tiempo. Por lo tanto, por cada vez que un artículo caduca, tendría cientos, si no miles, de solicitudes llegando a la base de datos para el mismo artículo. Y todos irán y actualizarán el caché nuevamente. Por lo tanto, una gran cantidad de tráfico innecesario va a la base de datos. Que, si tuviera una lectura completa, nunca saldría del caché. Siempre permanecerá en el caché y en algún momento simplemente se actualizará. Entonces, el tráfico a la base de datos nunca ocurre.
La segunda característica es la escritura simultánea, que funciona exactamente como la lectura simultánea, excepto que, por supuesto, es para escribir. Entonces, déjame mostrarte eso. Por ejemplo, aquí nuevamente, tiene Init, tiene Dispose, pero ahora tiene Write y le da el objeto real y luego la escritura podría ser agregar, actualizar o eliminar, ¿verdad? Entonces, los tres se llaman escritura. Entonces, según el tipo de operación que sea, vaya y actualice su base de datos o su fuente de datos.
#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
bool result = false;
OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
Customer value = (Customer)operation.ProviderCacheItem.Value;
if (value.GetType().Equals(typeof(Customer)))
{
result = sqlDatasource.SaveCustomer((Customer)value);
}
if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
return operationResult;
}
public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
throw new Exception("The method or operation is not implemented.");
}Ahora, la escritura simultánea tiene otro beneficio. Tiene el mismo beneficio que la lectura directa en términos de uniformidad del código. El segundo beneficio que tiene la escritura directa se llama escritura diferida. Que es eso, puedes actualizar. Por lo tanto, hay una función llamada escritura diferida en la que puede actualizar la memoria caché inmediatamente de forma síncrona, pero las actualizaciones de la base de datos se realizan de forma asíncrona. ¿Por qué es eso algo bueno? Bueno, porque esa base de datos es lenta. Entonces, si sabe, si está seguro de que la actualización de la base de datos se realizará a tiempo... es predecible, ¿por qué no simplemente ponerla en cola? Se pone en cola y el caché realmente realiza esta operación en segundo plano. Esa cola también se replica en más de un servidor. Por lo tanto, si algún servidor deja de funcionar, la cola no se pierde.
Creo que todo lo que tienes que ver en el contexto de la escalabilidad. Todo lo que sea rápido, incluso si es una base de datos en memoria, está todo en un servidor. Por lo tanto, cuantas más actualizaciones se envían, más lecturas se le envían, más carga se pone en la base de datos, más lenta se vuelve. Al igual que el punto único de falla. Eso es todo. Esa es la verdadera razón por la que todo esto existe y luego, dentro del contexto de todo esto existente, obtienes todos los beneficios adicionales. Si tenía una función de escritura diferida, de repente su aplicación solo tiene que actualizar el caché de forma síncrona. Porque, una vez que se actualiza el caché, el caché se encargará de la actualización de la base de datos de forma asíncrona. Y esa cola tiene su propia optimización. Puede hacer actualizaciones masivas, puede replicar. Entonces, la escritura diferida tiene el rendimiento, la parte de la velocidad de la que habló es más relevante para la escritura simultánea y la escritura diferida que para la lectura simultánea.
La lectura también es algo que, ya sabes, puede ser más rápido en algunos casos que el acceso de la aplicación, pero en la escritura posterior definitivamente siempre es más rápido.
¿Alguna pregunta? Me quedan sólo unos minutos. Voy a hablar de una característica más y luego iré al final. Por lo tanto, las personas que están acostumbradas a realizar el almacenamiento en caché en memoria In-Proc independiente, como el objeto de caché ASP.NET, cuando se trasladan a un caché distribuido, muchos de nuestros clientes nos llaman y dicen, ya saben, prometían que el caché en realidad mejorar mi rendimiento. De hecho, mi rendimiento bajó. ¿Porqué es eso? ¿Alguien puede adivinar? ¿Por qué eso realmente se ralentiza tan pronto como pasa a un caché distribuido en lugar de un caché In-Proc? Latencia de conexion. La latencia de la red es uno. Un problema mayor es la serialización y deserialización, que es un costo enorme.
Caché de cliente o Caché cercano
Entonces, ¿qué está haciendo parte del caché distribuido, incluido NCache, implementan esta cosa llamada caché del cliente, algunos lo llaman cerca de caché. Es un subconjunto de este caché, que se mantiene dentro del servidor de aplicaciones. Incluso puede ser In-Proc o puede ser OutProc. Pero, muchas veces es In-Proc. Por lo tanto, le brinda el mismo beneficio que un caché In-Proc independiente, excepto que está sincronizado con este.
Y, este es un subconjunto más pequeño, así que digamos, esto podría ser de 16 gigabytes cada servidor, esto podría ser solo un gigabit. Y, es una ventana en movimiento, ¿verdad? Por lo tanto, todo lo que está almacenando en caché se mantiene y luego, a medida que avanza, los elementos más antiguos caducan o son desalojados y luego los nuevos datos se almacenan en caché.
Entonces, un caché de cliente le brinda el rendimiento real. Mantiene los datos en forma de objeto dentro del proceso de aplicación. Entonces, si lo está recuperando cientos o decenas de veces, la primera vez, por supuesto, debe obtenerlo del caché distribuido. Tal vez, la primera vez que lo obtenga de la base de datos. Va a la memoria caché distribuida y luego a la memoria caché del cliente, pero una vez hecho esto, todas las lecturas adicionales se realizan dentro de su propio montón, lo cual es súper rápido. Entonces, esta es una característica que es realmente poderosa. Definitivamente quieres aprovechar esto.
Por lo tanto, hay algunas cosas de las que debe asegurarse. Un caché distribuido, al igual que una base de datos, se ejecuta en su centro de datos en su entorno de producción. Por lo tanto, debe cumplir con algunos de los requisitos arquitectónicos. Debe tener alta disponibilidad. Debe dar fiabilidad y escalabilidad a los datos. Por lo tanto, debe hacer una replicación inteligente.
No voy a entrar en los detalles de esto. Puedes mirarlo. Puedes hacer la investigación en línea. Por ejemplo, si tiene varios centros de datos y espera que su base de datos se replique, ¿por qué no la caché? Sabes. ¿Por qué la memoria caché no debería estar disponible también de forma sincronizada en múltiples... Entonces, sí, una buena memoria caché debería estarlo.
Opciones de almacenamiento en caché distribuido de .NET
Si está haciendo aplicaciones .NET, en este momento, ya sabe, hay prácticamente dos opciones que tiene para el almacenamiento en caché. Uno es Redis que Microsoft ha puesto en Azure. El otro es NCache. En el lado de Java, como dije, hay varios jugadores que son bastante buenos.
Entonces, solo quiero hacer una comparación de muy alto nivel.
NCache es la caché .NET más antigua. Ha estado en el mercado desde 2005. Es .NET nativo. También es de código abierto, al igual que Redis. También está disponible en Azure o en Amazon, ambos. Redis … Entonces, hay dos versiones de Redis, desarrollado por Redis Labs, que solo se ejecuta en Linux. De hecho, Microsoft usa esa versión en Azure. Y, la versión que Microsoft portó a Windows, ni siquiera la usan ellos mismos. En realidad, hemos escuchado muchas quejas de los clientes. No es muy estable. Pero, fuera de Azure, la única versión que tiene para Windows es la que portó Microsoft, MS Open Tech. Pero, aparte de eso, si vas a Redis solo te darán la versión de Linux. En Azure mismo hay dos diferencias entre NCache y Azure que es eso NCache en realidad le da un servidor de caché como una máquina virtual. Entonces, puede ejecutar todo ese código del lado del servidor usted mismo, monitorear las cosas. Redis le da caché como un servicio. Entonces, el caché es una caja negra. Solo tiene una API muy simple a la que llama. Y, la limitación de eso es que no obtienes todas las funciones de las que acabamos de hablar. ¿Cómo se sincroniza la base de datos? Lectura a través de escritura a través. En realidad, ni siquiera entré en la búsqueda de SQL porque no teníamos tiempo. Entonces, estas son las dos formas en que puedes hacer esto. Si desea obtener más información sobre esto, puede visitar nuestro sitio web y tenemos un documento comparativo detallado. Entonces, si tuviera que entrar Redis vs NCache aquí, puede ver un documento completo. También puedes descargarlo. Es una comparación característica por característica basada en su documentación y la nuestra y luego puede ver cuál satisface sus necesidades. ¿Alguna pregunta? Ese es el final de mi charla. Gracias.
¿Hay alguna dependencia de .NET Core Framework o puedes usarlo con .NET 4.0? Buena pregunta. Asi que, NCache soportes de servidor .NET frameworks. Es 4.0 o posterior. los NCache El cliente por defecto es .NET framework por supuesto. Estamos a punto de lanzar el .NET…. Entonces, apoyamos ASP.NET Core. Entonces el .NET Core que puede ejecutarse en Linux, aún no lo admitimos porque tiene limitaciones. Pero el .NET Core que se ejecuta en ASP.NET framework, debajo solo en Windows, especialmente ASP.NET Core NCache lo apoyará. Muchas gracias muchachos.