Algunos malentendidos sobre el uso del curador de la herramienta de conexión zk

Un desarrollador principal de zk dijo una vez que curador es para zk lo que guayaba es para java.

Curator ha realizado muchos paquetes sobre la base de la API zk original, proporcionando un marco de API fluido y más fácil de usar. Pero también existen algunos peligros ocultos durante su uso.

1. Después de crear pathChildrenCache, ¡asegúrese de llamar al método de inicio! De lo contrario, no surtirá efecto.

2. Si crea muchos PathChildrenCache, debe recordar personalizar los parámetros del grupo de subprocesos que utiliza. De lo contrario, cada vez que salga un nuevo PathChildrenCache, creará un grupo de un solo subproceso por sí solo. ni más ni menos. Cree algunos hilos y comience a lanzar más que el número máximo de excepciones.

3. Después de perder la conexión zk, si vuelve a crear curatorFramework, también deberá volver a crear PathChildrenCache y el oyente creado anteriormente ya no recibirá ningún evento.

4. Si hay demasiados nodos secundarios o demasiados datos, recuerde configurar el parámetro jute.maxbuffe. En nuestro proyecto, los nodos no tienen datos, pero debido a múltiples servicios públicos. Hay demasiadas URL para nodos consumidores. El consumidor más grande tiene más de 10.000 nodos y la longitud de cada URL supera los 10.000 nodos. La longitud de cada URL supera los 400 caracteres, supera la longitud de datos de 4 MB establecida por zk y tiene un tamaño cercano a los 8 MB, lo que provoca que se produzca una excepción.

5. Si desea consultar varios resultados de zk cada vez, no es necesario utilizar subprocesos múltiples. zk admite llamadas asincrónicas, por lo que cuando use curador, pase un BackgroundCallback cuando llame a inBackground.