También puede consultar https://blog.csdn.net/zl1zl2zl3/article/details/83721147
-
¿Cuáles son los componentes de dubbo y qué se requieren?
Dubbo requiere cuatro componentes básicos: Registro, Monitor, Proveedor y Consumidor.
Proveedor: proveedor
Consumidor:
registro de consumidores : centro de registro (equivalente a un intermediario)
monitor: centro de monitoreo (proyecto de monitoreo propio de dubbo, se puede lanzar directamente bajo tomcat, puede ver consumidores, productores) ---- ------ -
https://blog.csdn.net/qq_24853627/article/details/79380707
contenedor: contenedor de servicio
El contenedor de servicios es responsable de iniciar, cargar y ejecutar el proveedor de servicios. Cuando el proveedor de servicios se inicia, registra el servicio que brinda en el centro de registro.
Cuando se inicia un consumidor de servicios, se suscribe al registro del servicio que necesita.
El centro de registro devuelve la lista de direcciones de proveedores de servicios al consumidor. Si hay un cambio, el centro de registro enviará los datos del cambio al consumidor basándose en la conexión larga.
El consumidor de servicios, basándose en el algoritmo de equilibrio de carga suave, selecciona un proveedor para llamar de la lista de direcciones de proveedores y, si la llamada falla, selecciona otro para llamar.
Los consumidores y proveedores de servicios acumulan el número de llamadas y el tiempo de llamadas en la memoria y envían datos estadísticos al centro de monitoreo cada minuto.
-
¿Qué marco de comunicación se usa por defecto? ¿Hay otras opciones?
El marco netty y mina se recomiendan de forma predeterminada.
-
Proceso de inicio de Dubbo
Referencia de https://www.jianshu.com/p/7f3871492c71
-
¿Cuál es el proceso de solicitud de dubbo?
-
¿Está bloqueando la llamada al servicio dubbo?
El valor predeterminado es el bloqueo, puede llamar de forma asincrónica, puede hacer esto si no hay un valor de retorno
<dubbo:reference id="xxx" ....> <dubbo:method name="method1" async="true" / </dubbo:reference> -
Presente su comprensión de zk, ¿conoce el límite (consistencia, disponibilidad, tolerancia a fallas de partición)?
La teoría CAP existe en el campo distribuido, y esta teoría ha sido probada: cualquier sistema distribuido solo puede satisfacer dos puntos al mismo tiempo y no puede ocuparse de los tres.
①C: Consistencia, consistencia, actualización de datos consistente, todos los cambios de datos están sincronizados.
②A: Disponibilidad, disponibilidad, el sistema tiene un buen desempeño de respuesta.
③P: tolerancia de partición, tolerancia a fallos de partición.
Los detalles son los siguientes:
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。（等同于所有节点访问同一份最新的数据副本） ● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） ● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
(1) Consistencia
Consistencia significa que cuando los datos dentro del sistema se leen desde el exterior del sistema, son los mismos bajo ciertas restricciones, es decir, los cambios de datos deben sincronizarse entre los nodos del sistema. Según el grado de consistencia, los niveles de consistencia se pueden dividir en los siguientes tipos:
① Consistencia fuerte (consistencia fuerte). En cualquier momento, cualquier usuario puede leer los últimos datos actualizados correctamente.
② Consistencia monótona (consistencia monótona). En cualquier momento, una vez que un usuario lee el valor de ciertos datos después de una determinada actualización, no leerá un valor anterior a este valor. En otras palabras, el orden de los datos disponibles debe aumentar monótonamente.
③ consistencia de la sesión (consistencia de la sesión). Cualquier usuario en una sesión, una vez que haya leído el valor de ciertos datos después de una determinada actualización, en esta sesión no leerá un valor anterior a este valor. La coherencia de la sesión es una coherencia monótona. la monotonicidad dentro de una sola sesión de un solo usuario está garantizada, y no hay garantía entre diferentes usuarios o entre diferentes sesiones de un mismo usuario. Caso de ejemplo: concepto de sesión de PHP.
④ Consistencia eventual (consistencia eventual). El usuario solo puede leer el valor después de una determinada actualización, pero el sistema garantiza que los datos finalmente alcanzarán un estado completamente consistente, pero no se puede garantizar el tiempo requerido.
⑥ Consistencia débil (consistencia débil). El usuario no puede leer el último valor actualizado dentro de un cierto tiempo.
2. Servicio de coherencia proporcionado por ZooKeeper
Muchos artículos y blogs mencionaron que zookeeper es un servicio que proporciona una gran coherencia y que ha hecho un cierto compromiso en la disponibilidad y tolerancia a fallos de partición, lo que es coherente con la teoría CAP. Pero, de hecho, lo que proporciona el guardián del zoológico es solo una coherencia monótona.
Motivos:
1. Suponiendo que hay 2n + 1 servidores, en el proceso de sincronización, el líder sincroniza los datos con los seguidores. Cuando el número de seguidores sincronizados es mayor que n + 1, el proceso de sincronización finaliza y el sistema puede aceptar la conexión del cliente. peticiones. Si el cliente no está conectado a un seguidor que está sincronizado, no se obtienen los últimos datos, pero se puede garantizar la monotonicidad.
2. Una vez que el seguidor recibe la solicitud de escritura, la envía al líder para que la procese, el líder completa el mecanismo de confirmación de dos fases. Iniciar una propuesta para todos los servidores. Cuando la propuesta es aprobada por más de la mitad (n + 1) servidores, se sincronizará todo el clúster. Después de que más de la mitad (n + 1) servidores estén sincronizados, la solicitud de escritura se completará. Si el cliente no está conectado al seguidor de forma sincrónica, no se obtienen los datos más recientes, pero se puede garantizar la monotonicidad.
Analice Zookeeper con el principio CAP del sistema distribuido:
(1) C: Zookeeper garantiza la consistencia final y se puede sincronizar con cada nodo en diez segundos.
(2) A: Zookeeper garantiza la disponibilidad, los datos siempre están disponibles, sin bloqueo. Y los datos que pertenecen a más de la mitad de los nodos son los más recientes, en tiempo real. Si desea asegurarse de que los datos deben ser los más recientes, debe llamar manualmente a Sync ()
(2) P: Hay dos puntos para analizar .
① Hay muchos nodos Esto conducirá a un retraso muy grande en la escritura de datos, porque se requieren varios nodos para sincronizar.
② Si hay más nodos, la elección del líder lleva mucho tiempo, lo que agrava el problema de la red. El problema puede aliviarse introduciendo nodos observadores.
-
¿Cómo garantiza zk la coherencia?
Referencia https://blog.csdn.net/wq237wq/article/details/51607180
¿Cómo asegura zookeeper la coherencia de secuencia de las transacciones?
Zookeeper utiliza un ID de transacción incremental para identificarlo. Todas las propuestas se agregan con zxid cuando se proponen. Zxid es en realidad un número de 64 bits, y los 32 bits superiores se utilizan para epoch To identifique si el líder ha cambiado, si se genera un nuevo líder, la época aumentará automáticamente y los 32 bits inferiores se utilizan para incrementar el recuento. Cuando se genera una nueva propuesta, primero emitirá solicitudes de ejecución de transacciones a otros servidores de acuerdo con el proceso de dos etapas de la base de datos. Si más de la mitad de las máquinas pueden ejecutarse y tener éxito, entonces comenzará la ejecución.
¿Cómo elige el cuidador del zoológico al líder principal?
Cuando el líder falla o el líder pierde a la mayoría de sus seguidores, zk ingresa al modo de recuperación,
Hay cuatro tipos de znodes en zk. Nodos de directorio persistentes. Nodos de directorio de numeración de secuencia persistente (ordenados se pueden usar en muchos escenarios, como máquinas de registro). Nodos de directorio temporales
. Nodos de numeración de secuencia temporal . El mecanismo de notificación de zk. El
cliente establecer un znode.Un evento de observador, cuando el znode cambia, estos clientes recibirán la notificación zk, y luego el cliente puede realizar cambios comerciales de acuerdo con los cambios de znode.
El
programa de gestión de configuración de zk se implementa en diferentes máquinas de manera distribuida, y la información de configuración del programa se coloca debajo del znode de zk. Cuando cambia la configuración, es decir, cuando cambia el znode, puede cambiar un nodo de directorio in zk Use water para notificar a cada cliente que cambie la configuración.
El servicio de nombres de zk El servicio de nombres se
refiere a obtener la dirección de un recurso o servicio a través de un nombre específico. Usando zk para crear una ruta global, esta ruta se puede usar como un nombre, apuntando al clúster en el clúster, la dirección del servicio prestado, o un objeto Remoto y así sucesivamente.
Notificación y coordinación distribuidas
Para la programación del sistema: el operador envía una notificación para cambiar realmente el estado de un nodo a través de la consola, y luego zk envía estos cambios a todos los clientes que han registrado el observador de este nodo.
Para el informe de implementación: cada proceso de trabajo crea un nodo temporal en un directorio determinado. Y lleve los datos del progreso del trabajo, de modo que el proceso resumido pueda monitorear los cambios de los subnodos del directorio para obtener la situación global en tiempo real del progreso del trabajo.
¿Por qué hay un maestro
en una máquina? En un entorno distribuido, parte de la lógica empresarial solo necesita ser ejecutada por una máquina en el clúster, y otras máquinas pueden compartir este resultado, lo que puede reducir en gran medida los cálculos repetidos y mejorar el rendimiento, por lo que necesita a realizar la elección del Maestro.
-
Cómo determinar el tamaño de partición de Kafka es más razonable
- Algoritmo de equilibrio de carga de Dubbo (aplicado al clúster de Dubbo)
① Random LoadBalance（随机均衡算法）
② RoundRobin LoadBalance（权重轮询均衡算法）
③ LeastAction LoadBalance（最少活跃调用数均衡算法）
④ ConsistentHash LoadBalance（一致性Hash均衡算法）
缺省时为Random随机调用