Los sistemas distribuidos (sistema distribuido) se está convirtiendo cada vez más importante, los grandes sitios son casi siempre se distribuyen.
El más difícil de los sistemas distribuidos es cómo sincronizar el estado de cada nodo. CAP teorema es un teorema fundamental en este sentido, y es punto de partida para la comprensión de los sistemas distribuidos.
Tres indicadores de un sistema distribuido
1. Consistencia (consistencia)
En un entorno distribuido, la consistencia se refiere a si los datos entre múltiples copias de las mismas características se pueden mantener. Para cualquier dato leído solicitud enviada desde el cliente al sistema distribuido, o leer los datos más recientes, o no. Si es capaz de hacer una operación de actualización para la implementación exitosa de un elemento de datos, todos los usuarios pueden leer el valor más reciente de las cuales, ese sistema tal se considera que tiene consistencia sólida (o consistencia estricta).
Características: o bien leer los datos más recientes, o no, el énfasis está en los datos correctamente .
2. Disponibilidad (disponibilidad)
La disponibilidad se refiere a los servicios proporcionados por el sistema debe estar siempre en un estado utilizable, sino también para el funcionamiento de la petición de cada usuario, para ser siempre capaz de obtener un error de falta de respuesta por un período limitado de tiempo - pero no garantiza los datos adquiridos a los datos más recientes.
Tales como la estabilidad del sistema se ha hecho tres meses 9,4 9, es decir, 99,9%, 99,99%, donde N es el número 9 para una descripción de la disponibilidad, llamado el SLA, es decir, los acuerdos de nivel de servicio. Por ejemplo, se dice que SLA mensual de 99,95%, el tiempo medio hasta el fallo del servicio cada mes sólo el 0,05% del tiempo total, si este mes es de 30 días, que es de 21,6 minutos
Características: volverán los datos, no devuelve un error, pero no garantiza los últimos datos, el énfasis está no está mal en cualquier momento para leer y escribir tienen éxito.
3. tolerancia de reparto (tolerancia partición)
La mayoría de sistemas distribuidos están distribuidos a través de múltiples sub-redes. Cada subred se llama una zona (partición). tolerancia de partición se refiere a la "nodo se produce cuando una parte del mensaje se pierde o el fracaso de partición, los sistemas distribuidos continuará operando", es decir aparece partición del sistema de red tolerante, y en el caso de un encuentro entre un nodo de red o particiones de red inalcanzable bajo aún así ser capaz de proporcionar para cumplir con la consistencia externa y la disponibilidad de los servicios.
Características: Siempre voy a correr, no importa qué tipo de datos de sincronización mi aspecto interno, el énfasis está no cuelgue .
En un sistema distribuido, ya que el sistema de capas split, P se determina, la PAC arquitectura modelo de aplicación es CP y la arquitectura AP. Los sistemas distribuidos se refiere, que es la premisa PartitionTolerance, cómo lograr una mejor A, y ...
En segundo lugar, la teoría demostró CAP
CAP teoría de la prueba de varias maneras, a modo de prueba en contrario es el más intuitivo. CAP contradicción para demostrar teoremas, se propuso por primera vez por Lynch, a través de un escenario práctico, si el CAP puede satisfacer simultáneamente los tres, permitiendo la existencia de P, entonces la pérdida de paquetes entre el servidor debe existir, por lo que no se puede garantizar C.
sistema autónomo
Sistemas distribuidos
Se puede observar en un sistema distribuido no puede cumplir con la ley de "consistencia", "disponibilidad" y "tolerancia a fallos partición" tres al mismo tiempo de la PAC.
Tres aplicaciones de la teoría de la PAC,
La teoría de la PAC nos recuerda, en el diseño de la arquitectura, no pierda energía en la forma de diseñar distribuido para cumplir los tres sistema perfecto, pero a una compensación razonable, similar a la teoría de la PAC triángulo imposible en las matemáticas, sólo tres de su elección En segundo lugar, no todos los disponibles.
Para mantener la coherencia de los diferentes requisitos de negocio son diferentes. Por ejemplo, en términos de comentario y pulgares para arriba en el microblogging, los usuarios de inconsistencia no es sensible, puede tolerar una inconsistencia de tiempo relativamente largo, siempre y cuando hacer la interacción local, y no afecta a la experiencia del usuario, y nosotros cuando el proveedor de electricidad comercial, los datos de precios de productos es necesario un fuerte consistencia, si la empresa no puede cambiar los precios, con efecto inmediato, tendrá un impacto muy grande en la tasa de éxito de la transacción.
Cabe señalar, la teoría de CAP es ignorar la latencia de red, es decir, cuando los commit de transacción, los datos deben replicarse entre nodos requiere tiempo. Incluso, copie la misma habitación del nodo A al nodo B, porque la realidad no es la red en tiempo real, por lo que siempre hay una cierta cantidad de inconsistencia temporal.
Cuatro, la teoría BASE
teoría significado base es que no tenemos que elegir entre A o C pueden ser alcanzados de la Parte A y C.
BASE es Básicamente disponible (disponible básica), abreviaturas tres frases estado blando (estado blando) y, finalmente, consistente (consistencia final), la PAC es una extensión de la AP.
1. Básico Disponible
PAC no está disponible la búsqueda básica de "cualquier momento, la lectura y escritura tienen éxito." Disponible hizo hincapié en los sistemas distribuidos básicos en tiempos de fallas impredecibles, lo que permite la pérdida de disponibilidad parcial, en comparación con el sistema normal, el tiempo de respuesta puede ser extendido para asegurar que la funcionalidad central está disponible, o el servicio se degrada.
Por ejemplo, en la ACTIVIDAD DOS-las once de pico, si el número de personas que compran mucho más que el pico QPS fuerzas sistema de tuberías del sistema o reductor de flujo, que es a través de medios razonables para proteger la estabilidad del sistema, para asegurar que el servicio principal es normal, asegurar la disposición básica.
2. estado blando
estado suave puede corresponder a transacción ACID atómica, la transacción ACID, fuerte consistencia se consigue ya sea hacer o no hacer el todo, todos los usuarios ven los mismos datos. En donde atomicidad (atomicidad) copia de los datos requiere una pluralidad de nodos son los mismos, hace hincapié en la consistencia de datos.
ÁCIDO consistencia de datos es un fuerte énfasis atomicidad, consistencia, aislamiento y durabilidad, que se utiliza principalmente en la aplicación de base de datos.
Atómica puede ser entendido como un "estado duro", el estado suave es permitir que los datos en el sistema hay un estado intermedio, y que el estado no afecta a la disponibilidad global del sistema, es decir, el sistema permite la presencia de múltiples copias de los datos en los datos de extensión de diferentes nodos tiempo.
La teoría orientada base es altamente disponible y escalable, sistemas distribuidos, ÁCIDO de servicios financieros y otras tradicionales, en la escena real, diferentes requisitos de negocio para la consistencia de datos no es lo mismo.
3. El acuerdo final
Los datos no siempre puede ser un estado blando, debe lograr la consistencia después de cada nodo (esta vez como "ventana de inconsistencia") en un período de tiempo, después de que el límite de tiempo debe garantizar que todas las copias de consistencia de los datos, los datos se alcanza La consistencia final.
En el diseño del sistema, el tiempo para alcanzar una consistencia final depende de la latencia de la red, la carga del sistema, selección de diferente almacenamiento, el diseño de varios factores como la replicación de datos.
Base de la tapa, en teoría, no resuelve la latencia de la red, estado blando y, finalmente, en consonancia con la BASE de garantizar la coherencia de la demora. Ácido y la base se invierte, es completamente diferente modelo de ácido fuerte consistencia, pero se obtiene la disponibilidad sacrificando una fuerte consistencia y permite que los datos sean incompatibles con el tiempo, pero eventualmente llega a un estado coherente.
La consistencia Modelo
Dependiendo del modelo de consistencia eventual para asegurar que se proporciona se puede dividir en más modelos, incluyendo la consistencia causal y sesión de consistencia.
coherencia causal
consistencia Causal requiere una secuencia causal de operaciones para estar seguro de que la secuencia de operaciones es la relación no causal no importa.
Un proceso al final de la actualización de un elemento de datos para informar el proceso de B, entonces el acceso al elemento de datos después del proceso de B debe ser capaz de obtener los valores más recientes de actualización de proceso A, B y si el proceso es a la actualización de ese elemento de datos Por lo tanto, asegúrese de que el último valor de proceso se basa una actualizados.
coherencia causal de escenarios de aplicación puede dar un ejemplo, al comentar Weibo micro-canales o, por ejemplo, se envía una foto en el círculo de amigos, un amigo que lo ha comentado, y sus amigos comentan que responden, y esto mostrar en el círculo de amistades, su respuesta debe seguir amigos, se trata de una relación causal, mientras que otros datos hay ninguna relación causal se puede permitir inconsistente.
sesión consistencia
El bloque de proceso consistencia de los datos de sesión de acceso fijará el sistema en una conversación entre el sistema acordado para garantizar la realización de "la misma sesión activa leer escrito por nuestra propia identidad", que es su primera visita, la ejecución después de la actualización, el cliente siempre puede leer el último valor del elemento de datos en la misma sesión.
El desarrollo actual ha distribuido la consistencia de sesión, se puede considerar una aplicación coherente de la sesión.
Cinco, CP y la arquitectura AP de elección
Los requerimientos de negocio de coherencia se reflejará directamente en el diseño del sistema, es la estructura típica de CP y AP.
arquitectura CP
arquitectura CP: Para CP, la disponibilidad a renunciar a la búsqueda de la coherencia y particiones tolerancia a fallos.
ZooKeeper es el uso de consistencia CP, ZooKeeper es un marco de servicio distribuido, utilizado principalmente para resolver problemas en la coordinación del grupo distribuido y coherencia en la aplicación del sistema. Su algoritmo de núcleo es Zab, están diseñados para la consistencia. En el modelo PAC, ZooKeeper es CP, lo que significa que cuando se enfrentan con partición de la red, con el fin de mantener la consistencia, no está disponible. Después de partición, para A, sólo el nodo sub-región es mayor que el quórum era de Servicio Exterior
arquitectura AP
arquitectura AP: Para la AP, la fuerte consistencia a renunciar (en este caso decir la consistencia es la consistencia fuerte), la búsqueda de particiones de tolerancia a fallos y la disponibilidad, esta es la opción de muchos diseño de sistemas distribuidos, base también se extenderá según la AP.
Y ZooKeeper opuesto de Eureka, Eureka es SpringCloud tecnología de micro-servicios componente de descubrimiento de servicios pila, cada nodo Eureka son iguales, colgar varios nodos de nodo no afecta el trabajo normal, la sección restante todavía pueden proporcionar el registro y la consulta servicio, siempre y cuando todavía hay una Eureka, podemos garantizar el servicio de registro está disponible, pero no se puede encontrar en la información más reciente versión, no garantiza la consistencia para lograr la consistencia eventual.
Fuente de referencia
Distribuye PAC teorema, ¿por qué no puede cumplir con las tres características?
principios técnicos distribuidos y práctica digamos 45: tirón columna gancho
teorema CAP - teoría distribuido (a)
teorema de la PAC y la prueba
significado PAC teorema
teorema de CAP