Buen dia
Quiero compartir con ustedes una historia sobre la implementación de caché en la base de datos Tarantool y mis características de trabajo.
Trabajo como desarrollador de Java en una empresa de telecomunicaciones. La tarea principal: la implementación de la lógica de negocios para la plataforma que la empresa compró al proveedor. De las primeras características, esto es trabajo de jabón y la ausencia casi completa de almacenamiento en caché, excepto en la memoria JVM. Por supuesto, todo esto es bueno hasta que el número de instancias de la aplicación exceda de dos docenas ...
En el curso del trabajo y la aparición de una comprensión de las características de la plataforma, se hizo un intento de almacenar en caché. En ese momento, MongoDB ya se lanzó, y como resultado, no obtuvimos ningún resultado positivo como en la prueba.
Al buscar alternativas y consejos de mi buen amigo
mr_elzor , se decidió probar la base de datos Tarantool.
En un estudio superficial, solo aparecieron dudas en lua, ya que no había escrito sobre él desde la palabra "completamente". Pero dejando de lado todas las dudas, se puso a instalar. Acerca de las redes cerradas y los cortafuegos, creo que pocas personas están interesadas, pero le aconsejo que trate de sortearlas y poner todo de fuentes públicas.
Servidores de prueba con configuración: 8 CPU, 16 GB de RAM, 100 Gb HDD, Debian 9.4.
La instalación se realizó de acuerdo con las instrucciones del sitio. Y entonces obtuve una opción de ejemplo. La idea apareció inmediatamente de una interfaz visual con la que el soporte funcionaría convenientemente. Durante una búsqueda rápida, encontré y configuré
tarantool-admin . Trabaja en Docker y cubre las tareas de soporte al 100%, al menos por ahora.
Pero hablemos de más interesante.
El siguiente pensamiento fue configurar mi versión en la configuración maestro - esclavo dentro del mismo servidor, ya que la documentación contiene solo ejemplos con dos servidores diferentes.
Después de pasar un tiempo entendiendo lua y describiendo la configuración, lanzo el asistente.
Inmediatamente caigo en un estupor y no entiendo por qué es el error, pero veo que está en el estado de "carga".
Yo corro esclavo:
Y veo el mismo error. Aquí, generalmente empiezo a esforzarme y no entiendo lo que está sucediendo, ya que no hay nada en la documentación al respecto ... Pero cuando verifico el estado, veo que no comenzó en absoluto, aunque dice que el estado se está "ejecutando":
Pero al mismo tiempo, el maestro comenzó a trabajar:
Reiniciar el esclavo no ayuda. Me pregunto por qué
Yo detengo al maestro. Y realizar las acciones en orden inverso.
Veo que el esclavo está tratando de comenzar.
Comienzo el asistente y veo que no ha subido y, en general, ha cambiado al estado huérfano, mientras que el esclavo generalmente ha caído.
Se vuelve aún más interesante.
Veo en los registros del esclavo que incluso vio al maestro e intentó sincronizar.
2019-02-19 17:13:45.113 [20751] iproto/101/main D> binary: binding to 0.0.0.0:3302... 2019-02-19 17:13:45.113 [20751] iproto/101/main I> binary: bound to 0.0.0.0:3302 2019-02-19 17:13:45.113 [20751] iproto/101/main D> binary: listening on 0.0.0.0:3302... 2019-02-19 17:13:45.113 [20751] iproto D> cpipe_flush_cb: locking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] iproto D> cpipe_flush_cb: unlocking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main D> cbus_endpoint_fetch: locking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main D> cbus_endpoint_fetch: unlocking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main/101/slave2 I> connecting to 1 replicas 2019-02-19 17:13:45.113 [20751] main/106/applier/replicator@tarantuldb-t D> => CONNECT 2019-02-19 17:13:45.114 [20751] main/106/applier/replicator@tarantuldb-t I> remote master 825af7c3-f8df-4db0-8559-a866b8310077 at 10.78.221.74:3301 running Tarantool 1.10.2 2019-02-19 17:13:45.114 [20751] main/106/applier/replicator@tarantuldb-t D> => CONNECTED 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> connected to 1 replicas 2019-02-19 17:13:45.114 [20751] coio V> loading vylog 14 2019-02-19 17:13:45.114 [20751] coio V> done loading vylog 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> recovery start 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> recovering from `/var/lib/tarantool/cache_slave2/00000000000000000014.snap' 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(47) = 0x7f99a4000080 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> cluster uuid 4035b563-67f8-4e85-95cc-e03429f1fa4d 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(11) = 0x7f99a4004080 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(17) = 0x7f99a4008068
Y el intento fue exitoso:
2019-02-19 17:13:45.118 [20751] main/101/slave2 D> memtx_tuple_new(40) = 0x7f99a40004c0 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> assigned id 1 to replica 825af7c3-f8df-4db0-8559-a866b8310077 2019-02-19 17:13:45.118 [20751] main/101/slave2 D> memtx_tuple_new(40) = 0x7f99a4000500 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> assigned id 2 to replica 403c0323-5a9b-480d-9e71-5ba22d4ccf1b 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> recover from `/var/lib/tarantool/slave2/00000000000000000014.xlog' 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> done `/var/lib/tarantool/slave2/00000000000000000014.xlog'
Incluso comenzó:
2019-02-19 17:13:45.119 [20751] main/101/slave2 D> systemd: sending message 'STATUS=running'
Pero por razones desconocidas, perdió la conexión y cayó:
2019-02-19 17:13:45.129 [20751] main/101/slave2 D> SystemError at /build/tarantool-1.10.2.146/src/coio_task.c:416 2019-02-19 17:13:45.129 [20751] main/101/slave2 tarantoolctl:532 E> Start failed: /usr/local/share/lua/5.1/http/server.lua:1146: Can't create tcp_server: Input/output error
Intentar iniciar esclavo de nuevo no ayuda.
Ahora elimine los archivos creados por las instancias. En mi caso, elimino todo del directorio / var / lib / tarantool.
Comienzo esclavo primero, y solo luego amo. Y he aquí que ...
No encontré ninguna explicación para este comportamiento, excepto como una "característica de este software".
Esta situación aparecerá cada vez que su servidor se haya reiniciado por completo.
Tras un análisis más detallado de la arquitectura de este software, resulta que está planeado usar solo una vCPU para una instancia y muchos más recursos permanecen libres.
En la ideología de n vCPU, podemos criar al maestro y n-2 esclavos para leer.
Dado que en el servidor de prueba 8 vCPU podemos elevar el maestro y 6 instancias para leer.
Copio el archivo para esclavo, corrijo los puertos y ejecuto, es decir Se agregan algunos esclavos más.
Importante! Al agregar otra instancia, debe registrarla en el asistente.
Pero primero debe iniciar un nuevo esclavo, y solo luego reiniciar el maestro.
Ejemplo
Ya tenía una configuración ejecutándose con un asistente y dos esclavos.
Decidí agregar un tercer esclavo.
Lo registré en el maestro y reinicié el maestro primero, y esto es lo que vi:
Es decir nuestro maestro se volvió solitario y la replicación se vino abajo.
Iniciar un nuevo esclavo ya no ayudará y dará como resultado un error:
Y en los registros vi una pequeña entrada informativa:
2019-02-20 09:20:10.616 [21601] main/101/slave4 I> bootstrapping replica from 3c77eb9d-2fa1-4a27-885f-e72defa5cd96 at 10.78.221.74:3301 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t I> can't join/subscribe 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t xrow.c:896 E> ER_READONLY: Can't modify data because this instance is in read-only mode. 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t D> => STOPPED 2019-02-20 09:20:10.617 [21601] main/101/slave4 xrow.c:896 E> ER_READONLY: Can't modify data because this instance is in read-only mode. 2019-02-20 09:20:10.617 [21601] main/101/slave4 F> can't initialize storage: Can't modify data because this instance is in read-only mode.
Paramos al mago y comenzamos un nuevo esclavo. También habrá un error, como en el primer inicio, pero veremos que se está cargando.
Pero cuando inicia el maestro, el nuevo esclavo se bloquea y el maestro no va con el estado de ejecución.
En esta situación, solo hay una salida. Como escribí anteriormente, elimino archivos creados por instancias y primero ejecuto esclavos, y luego master.
Todo comenzó con éxito.
Así es como, mediante prueba y error, descubrí cómo configurar e iniciar la replicación correctamente.
Como resultado, se ensambló la siguiente configuración:
2 servidores
2 master. Reserva caliente
12 esclavos. Todos estan activos.En la lógica de tarantool, se utilizó http.server
para no
bloquear el adaptador adicional (recuerde el proveedor, la plataforma y el jabón) o sujetar la biblioteca a cada proceso comercial.
Para evitar una discrepancia entre los maestros, en el equilibrador (NetScaler, HAProxy o cualquier otro favorito), establecemos la regla de reserva, es decir. Las operaciones de inserción, actualización y eliminación van solo al primer maestro activo.
En este momento, el segundo simplemente replica los registros del primero. Los esclavos mismos están conectados al primer maestro especificado desde la configuración, que es lo que necesitamos en esta situación.
En lua, se implementaron operaciones CRUD para clave-valor. Por el momento, esto es suficiente para resolver el problema.
En vista de las características de trabajar con soap, se implementó un proceso de negocio proxy, en el que se estableció la lógica de trabajar con una tarántula a través de http.
Si los datos clave están presentes, se devuelven inmediatamente. De lo contrario, se envía una solicitud al sistema maestro y se almacena en la base de datos Tarantool.
Como resultado, un proceso de negocio en pruebas procesa hasta 4k solicitudes. En este caso, el tiempo de respuesta de la tarántula es de ~ 1 ms. El tiempo de respuesta promedio es de hasta 3 ms.
Aquí hay alguna información de las pruebas:
Hubo 50 procesos de negocios que van a 4 sistemas maestros y almacenan datos en la memoria caché. Duplicación de información en pleno crecimiento en cada instancia. Dado que Java ya ama la memoria ... la perspectiva no es la mejor.
Ahora
50 procesos de negocio solicitan información a través del caché. Ahora la información de 4 instancias del asistente se almacena en un lugar y no se almacena en la memoria caché en cada instancia. Fue posible reducir significativamente la carga en el sistema maestro, no hay duplicados de información y el consumo de memoria en instancias con lógica empresarial ha disminuido.
Un ejemplo del tamaño del almacenamiento de información en la memoria de la tarántula:
Al final del día, estos números pueden duplicarse, pero no hay una "reducción" en el rendimiento.
En batalla, la versión actual crea 2k - 2.5k solicitudes por segundo de carga real. El tiempo de respuesta promedio es similar a las pruebas de hasta 3 ms.
Si observa htop en uno de los servidores con tarantool, veremos que se están "enfriando":
Resumen
A pesar de todas las sutilezas y matices de la base de datos Tarantool, puede lograr un gran rendimiento.
Espero que este proyecto se desarrolle y estos momentos incómodos se resuelvan.