El pika de almacenamiento masivo similar a Redis lanzó la versión oficial 2.2

Equipo de infraestructura y DBA 360 cloud computing
pika es un almacenamiento Redis de gran capacidad desarrollado por el DBA del departamento de plataforma WEB 360 y el equipo de infraestructura. Se esfuerza por ser totalmente compatible con el protocolo Redis y heredar el conveniente diseño de operación y mantenimiento de Redis a través de Almacenamiento persistente. Redis tiene problemas en escenarios de gran capacidad, como tiempo de recuperación lento, alto costo de sincronización maestro-esclavo, subproceso único relativamente frágil, carga de datos limitada, alto costo de memoria, etc.

Lista de mejoras y correcciones de errores en pika2.2

Actualice rocksdb a 5.0.1 y conéctelo, luego puede actualizar dinámicamente la versión de rocksdb
Interfaz geográfica e interfaz hiperloglog agregadas (gracias a Leviathan1995 por el soporte)
Optimice el marco de red subyacente de color rosa para resolver el problema del desbordamiento de fd que puede ocurrir en el escenario de solicitudes extremadamente lentas y una gran cantidad de conexiones cortas.

Nota: La versión actual de pika bloqueará un hilo cuando encuentre una solicitud muy lenta, como llaves * (similar al bloqueo de Redis). En este momento, las solicitudes posteriores siempre estarán en la cola del hilo de trabajo, con más conexiones. provocó que el proceso se bloqueara con demasiados identificadores de fd. Después de la optimización, aumentamos el límite en el número de identificadores de fd y optimizamos la lógica de asignación de tareas de subprocesos. En la versión 2.2, incluso si hay solicitudes lentas, las conexiones posteriores se asignarán a inactivas hilos y no volverán a aparecer. Este tipo de problema

4. Optimice el rendimiento de escritura, habilite la escritura en paralelo en la capa del motor y el rendimiento de la interfaz de escritura se ha mejorado hasta cierto punto, por ejemplo, el rendimiento del conjunto se ha incrementado en un 30%.

5. Se mejoró el rendimiento de la interfaz de rango.

6. La metainformación residual después de la expiración de varias estructuras de datos se puede reciclar a través del comando compacto (si su instancia tiene una gran cantidad de estructuras de datos múltiples caducadas, ejecutar el comando compacto después de esta actualización le liberará más espacio)

7. Solucione el problema del bloqueo del análisis debido a errores durante el proceso de análisis.

8. Solucione el problema de que la clave que no existe puede no leerse en la operación de rango

9. Se solucionó el problema de que hay una probabilidad muy pequeña de interbloqueo cuando bgsave e info se ejecutan al mismo tiempo.

10. Virtual dbnum ahora tiene un límite superior, hasta 16 (db0-db15), para resolver el problema de algunas herramientas de administración de Redis atascadas en select porque pika no tiene límite superior de dbnum

11. Soporte completo para compacto multiproceso rocksdb, mejora la velocidad de compactación

12. El archivo de configuración agrega nuevos parámetros max-background-flushes, max-background-compactions, max-bytes-for-level-multiplicador, consulte la wiki para funciones específicas

github: https://github.com/Qihoo360/pika
(También puede hacer clic en "Leer el original para saltar" a continuación)
grupo de intercambio técnico pika: 294254078 Para
obtener más información sobre pika, haga clic en el nombre de la cuenta pública en la parte superior izquierda a seguir.
Bienvenido al público a través de la retroalimentación Número HULK pika errores relacionados y presentar puntos de mejora

Si aún no sabe qué es pika, explore la introducción a continuación

Pika es un almacenamiento Redis de gran capacidad desarrollado conjuntamente por el DBA del Departamento de Plataforma WEB 360 y el Grupo de Infraestructura. Se esfuerza por resolver sus problemas en escenarios de gran capacidad a través del almacenamiento persistente bajo la premisa de compatibilidad con el protocolo Redis y métodos de operación y mantenimiento, como recuperación Tiempo lento, alto costo de sincronización maestro-esclavo, hilo único relativamente frágil, carga de datos limitada y alto costo de memoria. Tiene las siguientes características:

1. Pika es totalmente compatible con el protocolo Redis, por lo que no tiene su propio cliente dedicado, utilice el cliente Redis para conectarse a pika directamente, por lo que es casi innecesario modificar el código del programa al migrar de Redis a pika

2. Pika es compatible con la mayoría de las interfaces de Redis (por encima del 80%). Consulte la wiki para obtener la lista de compatibilidad de interfaces específicas. El uso de interfaces individuales es ligeramente diferente. Además, hemos aumentado continuamente el número de interfaces compatibilidad.

3. Pika es un almacenamiento persistente, no se requieren configuraciones adicionales para que los datos se coloquen automáticamente en el disco y no hay necesidad de preocuparse por qué hacer si los datos se cortan repentinamente

4. Pika admite subprocesos múltiples y optimiza la asignación de subprocesos de trabajo. En escenarios extremos, pika tiene una tasa de supervivencia más alta que Redis. Por ejemplo, un comando de teclado que permite que Redis cuelgue completamente en el pika de 12 subprocesos que necesita enviar al menos continuamente 12 teclas pueden lograr el mismo efecto colgante, y la cantidad de hilos de pika se puede configurar de acuerdo con sus preferencias

5. Pika es barato, ocupa muy pocos recursos de memoria y tiene su propia función de compresión. En la prueba real, los datos de Redis importados a pika tienen una relación de compresión de 3 a 8 veces, es decir, solo 80G de datos de memoria de Redis son importado a pika.Los datos de disco de 10 ~ 30G son muy económicos, y pika admite múltiples algoritmos de compresión para que usted elija

6. Pika hereda el conveniente diseño de operación y mantenimiento de Redis. Si tiene experiencia en operación y mantenimiento de Redis, pika puede comenzar fácilmente. Además, hemos realizado algunas mejoras en algunas funciones relacionadas con la operación y el mantenimiento, tales como:

Slaveof crea una estructura maestro-esclavo con un clic (sincronización automática completa y conversión automática a sincronización incremental)
También es compatible con el modo de clúster en cascada de Redis
No es necesario volver a importar los datos después de reiniciar, y los datos se cargarán automáticamente en segundos.
La sincronización utiliza registros binarios como medio. Esta solución de sincronización de registros persistente hace que la base de datos esclava ya no tenga dolores de cabeza, como la base de datos esclava de Redis "reiniciar rehacer", "red desconectada durante demasiado tiempo para rehacer" y recuperación ante desastres de la base de datos. continuar sincronizando a través de la ubicación binlog antes del desastre
No es necesario volver a llenar los datos de la base de datos esclava después de la falla del maestro, y la base de datos esclava en la nueva base de datos maestra se puede montar en segundos, y la sincronización y la transmisión automática continuarán, lo que mejora en gran medida el tiempo de recuperación de todo el clúster después de la falla
Copia de seguridad en caliente completa de instantáneas sin bloqueo, mientras que la velocidad de la copia de seguridad es extremadamente rápida (se completa en milisegundos), la copia de seguridad solo ocupa un pequeño espacio y proporcionamos una herramienta de copia de seguridad incremental
Pika proporciona funciones de "lista negra de comandos" multiusuario (administrador / usuario normal) y multiusuario, que pueden proteger a los usuarios de comandos peligrosos, mientras que la cuenta de administrador no está restringida
Otras mejoras menores no se explicarán una por una
7. La salida de estado de Pika está lo más cerca posible de Redis en el diseño, por lo que algunas de sus estrategias de monitoreo de Redis actuales se pueden usar directamente en pika sin modificaciones.

8. Pika es compatible con codis (Gracias left2right de Huanxin Company por apoyar pika codis)

9. Ya sea que migrar a pika o migrar desde pika sea muy simple, proporcionamos las siguientes herramientas:

Redis -> herramienta de migración de pika, que se basa en AOF, puede enviar los datos en AOF a pika en incremento completo + automático
ssdb -> herramienta de migración pika
pika -> Herramienta de migración de Redis
Otras características":

Pika tiene tres gerentes de producto a tiempo parcial responsables de la mejora de funciones, seguimiento de BUG, desempeño y pruebas funcionales, y su otra identidad es DBA
Se dice que el grupo de desarrollo pika (grupo de infraestructura de plataforma WEB) puede ser uno de los equipos de rocksdb de "mejor conocimiento" en China.
No hay conejillos de indias en la comunidad pika. Todas las versiones nuevas de pika se ejecutarán en casi 1500 casos de prueba y luego darán prioridad al uso interno, y solo se lanzarán al público después de alcanzar un nivel estable.
La versión utilizada internamente por pika es exactamente la misma que la versión de código abierto

Pika se posiciona como un complemento a los escenarios de Redis, hemos seleccionado algunos escenarios que pueden ser adecuados para pika

El uso de Redis genera altos costos de servidor
La cantidad de datos es enorme (excede el límite superior de la memoria de una sola máquina) pero no es fácil de fragmentar.
Las solicitudes frecuentes con una gran complejidad de tiempo hacen que Redis se bloquee de forma intermitente
Espero que los datos puedan conservarse realmente en lugar de AOF
Almacene una gran cantidad de datos en Redis, pero no puede soportar el largo tiempo de recarga de datos después del desastre.
Separación de lectura y escritura y no quiero dejar de cambiar al maestro después de la sombra a la biblioteca esclava

Estado actual de los usuarios de pika

360 adentro


实例数量：已达500+

承载请求：400亿次/天

总数据量：4T（此处为单份数据未记入冗余部分，例如一个主从集群2个实例每个实例20G共40G，此处只按一个实例的数据量20G计算），换算到Redis大致相当于20T内存

Usuario de la comunidad

Consulte el LOGOTIPO del usuario de la comunidad en github o únase al grupo QQ para obtener más información