Charla en Live 360 Orlando 2016
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
¿Qué es la escalabilidad?
Entonces, comencemos con algunas definiciones. Estoy seguro de que la mayoría de ustedes ya saben esto, pero lo repasaremos para completarlo. La primera definición es escalabilidad. Entonces, ¿qué es la escalabilidad? La gente a menudo confunde la escalabilidad con el rendimiento. El rendimiento es un tiempo de respuesta realmente rápido por aplicación, pero eso podría ser solo con cinco usuarios y si pasa de cinco usuarios a cinco mil o 50,000 XNUMX usuarios y ese rendimiento sigue siendo bueno, entonces su aplicación es escalable. Esa es la esencia de lo que estamos tratando de lograr.
Independientemente de la aplicación que tenga, si puede lograr el mismo rendimiento que tenía con cinco usuarios o una carga de transacciones realmente baja, si puede lograr el mismo rendimiento con una carga de transacciones alta, entonces es escalable. Si no tiene un buen rendimiento con cinco usuarios, entonces tiene otros problemas.
Escalabilidad lineal
La escalabilidad lineal es más una definición de infraestructura, que es que si su aplicación está diseñada de tal manera que agrega más servidores a la implementación, ya sea agregando más servidores de aplicaciones o servidores de bases de datos o lo que sea, si eso puede aumentar la capacidad de transacción en un lineal moda, entonces tiene una arquitectura de aplicación linealmente escalable.
Sin embargo, si no puede hacer eso, si agregar más servidores no agrega ningún valor, entonces hay algo fundamentalmente incorrecto y no puede escalar la aplicación de manera lineal. El objetivo aquí es, por supuesto, poder escalar de forma lineal.
Escalabilidad no lineal
No lineal sería donde, a medida que agrega más servidores, ve un aumento, pero en cierto punto después de eso, no hay más aumento, de hecho, hay una caída del rendimiento incluso si se agregan más servidores porque la arquitectura de la aplicación y la implementación presentan algunos cuellos de botella. que simplemente no eres capaz de superar.
¿Qué aplicaciones necesitan escalabilidad?
Suelen ser aplicaciones web.
Entonces, estos son ASP.NET para gente de .NET, servicios web, back-end para Internet de las cosas, que es un espacio emergente muy fuerte y procesamiento de big data. El procesamiento de big data es más común en el lado de Java. No mucha gente lo hace en el lado de .NET, pero el procesamiento de big data también es otro espacio. Y, cualquier otra aplicación de servidor, esta podría ser su aplicación de procesamiento por lotes. Usted puede ser una empresa de servicios financieros y tiene millones de clientes y ellos llaman y cambian de dirección o tal vez están transfiriendo fondos de una cuenta a otra y tiene cierto requisito de cumplimiento que en medio de la noche o algo tiene para completar esos procesamientos y hay algunos procesamientos por lotes en el backend, en un flujo de trabajo, de alguna manera. Por lo tanto, cualquier otra aplicación de servidor que tenga limitaciones de tiempo para realizar una cierta cantidad de transacciones necesita escalabilidad.
Problema de escalabilidad
Entonces, ¿dónde está el problema de escalabilidad? Hablamos de escalabilidad lineal y no lineal. Entonces, el problema de escalabilidad es que el nivel de la aplicación se escala de una forma lineal muy agradable. Si tiene una aplicación web o servicios web, su nivel de aplicación, solo agrega más servidores, no hay problema. El almacenamiento de datos es el cuello de botella. Y, cuando digo la palabra almacenamiento de datos, me refiero a bases de datos relacionales y datos heredados de mainframe. no me refiero NoSQL database. NoSQL databaseson geniales También tenemos un NoSQL producto llamado NosDB pero ninguna base de datos SQL no siempre es la respuesta. Son una respuesta si puede mover cuantos más datos mueva a NoSQL database es más de una solución de escalabilidad que obtiene. Pero el problema es que no puede mover todos los datos a NoSQL. Hay una gran cantidad de datos que deben permanecer relacionales por razones técnicas y comerciales.
Entonces, las bases de datos relacionales llegaron para quedarse. No van a ninguna parte en términos de este problema. Por lo tanto, tiene que solucionar esta realidad o trabajar con esta realidad de que va a trabajar con bases de datos relacionales y todavía tiene que resolver este problema. Y, la razón por la que tienes que solucionar este problema es que tienes todas esas aplicaciones que mencioné que necesitan escalabilidad.
Implementación de caché distribuida
Y, por supuesto, la respuesta es tener un caché distribuido conectado entre el nivel de la aplicación y el nivel de la base de datos.
Entonces, un caché distribuido es, esencialmente, un concepto muy poderoso y, sin embargo, muy simple. Tiene dos o más servidores de bajo costo y están agrupados juntos y ese clúster agrupa la memoria y los recursos de CPU de todos los servidores en una sola capacidad lógica. el cuello de botella y la escalabilidad vienen en tres áreas. Uno es la memoria, el segundo es la CPU, el tercero es la tarjeta de red.
Entonces, si tiene, digamos, un servidor de base de datos aquí y tiene 20 cuadros de nivel de aplicación que un servidor de base de datos puede ocupar en términos de la potencia del hardware, puede agregar más memoria, muchas más CPU, pero hay un límite para eso. Entonces, la respuesta es, para poder tener más y más servidores que no sean de muy alta gama, de hecho, no deberían ser de alta gama por definición. Y, lo que hemos visto en los últimos 10 años o más de hacer esto es que la configuración más común es un tipo equivalente de cuatro núcleos de CPU dual. Entonces, digamos que una caja de 8 núcleos y una caja de 16 núcleos es en realidad una configuración bastante avanzada para un servidor de almacenamiento en caché. 8 núcleos es más o menos lo común.
Memoria, por supuesto, se necesita mucha memoria porque la memoria es barata, así que no es un factor importante. Necesita mucha memoria, porque el caché es un almacén en memoria, por lo que almacena todo en la memoria y, una configuración típica sería de aproximadamente 16 a 32 gigas de memoria en cada servidor de caché y 2 servidores de caché es el mínimo que debe tener con fines de redundancia. Entonces, al tener esta arquitectura, ahora se encuentra en una situación en la que agrega más servidores en el nivel de la aplicación. Agrega más servidores proporcionalmente en el nivel de almacenamiento en caché. Entonces, por lo general, una proporción de 4 a 1 o de 5 a 1 es lo que hemos visto como el más práctico. En algunos casos, puede ir mucho más de 5 a 1. Significa 5 servidores de aplicaciones por 1 servidor de almacenamiento en caché, pero no hay límite para la cantidad de servidores que puede tener. Puede tener 2, puede tener 4, 10, 20, 30 servidores, pero para tener 20 servidores aquí, probablemente necesite cien servidores en el entorno del balanceador de carga.
Entonces, en algún momento, eso se convierte en un extremo superior de cualquier aplicación que hayamos visto en la web o el comercio electrónico en el escenario comercial en línea. Entonces, al agregar más servidores aquí, este ya no es el cuello de botella. Por lo tanto, el almacenamiento en caché distribuido se está convirtiendo en una buena práctica. Si tiene escalabilidad como la necesidad. Porque ahora, no solo tiene una base de datos que está allí para su propio propósito, necesita persistencia de almacenamiento de datos permanente para todos los datos de la aplicación, sino que también tiene esta infraestructura realmente rápida y escalable que ahora es parte de la arquitectura de su aplicación. Entonces, cuando está programando, ya no está simplemente programando para la base de datos. Siempre está pensando en un caché porque el caché ahora se asegurará de que su aplicación nunca se ralentice, incluso bajo cargas máximas. Aunque la base de datos no fue diseñada para escalar de la misma manera. Entonces, esta es una imagen típica.
Alrededor del 80 % del tráfico quedará atrapado o el 80 % del tiempo irá al caché, el 20 % del tiempo irá a la base de datos y ese 20 % son en su mayoría actualizaciones y, por supuesto, algunas lecturas porque necesita obtener datos en el caché, pero también puede rellenar previamente el caché y hay muchas otras formas de hacerlo. Pero, al reducir el tráfico de manera tan drástica en el nivel de la base de datos, así es como se logra el rendimiento y la escalabilidad.
Entonces, ese es el caso para usar un caché distribuido. Por qué debe mantener eso como parte de la arquitectura de su aplicación.
Casos de uso común
Entonces, ahora que hemos defendido el uso de un caché distribuido, la siguiente pregunta es ¿cómo se usa? Dónde lo usas? ¿Qué tipo de uso debe tener de un caché distribuido?
Almacenamiento en caché de datos de aplicaciones
Bueno, el uso más común es el almacenamiento en caché de datos de la aplicación. Aquí es donde, como estaba hablando, cualquier dato que tenga en la base de datos, lo almacena en caché. Para que no tengas que ir a la base de datos. Lo que hay que tener en cuenta y repasaré este punto con más detalle en las diapositivas de seguimiento es que en un caso de uso de almacenamiento en caché de datos de una aplicación, los datos existen en dos lugares. Uno está en la base de datos que es donde siempre tiene que estar y el segundo es el caché. Entonces, siempre que existan datos en dos lugares, ¿cuál es el primer problema que se te ocurre? ¡Sincronizando! Sí.
Entonces, cualquier caché que no pueda manejar esa situación, lo obliga a almacenar en caché datos de solo lectura, datos que sabe que nunca van a cambiar. De hecho, la mayoría de las personas cuando hablan de caché, el pensamiento instintivo que les viene a la mente es ¿por qué es para datos de solo lectura? Realmente no quiero almacenar en caché mis clientes y cuentas y datos que cambian cada 30 segundos. Pero, la investigación muestra que el mayor uso de un caché está en los datos transaccionales y una vez que lo almacena en caché, probablemente lo necesitará en los próximos uno o dos minutos, sea cual sea esa actividad, sea cual sea la ventana móvil de su uso. Ahí es cuando necesita los mismos datos nuevamente y si puede obtenerlos del caché, está reduciendo esos viajes a la base de datos y multiplicándolos por millones de transacciones que están ocurriendo en su aplicación y se convierte en un impulso bastante significativo. Por lo tanto, tenga en cuenta ese problema a medida que avanzamos, ya que cualquier buen caché debe manejar eso de manera muy efectiva.
Almacenamiento en caché específico de ASP.NET
El segundo caso de uso es que, si tiene una aplicación ASP.NET, hay muchos datos transitorios. Transitorio significa temporal y que puede colocar en el caché y estos datos realmente no pertenecen a la base de datos. Por ejemplo, una base de datos está ahí para permanente. Es una tienda permanente. Ese es su registro maestro. Entonces, un estado de la sesión, probablemente necesite mantenerlo solo mientras el usuario haya iniciado sesión, tal vez 20 minutos después, ya sabe. Entonces, ¿por qué mantenerlo en la base de datos? La base de datos no es tan rápida. Las bases de datos relacionales no se diseñaron para almacenar blobs y, por lo general, las sesiones se almacenan como blobs. Por lo tanto, hay un gran impacto en el rendimiento cuando almacena sesiones en la base de datos. Por lo tanto, el estado de la sesión es un muy buen caso de uso para que ASP.NET lo coloque en la memoria caché distribuida.
Y, si no está utilizando el marco MVC, entonces el estado de vista también está ahí, que es una pieza de datos bastante pesada que fluye desde el servidor web al navegador con un solo propósito, regresar al navegador en una devolución de datos. Entonces, es un viaje bastante largo, para nada como dicen. Por lo tanto, sería mucho mejor si lo mantuvieras en el lado del servidor y enviaras una pequeña clave. Entonces, ese es un muy buen caso de uso para el almacenamiento en caché.
El tercer caso de uso es la salida de la página, la salida de muchas de sus páginas no cambia cada vez. Entonces, si no está cambiando, ¿por qué ejecutar la página porque cuando ejecuta la página está consumiendo la CPU, la memoria y todos los demás recursos? ¿Por qué no simplemente tomar el resultado de la última ejecución y mostrarlo? Entonces, Microsoft o ASP.NET tienen un marco de caché de salida donde puede conectar un caché distribuido. Entonces, ahora en este caso de uso, en estos tres casos de uso bajo ASP.NET, la naturaleza del problema ha cambiado por completo. Ya no es sincronización entre el caché y la base de datos. ¿Por qué? Porque no hay base de datos. Caché es la base de datos.
La naturaleza del problema ahora es... entonces el caché está en la memoria, ¿de acuerdo? Así es como obtienes todo el rendimiento. Entonces, cuando guarda datos en la memoria y ese es el único almacenamiento, ¿cuál es la mayor preocupación que tiene? ¡Puedes perderlo! ¿Qué pasa si esa caja se reinicia? Se sabe que Windows reinicia o recicla procesos de trabajo. ¿Qué pasa si y quiero decir, incluso si una caja de Linux tendría que reiniciarse pero, qué pasa si su caja se reinicia? ¿Estás listo para perder esos datos? ¿Qué pasa si usted es una aerolínea y ese cliente estaba en la última página de enviar un valor de $ 5,000 que tenía ese boleto de vacaciones familiares que iban a comprar para Hawái y de repente dice, lo siento, tiene que comenzar todo de nuevo! Ya sabes, y realizaron todo tipo de búsquedas de vuelos y verificaron los horarios y también hicieron vuelos de Google y vieron cuáles coincidían y todas las demás cosas, así que no fue una buena experiencia.
Como empresa, no quiere perder clientes, el carrito de compras, no quiere perder eso. Entonces, la respuesta a eso es un caché distribuido. Solo debe mantener sesiones en él o todos esos datos transitorios si puede garantizar la confiabilidad, si garantiza que nunca perderá esos datos, si garantiza que se replica. Entonces, un buen caché distribuido hace una replicación de datos en múltiples servidores. Ahora, la replicación es en realidad una pérdida de tiempo, es algo adicional que se está haciendo solo para esa contingencia de la que estamos hablando. Entonces, el lado negativo de la replicación es que tiene un impacto en el rendimiento. Por lo tanto, si un caché no lo hace de manera inteligente y muchos de ellos no lo hacen, entonces verá un impacto en el rendimiento cuando active la replicación.
Intercambio de datos en tiempo de ejecución a través de eventos
Por lo tanto, tenga en cuenta estos dos puntos y el tercer caso de uso es lo que la mayoría de la gente no sabe que un caché distribuido, una vez que tiene esa infraestructura en su entorno, es una plataforma de intercambio de datos impulsada por eventos muy poderosa. Por lo tanto, es posible que tenga varias aplicaciones que necesiten compartir datos en un flujo de trabajo. Es posible que tenga una situación de tipo publicación/suscripción, en la que probablemente utilizará un bus de mensajes, un bus de servicios empresariales o una cola de mensajes para ello. Un caché distribuido es una plataforma muy poderosa para eso. Dado que ya lo tiene interno, en realidad es más rápido y más escalable que las otras opciones porque fue diseñado para el rendimiento, mientras que las otras aplicaciones fueron diseñadas más para compartir.
Por lo tanto, el tipo de publicación/suscripción basada en eventos de un intercambio entre múltiples aplicaciones. Una aplicación produce algunos datos, los pone en el caché, dispara un evento. Hay otras aplicaciones que han registrado interés en ese evento, que quiero consumir estos datos siempre que estén disponibles para mí. Entonces, reciben el evento y nuevamente una aplicación podría estar aquí, una aplicación podría estar aquí, esto se convierte en un motor de eventos escalable muy, muy poderoso al que todos pueden acceder.
Entonces, ese es un tercer caso de uso. Incluso en el caso de que, en el caso de uso o función de uso compartido de datos en tiempo de ejecución, la mayoría de los datos sean transitorios. Aunque se deriva de datos permanentes y probablemente podría recrearlos a partir de esos datos permanentes, pero es mucho trabajo hacerlo y esos datos generalmente son temporales, porque la naturaleza de eso usa temporales. Por lo general, no es así, no es necesario guardarlo en la base de datos. Solo necesita ser consumido. Entonces, el caché es nuevamente la única tienda que será y, al igual que las sesiones y otros, los problemas son los mismos que la confiabilidad tiene que activar. Entonces, esas son las tres formas comunes en que usaría un caché distribuido.
Entonces, lo bueno de estos tres casos de uso es que no se necesita programación para hacerlo porque el ASP.NET framework le permite conectar un proveedor externo. Entonces, para las sesiones, por ejemplo, si tuviera que tener, le mostraré rápidamente una muestra rápida donde todo lo que debe hacer es ir a la configuración web y, por supuesto, en el ASP..NET core, ese paradigma va a cambiar un poco pero la idea es la misma.
Configuración del almacenamiento en caché de sesiones de ASP.NET
Entonces, si va a Web.config, esta es solo una aplicación ASP.NET simple. Vaya a Web.config, primero debe agregar el ensamblaje de cualquier caché que vaya a usar en caso de NCache, solo va a hacer el ensamblaje de agregar en el NCache proveedor de la tienda de sesión y simplemente copie y pegue y lo segundo que es lo que realmente debe hacer es realizar cambios aquí.
Por lo tanto, hay una etiqueta de estado de sesión en la web que se configura donde debe asegurarse de que el modo sea personalizado y que el tiempo de espera sea el que sea. Y, en caso de NCache, entonces solo necesita agregar esta línea y hay un montón de otros parámetros que puede especificar que no voy a entrar, pero uno de ellos es solo el nombre del caché. En caso de NCache, todos los cachés tienen nombre y también les daré una demostración de eso, pero. Entonces, solo especifica el nombre del caché. El caché ya está creado. Eso es como una cadena de conexión que le dice a qué caché conectarse porque puede tener varios cachés, uno para Sesiones, otro para datos de aplicaciones y eso es todo. Quiero decir que haces ese cambio y solo haces una prueba de cordura, revisas todos los casos de uso comunes de tu aplicación y tu aplicación está lista de repente para almacenar sesiones en un caché distribuida como NCache. Entonces, la forma más fácil de beneficiarse y la mayor ganancia en realidad son las sesiones.
Entonces, eso es todo lo que tiene que hacer para el uso del estado de la sesión en un caché distribuido como NCache o cualquier otro y lo mismo ocurre con la memoria caché de salida de estado de vista. Es todo el cambio basado en la configuración. No voy a entrar en esos cada uno de ellos. Solo quería mostrarles esto como un ejemplo.
Almacenamiento en caché de datos de aplicaciones
Entonces, vayamos al corazón de un caché distribuido y digo corazón porque ahí es donde se gastará la mayor parte de su tiempo. Si elige incorporar una memoria caché distribuida, dedicará la mayor parte de su tiempo al almacenamiento en caché de datos de la aplicación. Entonces, ¿cómo es una API típica?
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");Si conocen el objeto de caché de ASP.NET, NCache trata de imitarlo lo más cerca posible, aunque somos un superconjunto, así que hay más. Cada caché tiene su propia API. Esto es lo que un NCache API parece. Te conectas con el caché, es un caché con nombre. Obtiene un identificador de caché, mantiene ese identificador de caché alrededor y dentro de la aplicación que mantiene, simplemente haga Cache.Get. Obtener, Contiene, Agregar, Insertar, Quitar, también hay agregar Async, Insertar Async. Insertar significa agregar si no existe o actualizar si ya existe. Esa es la misma terminología que el objeto de caché de ASP.NET que usa, por eso también la usamos. Y, el método Async básicamente significa que no tiene que esperar a que se complete esa operación. De hecho, puede, hay un tercer parámetro que es que puede especificar una devolución de llamada. Por lo tanto, se llamará a su devolución de llamada en caso de que algo salga mal o, de lo contrario, puede suponer que todo salió bien.
Mantenga el caché actualizado
Entonces, cuando estuvimos aquí, hablamos sobre el almacenamiento en caché de datos de aplicaciones, la mayor preocupación es que debe mantener el caché actualizado. Por lo tanto, un buen caché distribuido debe permitirle hacer eso porque si no lo hace, lo obliga a almacenar en caché datos de solo lectura. De todos modos, los datos de solo lectura son aproximadamente del 10 al 15% de sus datos. Entonces, ¿cómo va a obtener realmente los beneficios de este caché si solo está almacenando en caché del 10 al 15% de lo que debería almacenar en caché? Entonces, lo que desea hacer es almacenar en caché todos los datos, prácticamente todos los datos, muy pocos datos estarían donde dice que realmente no tiene ningún sentido almacenar en caché. Pero, casi todos los datos. Algunos de los datos los almacenará en caché durante un breve periodo de tiempo. Entonces, una vez que almacena en caché esos datos, estos son todos los datos de la aplicación, el caché más duro garantiza que el caché esté actualizado, las diferentes formas en que puede hacer que el número uno sea el vencimiento.
Uso de vencimientos basados en el tiempo
La caducidad es una caducidad absoluta y hay una caducidad deslizante. Los 2 tienen significados muy diferentes a pesar de que ambos son vencimientos. La caducidad absoluta es lo que debe hacer para mantener el caché actualizado porque está adivinando que está diciendo, estoy guardando este objeto de cliente en el caché. Creo que es seguro almacenar en caché a los cinco minutos. Solo estás haciendo una suposición basada en, es una suposición educada pero es una suposición. Dentro de cinco minutos espera que nadie lo modifique en la base de datos, pero si lo hacen, su caché será inconsistente con la base de datos. La caducidad deslizante, por otro lado, no tiene nada que ver con mantener la memoria caché sincronizada. Tiene que ver con el desalojo o tiene que ver con la limpieza automática del caché.
Entonces, sesiones, estás diciendo que cuando no hay nadie conectado, después de 20 minutos de inactividad, elimina la sesión. Entonces, lo estás haciendo como una limpieza. Estás diciendo que el caché, por favor, límpialo, límpialo por mí. No quiero tener que hacer un seguimiento de todo esto. Lo puse en el caché, especifiqué cuánto tiempo debe permanecer en el caché incluso si nadie lo toca, después de eso, límpielo. Por lo tanto, objetivos muy diferentes que tiene de vencimiento absoluto frente a vencimiento móvil. Entonces, al deslizar el vencimiento, lo usaría para sesiones para datos transitorios. Caducidad absoluta, lo usaría para datos permanentes.
Otro término que quiero usar es datos de referencia frente a datos transaccionales. Los datos de referencia son datos que no cambian con mucha frecuencia, pero cambian, no son de solo lectura. es su tabla de productos, cuyo precio puede cambiar todos los días o todas las semanas o algo así, pero no es tan frecuente como un objeto de cliente o un objeto de actividad o algo o un objeto de pedido. Entonces, los datos transaccionales son lo que queremos almacenar en caché. Por supuesto, los datos de referencia son un hecho que queremos almacenar en caché, pero los datos transaccionales también son algo de lo que vamos a obtener todos los datos. Por lo tanto, si la caducidad no es suficiente para garantizar que su caché se mantenga actualizada, entonces necesita tener más funciones.
Uso de dependencias de bases de datos
Entonces, la siguiente característica, una característica muy poderosa que debe tener un buen caché distribuido es que debería poder sincronizar el caché con la base de datos sin involucrarlo, sin que usted supervise las cosas. Por lo tanto, debería poder decirle al caché que estoy almacenando en caché este objeto. Esto está relacionado con este conjunto de datos en la base de datos. Por lo tanto, controle este conjunto de datos en la base de datos. Vea si cambia, vaya y haga una o dos cosas, elimine este elemento del caché, la eliminación significa que la próxima vez que la aplicación lo quiera, no lo encontrará en el caché. ¿Qué sucede cuando no lo encuentras en el caché? Lo obtienes de la base de datos. Entonces, es como obtener una nueva copia o, en segundo lugar, podría volver a cargar una nueva copia automáticamente. Recargar una nueva copia automáticamente requiere otra función llamada lectura completa de la que hablaré.
Entonces, volveré a eso, pero sincronización de base de datos es una característica muy, muy poderosa. Esto es lo que le da tranquilidad para asegurarse de que su caché se mantenga actualizada. Que no tendrá que preocuparse por los datos que esté almacenando en caché y que hay diferentes formas de sincronizar el caché con la base de datos. La más común es la dependencia de SQL, que en realidad es una característica del servidor ADO.NET o SQL que NCache usos.
Entonces, por ejemplo, les mostraré el código que se suponía que debía mostrar. Entonces, permítanme rápidamente... Voy a mostrarles rápidamente cómo se ve el código. ¿Adónde fue eso? Entonces, si tiene una aplicación .NET, digamos que es NCache, por supuesto, harías referencia a dos de NCache bibliotecas NCache.Tiempo de ejecución y NCache.Web. Así que, como de nuevo, hemos intentado nombrarlo lo más cerca posible del espacio de nombres del objeto de caché de ASP.NET para que NCache.Web. Cuando salimos en 2005, el objeto de caché ASP.NET era el único caché que existía, por lo que somos los más antiguos en el espacio, por eso elegimos ese nombre para que sea más fácil para las personas. Entonces, dentro de la aplicación incluirías un par de NCache espacios de nombres Luego, se conectaría con su caché, obtendría un identificador de caché y ahora tiene un identificador de caché, digamos que crea su objeto y desea hacer Cache.Add. Entonces, Cache.Add toma una clave. Observe que la clave es en realidad una cadena, así que hemos seguido esto. Bueno, esto no sigue esa convención de nomenclatura, pero generalmente es Cliente: ID de cliente: cualquiera que sea la ID para ese cliente, entonces hace Caché. Agregar después y luego, en este caso, está especificando un vencimiento absoluto de un minuto. Como decir, no hagas ningún vencimiento deslizante y todas las demás cosas. Entonces, es solo para darle una idea de cómo se ve un caché.
Muy fácil de usar, API muy simple, mucho más simple que hacer ADO.NET o cualquier otra programación.
¿Qué aspecto tiene un caché?Permítanme, en realidad, déjenme mostrarles cómo se ve un caché pero con un caché real. Entonces, tengo estas máquinas virtuales y Azure. Entonces, tengo la demostración 1 y 2 dos. Estos son dos servidores de caché que voy a usar. Estas son máquinas virtuales de caché y tendré mi servidor de aplicaciones. Voy a llamarlo cliente de demostración. Entonces, mi aplicación se ejecutará en el cliente de demostración. ¡Okey! Entonces, tengo Remote Desktop en esto. voy a en caso de NCache Voy a ejecutar esta herramienta llamada NCache gerente, en realidad lo tengo aquí. Y seguiré adelante y crearé. Permítanme asegurarme rápidamente de que no haya ningún caché con ese nombre. ¡Okey! Entonces, voy a seguir adelante y crear un nuevo caché. Llamaré a mi caché caché de demostración. Voy a tomar todo lo demás como predeterminado. Elegiré una topología de almacenamiento en caché. No voy a entrar en detalles, pero esta topología de almacenamiento en caché realiza la partición y la replicación al mismo tiempo. Entonces, cuando haga esta topología, su caché se verá así.
Entonces, estos son sus servidores de caché. Entonces, algunos de los datos, este 1 2 3 4 son los elementos de datos. Por lo tanto, algunos de los datos están en la partición 1, algunos de los datos están en la partición 2 y cada partición está respaldada en un servidor diferente. Entonces, si tuvieras 3 servidores aquí.
Digamos que tendría la partición 1, 2 y 3, el servidor 2 tiene la réplica de la partición 1, el servidor 3 tiene una réplica de la partición 2 y el servidor 1 tiene una réplica de la partición 3. Entonces, el caché en realidad es un servidor. En realidad, es más de un servidor, que está en un clúster. Se conocen entre sí y ahora voy a llevarte rápidamente a esto. Entonces, digamos que elegí una topología de réplica de partición. Elegiré la demostración 1 como mi primer servidor de caché. ¿Por qué es tan lento? Demo 2 como mi segundo servidor de caché. Creo que es probablemente porque Internet es lento, tal vez. No sé. Entonces, tengo un clúster de caché de dos nodos. Entonces, la demostración uno y dos ahora se conocen. Entonces, van a hablar entre ellos en este puerto. En el puerto 7802 que podría cambiar. ¿Por qué es tan lento? Asegurarse.
¡Okey! Entonces, a continuación voy a especificar cuánta memoria debe tener el caché. Entonces, tiene un concierto, probablemente tendrás, como dije, 13 conciertos o algo así. Y luego voy a especificar la política de desalojo que se usó menos recientemente. Ahorraré un 15%... Lo siento, desalojar el 5% del caché. Esto es muy lento, no sé lo que está pasando. Toda esta caja es lenta, incluso un clic lo es, incluso la CPU no lo es, ¡sí! Lo parece. ¡Sí lo es!
¡Okey! Entonces, básicamente, tiene un grupo de servidores que lógicamente se denominan caché y los conoce solo por un caché de demostración. En su caja, digamos, en su caja de servidor de aplicaciones, digamos NCache está instalado aquí. Vas a tener un archivo de configuración que tendrá ese nombre de caché y una lista de servidores que lo representan. Entonces, ese es solo un punto de partida, pero nuevamente sabrá que todo el clúster es solo un nombre de caché y se conecta a él y luego su API de cliente se conectará a todos los servidores de caché en esta imagen. En el caso de las réplicas de partición, cada cliente se comunica con todos los servidores para que pueda ir directamente a donde están los datos, la parte de partición.
Continuaré y agregaré un cliente para esto, que es mi cliente de demostración. Continuaré y haré clic en el asistente de caché, me tomará mucho tiempo hacer clic y diré iniciar el caché. Entonces, con solo decir que el caché comenzará en ambos cuadros. NCache es un caché basado en Windows, por lo que tiene todas las capacidades fáciles de usar que tiene un buen producto basado en Windows. Entonces, puede hacer todo esto desde un lugar central, todo esto también puede hacerlo a través de secuencias de comandos.
Sincronización de base de datos - DemostraciónEntonces, déjame mostrarte cómo es la sincronización de la base de datos. Entonces, por ejemplo, lo que hace es, nuevamente, es el mismo tipo de aplicación, tiene el caché y cuando intenta agregar datos al caché, digamos que está haciendo Caché. Agregue aquí y esto es por supuesto NCache código, especifica una dependencia de caché de SQL que es un NCache class pero se asigna en el back-end a la clase de dependencia SQL del servidor SQL. Y le pasa una cadena SQL que luego es utilizada por NCache para conectarse a la base de datos y el servidor de caché ahora se convierte en un cliente de su base de datos. Entonces, por ejemplo, si su aplicación está aquí, digamos, su código se está ejecutando aquí, acaba de emitir esta llamada. ¡Ups, lo siento! Acaba de emitir esta llamada de caché de ese anuncio y pasa esta dependencia de caché de SQL. El cliente envía todo esto al servidor de caché.
Entonces, uno de los servidores de caché o varios. Y, el servidor de caché ahora abre una conexión a la base de datos porque también especificó una cadena de conexión aquí. Y, esta fuerza de conexión es, por supuesto, piscina. Asi que. si especifica varias veces la misma cadena de conexión, entonces hay un grupo de conexiones en el back-end. Entonces, otro caché ahora se ha convertido en un cliente de su base de datos. Supervisará su base de datos para que la base de datos notifique al NCache servidor que estos datos han cambiado que me ha pedido que supervise y el NCache El servidor en ese momento puede decidir si debe eliminar ese elemento del caché o volver a cargarlo desde la base de datos. Y, para recargarlo, debe pasar por la función de lectura.
¡Okey! Entonces, esa es una forma de hacerlo. Es realmente poderoso. Está basado en eventos. Tan pronto como ocurre el cambio, la base de datos notifica al caché, el caché inmediatamente toma la acción. Sin embargo, hay una sobrecarga en este extremo del servidor de la base de datos porque cada vez que hace una dependencia de caché SQL, se debe crear una estructura de datos dentro del servidor SQL para monitorear ese conjunto de datos. Ahora, si tuviera 1 millón de estos, puedo garantizarle que su servidor SQL se bloqueará. Nuevamente, dado que estamos hablando de escalabilidad, debe pensar en términos de números realmente grandes. Entonces, si tienes miles o decenas de miles de estos, no hay problema. Pero si tiene cientos de miles o millones de ellos, entonces una estrategia diferente sería una mejor estrategia.
Dependencia de la base de datosOtra estrategia se llama dependencia de base de datos, que es nuestra. NCache función que es una dependencia basada en sondeo. Hemos implementado esto donde. Hay una tabla especial y le pedimos que modifique los activadores para que pueda actualizar el indicador en esa tabla para esa fila correspondiente y luego, cada vez que haga una dependencia de base de datos desde el caché, el caché crea una entrada en esa tabla y luego en una búsqueda , la memoria caché puede obtener miles de filas donde el indicador es verdadero, se ha realizado la actualización. Entonces, es como nuestra propia forma de hacer un seguimiento. Está basado en encuestas, por lo que no es instantáneo. De manera predeterminada, un retraso de aproximadamente 15 segundos, pero puede reconfigurarlo. Tampoco querrás tirar con demasiada frecuencia. Entonces, ese es el otro, pero incluso ahí tiene la limitación de, ¿qué pasa si tiene 1 millón de filas en esa tabla con una bandera de verdadero y falso, el índice se vería bastante grande, verdad? Hay un índice verdadero y otro falso, esos son los dos nodos de un árbol. Por lo tanto, la dependencia de DB es más eficiente que la dependencia de SQL, pero no en tiempo real, pero incluso tiene limitaciones.
Procedimientos CLREl tercero son los procedimientos CLR en los que puede llamar a un procedimiento CLR desde un activador en la base de datos, de modo que cada vez que se agregue, actualice o elimine un elemento, llame al procedimiento. El procedimiento realiza una llamada asíncrona a la memoria caché. Dice que agregue, actualice o elimine este elemento del caché. La razón por la que Async es fundamental es porque no desea retrasar la transacción, la transacción de la base de datos. De lo contrario, comenzará a agotarse el tiempo. Por lo tanto, una llamada Async regresará inmediatamente y al menos la transacción de la base de datos se puede confirmar y el caché se puede actualizar. Por lo tanto, la sincronización de la memoria caché con la base de datos es una característica fundamental.
Sincronizar caché con no relacional
Debe tener eso y lo mismo si tiene una fuente de datos no relacional o puede tener mainframe o legado o cualquier otra fuente de datos, puede tener una fuente de datos en la nube, es posible que desee realizar llamadas de método web para incluso verificar si esos datos está actualizado o no y NCache le permite tener esta característica de dependencia personalizada donde es su código el que puede monitorear NCache, llama a su código cada pequeño intervalo, va y monitorea su fuente de datos para ver si esos datos han cambiado, si tiene que notificar NCache y NCache eliminará o volverá a cargar de la misma manera.
Manejo de Datos Relacionales
Por lo tanto, mantener el caché actualizado es fundamental. Cualquier caché que no te permita hacer eso, limita tu capacidad de beneficiarte. Voy a omitir el manejo de datos relacionales aunque, incluso eso no es y qué, déjame decirlo rápidamente, tienes relaciones de uno a muchos, relaciones de uno a uno. Entonces, si tiene un elemento en el caché y muchos elementos también en el caché, cuando elimina un elemento en el caché, lógicamente, los muchos elementos también deben eliminarse porque, ¿qué sucede si lo ha eliminado de la base de datos? Entonces, el caché debería poder realizar un seguimiento de todo esto. Podría hacer eso en su solicitud, pero solo complica su crédito de solicitud porque ahora está haciendo una gran cantidad de contabilidad para el caché. Es como si estuviera creando sincronización de base de datos o código de integridad de datos dentro de la aplicación que no es el trabajo de su aplicación. No haces eso para la base de datos. La base de datos lo hace por usted, por lo que el caché también debería hacerlo por usted.
Lectura y escritura
Por lo tanto, la lectura directa y la escritura directa son otra característica muy poderosa que debe tener su caché. La lectura es básicamente, de nuevo, el concepto es muy simple.
Implementas una interfaz, en caso de NCache implementa una interfaz llamada proveedor de lectura, aquí mismo. ¿Puedes ver eso?
Sí, y tiene tres métodos. Hay un Init que se llama cuando se inicia el caché para que pueda conectarse a su fuente de datos. Hay una disposición cuando el caché se detiene, puede hacer su limpieza y la mayoría de las veces llamará a esta carga desde la fuente. Por lo tanto, pasa su clave. La clave es su clave para saber qué elemento de su fuente de datos buscar y luego devolverlo, en caso de NCache un elemento de caché del proveedor. Y puede especificar vencimientos y resincronizar al vencimiento, todo tipo de indicadores aquí y luego pasarlo a NCache. NCache lo almacena en caché.
Entonces, ¿cómo funciona la lectura directa? La forma en que funciona es que su aplicación siempre solicita el caché. Dice Cache.Get. Si el caché no tiene los datos, en lugar de decir que no los tengo, va y los obtiene de la base de datos. Entonces, su aplicación de repente se vuelve mucho más simple. Gran parte del código de persistencia lo acaba de sacar de su aplicación. Entonces, uno de los beneficios de la lectura completa es que ha simplificado el código, lo ha encapsulado todo en el nivel de almacenamiento en caché. El nivel de almacenamiento en caché ahora tiene más y más de su capa de persistencia. No todo el código se puede hacer a través de la lectura, pero se puede hacer mucho.
Recargar al vencimiento
El segundo beneficio de la lectura completa es de lo que hablé anteriormente, que es la función de recarga. Ahora imagine, si tiene una aplicación de comercio electrónico y su precio cambia y cada vez que cambia el precio, esos elementos deben eliminarse del caché y volver a cargarse, pero es un tráfico muy pesado, por lo que mientras se eliminan, muchas solicitudes de clientes llegarán. la base de datos. El primero lo buscará y lo colocará en el caché, pero hasta ese momento, el caché de repente tiene mucho tráfico innecesario y, si eso sigue sucediendo, si tiene mucho de eso, la base de datos recibirá muchas visitas innecesarias. que podría haber evitado si solo hubiera dicho recargar al vencimiento. Entonces, recargar un vencimiento, ¿qué hace eso? No elimina el artículo al vencimiento. Simplemente lo vuelve a cargar para que, cuando se produzca la caducidad, la memoria caché llamará a la lectura y lo obtendrá de su fuente de datos y simplemente lo actualizará. Entonces, solo está ocurriendo una operación de actualización. No hay una operación de eliminación y adición y, por eso, los datos o el elemento siempre están en la memoria caché. Entonces, el caché de repente ahora se vuelve. Puede cuidarse solo y puede ir y recargarse cada vez que los datos necesitan recargarse.
Escriba por medio de
Entonces, esa es una capacidad realmente poderosa de lectura. Entonces, cuando combina eso con la caducidad y puede hacerlo también con la sincronización de la base de datos. Cuando ocurre la sincronización de la base de datos, nuevamente, ¿por qué eliminarla? Solo recarga. La otra función es la escritura simultánea, que funciona como una lectura simultánea, excepto que escribe. Hay una cosa más que hace, también puede hacer escritura masiva. Y, la razón por la que hace escritura masiva la explicaré en un momento. Entonces, de la misma manera que hay un Init, hay un descarte y ahora hay una escritura en las fuentes de datos. La escritura no significa agregar o insertar solamente. También se puede eliminar para que la escritura tenga un tipo de operación que luego se puede agregar, actualizar o eliminar. Y eso depende de cuál fue la operación de caché. Y, luego, también puede hacerlo a granel. Por lo tanto, la escritura simultánea tiene los mismos beneficios que la lectura simultánea en términos de simplificación del código, pero nuevamente tiene un beneficio más. Por lo tanto, la lectura directa tenía el beneficio de recargar, la escritura directa tiene el beneficio de poder escribir en segundo plano.
escribir detrás
Y, write-behind es una característica muy, muy poderosa. ¿Por qué? Porque las actualizaciones de la base de datos son un cuello de botella. Nuevamente, la base de datos es ese mal necesario con el que tienes que vivir. No puede vivir sin él, pero está causando todo tipo de cuellos de botella en su aplicación. Por lo tanto, cuanto menos pueda depender de él, mejor será su aplicación. El hecho de que no puedes vivir sin él todavía tienes que tenerlo. Entonces, ¿qué hace una escritura posterior? Dice que actualiza el caché, que es súper rápido, diez veces al menos más rápido que la base de datos, si no más, y luego el caché se encarga de la actualización de la base de datos. Entonces, hay una escritura simultánea asíncrona, eso es una escritura diferida. Entonces, irá y actualizará el caché, regresará y continuará con sus cosas y el caché se actualizará y actualizará la base de datos.
Por supuesto, hay muchos problemas que el caché debe abordar. Tan pronto como diga que el caché tiene que actualizar la base de datos, ¿qué pasa si el servidor del caché falla? ¿Qué le pasa a esa cola? Entonces, en caso de NCache, la cola en sí se replica en varios servidores, si algún servidor deja de funcionar, no perderá la cola. Luego también hay reintentos. ¿Qué sucede si esa actualización falla? Entonces puede volver a intentarlo. También puede hacer una actualización por lotes. Entonces, hay un montón de ellos que puedes hacer una actualización masiva. Por lo tanto, puede optimizar aún más las cosas. Por lo tanto, la escritura simultánea y la lectura simultánea son funciones muy potentes. Eso se llama código del lado del servidor. Este es su código que vive en el clúster de caché. Vive aquí y mantener ese código en el servidor simplifica su aplicación. Por lo tanto, cuanto más código presione hacia abajo, más simple se vuelve la aplicación.
Agrupación de datos
¡Okey! Ahora que, digamos, está convencido de que debe usar el almacenamiento en caché. Tiene los diferentes casos de uso en los que ahora confía en almacenar en caché una gran cantidad de datos. Así que ahora, el caché ha comenzado a parecerse a la base de datos. está empezando a tener muchos, tendrá millones de elementos en el caché. Entonces, cuando tiene millones de elementos en el caché, ¿es bueno simplemente leer cosas en función de una clave? ¡No! si la única forma de leer elementos de la memoria caché es en función de la clave, su aplicación sería muy, muy desafiante en comparación con si pudiera hacer las cosas, bueno, deme todas las cosas en función de este criterio de búsqueda.
Por lo tanto, buscar y agrupar se convierte en una necesidad muy poderosa o una necesidad muy importante de un caché. Nuevamente, como dije, el propósito es que entiendas cuáles son los beneficios. El beneficio es si puede almacenar en caché más y más datos. Cuantos más datos almacene en caché, más necesitará verlos o tener más características del tipo de base de datos. Una de esas características es poder hacer metadatos. En la base de datos, puede tener índices en muchos atributos diferentes. Aquí puede hacer etiquetas, etiquetas con nombre y, de hecho, cuando almacena en caché los objetos, en caso de NCache también te permite crear índices. Por lo tanto, puede indexar un objeto. Digamos que un cliente podría indexarse en el atributo de la ciudad porque va a buscar en la ciudad, por lo que debe indexarse. Si no está indexado, esa búsqueda será realmente dolorosa. Imagine millones de artículos que primero debe deserializar para inspeccionar cada objeto solo para saber qué clientes en Orlando. No es una buena imagen, no es una vista bonita.
Entonces, agrupar etiquetas de subgrupos y etiquetas de nombre nuevamente desde una perspectiva de codificación es muy simple. Voy a mostrarte esto rápidamente. Desde la perspectiva de la grabación muy fácil de usar. Agregas un montón de elementos y les asignas etiquetas y luego, ¡lo siento! grupo y subgrupo, grupo subgrupo y luego dice obtener datos del grupo o también puede hacer una búsqueda SQL y decir dame todo el objeto del producto donde el nombre del grupo es electrónica. Por lo tanto, las etiquetas y etiquetas de agrupación y subagrupación también son algo que AppFabric proporcionado, por cierto AppFabric se suspenderá en febrero. Tenemos más minutos, voy a acelerarlo.
Cómo encontrar datos
Una vez más, la búsqueda de datos está relacionada con la agrupación de datos en los que desea poder buscar datos basados en SQL, así que creo que... ¿dónde está el lenguaje de consulta de objetos? Ahí está. Entonces, podría, básicamente, tengo un montón de datos y podría emitir una declaración SQL y puedo especificar múltiples atributos y pasar parámetros y obtendré un registro establecido en caso de NCache y al igual que el servidor SQL, aunque es un subconjunto del SQL completo. No hace uniones, pero en lugar de unir, puede agrupar y etiquetar, y así es como puede agrupar varios objetos.
Entonces, en el caso de LINQ, NCache ha implementado un proveedor LINQ por lo que la interfaz Iqueryable. Ve y consigue esa colección de NCache y luego realiza una consulta LINQ tal como lo hace con cualquier otra colección de objetos y continuará y obtendrá una colección de estos objetos, los objetos del producto de vuelta. Entonces, si LINQ es realmente su zona de comodidad en términos de búsqueda, use LINQ para buscar. Cuando emita esta consulta, irá al clúster, esa misma consulta se enviará a todos los servidores y los resultados vendrán, se fusionarán y luego se le mostrarán. Entonces, podría, aunque parece muy simple aquí, detrás de escena hay mucho trabajo realizado por NCache.
Entonces, tenemos SQL y LINQ. También tenemos a granel y como dije, puedes hacer Indexación.
Intercambio de datos en tiempo de ejecución
Voy a ir muy rápidamente... hay eventos basados en claves, hay eventos a nivel de caché, hay subeventos de publicación, hay una consulta continua.
La consulta continua es una función que es como una función de dependencia de SQL, excepto que está en la memoria caché. Le está pidiendo al caché que monitoree un conjunto de datos por usted. Entonces, al igual que estábamos usando la dependencia de SQL y le pedimos al servidor SQL que monitoreara este conjunto de datos y dijimos que si este conjunto de datos cambia, avíseme. Ahora, estás preguntando NCache, diciendo por favor, aquí está mi instrucción SQL, seleccione clientes donde Cliente.Ciudad sea igual a Nueva York y está diciendo que si algún cliente que coincide con este criterio se agrega, actualiza o elimina del caché, notifíqueme y podría ser cualquier lugar en la red, cualquier lugar en el clúster de caché y usted podría ser cualquier otro cliente. Se le notificará. Entonces, al tener ese tipo de funciones ahora, puede monitorear de repente lo que sucede con el caché y recibir notificaciones en lugar de sondear cosas y eso es lo que estaba diciendo, el caché se convierte en una plataforma de intercambio de datos en tiempo de ejecución realmente poderosa.
Alta disponibilidad
¡Okey! Voy a saltarme esto también. Me refiero a que cualquier caché que uses tiene que tener dinámica. Tiene que proporcionar una alta disponibilidad que en caso de NCache, tiene una arquitectura peer-to-peer.
Caché de cliente
Hay una característica que quiero que sepas que se llama caché del cliente. Algunas personas lo llaman caché cercano.
Este es en realidad un caché que se encuentra localmente en su caja de servidor de aplicaciones. Es como un caché independiente, excepto que no es independiente. Entonces, incluso puede ser InProc. Puede estar dentro de su proceso de aplicación, lo que significa que en realidad está obteniendo cosas como en su montón de objetos. Su montón tiene datos en forma de objeto. Nada supera ese rendimiento, ¿verdad? Si solo puede obtener esos datos del montón en lugar de ir a un cuadro local de caché OutProc porque cuando atraviesa procesos tiene que pasar por IPC, tiene que hacer serialización, deserialización, cuando atraviesa la red es aún más, cuando vas a la base de datos es fenomenalmente caro, comparativamente.
Entonces, este es un caché local dentro de su proceso de aplicación o localmente en el cuadro. Pero, se mantiene sincronizado. No realiza ninguna programación de API especial para la memoria caché del cliente. Solo haces las llamadas al caché, en caso de NCache, simplemente se conecta al cambio de configuración e intercepta las llamadas y lo que sea que esté buscando, guarda una copia localmente. Entonces, la próxima vez que lo busque, lo obtendrá automáticamente del caché local. Gran impulso en el rendimiento. Esto es algo que solo NCache tiene en el lado .NET. En el lado de Java, hay otros productos que tienen caché de cliente, pero en .NET dijeron que esto es solo. Esto es como un caché encima de un caché y esta es la razón por la que muchas personas, cuando pasan del caché de InProc independiente a un caché distribuido, se quejan, mi rendimiento en realidad ha disminuido, mi aplicación es más lenta, pensé que el caché distribuido era se supone que debe aumentar mi rendimiento y les decimos que no, se supone que debe aumentar la escalabilidad. Nada coincide con un caché de InProc local, nadie puede hacerlo. Quiero decir que esto no es algo que podamos inventar y hacer algo. Estás pasando por procesos, eso es un costo que se necesita.
Entonces, decimos bien, una forma de superar ese desafío es usando un caché de cliente. Entonces, un caché de cliente nuevamente es un subconjunto. Por lo general, tendría de 16 a 32 gigas en cada servidor de caché. Por lo tanto, si tiene de tres a cuatro servidores, tiene potencialmente más de cien gigas de datos almacenados en caché y la memoria caché del cliente puede ser de un giga, tal vez de dos gigas, tal vez de tres o cuatro gigas, como máximo cada uno y depende de cuántos trabajadores procesen. tener. Si solo tiene un proceso de trabajo, hágalo de cuatro gigas. Si tiene ocho procesos de trabajo, que muchos de nuestros clientes de gama alta tienen en su nivel web, entonces no querrá tener cuatro veces ocho solo en la memoria caché del cliente. Entonces, tal vez, es bueno tener un caché de proceso de cuatro gigabytes que aún es mejor que ir al nivel de almacenamiento en caché. Todavía es más rápido o puede tener un caché de un giga más pequeño o menos de un giga que es InProc. Ahora, tienes ocho copias pero también están sincronizadas. Entonces, definitivamente, un caché de cliente es algo que debe considerar usar si va a obtener el valor de un caché.
Ahora, mi objetivo y esto no es venderle ninguna función de caché, sino decir qué debe tener un buen caché y muchas de estas características las encontrará en el lado de Java. Java es un mercado mucho más maduro en el lado del almacenamiento en caché. Usan la palabra cuadrícula de datos en memoria en lugar de caché distribuida, pero cualquiera que sea la función que esté viendo con NCache, verá muchos de ellos también en el lado de Java, pero en el lado de .NET NCache es el único
Replicación WAN
Otra característica es, bueno, si tiene varios centros de datos, querrá que su base de datos se replique, ¿por qué no el caché? ¿Qué vas a hacer? ¿Vas a reconstruir todo el caché? ¿Qué pasa con el carrito de compras? ¿Qué pasa con las sesiones? Por lo tanto, los centros de datos múltiples son una realidad y la nube lo ha hecho aún más fácil porque no hay ningún esfuerzo de su parte. Simplemente vaya y diga región uno y región dos y tiene dos centros de datos, ¿verdad? Pero el problema subyacente no desaparece, es decir, si usa un caché distribuido que no admite la replicación WAN, está atascado. No puede tener una solución de centro de datos múltiple activa-activa o incluso activa-pasiva sin que se replique la memoria caché, por lo que es una característica muy importante.
NCache por supuesto tiene esto. Ya te he dado la demostración práctica. NCache es la caché .NET más antigua del mercado. Fuimos lanzados en 2005, mucho antes.
NCache vs Redis
Entonces, voy a repasar rápidamente NCache Redis, muy muy alto nivel y eso es porque Redis mucha gente viene y nos pregunta cómo se compara con Redis ya que Microsoft los eligió para Azure.
Redis, es un gran producto. Es súper rápido. Viene principalmente del lado de Linux. No tiene muchas características. No gana en características. Simplemente gana por el hecho de que vino del lado de Linux y Microsoft quería capturar el mercado de AWS para que no pudieran adoptar una solución .NET. Tuvieron que adoptar, multiplataforma. Entonces, su versión de Linux es muy estable, muy buena, pero el puerto de Windows que Microsoft hizo es una especie de puerto huérfano. Microsoft no lo usa ellos mismos. Cuando estás en Azure y usas Redis, no está utilizando el puerto de Windows de Redis, está utilizando la versión de Linux. Entonces, si no está en Azure y va a usar el puerto de Windows de Redis, tener cuidado. Quiero decir que nadie lo posee. Redis labs, si vas a su sitio web, ni siquiera tienen una descarga de Windows. Quiero decir que solo tienen descargas de Linux, que es el creador de Redis. Microsoft, como dije, no pusieron su dinero donde estaba su boca en términos del uso del compromiso.
¿Entonces NCache es la única opción viable para usted y es de código abierto, por lo que si no tiene el dinero, elija la versión gratuita de código abierto. Si su proyecto es importante y desea soporte y más funciones, cuáles son las funciones empresariales. La empresa NCache está construido sobre código abierto. No es como una cosa separada. El código abierto no es huérfano. Quiero decir que lo poseemos, lo mantenemos y la empresa está construida sobre la base. Por lo tanto, el código abierto tiene que ser estable, pero si desea soporte y más funciones, simplemente compre Enterprise Edition.
Somos nativos .NET. Desarrollamos en c-sharp y contamos con la certificación Windows Server 2012 r2. Vamos a conseguir el próximo también pronto. Entonces, queremos decir que no estamos en la cima del juego en lo que respecta a Microsoft. Somos más o menos .NET, eso es lo que somos. Tenemos un cliente de Java, pero casi todos nuestros usos de Java son de clientes que compran NCache para .NET y como lo tienen internamente también lo usan desde Java. Por lo tanto, nuestro pan de cada día, toda nuestra supervivencia está en .NET. Entonces, siempre estaremos en lo último y lo mejor, lo primero y lo más fácil.