Escale aplicaciones .NET en Microsoft Azure con caché distribuida
Seminario web grabado
Por Ron Hussein
Aprenda cuáles son los cuellos de botella de escalabilidad para sus aplicaciones .NET en Microsoft Azure y cómo puede mejorar su escalabilidad con el almacenamiento en caché distribuido.
Este seminario web cubre:
- Visión general rápida de los cuellos de botella de rendimiento en las aplicaciones .NET
- ¿Qué es el almacenamiento en caché distribuido y por qué es la respuesta en Azure?
- ¿En qué parte de su aplicación puede usar el almacenamiento en caché distribuido?
- ¿Cuáles son algunas características importantes en un caché distribuido?
- Algunos ejemplos prácticos del uso de una caché distribuida en Azure
Muchas gracias por unirte. Permítame informarle rápidamente sobre el seminario web. En primer lugar, mi nombre es Ron Hussain. Soy uno de los expertos técnicos en Alachisoft y seré su presentador para el seminario web de hoy. Cubriré todos los detalles técnicos que necesita para escalar sus aplicaciones .NET en Microsoft Azure con la ayuda de un sistema de almacenamiento en caché distribuido en memoria y usaré NCache como un producto de ejemplo para esto. Ese es nuestro producto principal para el almacenamiento en caché distribuido. Somos el orgulloso fabricante de NCache y lo usaré como un producto de ejemplo. La mayor parte de este seminario web será solo para escuchar, lo que significa que yo haré la mayor parte de la conversación, pero usted siempre puede participar. Puedes hacer tantas preguntas como necesites. En el lado derecho de la pantalla, está esta pestaña de preguntas y respuestas. Si expande la pestaña de preguntas, puede publicar tantas preguntas como necesite y, como dije, estaré atento a esto y responderé todas las preguntas que ustedes publiquen en esta ventana. Entonces, solo por el bien de la confirmación, si puede confirmar usando la misma pestaña de preguntas y respuestas, confirme si puede ver mi pantalla y si puede escucharme bien. Puedo empezar rápidamente. Bueno. Ya veo que se están publicando algunas preguntas. Así que muchas gracias por la confirmación.
Comencemos con esto. Hola a todos, mi nombre es Ron Hussain como dije, soy uno de los expertos técnicos de Alachisoft y seré su presentador para el seminario web de hoy. El tema que hemos elegido hoy es escalar horizontalmente las aplicaciones .NET en Microsoft Azure con la ayuda de un sistema de almacenamiento en caché distribuido en memoria. A Alachisoft Tenemos varios productos y el más popular es NCache, que es un sistema de almacenamiento en caché distribuido en memoria para aplicaciones .NET y Java. NCache será el producto principal, que usaré como ejemplo, pero me ceñiré a los conceptos básicos de Microsoft Azure. Cómo utilizar NCache (un sistema de almacenamiento en caché distribuido) en Microsoft Azure y aprovéchelo en términos de escalabilidad, rendimiento de la aplicación y confiabilidad general del sistema en su arquitectura. Entonces, ya que ha confirmado que puede ver mi pantalla, permítame comenzar con esto.
¿Qué es la escalabilidad?
¡De acuerdo! antes de pasar al tema real. Hablaré sobre algunos conceptos básicos y comenzaré con ¿qué es la escalabilidad? La escalabilidad es la capacidad de aumentar la carga transaccional en las aplicaciones y, al mismo tiempo, no ralentizar sus aplicaciones. Por ejemplo, en este punto, si está manejando 1,000 solicitudes, si la carga de su aplicación crece, más usuarios inician sesión y luego comienzan a usar sus aplicaciones más intensamente que la carga, por ejemplo, crece de 1,000 a 10,000 solicitudes por segundo. Ahora desea acomodar ese aumento de carga, desea manejar ese aumento de carga y, al mismo tiempo, no desea ralentizar el rendimiento de su solicitud individual. No debería suceder de tal manera que una solicitud esté esperando a completarse y una solicitud esté en proceso de finalización, otras solicitudes estén esperando eso. Esas solicitudes deben manejarse exactamente en la misma cantidad de tiempo que estaban tomando anteriormente. Pero al mismo tiempo, desea esa escalabilidad, esa capacidad en la que podría manejar más y más solicitudes, cargar 10,000 solicitudes por segundo o 20,000 solicitudes por segundo. Entonces, sin perder el rendimiento, si tiene la capacidad de aumentar su carga transaccional en sus aplicaciones, eso es lo que llamaríamos escalabilidad. Y eso es en lo que nos centraremos hoy.
¿Qué es la escalabilidad lineal?
Hay un término asociado llamado escalabilidad ilimitada. Es escalabilidad lineal. La escalabilidad lineal es tener un crecimiento lineal en su capacidad de lecturas y escrituras por segundo. Por ejemplo, si agrega más servidores. Entonces, ahora que agrega un servidor, tiene cierta capacidad para manejar solicitudes de operaciones de lectura y escritura. ¿Qué sucede si agrega otro servidor y luego agrega más servidores? La capacidad en la que puede agregar más servidores y, al agregar más servidores, aumenta sus números de escalabilidad, obtiene más y más capacidad manejada por la arquitectura de su aplicación, eso es a lo que nos referimos como escalabilidad lineal.
¿Qué aplicaciones necesitan escalabilidad?
¡Ahora! La siguiente pregunta sería qué tipo de aplicaciones necesitarían escalabilidad. La respuesta es muy simple. Cualquier aplicación que pueda tener que manejar millones de solicitudes de los usuarios. Si se trata de una gran carga de transacciones. Por lo general, tenemos aplicaciones ASP.NET. Si hay un front-end, por ejemplo, una aplicación de comercio electrónico, tal vez una aplicación de reserva de una aerolínea, cualquier cosa que esté orientada al público pero que tenga mucho tráfico, esa aplicación es la principal candidata para la escalabilidad.
Luego, podríamos tener WCF para servicios web .NET y arquitectura orientada a servicios. Podría estar de vuelta o podrían ser servicios web front-end, tal vez consumidos por sus aplicaciones web o por aplicaciones internas que pueda tener. Es posible que deban procesar una gran cantidad de solicitudes, una gran cantidad de datos deben obtenerse y entregarse a los programas que llaman. Por lo tanto, este tipo de aplicaciones también necesitan escalabilidad. Y luego es posible que desee instalar algún tipo de infraestructura que pueda manejar la cantidad de carga de solicitudes.
Luego, tenemos aplicaciones de big data. Esta es una palabra de moda común en estos días. Muchas aplicaciones, muchas arquitecturas se están moviendo hacia él, donde es posible que tenga que procesar grandes cantidades de datos para distribuirlos en diferentes módulos, diferentes procesos, pero hacia el final, estaría tratando con una gran cantidad de datos, una gran cantidad de solicitudes, con el fin de procesar esto.
Y luego tenemos excelentes aplicaciones informáticas, en las que es posible que deba procesar una gran cantidad de cálculos a través de la distribución en múltiples servidores económicos, esas son las aplicaciones. Entonces, en general, cualquier aplicación .NET o aplicación Java, que puede tener que manejar un millón de solicitudes de los usuarios o de los programas de back-end, son los principales candidatos que necesitan escalabilidad en la arquitectura.
Y, nos centraremos en algunos de estos una vez, también pasaremos a nuestros casos de uso. Y, chicos, apenas estamos al comienzo de este seminario web, para aquellos de ustedes que acaban de unirse, solo voy a cubrir algunos conceptos básicos en términos de almacenamiento en caché distribuido. Hablaré sobre los diferentes problemas que enfrentaría y luego las soluciones, y también hablaré sobre la implementación de un caché distribuido, como NCache en Microsoft Azure. Por lo tanto, si tiene alguna pregunta, no dude en escribir en la pestaña de preguntas y respuestas. Y siempre puedes darme tu opinión también. Si desea participar, puede volver a utilizar la misma pestaña de preguntas y respuestas.
¿Qué es el problema de escalabilidad?
Ahora lo siguiente, una vez que definimos que tenemos, ¿qué es la escalabilidad? ¿Qué es la escalabilidad lineal y qué tipo de aplicaciones necesitan escalabilidad? El siguiente y luego el punto más importante de este seminario web, ¿qué tipo de aplicaciones o qué tipo de problemas de escalabilidad enfrentarían sus aplicaciones? ¿Dónde está exactamente el problema de escalabilidad?
Ahora, la arquitectura de su aplicación, podría ser una aplicación ASP.NET o un servicio WCF, estos se escalan muy bien y ya se escalan linealmente. Puede poner un balanceador de carga al frente y simplemente puede agregar más y más servidores de aplicaciones o servidores web, servidores front-end web y ya obtiene escalabilidad lineal de su arquitectura. Entonces, no hay problema allí. El problema real con respecto al almacenamiento de datos, estos servidores de aplicaciones o servidores web, siempre hablarían con algunas fuentes de datos de back-end, como el servicio de estado de bases de datos o podría ser cualquier sistema de archivos de back-end o fuente de datos heredada. . Lo que no puede manejar una gran carga de transacciones y no tiene la capacidad de agregar más y más servidores aquí. Y este diagrama lo explica muy bien.
Donde tenemos almacenamiento de datos hay un cuello de botella de escalabilidad. Tenemos un ejemplo de ASP.NET WCF aquí mismo, pero puede agregar tantos servidores como desee, comienza con dos servidores, si su carga crece, puede agregar otro servidor, colocar un equilibrador de carga al frente y luego usar uniformemente todo el recursos en esta capa. Entonces, no hay problemas. Pero estas cajas de aplicaciones o servidores front-end web siempre hablarían con algunas fuentes de datos de back-end. Y esta es una implementación típica, donde tenemos servidores de bases de datos, que no son tan rápidos al principio, y luego tienen problemas de escalabilidad. Se ahogarían bajo una gran carga de transacciones y luego, en algunos casos, también son un único punto de falla. Pero lo que es más importante, estos servidores de bases de datos en cualquier arquitectura de aplicación representan una amenaza muy grave y eso es un cuello de botella de escalabilidad. Por lo tanto, perdería toda la escalabilidad que logra en este nivel una vez que dirija todas sus solicitudes a algunos servidores de bases de datos. Y lo mismo es el caso del estado de sesión de ASP.NET. Si usa un SQL Server o un servidor de estado de sesión para eso, es porque permanece sobre eso. Siempre va a ser un único servidor que aloje todos los datos de su sesión y la sesión es un tipo de datos muy transaccional y luego necesita una fuente de datos muy escalable para manejar esas solicitudes. Entonces, ese es el principal desafío que estamos tratando de abordar con la ayuda de un sistema de almacenamiento en caché distribuido.
La solución: caché distribuida en memoria
La solución es muy simple, como dije, podría usar un sistema de almacenamiento en caché distribuido en memoria escalable. Como NCache para manejar todos los problemas de los que acabamos de hablar asociados con las fuentes de datos con respecto a la escalabilidad.
Lo siguiente que haré rápidamente es hablar sobre algunos conceptos básicos del sistema de almacenamiento en caché distribuido en memoria, como NCache. Hay algunas características importantes, que usted encontraría en NCache y espero que esto sea parte de la mayoría de nuestros sistemas de almacenamiento en caché distribuidos en memoria, que están disponibles. Entonces, en este sentido, así NCache si tengo que definir, ¿qué sería un sistema de almacenamiento en caché en memoria?
Agrupación dinámica
Es un grupo de múltiples servidores de caché de bajo costo, que se unen, puede extraer su memoria y la capacidad de la CPU. Por lo tanto, se unen en una capacidad y se extrae su memoria, así como los recursos de la CPU. Entonces, físicamente podrían ser varios servidores, que no son tan costosos una vez que una caja de configuración de servidor web simple funcionaría, eso es algo que podría usar para el almacenamiento en caché, y luego esos servidores se unen y formalizan la capacidad lógica. Entonces, desde el punto de vista de su aplicación, solo está usando un caché distribuido, pero físicamente, podría tener varios servidores trabajando detrás de escena, aprovechando toda la potencia computacional y la memoria para crear este caché distribuido en memoria. Entonces, esa es la primera y más importante característica de que no es este único servidor. Tendría múltiples servidores trabajando en combinación entre sí. Entonces, ya estamos por delante de la base de datos, donde solo tendríamos un servidor que aloja todos los datos y maneja todas las solicitudes.
Consistencia de los datos
La siguiente característica y esto se refiere a la consistencia de los datos, ya que estamos tratando con múltiples servidores detrás de escena, la siguiente pregunta sería, ¿cómo manejaríamos las actualizaciones? Por ejemplo, los mismos datos se actualizan en uno o dos servidores o si hay réplicas o varias copias de datos en diferentes servidores. Por lo tanto, independientemente de la topología que utilice, los datos deben actualizarse de forma coherente. Entonces, una vez que actualice algo en cualquier servidor de caché, todas las actualizaciones deberían ser visibles para todos los servidores de almacenamiento en caché en el caché distribuido. Y por cierto, estoy usando algo visible, no estoy usando el término replicación. La replicación es otra característica. Entonces, por visible me refiero a que, por ejemplo, el servidor uno maneja una solicitud, esos datos se actualizan. Si la siguiente solicitud va al servidor dos, si también tenía los mismos datos en el servidor dos, debería obtener el valor actualizado, no el valor obsoleto de la memoria caché distribuida.
Por lo tanto, esta es una característica muy importante en términos de caché distribuida, donde todas sus actualizaciones de datos deben aplicarse de manera consistente en todos los servidores de almacenamiento en caché. Y esto debería ser responsabilidad del caché distribuido, no de su aplicación. La arquitectura debe soportar este modelo.
Escalabilidad lineal
Lo siguiente, que se alinea con nuestro tema de hoy, es cómo escalar linealmente. Por lo tanto, la memoria caché distribuida debe escalar linealmente tanto para transacciones como para capacidad de memoria. Debería regalarlo, donde puede agregar más y más servidores de almacenamiento en caché y, como tenía más servidores de almacenamiento en caché, obtiene escalabilidad lineal. Te había mostrado un gráfico antes. Entonces, a eso me refiero aquí, donde agrega más y más servidores, debe aumentar la capacidad de cuántos solicitantes puede manejar y, al mismo tiempo, cuántos datos, cuántos datos se pueden almacenar en el caché distribuida linealmente. Entonces, esa es una característica muy importante, que le brinda escalabilidad lineal fuera del caché distribuido y que hace que la arquitectura general de su aplicación sea muy escalable.
Replicación de datos para confiabilidad
Cuarta característica importante. Esta es la primera opción, puede elegir una topología, que también admita la replicación. Tiene un caché distribuido, que replica datos entre servidores para mayor confiabilidad. Si algún servidor deja de funcionar o necesita desconectarlo para realizar el mantenimiento, no debe preocuparse por la pérdida de datos o la caída de la aplicación. Entonces, estas son algunas características importantes del caché distribuido. Cubriré esto con más y más detalle en las próximas diapositivas y luego también hablaremos sobre la implementación específica de Azure de una caché distribuida. ¿Cómo usar el caché distribuido en Microsoft Azure? Por favor, hágamelo saber si hay alguna pregunta hasta ahora. Utilice la pestaña de preguntas y respuestas. Veo algunas manos levantadas en general, ir a la reunión tiene este problema, donde muestra muchas manos levantadas, pero avíseme si en realidad hay alguna pregunta. Escriba en la pestaña de preguntas y respuestas y estaré encantado de responderlas por usted. Creo que deberíamos continuar.
Esta es la implementación típica de una caché distribuida. Esta es una implementación general, no es específica de Microsoft Azure.
NCache Despliegue en Microsoft Azure
Pasaré al despliegue de NCache en Microsoft Azure justo después de esto. Por lo tanto, normalmente podría ser en las instalaciones o en la nube, no hay muchas cosas que cambien en cuanto a la implementación de NCache va. Así es como normalmente implementaría NCache, donde tendría una capa dedicada de almacenamiento en caché.
Estas podrían ser cajas físicas en las instalaciones, podrían ser máquinas virtuales de cajas alojadas, o también podrían ser máquinas virtuales reales en la nube, donde solo obtiene una máquina virtual de la nube y luego la usa para el almacenamiento en caché. Puede formular un caché en cajas de almacenamiento en caché dedicadas separadas, esa es la recomendada. Una plataforma preferida es de 64 bits y el único requisito previo para NCache es .NET 4.0. Y luego sus aplicaciones, estas también podrían estar alojadas o en las instalaciones. Estos podrían implementarse directamente en los servidores en IIS o podrían ser roles web o de trabajo, en lo que respecta a Microsoft Azure. Todos pueden conectarse a este nivel de almacenamiento en caché para los requisitos de datos. Podría tener una instalación separada para estos, una capa separada para estos, o simplemente tendrá todo en la misma capa también. Ambos modelos son compatibles. Pero una vez que presentas NCache en la arquitectura de su aplicación, una vez que se implementa para el almacenamiento en caché de objetos o para el almacenamiento en caché de sesiones, cubriré NCache casos de uso una vez que avanzamos hacia los casos de uso.
Una vez que empieces a usar NCache, ahorra tus costosos viajes a través de la espalda y bases de datos. Y luego le brinda una plataforma muy escalable aquí mismo, donde puede agregar tantos servidores como desee y puede escalar. Ahora compare esto con el diagrama que le mostré antes.
Tenías una plataforma muy escalable aquí mismo, pero esta era la principal fuente de controversia. La principal fuente de cuello de botella de escalabilidad. Ahora, si compara esto, ahora tiene una plataforma muy escalable entre su capa de aplicación y su base de datos. Esta es una plataforma muy escalable y nuevamente ahora tiene una fuente de datos en términos de caché distribuida, que nuevamente es muy escalable. Puede agregar tantos servidores como desee. Si su carga crece, no tiene que preocuparse de que las fuentes de datos de back-end se ahoguen en ese momento. Puede agregar tantos servidores como desee y puede aumentar linealmente su capacidad de manejo de solicitudes fuera de NCache. Avíseme si tiene alguna pregunta sobre la arquitectura de implementación de NCache pero en general, es muy sencillo.
Ahora, lo siguiente es cómo implementar NCache en Microsoft Azure. Entonces, usaré nuestro sitio web. Usaré un diagrama de allí, así que tengan paciencia conmigo. La implementación en Microsoft Azure no es tan diferente de lo que tenemos en las instalaciones.
Entonces, en primer lugar, se recomienda que esta sea la implementación básica, donde tiene todo en la misma red virtual de Microsoft Azure. Por ejemplo, crea una red virtual y luego tiene máquinas virtuales de Microsoft Azure, la implementación del lado del servidor siempre estará en las máquinas virtuales. Entonces, ese es el modelo que hemos elegido para NCache en Microsoft Azure. Usted crea una VM o, al elegir la misma red virtual, crea todas sus implementaciones de VM. Por ejemplo, puede comenzar con tres VMS como se muestra aquí y luego puede agregar tantas VM a esta capa de almacenamiento en caché como sea necesario. Preferiblemente, también queremos que sus aplicaciones estén en la misma red virtual de Azure. Por lo tanto, todo puede ser parte de la misma red virtual que es cuando obtiene la mayor parte del rendimiento y luego los beneficios de estabilidad de NCache. Cuando no hay requisitos estrictos sobre esto, siempre puede tener aplicaciones implementadas en diferentes máquinas virtuales.
Por lo tanto, en función de este modelo, la arquitectura de su aplicación puede estar en la propia VM, lo que significa que su aplicación puede implementarse directamente en IIS, que usted mismo administra y luego, tomar el control completo o podría ser yo mismo el rol web de Azure o los roles de trabajador. los modelos son compatibles en el lado de la aplicación, pero NCache la implementación del lado del servidor siempre estará en las máquinas virtuales. Entonces, así es como aplicarías NCache y de hecho les mostraré una vez que pasemos a nuestra parte práctica.
Otro tipo de implementación es que podría tener una red virtual de Azure específica para su NCache máquinas virtuales de servidor, donde todos sus servidores son parte de la misma red virtual. Preferiblemente la misma subred también. Y luego sus aplicaciones también podrían estar en una red virtual separada. En ese caso, tendría que tener algún tipo de puertos reenviados en el NCache red virtual Por ejemplo, los puertos privados se asignan al puerto público aquí y luego sus aplicaciones usan este puerto público para conectarse realmente a NCache. Es posible que deba realizar algunas configuraciones adicionales aquí, pero tenemos un documento de ayuda detallado disponible para eso, pero funciona sin problemas. Podría tener este servidor de red virtual accediendo a servidores de almacenamiento en caché desde otra red virtual. E incluso podría tener las aplicaciones de caché a caché con la ayuda de la misma característica.
Por lo tanto, este es otro tipo de implementación, pero el enfoque preferido, el recomendado, es que tenga todos sus servidores de caché y servidores de aplicaciones implementados en la misma red virtual de Microsoft Azure. Ahí es cuando obtendrías los mayores beneficios de NCache. Por favor, hágamelo saber si hay alguna pregunta.
También tenemos una guía de implementación de Azure disponible en nuestro sitio web si pudiera llevarlo al soporte. En realidad, déjame ir a la documentación aquí. Sobre la documentación, tenemos una guía específica, una guía de despliegue que cubre todos estos detalles con gran detalle.
Bueno. Hay una pregunta. Como es NCache diferente de Redis? Bueno. La agenda de hoy es más de usar NCache o utilizando un sistema de almacenamiento en caché distribuido en Microsoft Azure. Tenemos un seminario web separado sobre Redis NCache. Donde hablamos de las diferentes características que están disponibles en NCache y luego no ser parte de Redis. Para una respuesta rápida sobre esto, le recomendaría que vaya a nuestra página de comparaciones aquí mismo, y luego tenga una Redis NCache. Puede registrarse rápidamente para esto y luego debería poder ver todas las características, comparación característica por característica de NCache Redis. Y, de hecho, también tenemos un seminario web solo para esto, que es un seminario web en nuestro canal de YouTube. Por lo tanto, si acaba de iniciar sesión en YouTube, busque Alachisoft y luego bajo Alachisoft habrá muchos videos y uno de esos videos tendría Redis fuentes NCache título. Hay un seminario web separado sobre eso. Espero que esto responda tu pregunta. Hay más preguntas sobre esto. Bueno. Volviendo, ya que hemos cubierto la implementación, hágamelo saber si tiene alguna pregunta relacionada con la implementación y estaré encantado de responder esas preguntas por usted.
Usos comunes de la caché distribuida
Lo siguiente es cómo usar el caché distribuido. ¿Cuáles son las áreas comunes, donde usaría un sistema de almacenamiento en caché distribuido como NCache? Acabo de enumerar tres de los más comunes, pero estos podrían ser específicos de la industria, esto podría ser específico para sus requisitos, casos de uso, podrían ser diferentes formas en que podría usar NCache. Pero principalmente estos se dividen en estas tres categorías.
Almacenamiento en caché de datos de aplicaciones
La primera categoría es el almacenamiento en caché de datos de la aplicación. Puede usar un sistema de almacenamiento en caché distribuido como NCache como una aplicación de almacenamiento en caché de datos. Cualquier cosa que anteriormente estaba presente en la base de datos y sus aplicaciones iban a las bases de datos, ahora puede poner eso en NCache. Y puede obtener un caché en memoria más rápido en comparación con la base de datos para acceder a todos los datos que tenía previamente en la base de datos. Por lo tanto, mejora el rendimiento de su aplicación y, lo que es más importante, escala linealmente cuando la base de datos no lo hace. Puede escalar horizontalmente a algunos niveles dramáticos. Puede manejar una gran cantidad de cargas de transacciones y puede agregar tantos servidores como desee. Y esto implica NCache API. Simplemente podría agregar datos en un par clave-valor. La clave es una cadena y el valor es un objeto permitido de .NET, puede almacenar en caché los objetos de su dominio, colecciones, conjuntos de datos, imágenes, cualquier tipo de datos relacionados con la aplicación se pueden almacenar en caché utilizando nuestro modelo de almacenamiento en caché de objetos. Y luego esto le daría grandes beneficios en términos de funciones que estamos ofreciendo en el lado del almacenamiento en caché de datos.
Caché confiable y escalable para datos específicos de ASP.NET
El siguiente caso de uso se trata de aplicaciones específicas de ASP.NET. Por ejemplo, ASP.NET y hay una manera muy fácil de comenzar con NCache. Tenemos tres opciones aquí.
Almacenamiento de sesiones ASP.NET
Tenemos almacenamiento de estado de sesión ASP.NET. Puede usarlo en formularios web MVC o ASP.NET o cualquier aplicación web ASP.NET puede hacer uso de esto. Sin ningún cambio de código, puede tener los datos de su sesión almacenados en un caché distribuido. Y a diferencia de la base de datos o el servidor de estado, no será un único servidor. Podría tener múltiples servidores. Por lo tanto, es muy escalable, es muy confiable porque tenemos los datos de la sesión replicados en los servidores y también se obtiene un muy buen rendimiento porque está en la memoria. Y todo sin ningún cambio de código. Y con NCache, también tenemos una implementación de sesión en varios sitios. Podría tener dos centros de datos, sincronizar sus sesiones sin ningún cambio de código. Entonces, estas son algunas características extendidas que puede utilizar. Fuera de nuestro soporte de estado de sesión para aplicaciones ASP.NET y esto no requiere ningún cambio de código.
ASP.NET View State Almacenamiento en caché
La siguiente característica de esto es ASP.NET view state, esa tampoco es una opción de cambio de código. Para aquellos de ustedes que quieran saber, ¿qué estado de vista es? Ver el estado es la administración del estado del lado del cliente. Por ejemplo, si los estados de vista solo se aplican en formularios web, la arquitectura MVC ya no tiene su estado. Para los formularios web ASP.NET, todos los controles, todos los botones o todos los widgets que tiene en sus páginas, contribuyen a crear el estado de vista, que se envía de vuelta al navegador con respecto a nuestra respuesta, el estado de vista se une para el paquete de respuesta y luego enviado de vuelta al navegador. En el lado del navegador, nunca se usa realmente. Simplemente permanece allí y cuando vuelve a publicar, el estado de vista viene junto con el paquete de solicitud en el servidor y ahí es cuando realmente usa el estado de vista. Por lo tanto, siempre se envía de vuelta al navegador como parte de la respuesta, se devuelve al servidor como parte de la solicitud, por lo que sus paquetes de solicitud y respuesta se vuelven más pesados. Nunca se usa realmente en el lado del navegador. Siempre se usa en el lado del servidor. Consume una gran cantidad de su ancho de banda específicamente bajo una gran carga de transacciones.
Por lo tanto, tenemos muchos problemas asociados con él en términos de rendimiento y en términos de utilización del ancho de banda. Con NCache puede almacenar sus estados de vista en el lado del servidor, puede mantenerlo en el lado del servidor en NCache, envíe un pequeño token ficticio de regreso al navegador. Por lo tanto, sus estados de vista se vuelven más pequeños en tamaño, mejoran sus costos de utilización de ancho de banda. Ahorras mucho ancho de banda en eso. Y luego, al mismo tiempo, los paquetes más pequeños son más fáciles de procesar. Su solicitud y respuesta, el paquete se vuelve más pequeño y eso también contribuye a mejorar el rendimiento de su aplicación. Por lo tanto, obtiene rendimiento y reducción en el costo de utilización del ancho de banda, una vez que comienza a usar nuestro ASP.NET view state proveedor. Y esta es también una opción de cambio de código para NCache. Y puede usarlo muy fácilmente en Microsoft Azure.
Almacenamiento en caché de resultados de ASP.NET
La tercera característica importante aquí es el proveedor de almacenamiento en caché de salida ASP.NET, tanto para ASP.NET MVC como para granjas web. Si tiene contenido bastante estático dentro de su aplicación en cuatro páginas diferentes para diferentes solicitudes, en lugar de volver a procesar y volver a ejecutar todas esas solicitudes, aunque obtenga los mismos datos en respuesta a esas solicitudes, tiene sentido almacenarlos en caché y luego use la salida almacenada en caché para solicitudes posteriores. Si vuelve a recibir la misma solicitud, no realice el simulacro y luego simplemente extraiga el contenido del caché de NCache directamente. Por lo tanto, le permitimos almacenar resultados de páginas ASP.NET completos en NCache y para ser utilizado para solicitudes posteriores. Y esto tampoco es un cambio de código porque ahorra mucha potencia de procesamiento, mucho tiempo de ejecución, muchos beneficios de rendimiento se logran con la ayuda de nuestro proveedor de caché de salida ASP.NET.
Entonces, estos son tres aspectos importantes con los que puede comenzar rápidamente. Todas estas son opciones sin cambio de código. Puede tomar de 10 a 15 minutos configurarlo y luego, podría comenzar a ver todos los beneficios que acabamos de discutir. Y en Microsoft Azure, en realidad no hay ningún sustituto para estos. Terminaría usando las opciones predeterminadas, lo que significa que mantiene todo en el procesador en esta base de datos. Y ya hemos hablado sobre cuáles son los problemas asociados con ellos. Por lo tanto, le recomiendo encarecidamente que eche un vistazo a estas características para comenzar y luego, una vez que su caso de uso progrese, podría comenzar a usar el almacenamiento en caché de datos de nuestra aplicación. El tercer caso de uso importante de NCache, estoy dedicando mucho tiempo a esto para poder transmitir la importancia de usar un caché distribuido en sus arquitecturas de aplicaciones. Por favor, hágamelo saber si hay alguna pregunta en este punto hasta el momento.
Intercambio de datos de tiempo de ejecución escalable a través de mensajería
Ahora, el tercer caso de uso importante de NCache es que puede usarlo de manera escalable y muy confiable para la plataforma de intercambio de datos en tiempo de ejecución con la ayuda de nuestro soporte de mensajería. Similar a la cola de MSN y al servicio de mensajería de Java. También tenemos una plataforma de mensajería. Dado que ya tiene datos en el caché. Por ejemplo, se agregan algunos datos, tiene algunos catálogos de productos, se agrega, actualiza o elimina un producto del caché, desea recibir una notificación en función de eso, podría tener nuestro sistema de propagación de notificación de eventos, que puede propagar y luego notificar usar si los datos cambian en el caché. Entonces, hay mensajes de nivel de datos, a los que puede conectarse y comenzar a usar esos mensajes según sea necesario, y también podría haber algunos mensajes de aplicaciones personalizados, donde una aplicación puede comunicarse con otras aplicaciones con la ayuda de nuestra plataforma de mensajería. Por lo tanto, es un intercambio de datos muy poderoso porque una aplicación puede compartir datos con otra y luego también podría compartir mensajes entre diferentes aplicaciones que usan el mismo sistema de almacenamiento en caché distribuido. Entonces, esta es una característica muy poderosa, mucha gente no la conoce, pero es muy poderosa en términos de la capacidad que ofrece.
Por favor, hágamelo saber si hay alguna pregunta. Estos son algunos casos de uso importantes de NCache, que cubriré rápidamente. Una vez que planea usar un caché distribuido en Microsoft Azure, hay un concepto muy importante, diría que es muy importante la escena que se va a crear.
¿Qué datos almacenar en caché?
¿Qué tipo de datos deben almacenarse en caché? Ahora, la caché distribuida suele ser para los datos a los que se accede más fácilmente, donde tiene más lecturas y escrituras y luego esos datos se leen una y otra vez para solicitudes posteriores. He clasificado los datos en dos categorías diferentes. Podría tener datos permanentes, que generalmente existen en la base de datos, pueden cambiar, pero la frecuencia de cambio no es tan grande, por eso los he dividido en datos de referencia y transaccionales. Pero tenemos datos permanentes y luego tenemos datos transitorios. Los datos permanentes son los que realmente existen en la base de datos y es muy importante que los almacene en caché. Entonces, reduce sus costosos viajes a las bases de datos de back-end.
Y luego, tenemos datos transitorios que son datos temporales, que son de corta duración, pueden ser válidos solo para el alcance del usuario actual o solo para el alcance del ciclo de aplicación actual para el caso. Podrían ser configuraciones de usuario, podrían ser configuraciones de usuario, podrían ser sesiones de ASP.NET de usuario, ver almacenamiento en caché de salida de estado. Por lo general, no pertenece a la base de datos, pero tiene sentido mantenerlo en el caché dependiendo de qué tan pronto lo necesite y cuántas veces lo necesite una vez que lo almacene en caché. Luego, estos datos se pueden dividir en otras categorías. Por ejemplo, donde la mayoría de los datos son de lectura, más lecturas que escrituras o un número igual de lecturas o escrituras. Por lo tanto, la referencia es más lecturas que escrituras y las transacciones son lecturas y escrituras.
Y luego, tenemos datos transitorios que son datos temporales, que son de corta duración, pueden ser válidos solo para el alcance del usuario actual o solo para el alcance del ciclo de aplicación actual para el caso. Podrían ser configuraciones de usuario, podrían ser configuraciones de usuario, podrían ser sesiones de ASP.NET de usuario, ver almacenamiento en caché de salida de estado. Por lo general, no pertenece a la base de datos, pero tiene sentido mantenerlo en el caché dependiendo de qué tan pronto lo necesite y cuántas veces lo necesite una vez que lo almacene en caché. Luego, estos datos se pueden dividir en otras categorías. Por ejemplo, donde la mayoría de los datos son de lectura, más lecturas que escrituras o un número igual de lecturas o escrituras. Por lo tanto, la referencia es más lecturas que escrituras y las transacciones son lecturas y escrituras. Por lo tanto, podría considerar almacenar en caché todos sus datos de referencia, estos suelen ser sus datos permanentes que pertenecen a la base de datos. Trate de traerlo al caché distribuido y almacene en caché tanto como pueda, para que no regrese a las bases de datos. Y obtiene la mayoría de los beneficios de rendimiento que se necesitan de esto. Y luego, debería considerar almacenar en caché algunos de sus datos de transacciones, como el estado de la sesión ASP.NET, el estado de vista y el almacenamiento en caché de salida porque no desea perder rendimiento al obtener estos datos transitorios o datos transaccionales de las fuentes de datos de back-end. . Dependiendo de la cantidad de usuarios, si tiene millones de usuarios conectados, piense en un escenario en el que va a la base de datos dos veces por usuario, podría ver cuánto tiempo gastaría en obtener esos datos de una fuente más lenta. , desde la fuente de datos de back-end. Obtener del caché y para eso definitivamente debería considerar almacenarlo en caché en el caché distribuido.
Descripción general de la API de almacenamiento en caché
Así es como se ve el almacenamiento en caché. Es una tabla hash como Interface. Tenemos una clave basada en cadenas y luego tenemos un objeto como su valor. El objeto podría ser cualquier objeto de parámetro .NET. Podría tener cualquier cosa que esté permitida por .NET, almacenada como caché de objetos. Mientras que la clave de cadena, podría crear una formación clave significativa. Por ejemplo, todos los empleados con ID de empleado 1000, un empleado con ID de empleado 1000 se puede almacenar con esta clave aquí mismo. Todos los pedidos de ese empleado pueden tener esta clave, donde tiene pedidos de empleados y luego la identificación de ese empleado. También podría haber un parámetro de tiempo de ejecución. Y luego, podría tener una consulta de empleado. Por ejemplo, almacenó en caché la consulta responsable y el argumento fue encontrar el código de empleados en función de un título equivalente a gerente. Entonces, podría obtener una colección almacenada como un solo objeto en el caché. Entonces, este es solo un ejemplo de cómo se puede formular la clave de caché, pero puede encontrar cualquier técnica de base clave según sea necesario. Es solo un ejemplo, use lo que tenga más sentido para su aplicación.
Chicos, por favor háganme saber si hay alguna pregunta. No veo muchas preguntas hoy. Por favor, hágamelo saber si hay alguna pregunta hasta ahora. Además, avíseme si voy demasiado lento o demasiado rápido en una parte específica, para que pueda mantener el ritmo. También puede enviarme sus comentarios usando la misma pestaña de respuesta de preguntas e incluso pasaré más tiempo en una característica específica.
Chicos, por favor háganme saber si hay alguna pregunta. No veo muchas preguntas hoy. Por favor, hágamelo saber si hay alguna pregunta hasta ahora. Además, avíseme si voy demasiado lento o demasiado rápido en una parte específica, para que pueda mantener el ritmo. También puede enviarme sus comentarios usando la misma pestaña de respuesta de preguntas e incluso pasaré más tiempo en una característica específica. Bueno. Hay una pregunta, ¿qué pasa con los datos espaciales? Bueno. ¿Podemos consultar ese tipo de datos también? Sí. Absolutamente, tenemos un soporte de consulta muy fuerte, este objeto puede ser de cualquier tipo. Entonces, déjame decirte que esto cubre todo tipo de datos que planeas almacenar en caché. Ahora, esos datos se pueden consultar en función de diferentes argumentos, en función de diferentes parámetros que transmita. De hecho, tenemos un lenguaje de consulta de objetos muy fuerte, que he planeado aquí mismo. Entonces, tenemos consultas paralelas con la ayuda del lenguaje de consulta de objetos. Y podría ejecutar consultas muy flexibles con la ayuda de nuestro lenguaje de consulta de objetos. Por ejemplo, hay una pregunta tuya. Si queremos que todos los lugares estén cerca de la ubicación actual, por ejemplo, sí. puedes. Por ejemplo, tiene todos los datos propagados en el caché. Tiene todos los menús, almacenados en el caché por separado como objetos separados. ¿Derecha? Y luego podría tener sus atributos de objeto, que también pueden brindarle información de ubicación. Por lo tanto, puede ejecutar una consulta que diga seleccionar todos los lugares, donde el lugar es esa ubicación igual a esto. Entonces, si los atributos del objeto tienen esta información, podría obtener todos los registros coincidentes del caché de distribución. Es por eso que una forma de hacerlo.
La segunda forma de hacerlo es que pasa la información espacial o toda la información que necesita consultar como parte de esos objetos en forma de etiquetas. Almacena sus objetos y luego almacena palabras clave adicionales, que están aquí como etiquetas. Estos son identificadores que identifican, que hacen colecciones lógicas en el caché. Entonces, puede usar la API basada en etiquetas, donde dice obtener por etiqueta y luego obtiene la colección completa que coincide con los resultados o incluso puede ejecutar una consulta donde dice seleccionar lugares donde la etiqueta es igual a, y la etiqueta es esencialmente una ubicación que ya ha agregado, donde la etiqueta equivale a una ubicación XYZ y obtendrá todos los registros que coincidan según ese criterio. Entonces, estas son las dos formas en que puede manejar las consultas, donde puede agregar etiquetas encima de sus objetos o simplemente confiar en los atributos reales del objeto. Y luego realice consultas de búsqueda similares a SQL en ellos. Espero que responda a sus preguntas. Por favor, hágamelo saber si hay más preguntas sobre esto.
Hay otra pregunta. ¿Puedo configurar la caducidad de ciertos elementos almacenados en caché en función de los eventos? Por ejemplo, un registro es caché y caduca, si se actualiza en la base de datos. ¡Absolutamente! tenemos dos tipos de vencimientos. Tenemos, el tiempo es la caducidad y hay dos tipos de caducidad, por lo que si transcurre el tiempo, puede caducar los elementos y esta caducidad también puede basarse en la dependencia de la base de datos. Por ejemplo, algo cambia en la base de datos y eso respondería a su pregunta. Por ejemplo, un registro cambia en la base de datos que tenía un registro en el caché, que dependía de eso, tan pronto como cambia el registro de la base de datos, la base de datos puede enviar una notificación de evento y el elemento en el caché puede eliminarse automáticamente del frente de el caché Por lo tanto, puede caducar tan pronto como caduque en la base de datos. Entonces, eso es exactamente lo que ofrecemos en términos de dependencias de bases de datos relacionales y la dependencia de SQL cubriría esto. Apreciaría si pudiéramos pasar rápidamente por otra diapositiva y luego llegar a nuestra parte de almacenamiento en caché de objetos y esto debería responder muchas preguntas. Por favor, hágamelo saber, si hay más preguntas, de lo contrario, voy a reanudar la presentación desde el mismo momento.
Hay una pregunta. ¿Puede mostrar una muestra persistente y recuperar datos de la memoria caché de muestra? Rápidamente recomendaría que mire nuestras muestras, que vienen y comienzan con NCache y también están disponibles en nuestro sitio web. Entonces, si lo llevo rápidamente a nuestras muestras, aquí tiene y NCache. Puedo guiarlo hacia la muestra, que maneja exactamente esto. Entonces, tenemos sincronización de base de datos y luego tenemos dependencias. Entonces, estos deberían. Los identificadores de dependencia, la dependencia de SQL y la sincronización de la base de datos son otro tipo de ejemplo, que lo ayuda a manejar el escenario con la ayuda de solicitudes de lectura y escritura. Espero que esto responda a su pregunta. Muchísimas gracias.
Hay otra pregunta. ¿Podemos consultar esto para ordenar los datos? Sí. los hemos agrupado por un orden por soporte. Entonces, podría usar esos atributos junto con la consulta. ¡Muy bien chicos! Muchas gracias por enviar estas preguntas. Realmente aprecio estos. Por favor, que sigan viniendo. Ya que esto estaba planeado hacia el final de nuestra presentación y ya iba a cubrir esto, pero es bueno tener todas las preguntas, así que por favor sigan haciéndolas. Muchísimas gracias.
NCache Arquitectura
Ahora lo siguiente, iré rápidamente a la arquitectura. La caché distribuida es muy elástica en términos de agregar o quitar servidores. Puede agregar tantos servidores como desee. Puede desconectar cualquier servidor. Se basa en la agrupación en clústeres de caché basada en TCP. Es nuestro propio protocolo de preguntas implementado. No utilizamos clústeres de Windows ni de terceros. Incluso en Microsoft Azure, solo confiaría en una dirección IP y un puerto y NCache se encargaría del resto. Es una arquitectura 100% peer-to-peer. No hay un punto único de falla, puede desconectar cualquier servidor y agregar nuevos servidores y clientes sin ningún impacto. Puede aplicar cambios dinámicamente a un clúster de caché en ejecución. Entonces estas configuraciones son dinámicas de tal manera que estos servidores están en constante comunicación con los clientes. Cualquier servidor que se caiga o que se agregue un nuevo servidor se notifica de inmediato. Hay un mapa en memoria, que se propaga al cliente y se actualiza cada vez que hay un cambio en el caché. Por lo tanto, la información de membresía del clúster de estos mapas y el mapa de información de topología de caché se actualizan tan pronto como hay un cambio en el clúster de caché. Por lo tanto, hay un soporte de conmutación por error de conexión, además de que si un servidor se cae, los clientes lo automatizarían y los servidores harían que ese servidor se fuera y los nodos supervivientes estarían disponibles automáticamente y los clientes se conectarían automáticamente. Entonces, en resumen, no tendría ninguna pérdida de datos ni ningún tiempo de inactividad de la aplicación en lo que respecta a las aplicaciones cliente y luego hay cuatro topologías diferentes entre las que puede elegir.
Topologías de almacenamiento en caché
El modo activo y pasivo o el modo maestro o esclavo se determinarían en función de las topologías de almacenamiento en caché. Como dije, es una arquitectura peer-to-peer. Por lo tanto, cada servidor participa de forma independiente en el clúster de caché. Por lo tanto, no hay dependencia o no existe el concepto de host principal como el que tenía en AppFabric o no hay activo o pasivo o en términos de configuración o en términos de administración de clústeres. Cada servidor es 100% independiente en términos de configuración, en términos de su posición en el clúster de caché. Pero hay diferentes topologías de almacenamiento en caché y tenemos activo y pasivo, pero se basan en los datos en el caché. Si los datos están disponibles activamente, los llamamos activos y si los datos son solo una copia de seguridad, los clientes no están conectados a ellos, los llamamos pasivos. Pero este servidor pasivo se agrega nuevamente en el caché en una arquitectura 100% peer-to-peer.
Hay una pregunta. ¿Hay algún SDK para plataformas móviles, Android o iOS para usar? NCache en aplicaciones móviles nativas? En este momento tenemos .NET y la API de Java, estamos trabajando en una API tranquila, por lo que, si se lanza, estoy bastante seguro de que podrá usarla desde las aplicaciones de Android y iOS. Envíeme un correo electrónico sobre eso, envíeme una solicitud sobre eso y lo enviaré a ingeniería y también me pondré en contacto con usted rápidamente con los plazos.
Ahora tenemos cuatro topologías de almacenamiento en caché diferentes.
Caché reflejada
Hemos reflejado, que es activo/pasivo. Voy a hojearlos rápidamente porque esta no es nuestra agenda hoy. Quiero centrarme más en nuestra parte práctica. Les daré un vistazo de las diferentes topologías NCache ofertas Tenemos cuatro topologías diferentes. Mirrored Cache, es un activo-pasivo de dos nodos. Tiene todos los clientes conectados activos y luego tenemos un servidor de respaldo aquí. Si la actividad se desactiva, las copias de seguridad se activan automáticamente. Y estos clientes conmutan por error automáticamente. Esto se recomienda para configuraciones más pequeñas, muy bueno para lecturas, muy bueno para la derecha y también es muy confiable.
Caché replicado
Luego tenemos Replicado, es un modelo activo-activo. Entonces, ambos servidores están activos pero los clientes están distribuidos. Por lo tanto, si tiene seis roles web o roles de trabajo en Microsoft Azure, con equilibrio de carga uniforme, algunos se conectarían al servidor uno y otros se conectarían al servidor dos. Y tenemos un modelo de sincronización aquí.
En espejo teníamos asíncrono, por lo que el rendimiento de lectura también fue muy rápido. En replicado siempre tenemos un modelo de sincronización. Entonces, tenemos una copia completa de caché en cada servidor y estos servidores tienen los mismos datos y de manera sincronizada todas las actualizaciones se aplican en todos los servidores. Por ejemplo, si actualiza el elemento del servidor número dos en el servidor uno, se aplica en el servidor dos de forma sincronizada y solo entonces se completa la operación. Pero lee, que se aplican localmente en el servidor donde está conectado el cliente. Entonces, las lecturas son muy rápidas, muy escalables, las escrituras son muy consistentes, diría que si cambia algo aquí, siempre tendría ese cambio aquí también, solo que la operación se completaría. Por lo tanto, para transacciones de datos confiables para actualizaciones, para un rendimiento ultrarrápido, esta es una muy buena topología, si pierde el servidor uno, estos clientes conmutarán por error al servidor dos y si pierde el servidor dos, estos clientes conmutarán por error. Por lo tanto, no hay pérdida de datos, ni rebote de aplicaciones.
Caché con particiones
Luego tenemos el caché particionado, donde tenemos los datos particionados y luego los hemos particionado con replicación. Entonces, tenemos datos particionados, donde puede tener dos o más servidores según sea necesario y los datos se dividen automáticamente en todos los servidores. Algunos datos irían al servidor uno y algunos datos irían al servidor dos. Los mapas de distribución de monedas ya son conscientes, donde existen datos en el caché, identificarían el servidor y usarían ese servidor para leer y escribir datos. Más servidores significan más copias de lectura del caché, más escritura, más servidores para leer datos, más servidores para escribir datos. Por lo tanto, estos servidores contribuyen al rendimiento general, la escalabilidad general. Por lo tanto, más servidores significan más escalabilidad fuera del caché. Particionado no tiene ninguna copia de seguridad.
Caché de réplica de partición
Tenemos particiones con réplicas, donde puede tener una copia de seguridad de cada partición en otro servidor en una partición de réplica pasiva. Por ejemplo, la copia de seguridad de uno está en el servidor dos y la copia de seguridad del servidor dos está en el servidor uno. Por lo tanto, no hay pérdida de datos, si el servidor uno se cae o si necesita desconectar el servidor. Las copias de seguridad están disponibles a la vez. Y esto también es muy escalable linealmente, de hecho, es nuestra topología más escalable en términos de números de rendimiento.
Permítanme mostrarles rápidamente algunos números de referencia para respaldar esto. Por favor, hágamelo saber si hay alguna pregunta. Como dije, voy a hojear rápidamente estas topologías para ahorrar algo de tiempo aquí.
Aquí hay un caché reflejado con dos nodos. Replicado muy bien para lecturas, las escrituras no son tan escalables, pero podría ver el punto aquí porque tiene una naturaleza sincronizada de actualizaciones y particiones con escalabilidad de lecturas y escrituras. Réplicas particionadas con lecturas y escrituras, esto también tiene copias de seguridad para que pueda obtener copias de seguridad junto con el rendimiento y la escalabilidad. Y luego tenemos réplicas particionadas con la réplica de sincronización también.
Caché de cliente
También hay algunas características más, por ejemplo, también admitimos el almacenamiento en caché local cercano al cliente sin ningún cambio de código, también puede activar el almacenamiento en caché en el lado de su aplicación. Y este caché estaría sincronizado con el caché del servidor, recomendado principalmente para el tipo de datos de referencia. Por lo tanto, si tiene más lecturas que escrituras, es posible que desee activarlo y esto le brindará mejoras de rendimiento súper rápidas además de su aplicación existente. Guarda sus viajes a través de la red en un caché distribuido. Esto ya está guardando sus viajes en la parte posterior de las bases de datos, pero incluso puede guardar este viaje en el que tiene que cruzar la red utilizando un caché de cliente. Sólo tienes que apagarlo. E incluso puede hacerlo en el proceso a su aplicación para ahorrar aún más la serialización y la comunicación entre procesos. Y NCache gestiona toda la sincronización. Si algo cambia aquí, se propaga aquí, así como en otros cachés de clientes y viceversa. Es una característica muy buena para empezar. Ya cubrí los puntos de referencia de rendimiento.
Replicación WAN de caché distribuida
Luego tenemos soporte de replicación WAN también en Microsoft Azure. Por ejemplo, si tiene dos centros de datos, uno en Nueva York y el otro quizás en Europa, incluso podría transferir datos de un centro de datos a otro. Podría tener un clúster de caché aquí y con la ayuda de nuestro puente, que también está respaldado con los nodos activo-pasivo, puede transferir datos al puente y luego el puente puede, a su vez, transferirlos al sitio de destino. Esto podría ser activo-pasivo para el escenario DR o también podría ser activo-activo.
BUENO. Hay una pregunta. ¿Puedo usar la memoria caché del cliente en un sistema desconectado que son aplicaciones móviles sin conectividad de red temporal? Esa es una muy buena pregunta. La pregunta es si puedo usar el caché del cliente en un modo desconectado. Hemos hablado de ello; Esta fue una solicitud de función de uno de los clientes y luego lo discutimos en profundidad. Entonces, hay un requisito específico que le interesa. Ya tenemos algunos planes, ya lo hemos discutido y, desde entonces, ya hemos recibido una solicitud similar a esta. Si pudiera enviarme un correo electrónico sobre eso, quiero que se use el caché del cliente para mi caso de uso y quiero que se use incluso en modo desconectado. Estaré muy feliz de pasar esto a ingeniería porque ya lo están discutiendo y resulta que lo proporcionan. Muchísimas gracias.
Bueno. Estaré esperando tu correo electrónico en ese caso. En este punto, la memoria caché del cliente camina en combinación con la memoria caché del servidor. Si esto baja el caché del cliente, ya que se sincroniza con un caché del servidor, entonces si esto también perdería todos los datos. Pero planeamos usar un modo desconectado, donde incluso si la conexión del servidor se cae, el caché del cliente permanece en funcionamiento y también pone en cola algunas operaciones que se realizarán en una etapa posterior.
Demostración práctica
A continuación, le mostraré rápidamente una demostración práctica. ¿Cómo funciona el producto real? Nos queda poco tiempo, creo que tenemos diez minutos. Por lo tanto, le daré rápidamente una descripción general de Azure. Lo que esencialmente necesita para comenzar con NCache es que planeas el despliegue para NCache.
Lo primero que necesitas es que crees una red virtual de Azure. Vienes a Microsoft Azure, creas una red virtual. Podría usar la creación rápida o la creación personalizada y luego, por ejemplo, si elijo la creación rápida, solo puedo decir NCache máquina virtual Esta sería una red virtual que usaré para NCache y luego podría simplemente crear esta red virtual. Simplemente podría aportar cualquier detalle específico sobre la red virtual según sea necesario. O puede que ya tenga una red virtual en su entorno que le gustaría usar para NCache implementaciones. Entonces, ese es nuestro primer paso. Tengo algunas redes virtuales que ya están creadas. Entonces, puedo seguir adelante y pasar al siguiente paso.
El siguiente paso sería crear NCache maquinas virtuales. Solo necesita crear una máquina virtual que pueda tener NCache preinstalado, solo puede instalar NCache tome nuestra imagen de máquina virtual de Microsoft Azure de la Azure marketplace eso es para NCache professional pero si te interesa NCache enterprise, simplemente podría usar el servidor de imagen simple 2012. Instalar NCache en la parte superior y luego guarde esa imagen para una etapa posterior y luego cárguela, cada vez que necesite generar una nueva VM para NCache implementación del servidor. Entonces, de la galería, podría elegir una imagen, por ejemplo, el servidor de 2012. Podría elegir lo siguiente en esto solo dale un nombre. Por ejemplo, demostración 3. Elegiré algún nivel de servidor y luego podría completar alguna información según sea necesario.
Estos son pasos específicos de Azure. Entonces, estoy bastante seguro de que estarías familiarizado con esto. Lo siguiente, que es el más importante, es si desea crear un nuevo cloud service o usar el que ya está allí. Por ejemplo, si uso el punto de referencia, también seleccionará automáticamente la red virtual. Pero podría crear sus máquinas virtuales para que estén allí por su cuenta cloud services también para que usted podría optar por crear un nuevo cloud service. Pero aun así, le recomendaría que elija una red virtual para todas las máquinas virtuales de su servidor y luego debería ser la misma para todas las máquinas virtuales de servidor para NCache. Por lo tanto, obtiene más rendimiento del sistema en lo que respecta a la comunicación de servidor a servidor. Entonces, voy a elegir este punto de referencia y, en base a eso, podría elegir el siguiente.
Puede completar algunos detalles específicos sobre la red si es necesario. Pero en general, esto es todo lo que necesito. Entonces, podría simplemente... Está bien. El servidor en la nube que he elegido no admite este tipo de máquina virtual. Entonces, solo necesito elegir crear una nueva cloud service con ese. Bueno. Entonces, solo diré para que apruebe y listo. Entonces, así es como sería esto. Voy a cancelar esto. Ya tengo estos servidores aquí y, de hecho, puedo iniciar sesión rápidamente en algunos servidores que ya tengo configurados. Entonces, por favor tengan paciencia conmigo. Permítame mostrarle cómo puede comenzar a crear un caché y configurarlo y probarlo rápidamente en su entorno. Tenemos unos diez minutos. Por lo tanto, quiero hacer un uso completo de ella. Y chicos, siéntanse libres de publicar tantas preguntas como sea necesario. Siempre respondo preguntas mientras preparo el ambiente.
Bueno. Ya tengo estos servidores. Puedo iniciar sesión rápidamente en estos. Ya los hemos estado usando para algunas pruebas, creo que arruiné la contraseña aquí, por favor tengan paciencia conmigo. ¡Ahí tienes! ¡OKEY! ahí vas! entonces tengo esa Demo 2 justo aquí. Entonces, estas son mis dos cajas, ahí tienes. ¡OKEY! Entonces, tengo estas dos cajas ya configuradas que son parte de la misma red virtual en Microsoft Azure.
Hay una pregunta. ¿Necesito una máquina virtual necesariamente o puedo usar un servidor de aplicaciones de Azure? ¿Qué pasa con la ventana acoplable? Todavía no tenemos soporte para Docker. Puedo consultar con ingeniería si están trabajando en uno. En lo que respecta al modelo de servidor, por NCache necesita tener una máquina virtual en Microsoft Azure. La aplicación virtual podría ser un modelo de servicio, podría ser un cloud service, podría ser un rol web, podría ser un rol de trabajador, podría ser una VM real donde se implementa su aplicación. Pero el NCache la parte del servidor tiene que ser una VM y, como dije, la forma más fácil sería crear una imagen de VM preconfigurada de NCache. Guárdelo en la galería y luego cárguelo, cuando necesite generar una nueva instancia. Incluso puede elegir lo mismo para el escalado automático, donde tiene las plantillas de VM disponibles, NCache instalado activado y configurado, solo genera esas nuevas máquinas virtuales, cuando su nodo crece hasta cierto límite.
Hay otra pregunta. Es posible que ya haya mencionado, ¿hay cifrado y compresión para la reducción de datos en términos de utilización del ancho de banda y creo que está preguntando sobre el cifrado y la compresión? ¡Sí! estas dos características están disponibles sin ningún cambio de código. Puede cifrar sus datos para la transmisión de datos confidenciales, los datos se pueden cifrar y luego los datos también se pueden comprimir. Entonces, estos son parte de NCache apoyo. Muchas gracias por hacer estas preguntas. Por favor, hágamelo saber si hay más preguntas.
Configuración de un entorno
Rápidamente quiero mostrarles el producto real en acción. Entonces, lo siguiente que debe hacer es ir a nuestro sitio web e instalar NCache ya sea la versión en la nube, que está aquí mismo, que es una nube profesional, está disponible en Microsoft Azure marketplace también o simplemente descargue la Enterprise Edition normal e instálela en sus máquinas virtuales de Microsoft Azure. Ya he hecho la instalación Enterprise. Entonces, el paso uno está completo. Ahora el paso dos es crear un caché sin nombre y para eso podría iniciar un NCache herramienta de administrador que viene instalada con NCache. Por lo tanto, puede administrar todo desde uno de los VMS según sea necesario o también puede administrarlo desde un servidor separado que tenga acceso en la red a estos servidores.
Crear una caché en clúster
El siguiente paso es crear un caché con nombre. Rápidamente voy a hacerlo. Se llama caché de demostración.
Este es el nombre que usará para todas sus aplicaciones cliente para usar este caché. Podría hacer referencia a este nombre para continuar y obtener datos del caché. Elegiré la topología de caché de réplica particionada porque es la más recomendada.
A continuación, elegiré Async como opción de replicación porque es más rápido. El servidor 1 y mire está usando la IP privada de los servidores y es por eso que le recomendé que mida la red virtual en términos de implementación de servidor a servidor. Entonces, son accesibles en las IP internas y tiene una comunicación muy rápida entre servidores.
El puerto TCP para la comunicación por defecto Azure VMS tiene el firewall abierto. Por lo tanto, le recomendaría que apague eso o al menos golpee NCache puertos de comunicación en el cortafuegos. Y luego, el tamaño del caché por servidor se basa en la memoria que se basa en los datos que planea tener en el caché. Por lo tanto, si necesita dos gigabits de tamaño de caché, simplemente obtenga la cantidad correcta de memoria especificada aquí. Este es solo un límite superior, si el caché se llena, tiene dos opciones, puede rechazar nuevas actualizaciones, lo que significa que no se pueden agregar datos, obtendrá una excepción o puede activar los desalojos donde solo puede especificar un porcentaje de desalojo y estos algoritmos pueden controlar cuántos elementos se pueden eliminar utilizando estos algoritmos para dejar espacio para los nuevos elementos. Por lo tanto, si su caché se llena, se activan los desalojos, algunos elementos se eliminarán automáticamente y podrá agregar más elementos. Simplemente elijo terminar con la configuración predeterminada.
Luego, esto completa nuestro paso 2, donde tenemos el caché configurado en el panel derecho, hay todas las configuraciones relacionadas con este caché. El paso 3 es agregar el nodo cliente. Podría agregar la demostración 3, pero dado que solo tenemos dos servidores, también agregaré estas dos cajas como clientes. El paso 4 es iniciar y probar este clúster de caché, para eso solo haré clic con el botón derecho y elegiré eso y esto iniciaría este caché en todo mi servidor de almacenamiento en caché y, por cierto, estos nodos de cliente son en realidad mis roles web o VM, donde mi aplicación está implementada.
Entonces, por eso te recomendé que mantuvieras todo en la misma red también. Entonces, podrías administrarlos desde NCache Gerente. Y haga clic con el botón derecho en las estadísticas, esto abriría los contadores perf-mon. El caché ha comenzado, algunas de las configuraciones están atenuadas y no se pueden cambiar mientras la caché se está ejecutando, pero aún puede cambiar algunas de las configuraciones, como activar la compresión, hacer clic con el botón derecho y elegir configuraciones de aplicación permanente. Le pedirá que guarde el proyecto primero. Entonces, solo voy a hacer eso y luego aplicaré configuraciones. Ahí tienes
Ahora se ha configurado el caché, se han configurado los clientes. Hemos terminado con tres pasos, hemos instalado NCache.
Simule estrés y monitoree estadísticas de caché
Creamos el caché, configuramos los clientes, terminamos desde el punto de vista de la configuración, pero solo necesitamos iniciar y ejecutar este clúster de caché y para eso, solo usaré una herramienta de prueba de esfuerzo, que viene instalada con NCache. Y ejecutarlo contra mi caché. Entonces, también pude ver algo de actividad. También voy a iniciar sesión en mi segundo cuadro y también ejecutaré esta aplicación basada en consola. Entonces, eso y antes, ejecuto la segunda instancia, miro las solicitudes por contador de segundo. Tenemos alrededor de mil solicitudes por segundo generadas por una instancia de la herramienta de prueba de esfuerzo.
En el segundo servidor, solo voy a ejecutar esto. Entonces, tenemos algo más de carga y notamos que el contador de solicitudes por segundo casi se ha duplicado. Dos mil solicitudes por segundo.
Aunque he ejecutado una instancia desde este cuadro, todavía estaba usando ambos servidores. Ejecuté otra instancia en la que la aplicación también estaba usando ambos servidores en combinación entre sí y luego tenemos esta herramienta de monitoreo, que nos brinda estado, CPU, solicitud, tamaño, red y diferentes matrices desde el lado del servidor como con nosotros desde el lado del cliente.
Y también podría crear sus propios tableros como lo he hecho aquí. Lo siento chicos por limitaciones de tiempo, tuve que ser un poco rápido para esto, pero esto fue solo cinco pasos simples para comenzar. NCache. Nuestro caché está en funcionamiento.
Uso NCache Muestras
Lo siguiente es usar el caché en sus aplicaciones reales y para eso, puede consultar rápidamente nuestro NCache muestras Por ejemplo, si desea utilizar operaciones básicas, esta es la muestra. Si desea utilizar el estado de sesión, puede utilizar esta aplicación de estado de sesión de ASP.NET. También tenemos ejemplos de almacenamiento en caché de salida y estado de vista disponibles en esta lista. Entonces, aproveche estos y consulte esto para usar NCache en aplicaciones reales.
Hay una pregunta. ¿Puedo configurar dos niveles de caché, uno más grande que equivale a 200 GB en un estado persistente y otro más pequeño que equivale a 1 GB más volátil en la memoria, y tener una memoria de nivel 1 sincronizada con un subconjunto de la memoria a la que comúnmente se hace referencia a los objetos del caché de nivel 2? Esto es posible. Tienes dos preguntas. La primera pregunta es si puedes crear dos cachés diferentes con dos memorias diferentes. Sí. Puede, la mayoría de nuestros clientes crean un caché para datos estáticos y otro caché para datos dinámicos. Entonces, eso es algo que puede hacer y puede crear configuraciones completamente diferentes para estos dos cachés.
La siguiente pregunta es, ¿existe la posibilidad de sincronizar datos entre estos dos cachés? Sí. Puedes. Existe esta dependencia de sincronización de caché. Esa función está disponible de forma privada, pero puedo compartir algunos detalles sobre cómo implementarla y también podría tener una dependencia de sincronización entre dos cachés diferentes. Esta misma característica es lo que usamos en cachés en especie siempre que tenemos caché de cliente, que es un caché y está sincronizado con el caché en clúster configurado en otros servidores. Entonces sí. Para responder a su pregunta, sí, puede tener dos cachés diferentes y también podría tener sincronización entre los datos en esos dos cachés.
Lo resumiré rápidamente para usted, hay muchos aumentos de caché de objetos que puede aprovechar, estos son parte de NCache soporte de almacenamiento en caché de objetos y luego ya cubrimos el estado de vista de la sesión ASP.NET. También hay algunas integraciones de terceros. Entonces, este es esencialmente el final de nuestro seminario web. Me disculpo por repasar algunos fragmentos debido a las limitaciones de tiempo, pero solo para reiterar que cubrimos algunos detalles básicos sobre problemas de incapacidad, hablamos sobre el almacenamiento en caché de distribución en memoria en la solución, hablamos sobre la implementación en Microsoft Azure, diferentes casos de uso , soporte de agrupamiento, soporte de topología dentro NCache. Tuvimos una demostración práctica específica sobre cómo comenzar en Microsoft Azure en lo que respecta a NCache va
Por favor, hágamelo saber, ¿qué le pareció la presentación? ¿Qué le pareció el producto en general? Dame tu opinión sobre esto. Hay algunas cosas que puedes hacer hacia el final. Puede ir a nuestro sitio web y puede descargar una versión de prueba de 30 días de NCache. También puede elegir nuestra edición en la nube, que es NCache professional cloud, está disponible en Microsoft Azure. Nosotros también tenemos un cliente. Luego, incluso podría usar sus máquinas virtuales de Azure para ir con el producto Enterprise Edition si lo necesita. Puede ponerse en contacto con nuestro equipo de soporte yendo a la página de soporte. Hay algunos detalles de contacto con los que puede ponerse en contacto con el soporte en support@alachisoft.com.Puede solicitar una demostración del producto según sea necesario y también puede ponerse en contacto con nuestro equipo de ventas para obtener información sobre precios. Entonces, ya estamos en nuestro marcador de una hora, así que creo que es hora de decir adiós. Avíseme si tiene alguna pregunta incluso después de esta demostración. Puede ponerse en contacto por correo electrónico o por teléfono y estaré muy feliz de ver cualquier pregunta de ustedes. Muchas gracias muchachos. fue un placer presentar NCache seminario web hoy. Hágame saber cómo le gustó el producto, cómo le gustó la presentación y siempre podemos continuar desde allí. Muchas gracias por su tiempo a todos.