SOFARegistro

Referenciado desde: /s/mZo7Dg6gfNqXoetaqgwMww

(En realidad proveedores y consumidores)

(Conectado a todos los proveedores y consumidores de SOFARegistry Todos van a esta capa)

Corresponde a los datos almacenados en cada nodo de zk.

Notificaciones push

Un registro normal como zk almacenará todos los registros de servicios en la misma instancia y luego las otras máquinas del clúster sincronizarán los datos. Pero cuando la cantidad de registros de servicios es enorme, ZooKeeper puede alcanzar fácilmente un cuello de botella en una sola máquina. Aquí es donde el hash consistente resulta útil.

Aún tomando zk como ejemplo, cuando el número de clientes alcanza un cierto orden de magnitud, la conexión entre el cliente y zk también alcanzará un cuello de botella. El diseño de la arquitectura SOFARegistry divide la conexión entre el cliente y el servidor en dos partes: el cliente se conecta al servidor de sesión y luego el servidor de sesión se comunica con el servidor de datos, mientras que el servidor de datos no participa en ninguna operación relacionada con los datos. como registro, fuera de línea, sincronización de datos, etc. Por lo tanto, incluso si el número de conexiones aumenta, es sólo cuestión de tiempo antes de que un cliente se conecte al servidor de datos. Por lo tanto, incluso si aumenta el número de conexiones, solo es necesario escalar el servidor de sesión. Después de todo, para registros como zk o eureka, si se expande el servidor, se requerirán múltiples replicaciones de datos dentro del clúster. Especialmente para zk, debe esperar hasta que se haya copiado en más de la mitad de las máquinas antes de tener éxito, lo que definitivamente afectará la eficiencia de la escritura.

dataInfoId se divide en lista de proveedores y lista de consumidores. La lista de proveedores se mantiene en el servidor de datos y la lista de consumidores se mantiene en el servidor de sesión.

SOFARegistry es en realidad un mecanismo de fragmentación previa porque necesita sincronizarse con múltiples copias de los datos. Si se utiliza un hash consistente, el costo de expansión y contracción de la capacidad será mayor

Cuando los datos se escriben en DataServerA, el registro de operaciones se envía de forma asíncrona a otros servidores como DataServerB y C, donde se encuentran varias réplicas. B y C escribirán datos en una copia de a, donde a es la granularidad de dataInfoId

Resumen: para implementar el contexto de segundo nivel, el contexto del servicio lo envía principalmente al SessionServer, y el SessionServer luego lo envía al consumidor. Sin embargo, esto también tendrá el impacto negativo de "cargas y descargas frecuentes debido a la inestabilidad de la red".