Alta disponibilidad y coherencia
Luego, esta sección hablará sobre cómo MongoDB logra su alta disponibilidad y luego explicará en qué medida estas características pueden lograr una alta disponibilidad.
Creo que una vez que se menciona la alta disponibilidad, pensarás en las siguientes preguntas:
Entonces, con estas preguntas, sigamos leyendo, después de leer, todos deberían entender estas preguntas. .
La base de la alta disponibilidad de MongoDB es un clúster de replicación, que es esencialmente una copia de los datos almacenados en múltiples réplicas para garantizar que los datos no se pierdan si la máquina se bloquea.
El conjunto de réplicas consta de al menos 3 nodos:
Como se puede ver en los tipos de nodos anteriores, un clúster de replicación de tres nodos puede ser una estructura PSS o PSA.
La ventaja de la estructura PSA es que ahorra costos, pero la desventaja es que después de que el Primario cuelgue, algunas funciones de escritura que dependen de la característica mayoritaria tendrán problemas, por lo que generalmente no se recomienda úsalo.
El diseño central de un clúster de replicación para garantizar la coherencia de los datos es:
Con base en los cuatro puntos anteriores, podemos sacar la siguiente conclusión: MongoDB tiene alta disponibilidad:
MongoDB Después de apagar y reiniciar, puede restaurar rápidamente los datos antes de los últimos 60 segundos a través del punto de control.
Los datos desde el último punto de control de MongoDB hasta el tiempo de inactividad se pueden recuperar mediante la reproducción del registro.
Debido a que el registro se actualiza cada 100 milisegundos, se perderán hasta 100 milisegundos de datos.
(Esto se puede controlar a través de los parámetros de WriteConcern, pero el rendimiento se verá afectado y es adecuado para escenarios con requisitos de confiabilidad muy estrictos).
Si la mayoría de las escrituras son para escrituras Si comienza con datos, incluso si el servidor principal falla, se perderán hasta 100 milisegundos de datos (evitable, igual que arriba).
Uno de los problemas que deben afrontar los sistemas distribuidos es la coherencia de los datos y la alta disponibilidad. Una teoría muy famosa es la teoría CAP.
La conclusión central de la teoría CAP es que un sistema distribuido sólo puede satisfacer como máximo dos de los tres elementos de coherencia, disponibilidad y tolerancia de partición.
Hay muchas discusiones sobre la teoría CAP en Internet, por lo que no entraré en detalles aquí.
La teoría CAP plantea los problemas que deben afrontar los sistemas distribuidos, pero es imposible que no utilicemos sistemas distribuidos debido a este problema.
Por lo tanto, se propone la teoría básica (básicamente disponible, estado blando, consistencia eventual de consistencia eventual).
La teoría subyacente es el equilibrio entre coherencia y usabilidad. La mayoría de los sistemas distribuidos ahora están diseñados en base a la teoría BASE y, por supuesto, MongoDB también sigue esta teoría.
Para garantizar la disponibilidad y la tolerancia a fallos de la partición, MongoDB utiliza conjuntos de réplicas. Un problema que este modelo debe resolver es cómo seleccionar rápidamente el nodo maestro apropiado cuando el sistema se inicia y el nodo maestro es anormal.
Aquí hay varios problemas potenciales:
El algoritmo de elección de MongoDB se basa en mejoras en el protocolo Raft, lo que permite que los nodos de un clúster distribuido tengan tres estados:
Líder: Es el nodo maestro y es responsable de las operaciones de escritura de todo el clúster.
Nodo candidato: nodo candidato, nodo que participa en la elección después de que el nodo maestro cuelga. Sólo existe durante las elecciones y es un estado temporal.
Seguidor: Es un nodo esclavo que extrae pasivamente datos actualizados del nodo maestro.
El cambio de estado del nodo es: En circunstancias normales, solo hay un líder y varias flores. Cuando el líder cuelgue, algunos de los nodos de la flor se convertirán en candidatos para las elecciones.
Cuando un candidato gana unas elecciones, se convierte en el nuevo líder, mientras que los demás candidatos regresan al Estado de las Flores.
La máquina de estado específica es la siguiente:
Hay dos protocolos RPC centrales en el protocolo Raft, que se utilizan en la fase electoral y la fase normal respectivamente:
Solicitud de voto: durante la fase de elección, los candidatos envían solicitudes a otros nodos pidiéndoles que voten por sí mismos.
Entradas adicionales: en la fase normal, el nodo líder envía una solicitud al nodo seguidor para informar a la otra parte que hay una actualización de datos. También sirve como un mecanismo de latido para declarar su estado a todos los seguidores. .
Si el seguidor no recibe la solicitud en un plazo determinado, comenzará una nueva ronda de votación electoral.
El protocolo Raft estipula las reglas de votación para la fase de elección:
Un nodo solo puede votar por un nodo candidato dentro de un período de elección ($Term), y el primero en llegar- Se utiliza el principio de primero en ser atendido.
Votarás a favor sólo si el registro de operaciones del nodo candidato es líder o igual que él.
Un proceso de elección completo incluye lo siguiente:
Lo anterior es el mecanismo de elección de MongoDB. Todavía hay una pregunta que no ha sido respondida, que es la última. ¿Cómo se asegura que la primaria elegida sea la primaria más apropiada?
Porque, a juzgar por el acuerdo anterior, hay un error lógico: porque la conversión de seguidor a candidato es aleatoria y paralela, y el mecanismo de votación por orden de llegada conducirá a la selección de un nodo subóptimo para convertirse en primario.
En respuesta a este problema con el protocolo Raft, busqué información y llegué a la conclusión:
El protocolo Raft no puede garantizar que el nodo maestro seleccionado sea óptimo.
MongoDB resuelve este problema agregando una operación de recuperación antes de que una elección tenga éxito y una nueva primaria tome el trono.
Es decir, después de que un nodo gane la votación, primero verificará si otros nodos han actualizado el registro de operaciones. De lo contrario, tomará la posición directamente. Si es así, sincronizará los datos antes de tomar la votación. posición.
El mecanismo de sincronización maestro-esclavo de MongoDB es un mecanismo importante para garantizar la coherencia y confiabilidad de los datos. La base de su sincronización es oplog, que es similar al binlog de MySQL, pero existen algunas diferencias. Aunque se denomina registro, el registro de operaciones no es un archivo, sino una colección.
Al mismo tiempo, debido a la escritura paralela del registro de operaciones, hay un desorden de cola y lagunas. Específicamente, el orden de los datos en el registro de operaciones puede ser inconsistente con el orden de los datos reales, y hay un momento. problema de discontinuidad.
Para resolver este problema, MongoDB adopta el reloj lógico híbrido (HLC), que no solo resuelve los problemas de desorden y vacío, sino que también resuelve el problema de coherencia de las transacciones en sistemas distribuidos.
De hecho, la esencia de la sincronización maestro-esclavo es que el nodo maestro recibe la solicitud del cliente, escribe la operación de actualización en el registro de operaciones y luego extrae el registro de operaciones de la fuente de sincronización y lo reproduce localmente para lograr sincronización de datos.
La fuente de sincronización se refiere al nodo de origen del cual el nodo extrae el registro de operaciones. El nodo puede no ser el nodo maestro, pero puede ser cualquier nodo en modo de replicación en cadena.
Seleccionar una fuente de sincronización de nodos es un proceso muy complicado, que es aproximadamente el siguiente:
Existen algunas circunstancias especiales al seleccionar una fuente de sincronización:
Usuarios Puede especificar la fuente de sincronización.
Si la replicación en cadena está desactivada, la fuente de sincronización de todos los nodos secundarios es el nodo principal.
Si se extrae incorrectamente de la fuente de sincronización, se incluirá en la lista negra en un corto período de tiempo.
Toda la lógica de extracción y reproducción es muy complicada, por lo que simplificaré la explicación según mi propio entendimiento. Si desea obtener más información, puede leer la información detallada sobre la tecnología de replicación de MongoDB.
El nodo tiene un hilo especial para extraer el registro de operaciones y extraer el registro de operaciones de la fuente de sincronización a través del cursor agotado. Una vez retirado, no se reproduce, sino que se arroja a un lugar.
En la cola de bloqueo.
Luego, hay varios subprocesos de ejecución específicos que toman el registro de operaciones de la cola de bloqueo y lo ejecutan.
Durante el proceso de adquisición, los registros de operaciones de la misma colección serán adquiridos y ejecutados por el mismo hilo, que fusionará comandos de inserción consecutivos tanto como sea posible.
El proceso de ejecución de toda la reproducción es aproximadamente el siguiente: primero bloquear, luego escribir nuestro registro de operaciones, luego actualizar el registro de operaciones (mecanismo WAL) y finalmente actualizar su último opTime.
Gráfico de conocimiento completo de MongoDB
/s/bhxpnlotuoqyji 61 EOR CFA