Zookeeper es un subproyecto de Hadoop, y aunque deriva de hadoop, he comprobado que zookeeper utiliza cada vez más frameworks distribuidos fuera de Hadoop. Hoy quiero hablar sobre zookeeper; este artículo no hablará de cómo usar zookeeper, sino de cuáles son las aplicaciones prácticas de zookeeper, qué tipos de aplicaciones pueden desempeñar las ventajas de zookeeper y, finalmente, del papel que zookeeper puede desempeñar en la arquitectura distribuida de sitios web.
Zookeeper es un sistema de coordinación altamente fiable para grandes sistemas distribuidos. A partir de esta definición, sabemos que el cuidador de zoos es un sistema coordinado que actúa sobre sistemas distribuidos. ¿Por qué los sistemas distribuidos necesitan un sistema de coordinación? Las razones son las siguientes:
Desarrollar un sistema distribuido es algo muy difícil, y la dificultad se refleja principalmente en el "fracaso parcial" del sistema distribuido. "Fallo parcial" se refiere a la transmisión de información entre dos nodos de la red; si la red falla, el emisor no puede saber si el receptor ha recibido el mensaje, y la causa de este fallo es compleja, el receptor puede o no haber recibido el mensaje antes del error de red, o el proceso del receptor está muerto. La única forma en que el emisor puede obtener la imagen real es reconectarse al receptor y preguntarle por qué ocurrió el error, que es el problema de "fallo parcial" en el desarrollo de sistemas distribuidos.
Zookeeper es el marco para resolver el "fallo parcial" de los sistemas distribuidos. Zookeeper no permite que los sistemas distribuidos eviten problemas de "fallo parcial", pero permite que los sistemas distribuidos gestionen correctamente dichos problemas cuando se encuentran con fallos parciales, de modo que los sistemas distribuidos puedan funcionar con normalidad.
Hablemos del uso práctico de Zookeeper:
Escenario 1: Hay un grupo de servidores que proporcionan un determinado servicio al cliente (por ejemplo, el lado del servidor del sitio web distribuido que hice antes es un clúster compuesto por cuatro servidores para proporcionar servicios al clúster front-end), y esperamos que el cliente pueda encontrar un servidor en el clúster de servidores cada vez que el cliente lo solicite, para que el servidor pueda proporcionar al cliente los servicios que el cliente requiere. Para este escenario, debemos tener una lista de servidores en nuestro programa, de la cual leemos la lista cada vez que el cliente la solicita. Entonces, obviamente, esta sublista no puede almacenarse en un solo servidor de nodo, de lo contrario el nodo se colgará y todo el clúster fallará, y esperamos que esta lista esté muy disponible en ese momento. Si un servidor en la lista de almacenamiento está roto, otros servidores pueden reemplazar inmediatamente al servidor roto, y el servidor roto puede ser eliminado de la lista, de modo que el servidor fallido pueda retirarse de la operación de todo el clúster, y todas estas operaciones no serán operadas por el servidor fallido, sino por el servidor normal dentro del clúster. Esta es una estructura de datos distribuida activa que puede modificar activamente el estado de los elementos de datos cuando cambian las condiciones externas. El marco Zookeeper ofrece este servicio. El nombre de este servicio es: Servicio Unificado de Nombres, que es muy similar al servicio JNDI en javaEE.
Escenario 2: Servicio de cerradura distribuida. Cuando un sistema distribuido manipula datos, como leer, analizar datos y, finalmente, modificar datos. En el sistema distribuido, estas operaciones pueden dispersarse a diferentes nodos del clúster, entonces surge un problema de consistencia en el proceso de operación de los datos; si es inconsistente, obtendremos un resultado de operación incorrecto; en un solo programa de proceso, el problema de consistencia es fácil de resolver, pero es más difícil llegar al sistema distribuido, porque las operaciones de los diferentes servidores en el sistema distribuido están en procesos independientes, y los resultados y procesos intermedios de la operación deben transmitirse a través de la red. Entonces es mucho más difícil lograr la consistencia de la operación de datos. Zookeeper ofrece un servicio de bloqueo que resuelve este problema, permitiéndonos garantizar la consistencia de las operaciones de datos al realizar operaciones de datos distribuidos.
Escenario 3: Gestión de configuración. En un sistema distribuido, desplegamos una aplicación de servicio en n servidores por separado, y los archivos de configuración de estos servidores son los mismos (por ejemplo, en el framework de sitios web distribuidos que diseñé, hay 4 servidores en el lado del servidor, los programas en los 4 servidores son los mismos y los archivos de configuración son los mismos), si cambian las opciones de configuración de los archivos de configuración, entonces tenemos que cambiar estos archivos de configuración uno por uno, si necesitamos cambiar, los servidores son relativamente pequeños, estas operaciones no son demasiado complicadas, Si tenemos un gran número de servidores distribuidos, como el clúster Hadoop de una gran empresa de Internet con miles de servidores, entonces cambiar las opciones de configuración puede ser algo problemático y peligroso. En este momento, zookeeper puede ser muy útil, podemos usar zookeeper como una memoria de configuración altamente disponible, entregar algo así a zookeeper para su gestión, copiar el archivo de configuración del clúster a un nodo del sistema de archivos de zookeeper, y luego usar zookeeper para monitorizar el estado del archivo de configuración en todos los sistemas distribuidos, una vez que se detecta que el archivo de configuración ha cambiado, Cada servidor recibirá una notificación de Zookeeper para sincronizar los archivos de configuración en Zookeeper, y el servicio Zookeeper también se asegurará de que la operación de sincronización sea atómica para garantizar que el archivo de configuración de cada servidor se actualice correctamente.
Escenario 4: Proporcionar funciones de reparación de fallos para sistemas distribuidos. La gestión del clúster es difícil, y añadir el servicio de cuidador al sistema distribuido facilita la gestión del clúster. Lo más problemático en la gestión de clústeres es la gestión de fallos de nodos; zookeeper puede permitir que el clúster seleccione un nodo sano como maestro, el nodo maestro conocerá el estado de salud actual de cada servidor del clúster; una vez que un nodo falla, el maestro notificará a los demás servidores del clúster para redistribuir las tareas de cómputo de diferentes nodos. Zookeeper no solo puede encontrar fallos, sino también filtrar el servidor defectuoso, ver qué tipo de fallo es, si el fallo puede repararse, Zookeeper puede corregir automáticamente o comunicar al administrador del sistema la causa del error, para que este pueda localizar rápidamente el problema y reparar el fallo del nodo. Puede que aún tengas alguna pregunta, ¿qué debería hacer si el máster está defectuoso? Zookeeper también tiene esto en cuenta, zookeeper tiene un "algoritmo interno para elegir líderes", los amos pueden seleccionarse dinámicamente y, cuando el master falla, el zookeeper puede seleccionar inmediatamente un nuevo master para gestionar el grupo.
Hablemos de las características de Zookeeper:
ZooKeeper es un sistema de archivos simplificado. Esto es un poco similar a Hadoop, pero el sistema de archivos ZooKeeper gestiona archivos pequeños, mientras que Hadoop gestiona archivos muy grandes.
Zookeeper proporciona una gran cantidad de "artefactos" que permiten a muchas operaciones coordinar estructuras de datos y protocolos. Por ejemplo: colas distribuidas, bloqueos distribuidos y el algoritmo de "elección de líder" de un grupo de nodos al mismo nivel.
ZooKeeper está muy disponible, su propia estabilidad es bastante buena, los clústeres distribuidos pueden depender de la gestión de los clústeres de Zookeeper, y ZooKeeper se utiliza para evitar el problema de fallo puntual único de los sistemas distribuidos.
Zookeeper adopta un modo de interacción débilmente acoplado. Esto es más evidente en el hecho de que zookeeper proporciona bloqueos distribuidos, que pueden usarse como mecanismo de cita para permitir que los procesos participantes descubran e interactúen entre sí sin conocer los demás procesos (o la red), y las partes participantes ni siquiera tienen que existir al mismo tiempo, siempre que dejen un mensaje en zookeeper, y tras el final del proceso, otro proceso pueda leer ese mensaje, desacoplando así la relación entre los nodos.
ZooKeeper proporciona un repositorio compartido para el clúster, desde el cual el clúster puede leer y escribir información compartida de forma centralizada, evitando la programación de operaciones compartidas para cada nodo y reduciendo la dificultad de desarrollo de los sistemas distribuidos.
Zookeeper es principalmente responsable de almacenar y gestionar los datos que a todos les importan, y luego aceptar el registro de observadores; una vez que cambie el estado de estos datos, Zookeeper será responsable de notificar a aquellos observadores que se hayan registrado en Zookeeper para que respondan en consecuencia, con el fin de lograr un modo de gestión maestro/esclavo similar al del clúster.
Se puede ver que el cuidador de zoos es muy propicio para el desarrollo de sistemas distribuidos, lo que puede hacer que los sistemas distribuidos sean más robustos y eficientes.
No hace mucho, participé en el grupo de interés de Hadoop del departamento, instalé Hadoop, Mapreduce, Hive y Hbase en el entorno de prueba, y instalé Zookeeper con antelación al instalar hbase. Zookeeper puede ofrecer servicios, así que más de la mitad de los 3 son 2, y más de la mitad de los 4 también son dos, por lo que instalar tres servidores puede lograr el efecto de 4 servidores. En el proceso de aprender Hadoop, siento que Zookeeper es el subproyecto más difícil de entender, la razón no es que sea técnicamente responsable, sino que su dirección de aplicación me resulta muy confusa, así que mi primer artículo sobre tecnología Hadoop comienza con Zookeeper y no habla de una implementación técnica específica, pero a partir de los escenarios de aplicación de Zookeeper, entiendo el campo de la aplicación de Zookeeper, creo que aprender Zookeeper será más efectivo con la mitad del esfuerzo.
La razón por la que quiero hablar hoy sobre zookeeper es para complementar el framework distribuido de sitios web de mi artículo anterior. Aunque diseñé la arquitectura del sitio web para que fuera una estructura distribuida, también creé un mecanismo sencillo de manejo de fallos, como el mecanismo de latido del corazón, pero aún no hay forma de resolver el único punto de fallo del clúster; si un servidor se estropea, el cliente intentará conectarse a ese servidor, lo que resultará en el bloqueo de algunas solicitudes y también en el desperdicio de recursos del servidor. Sin embargo, no quiero modificar mi framework en este momento, porque siempre siento que añadir el servicio de cuidador de zoos a los servicios existentes afectará la eficiencia de la web. Afortunadamente, nuestro departamento también ha detectado este problema: desarrollará un potente marco de llamadas remotas, separará la gestión del clúster y la gestión de comunicaciones, y proporcionará servicios eficientes y disponibles de forma centralizada.
Transferido desde ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Publicado en 18/7/2017 14:19:01
|
|
|
