Sincronizar cachés en Bridge: replicación geográfica
El NCache El clúster de caché distribuida en memoria es la auto-sanación, dinámico y altamente escalable. Puede agregar o eliminar servidores de caché en tiempo de ejecución, sin tiempo de inactividad de la aplicación. El NCache El clúster proporciona escalabilidad lineal en términos de manejo de datos y procesamiento de solicitudes de aplicaciones. Cuando su clúster de caché alcance sus límites máximos, podrá agregar más servidores a redistributo a las solicitudes y cargas de datos.
Si un servidor de caché deja de funcionar, el clúster de caché detecta automáticamente la falla del servidor y se ajusta en consecuencia. Consideremos un caso en el que un servidor de caché deja de funcionar en el Réplica de partición topología, el clúster de caché reorganiza automáticamente las particiones y los datos. Los servidores de caché restantes copian los datos sobrantes del servidor que se cayó de su servidor de respaldo.
Cada caché agrupada tiene un clúster dedicado basado en TCP. Las aplicaciones se comunican con el clúster de caché a través de TCP. Por lo tanto, si el proceso de solicitud falla, no afecta el clúster de caché. Cada clúster de caché requiere un puerto TCP independiente al momento de configurar un caché en clúster. El Réplica de partición la topología ocupa un puerto TCP adicional para la réplica.
El Arquitectura punto a punto permite que cada servidor de caché establezca una conexión TCP con todos los demás servidores de caché. Esto permite que los servidores de caché se comuniquen directamente entre sí cuando sea necesario o transmitan las solicitudes en otros momentos. El clúster de caché, la arquitectura multiproceso permite ejecutar operaciones en paralelo, aprovechando así los beneficios del potente hardware actual.
solicite configurar el tiempo de espera de la solicitud para el clúster de caché en el momento de configurar el clúster de caché. El tiempo de espera de solicitud predeterminado es de 60 segundos.
Note
Esta característica también está disponible en NCache Professional.
Note
Los puertos del clúster asignados al clúster de caché deben estar disponibles en todos los servidores de caché configurados. De manera similar, el firewall debe configurarse para permitir la comunicación entre servidores de caché en determinados puertos del clúster. El clúster predeterminado rango de puertos comienza desde 7800.
Coordinador de clúster en una caché distribuida en memoria
En un entorno distribuido, la coordinación de diferentes tareas es inevitable. En el clúster de caché, el servidor coordinador desempeña este papel fundamental. Cada clúster de caché tiene un servidor de caché coordinador.
La selección del servidor coordinador en NCache es simple. El servidor de caché más antiguo asume el rol de servidor coordinador. Entonces, el servidor de caché que se unió al clúster primero se convierte en el servidor coordinador. Si un servidor de caché coordinador abandona el clúster de caché graciosamente o abruptamente, el siguiente servidor de caché más antiguo se convierte en el coordinador.
El servidor de caché del coordinador es responsable de lo siguiente:
Membresía del clúster: El servidor coordinador es responsable de aceptar solicitudes de membresía de nuevos servidores de caché. También transmite la lista de miembros actualizada al resto de servidores. De manera similar, cuando un servidor abandona el clúster, el servidor coordinador notifica a los demás servidores sobre el cambio de membresía.
Generación de Mapas de Distribución: El servidor coordinador genera el mapa de distribución y administra las réplicas cada vez que un servidor se une o deja el clúster de caché en el Particionado y Réplica de partición topologías.
Solicitud de pedido: Adición y actualización de datos en el Topología replicada requiere que las operaciones en todos los servidores de caché se ejecuten en el mismo orden para lograr la consistencia de los datos. Estas operaciones toman tokens de secuencia del servidor coordinador y la ejecución de las operaciones se lleva a cabo de acuerdo con estos tokens de secuencia. Este mecanismo garantiza que las mismas actualizaciones contra un determinado
CacheItem
se aplican en todo el clúster.Cargador de datos de caché y gestión de actualización: Cargador y actualización de inicio de caché las tareas se ejecutan en el servidor coordinador. cuando varios sugerencias de distribución se especifican para el cargador o la actualización de inicio de caché, el coordinador asigna estas sugerencias a diferentes miembros del clúster para la carga y actualización en paralelo.
Invalidación y Expulsión de Datos: Cada servidor de caché en Replicado y Mirror topologías contienen el mismo conjunto de datos. Por lo tanto, el servidor coordinador es responsable de la invalidación de datos (Expiraciones y Dependencias) en todo el grupo. El servidor coordinador determina qué elementos se van a expirado or desalojado de la memoria caché y elimina esos elementos de todo el clúster a través de una llamada de clúster.
Cómo los servidores se unen y abandonan el clúster de caché en una caché distribuida en memoria
El siguiente es el proceso mediante el cual los nodos del servidor se unen y abandonan el clúster de caché:
Descubrimiento de miembros y unión al servidor
Cuando inicia la caché en el primer servidor de caché, forma el clúster de caché. Un proceso de descubrimiento de miembros se ejecuta en cada servidor de caché al iniciarse el caché. En el proceso de descubrimiento, el servidor de caché intenta establecer una conexión TCP con los otros miembros de caché en el puerto de clúster configurado.
Cuando el primer servidor de caché se inicia y no puede establecer una conexión con los otros servidores de caché en el clúster de caché, concluye que no hay ningún otro servidor de caché activo. Este servidor se convierte entonces en el primer miembro y el servidor coordinador del clúster de caché. Tan pronto como se inician los otros servidores, pasan por el mismo proceso de descubrimiento y establecen conexiones con los servidores de caché en ejecución.
Estos servidores de caché buscan información sobre el servidor coordinador del clúster de caché de los servidores de caché que ya se están ejecutando. Una vez que el proceso de descubrimiento ha concluido y se determina el servidor coordinador, los nuevos servidores de caché que se unen envían solicitudes de unión al coordinador.
El coordinador acepta las solicitudes de unión, genera el mapa de distribución (sólo en el Particionado y Réplica de partición topologías) y difunde la nueva lista de miembros a todo el clúster de caché.
Salida elegante del servidor
Cuando detener el caché en un servidor de caché a través del NCache Centro de gestion or Herramientas de PowerShell, el servidor de caché saliente informa al coordinador enviando una solicitud de salida. El coordinador procesa inmediatamente la solicitud de licencia, genera mapas de distribución y transmite la nueva lista de miembros a todo el grupo. Por tanto, el grupo se ajusta rápidamente según los nuevos mapas de distribución.
Fallo abrupto del servidor
Hay casos en los que un servidor de caché puede fallar abruptamente sin informar al coordinador, es decir, una falla de energía. Cuando un servidor de caché deja de funcionar abruptamente, las conexiones TCP se interrumpen entre el servidor saliente y otros servidores de caché. Intentan restablecer la conexión TCP para un número configurable de reintentos con el servidor saliente. Este mecanismo ayuda a recuperarse de fallas de conexión temporales y evita la declaración de muerte incorrecta de un servidor.
Una vez que finalizan los reintentos de conexión, el servidor de caché dado concluye con la muerte del servidor que abandonó abruptamente. Tras la conclusión de la muerte, los servidores de caché informan al coordinador. Aunque es posible que el coordinador ya haya descubierto la muerte de un servidor de caché, la información proporcionada por otros servidores de caché da como resultado un ajuste rápido de la membresía en caso de que el coordinador descubra la muerte del servidor.
Cualquiera que sea el caso, el coordinador genera los nuevos mapas de distribución y transmite la nueva lista de miembros a través de los servidores de caché existentes.
Latido del corazón
La detección de una conexión TCP rota depende del tráfico que pasa por la conexión. Por ejemplo, si el clúster de caché está ocupado y envía solicitudes a través de diferentes servidores de caché, la interrupción de la conexión se detecta desde el principio. Sin embargo, si el clúster de caché tiene una actividad muy baja, la detección de una interrupción de la conexión TCP puede llevar más tiempo.
Para evitar este problema, el NCache clúster tiene un incorporado mecanismo de latido del corazón que se puede habilitar. Cuando el clúster está en un estado inactivo, latido del corazón Los mensajes se intercambian periódicamente entre servidores. Por lo tanto, la mecanismo de latido del corazón genera tráfico entre los servidores de caché y ayuda a la detección temprana de la muerte de los servidores que abandonan abruptamente.
regañando
NCache cluster admite la ejecución paralela de múltiples solicitudes. El término regañando se refiere a combinar varias solicitudes en una sola antes de enviarlas a través de la conexión TCP. Esto aumenta el rendimiento del clúster. Puedes configurar regañando y su umbral a través de la archivo de configuración del servicio.
Alertas de cambio de membresía del clúster
El cambio en la membresía del clúster es una actividad importante. Asi que, NCache proporciona múltiples mecanismos para notificar a los administradores de caché y las aplicaciones sobre los cambios de membresía.
Registros de caché: Registros de caché son el primer lugar para buscar cambios de membresía para los administradores de caché.
Visor de eventos: Las notificaciones de entrada y salida de miembros son iniciado sesión en el visor de eventos en Windows.
Alertas de correo electrónico: solicite configurar alertas de correo electrónico de servidores que se unen y salen de eventos para un caché determinado. Cada vez que se produce un cambio de membresía, se genera un correo electrónico y se envía a los destinatarios de correo electrónico registrados.
Notificaciones a nivel de aplicación: Las aplicaciones cliente también pueden registrar notificaciones devolución de llamada sobre los cambios en la membresía del clúster. Estas devoluciones de llamada se llaman cada vez que se produce un cambio en la membresía del clúster.
Vea también
Topologías de caché
Caché local
Cliente de caché
Caché de cliente
Puente para replicación WAN