Introducción a las soluciones distribuidas

Introducción a las soluciones distribuidas

  Con el fin de resolver cuellos de botella como la capacidad, el rendimiento y la alta disponibilidad de una sola máquina, están surgiendo diversas tecnologías y soluciones distribuidas, como sistemas de archivos distribuidos, computación distribuida, mensajería distribuida, transacciones distribuidas, bases de datos distribuidas, etc., que se utilizan para resolver diferentes problemas en diferentes escenarios Este artículo explica brevemente sus principios y funciones. Es posible que la comprensión no sea lo suficientemente profunda, hay muchos extractos, por favor corríjame.

1. Principios y herramientas

• Principio de CAP: El principio de CAP también se conoce como teorema de CAP, que se refiere a la coherencia, disponibilidad y tolerancia de partición en un sistema distribuido. El principio de la PAC significa que estos tres elementos solo pueden lograr dos puntos al mismo tiempo, y es imposible ocuparse de los tres.
• BASE: BASE es el resultado del equilibrio entre consistencia y disponibilidad en CAP. Proviene de la conclusión de la práctica distribuida de los sistemas de Internet a gran escala. Se desarrolla gradualmente en base al teorema de CAP. Su idea central es que incluso si hay una fuerte consistencia no se puede lograr (Consistencia fuerte), pero cada aplicación puede adoptar un método apropiado para hacer que el sistema logre una consistencia eventual de acuerdo con sus propias características comerciales. A continuación, nos enfocamos en explicar los tres elementos en BASE en detalle. Básicamente disponible: significa que el sistema distribuido puede perder parte de su disponibilidad en caso de fallas impredecibles.
• Algoritmo PAXOS: El problema resuelto por el algoritmo Paxos es cómo un sistema distribuido puede ponerse de acuerdo en un determinado valor (resolución). Un escenario típico es que en un sistema de base de datos distribuida, si el estado inicial de cada nodo es el mismo y cada nodo realiza la misma secuencia de operaciones, finalmente pueden obtener un estado consistente. Para garantizar que cada nodo ejecute la misma secuencia de comandos, es necesario ejecutar un "algoritmo de coherencia" en cada instrucción para garantizar que las instrucciones que ve cada nodo sean coherentes. Un algoritmo de consenso general se puede aplicar en muchos escenarios y es un tema importante en la computación distribuida. Por tanto, la investigación sobre algoritmos de consenso no se ha detenido desde la década de 1980. Hay dos modelos de comunicación de nodo: memoria compartida y paso de mensajes. El algoritmo de Paxos es un algoritmo de consenso basado en el modelo de paso de mensajes.
• Servicio Zookeeper: ZooKeeper es un servicio de coordinación de aplicaciones distribuidas de código abierto distribuido. Es un software que brinda servicios consistentes para aplicaciones distribuidas, las funciones que brinda incluyen: mantenimiento de configuración, servicios de nombres de dominio, sincronización distribuida, servicios grupales, etc. ZooKeeper se basa en el algoritmo Fast Paxos. El algoritmo Paxos tiene un problema de livelock, es decir, cuando se envían múltiples propuestas de manera escalonada, pueden ser mutuamente excluyentes y nadie puede enviarlas correctamente. Fast Paxos ha realizado algunas optimizaciones y ha pasado la elección Se genera un líder (líder), y solo el líder puede presentar una propuesta.

2. Sistema de archivos distribuido (HDFS)

 El sistema de archivos distribuido de Hadoop (HDFS) está diseñado para ser un sistema de archivos distribuido adecuado para ejecutarse en hardware básico. Tiene mucho en común con los sistemas de archivos distribuidos existentes. Pero al mismo tiempo, la diferencia entre este y otros sistemas de archivos distribuidos también es muy obvia. HDFS es un sistema altamente tolerante a fallas, adecuado para su implementación en máquinas baratas. HDFS puede proporcionar acceso a datos de alto rendimiento, que es muy adecuado para aplicaciones en conjuntos de datos a gran escala. HDFS relaja algunas restricciones POSIX para lograr el propósito de transmitir datos del sistema de archivos.
 HDFS utiliza una arquitectura maestro / esclavo. Un clúster HDFS está compuesto por un Namenode y una cierta cantidad de Datanodes. Namenode es un servidor central responsable de administrar el espacio de nombres del sistema de archivos y el acceso del cliente a los archivos. El Datanode en el clúster es generalmente un nodo, responsable de administrar el almacenamiento en el nodo donde se encuentra. HDFS expone el espacio de nombres del sistema de archivos y los usuarios pueden almacenar datos en él en forma de archivos. Desde un punto de vista interno, un archivo se divide en uno o más bloques de datos, que se almacenan en un grupo de Datanodes. Namenode realiza operaciones de espacio de nombres del sistema de archivos, como abrir, cerrar y cambiar el nombre de archivos o directorios. También es responsable de determinar la asignación de bloques de datos a nodos de Datanode específicos. Datanode es responsable de manejar las solicitudes de lectura y escritura de los clientes del sistema de archivos. Cree, elimine y replique bloques de datos bajo la programación unificada de Namenode.

 Namenode y Datanode están diseñados para ejecutarse en máquinas comerciales comunes. Estas máquinas generalmente ejecutan el sistema operativo (SO) GNU / Linux. HDFS está desarrollado en lenguaje Java, por lo que cualquier máquina que admita Java puede implementar Namenode o Datanode. Gracias al lenguaje Java altamente portátil, HDFS se puede implementar en varios tipos de máquinas. Un escenario de implementación típico es que solo una instancia de Namenode se ejecuta en una máquina, mientras que otras máquinas en el clúster ejecutan una instancia de Datanode. Esta arquitectura no excluye la ejecución de múltiples Datanodes en una máquina, pero estos casos son relativamente raros.
 La estructura de un solo Namenode en el clúster simplifica enormemente la arquitectura del sistema. Namenode es el árbitro y administrador de todos los metadatos de HDFS, por lo que los datos del usuario nunca fluirán a través de Namenode.
Documento de referencia: http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_design.html

Tres, computación distribuida (Mapa / Reducir)

 Hadoop Map / Reduce es un marco de trabajo de software fácil de usar. Las aplicaciones escritas en base a él pueden ejecutarse en un gran clúster compuesto por miles de máquinas comerciales y procesar conjuntos de datos del nivel T en paralelo de una manera confiable y tolerante a fallas. .
 Un trabajo de Mapa / Reducción generalmente divide el conjunto de datos de entrada en varios bloques de datos independientes, y la tarea de mapa (tarea) los procesa de manera completamente paralela. El marco ordena la salida del mapa primero y luego ingresa el resultado a la tarea de reducción. Por lo general, la entrada y la salida del trabajo se almacenarán en el sistema de archivos. Todo el marco es responsable de la programación y el seguimiento de tareas, así como de volver a ejecutar las tareas que han fallado.
 Generalmente, el marco Map / Reduce y el sistema de archivos distribuido se ejecutan en el mismo conjunto de nodos, es decir, los nodos de computación y los nodos de almacenamiento suelen estar juntos. Esta configuración permite que el marco programe tareas de manera eficiente en los nodos que tienen datos almacenados, lo que puede hacer que el ancho de banda de la red de todo el clúster sea muy eficiente.

 El marco Map / Reduce consta de un solo JobTracker maestro y un TaskTracker esclavo para cada nodo del clúster. El maestro es responsable de programar todas las tareas que constituyen un trabajo, estas tareas se distribuyen en diferentes esclavos, el maestro monitorea su ejecución y vuelve a ejecutar las tareas que fallaron. El esclavo solo es responsable de realizar las tareas asignadas por el maestro.
 La aplicación debe al menos especificar la ubicación (ruta) de la entrada / salida, y proporcionar funciones de mapa y reducción mediante la implementación de interfaces apropiadas o clases abstractas. Junto con los parámetros de otros trabajos, constituye una configuración de trabajo. Luego, el cliente de trabajo de Hadoop envía trabajos (paquetes jar / programas ejecutables, etc.) e información de configuración a JobTracker, que es responsable de distribuir este software y la información de configuración a los esclavos, programar tareas y monitorear su ejecución, mientras proporciona estado y diagnóstico. información al trabajo-cliente.
 Aunque el marco Hadoop está implementado en JavaTM, las aplicaciones Map / Reduce no tienen que estar escritas en Java.
Documento de referencia: http://hadoop.apache.org/docs/r1.0.4/cn/mapred_tutorial.html

Cuatro, base de datos distribuida (OceanBase)

 OceanBase es una base de datos relacional distribuida desarrollada de forma completamente independiente por Ant Financial y Alibaba. Fue fundada en 2010. OceanBase tiene las características de fuerte consistencia de datos, alta disponibilidad, alto rendimiento, expansión en línea, alta compatibilidad con estándares SQL y bases de datos relacionales convencionales, y bajo costo. Es adecuado para escenarios financieros con altos requisitos de rendimiento, costo y escalabilidad.

 Principales características:

• Alto rendimiento: OceanBase utiliza una arquitectura de separación de lectura y escritura para dividir los datos en datos de referencia y datos incrementales. Los datos incrementales se almacenan en la memoria (MemTable) y los datos de referencia se almacenan en el disco SSD (SSTable). Las modificaciones a los datos son datos incrementales y solo se escribe la memoria. Entonces DML es una operación de memoria completa con un rendimiento muy alto.
• Bajo costo: OceanBase logra una alta compresión a través de la tecnología de compresión de codificación de datos. La codificación de datos es una serie de métodos de codificación basados ​​en el rango de valores y el tipo de información de diferentes campos en la tabla relacional de la base de datos. Comprende los datos mejor que los algoritmos de compresión generales y puede lograr una mayor eficiencia de compresión. Al utilizar servidores de PC y SSD de gama baja, la alta tasa de compresión del almacenamiento reduce los costos de almacenamiento, el alto rendimiento reduce los costos de computación y las unidades mixtas de múltiples inquilinos aprovechan al máximo los recursos del sistema.
• Alta disponibilidad: los datos se almacenan en varias copias y algunos errores de copia no afectan la disponibilidad de los datos. Mediante el despliegue de "tres ubicaciones y cinco centros", se realiza la recuperación automática y no destructiva ante desastres de las fallas a nivel de la ciudad.
• Fuerte consistencia: múltiples copias de datos sincronizan los registros de transacciones a través del protocolo paxos, y la mayoría solo pueden enviar transacciones exitosas. De forma predeterminada, las operaciones de lectura y escritura se realizan en la copia maestra para garantizar una sólida coherencia.
• Escalable: los nodos del clúster son todos de igual a igual, cada nodo tiene capacidades informáticas y de almacenamiento, y no existe un único punto de cuello de botella. Se puede ampliar y contraer de forma lineal y online.
• Compatibilidad: Compatible con las funciones de MySQL / ORACLE de uso común y los protocolos de front-end y back-end de MySQL / ORACLE. La empresa se puede migrar de MySQL / ORACLE a OceanBase con pocas o ninguna modificación.

  Escenarios de aplicación:

• El posicionamiento de productos de OceanBase es una base de datos relacional distribuida. Los productos de OceanBase son adecuados para finanzas, valores, etc. que involucran transacciones, pagos y contabilidad, etc., que requieren alta disponibilidad y consistencia sólida, y requieren rendimiento, costo y escalabilidad. Escenarios de atributos, y varias aplicaciones OLTP de almacenamiento estructurado relacional.

 Arquitectura de software:

• OceanBase está diseñado como una arquitectura Share-Nothing, por lo que no tiene ninguna estructura de almacenamiento compartido. Es necesario implementar al menos tres zonas y los datos se almacenan en cada zona. No hay un solo punto en todo el diseño de OceanBase, cada zona tiene múltiples nodos ObServer, lo que resuelve el problema de alta confiabilidad y alta disponibilidad de la arquitectura.
• Cada nodo es completamente igual y cada uno tiene su propio motor SQL y motor de almacenamiento. El motor de almacenamiento solo puede acceder a datos locales, mientras que el motor SQL puede acceder al esquema global y generar un plan de consulta distribuido. El ejecutor de consultas puede acceder al motor de almacenamiento de cada nodo, distribuir y recopilar datos entre cada nodo, completar la ejecución del plan distribuido y devolver el resultado al usuario.
• Uno de los nodos asumirá adicionalmente el servicio RootService, y RootService también tendrá múltiples dispositivos distribuidos en cada zona. Las concesiones se mantienen entre el RootService principal y todos los ObServers. Cuando el ObServer falla, el RootService principal puede detectar y realizar operaciones de recuperación de fallas. RootService es un módulo funcional del proceso ObServer, y cada ObServer tiene la función RootService. Las funciones de RootService incluyen principalmente: administración de servidores y zonas, administración de zonas, control de fusión diario, arranque del sistema, operación DDL, etc.
  

Cinco, mensajería distribuida (Kafka)

 Arquitectura distribuida:

• Cada Broker representa un servidor kafka y admite varios productores y consumidores de mensajes al mismo tiempo.
• Los mensajes se gestionan en la unidad de tema Tema. Cada tema puede tener varias particiones almacenadas en diferentes Brokers.
• Kafka permite que las particiones de temas tengan varias copias y puede configurar el número de copias de las particiones en el lado del servidor. Cuando un nodo del clúster falla, puede realizar una conmutación por error automáticamente para garantizar la disponibilidad de los datos.
• Zookeeper se utiliza para el registro de corredores y el registro de temas de Kafka, lo que guarda la correspondencia entre los consumidores y las particiones, activa el equilibrio de carga del consumidor y ahorra las compensaciones de los consumidores.
• La unidad de creación de réplicas es la partición del tema. Normalmente, cada partición tiene un líder y cero o más seguidores. El número total de réplicas es la suma del líder. Todas las operaciones de lectura y escritura son manejadas por el líder. Generalmente, el número de particiones es mayor que el número de intermediarios, y los líderes de cada partición se distribuyen uniformemente entre los intermediarios. Todos los nodos seguidores sincronizan el registro del nodo líder, y los mensajes y compensaciones en el registro son consistentes con los del líder. (Por supuesto, en un momento dado, puede haber varios mensajes al final del registro del nodo líder que aún no se han respaldado). Los nodos seguidores extraen mensajes del nodo líder al igual que los consumidores normales y los guardan en sus archivos de registro. Los nodos seguidores pueden extraer registros de mensajes del nodo líder en lotes a sus propios archivos de registro.
• Como ocurre con la mayoría de los sistemas distribuidos, el manejo automático de fallas requiere una definición precisa del concepto de nodo "vivo". Kafka tiene dos formas de juzgar si un nodo está vivo. El nodo debe poder mantener la conexión con ZooKeeper, y ZooKeeper comprueba la conexión de cada nodo a través del mecanismo de latido. Si el nodo es un seguidor, debe poder sincronizar las operaciones de escritura del líder en el tiempo y el retraso no puede ser demasiado largo.
  

 Escenarios de aplicación:

• Kafka se puede utilizar como intermediario de mensajes en diversas situaciones (como desacoplar generadores de datos del procesamiento de datos, almacenar en búfer mensajes no procesados, etc.). En comparación con otros sistemas de mensajería, Kafka tiene un mejor rendimiento, particiones integradas, replicación y tolerancia a fallas, lo que la convierte en una aplicación ideal de procesamiento de mensajes a gran escala.
• El caso de uso inicial de Kafka fue reconstruir la canalización de seguimiento de la actividad del usuario en un conjunto de fuentes de publicación y suscripción en tiempo real. Esto significa que las actividades del sitio web (navegación web, búsqueda u otras acciones del usuario) se publicarán en un tema central, donde cada tipo de actividad tiene un tema. Estos feeds brindan una variedad de casos de uso, que incluyen procesamiento en tiempo real, monitoreo en tiempo real y procesamiento e informes fuera de línea de datos cargados en Hadoop o sistemas de almacenamiento de datos fuera de línea.
• Kafka puede proporcionar funciones de envío de registros para sistemas distribuidos desde el exterior. Los registros ayudan a registrar datos entre nodos y comportamientos, y se puede utilizar un mecanismo de resincronización para recuperar datos de nodos fallidos. La función de compresión de registros de Kafka admite este uso.
• Una vez que los datos se escriben en Kafka, se escriben en el disco y se realiza una copia de seguridad para la tolerancia a errores. Hasta la copia de seguridad completa, Kafka deja que el productor piense que la escritura está completa. Incluso si falla la escritura, Kafka se asegurará de que continúe escribiendo en Kafka utilizando la estructura de disco, que tiene una buena escalabilidad: los datos de 50 kb y 50 TB se comportan igual en el servidor. Se puede almacenar una gran cantidad de datos y el cliente puede controlar la ubicación de los datos. Puede pensar en Kafka como un sistema de archivos distribuido de alto rendimiento y baja latencia con funciones de almacenamiento, copia de seguridad y propagación de registros.

 Garantía semántica de entrega de mensajes:

• Como mucho una vez, el mensaje puede perderse pero nunca volver a transmitirse.
• Al menos una vez: el mensaje se puede retransmitir, pero nunca se pierde.
• Exactamente una vez: esto es exactamente lo que la gente quiere, cada mensaje se envía solo una vez.

 Otras garantías:

• Los mensajes enviados por el productor a una partición de tema específica se procesarán en el orden en que se envían. Es decir, si el registro M1 y el registro M2 son enviados por el mismo productor y el registro M1 se envía primero, entonces el desplazamiento de M1 es menor que el de M2 ​​y aparece antes en el registro.
• Una instancia de consumidor examina los registros en el orden del registro.
• Para un tema con N copias, podemos tolerar como máximo N-1 fallas del servidor, a fin de garantizar que no se pierda ningún registro enviado al registro.

Documento de referencia: https://kafka.apachecn.org/intro.html

Seis transacciones distribuidas (RocketMQ)

 Plan de coherencia sólida (nivel de base de datos), presentación en dos etapas 2PC:

• 2PC presenta el papel de un coordinador de transacciones para coordinar y gestionar la presentación y el retroceso de cada participante (también conocido como cada recurso local) Las dos fases se refieren a las fases de preparación (votación) y presentación.
• El coordinador de la fase de preparación enviará un comando de preparación a cada participante, se puede entender el comando de preparación como la finalización de todo excepto el compromiso de la transacción. Después de esperar sincrónicamente la respuesta de todos los recursos, ingresa a la segunda fase, la fase de compromiso (tenga en cuenta que la fase de compromiso no es necesariamente una transacción de compromiso o una transacción de reversión).
• Si todos los participantes en la primera etapa regresan para prepararse con éxito, entonces el coordinador envía un comando de transacción de confirmación a todos los participantes y luego espera a que todas las transacciones se confirmen correctamente y luego devuelve la ejecución de la transacción con éxito.
• Si un participante devuelve un error en la primera etapa, el coordinador enviará a todos los participantes una solicitud para revertir la transacción, es decir, la ejecución de la transacción distribuida falla.
• Si la confirmación de la segunda etapa falla, si la segunda etapa realiza una operación de transacción de reversión, entonces la respuesta es seguir reintentando hasta que todos los participantes sean revertidos; de lo contrario, aquellos que se prepararon correctamente en la primera etapa continuarán bloqueando con.
• Si la confirmación de la segunda etapa falla, si la segunda etapa es confirmar la operación de transacción, entonces la respuesta es volver a intentarlo, porque es posible que las transacciones de algunos participantes se hayan enviado con éxito y solo hay una forma en este momento, que es seguir adelante. Apresúrate, sigue intentándolo, hasta que el envío sea exitoso, al final, realmente no funciona, solo se puede manejar manualmente.
• El coordinador falla y se obtiene un nuevo coordinador mediante elección.

 TCC (Probar - Confirmar - Cancelar) ：

• Intentar se refiere a la reserva, es decir, la reserva y bloqueo de recursos, preste atención a la reserva.
• Confirmar se refiere a la operación de confirmación, este paso se ejecuta realmente.
• Cancelar se refiere a la operación de cancelación, que puede entenderse como la cancelación de la acción en la fase de reserva.
• Por ejemplo, si una transacción necesita realizar tres operaciones A, B y C, primero realice las acciones de reserva para las tres operaciones. Si todas las reservas tienen éxito, se realiza la operación de confirmación y, si una reserva falla, se llevan a cabo todas las acciones de cancelación. El modelo TCC también tiene la función de administrador de transacciones, que se utiliza para registrar el estado de la transacción global de TCC y confirmar o revertir la transacción.
• A nivel empresarial, dado que es necesario definir tres acciones para que cada operación corresponda a Intentar-Confirmar-Cancelar, TCC tiene una gran intrusión al negocio y estrechamente acoplado al negocio. Es necesario diseñar la operación correspondiente de acuerdo a la especificación escenario y lógica empresarial. Además, es posible que sea necesario reintentar la ejecución de operaciones de deshacer y confirmar, por lo que también es necesario asegurarse de que las operaciones sean idempotentes.
• En comparación con 2PC y 3PC, TCC tiene una gama más amplia de aplicaciones, pero la cantidad de desarrollo también es mayor. Después de todo, todas se realizan en los negocios y, a veces, encontrará que estos tres métodos son realmente difíciles de escribir. Sin embargo, debido a que se implementa en los negocios, TCC puede implementar transacciones en bases de datos y en diferentes sistemas comerciales.

 Consistencia eventual, tabla de mensajes locales:

• Tomando los servicios de pago y los servicios de contabilidad como ejemplos, el proceso aproximado es el siguiente: Una vez que el usuario completa la orden de pago y el servicio de pago se paga con éxito, el usuario llamará a la interfaz del servicio de contabilidad para generar un comprobante contable original en la base de datos. Debido a que después de que el usuario completa el pago, debe darle inmediatamente una retroalimentación del pago, todo lo que necesita hacer es recordarle al usuario que el pago se realizó correctamente.
• La tabla de mensajes locales, como su nombre lo indica, es una tabla para almacenar mensajes locales, que generalmente se almacena en la base de datos. Luego, cuando se ejecuta el negocio, la operación de ejecución del negocio (servicio de pago) y la operación de poner el mensaje en la tabla de mensajes se colocan en la misma transacción, de modo que se puede garantizar que el negocio de poner el mensaje en el La tabla local debe ejecutarse con éxito.
• Luego vaya a llamar a la siguiente operación (servicio de contabilidad) Si la siguiente operación se llama con éxito, el estado del mensaje de la tabla de mensajes se puede cambiar directamente a correcto.
• Si la llamada falla, está bien. Habrá una tarea en segundo plano para leer la tabla de mensajes locales con regularidad, filtrar los mensajes fallidos y luego llamar al servicio correspondiente. Después de que la actualización del servicio sea exitosa, se cambiará el estado del mensaje.
• En este momento, es posible que la operación correspondiente al mensaje no sea exitosa, por lo que es necesario volver a intentarlo. Reintentar debe garantizar que el método de servicio correspondiente sea idempotente, y generalmente habrá un número máximo de reintentos. Si el número máximo veces se excede, se puede grabar una alarma para su procesamiento manual.

 Consistencia eventual, mensaje de transacción (RocketMQ):

• El esquema de mensajes de transacción se puede utilizar para reemplazar el esquema de tabla de mensajes local
• El primer paso es enviar un mensaje de transacción al Broker, es decir, medio mensaje. Medio mensaje no significa medio mensaje, pero el mensaje es invisible para el consumidor, y luego el remitente ejecuta la transacción local después de la transmisión. es exitoso. Luego envíe los comandos Commit o RollBack al Broker según los resultados de la transacción local.
• Y el remitente de RocketMQ proporcionará una interfaz de estado de transacción de contraverificación. Si el mensaje no recibe ninguna solicitud de operación durante un período de tiempo, el corredor sabrá si la transacción del remitente se ejecutó correctamente a través de la interfaz de contraverificación y luego ejecutar comandos Commit o RollBack.
• Si es Commit, el suscriptor puede recibir el mensaje y luego realizar la operación correspondiente y luego consumir el mensaje una vez completado.
• Si es RollBack, el suscriptor no puede recibir este mensaje, lo que significa que la transacción no se ha ejecutado.
• Se puede ver que es relativamente fácil de implementar a través de RocketMQ. RocketMQ proporciona la función de mensaje de transacción, solo necesitamos definir la interfaz de verificación inversa de transacción.

Documento de referencia: https://zhuanlan.zhihu.com/p/183753774