Experiencia práctica del sistema de control de riesgos: drools y redis
Requisitos:
Desarrollar un sistema de control de riesgos. El sistema incluye un motor de reglas y un motor de cálculo. Los contenidos principales son los siguientes:
1. Adición. , eliminación y modificación de reglas. Efectivo en tiempo real, las reglas se ejecutan según categorías
2. Calcule el valor acumulado según una determinada latitud, como IP, ID de usuario, cuenta y otras latitudes.
3. Necesidad de admitir ventanas deslizantes, ventanas enrollables, ventanas longitudinales, etc.
Los principales problemas encontrados son los siguientes:
1. Redis transmite Computación Es demasiado reacio. En primer lugar, según las necesidades comerciales, la cantidad de claves que deben contarse es de al menos cientos de millones y, como máximo, miles de millones. Además, Redis necesita almacenar una pequeña cantidad de información de transacciones. La cantidad estimada también es muy considerable.
2. La clave de acceso rápido en redis es particularmente obvia. Por ejemplo, si la clave del comerciante no está descomprimida, los comerciantes con tráfico como Hema no podrán redisificar. es muy grande.
Usamos el modo de clúster de redis, por lo que la tecla de acceso rápido de redis tendrá un mayor impacto en redis. Es necesario dividirlo, por ejemplo, por horas. ?
3. En la informática de transmisión, uno es que el cálculo de acumulación es inexacto (con valores negativos) debido al desorden, y el otro es el retraso del mensaje. En ese momento, intentamos utilizar el concepto de marca de agua. Finalmente resolvió el problema y descubrió que no era adecuado. Este error también fue descubierto después de que lo practicamos.
La experiencia más dolorosa fue la resolución de mensajes desordenados y retrasados, que ahora se soluciona de forma correctiva.
Motor de reglas
Elegimos drools como motor de reglas y exploramos brevemente drools core, drools DRL, drools CEP, etc. Sin embargo, mirando hacia atrás, todavía hay muchas deficiencias en el uso. de drools Y es obvio que no hay ningún plan para reemplazarlo todavía.
1. ¿Cómo usar drools CEP para realizar la distribución? Descubrimos que varias ventanas en drools CEP son todas cálculos basados en memoria. Y no existe una buena manera de aplicarlos a aplicaciones distribuidas, es casi imposible, a menos que Drols también integre cachés distribuidos como Redis.
2. Usar drools se siente engorroso porque hay muchas dependencias. En segundo lugar, solo usamos if else y otros juicios en drools, y muchas otras funciones básicamente no se usan porque la distribución no se puede resolver en 1. pregunta de fórmula. . Entonces, desde este punto de vista, Drols está obsoleto y no hay necesidad de crear cosas tan pesadas como Kiesession.
3. Los operadores admitidos en drools no son particularmente suficientes. Por ejemplo, operaciones como operación de registro, suma, máximo, promedio, etc. no son compatibles. El lenguaje DRL no es muy adecuado para el personal empresarial. . amigable.
4. Además, no hay forma de configurar las reglas continuas y no continuas en drools. Al menos flink cep tiene dicha API.
En resumen, me quedo sin palabras cuando tengo que quejarme de las babas. Tal vez sea muy sencillo de entender, y además, el banco de trabajo de babas también es muy mudo y complicado. El fabricante de babas quiere utilizar este método.
Mi sensación general es que si hay otras opciones, es mejor no usar drools. Si el problema distribuido no se resuelve, será inútil, porque necesitamos implementar varias ventanas distribuidas nosotros mismos. ¿Qué debemos hacer?
El motor de reglas finalmente usó drools para crear diferentes kiesession según el significado comercial específico. Drools desempeña el papel de juicio de si no, en cuanto a la ventana rodante, la ventana de longitud y la ventana deslizante. window all pass redis hace los cálculos.
Los dolores de cabeza encontrados son
1. Basándonos en diferentes dimensiones estadísticas, calculamos aproximadamente que se necesitan miles de millones de claves y el cálculo se realiza en redis
2. Ventana deslizante Por el momento Siendo así, confío en la estructura de datos de zsort de Redis, pero el rendimiento no es muy bueno
3. El problema de las teclas de acceso rápido, especialmente para los grandes comerciantes, debe dividirse, lo cual es relativamente complicado
4. Retraso de mensajes y problemas de mensajes desordenados.
Por lo tanto, los requisitos del motor de cálculo son generalmente
1. El cálculo es rápido, se pueden utilizar cientos de reglas y se pueden calcular resultados precisos rápidamente
2. Precisión del cálculo, cómo calcular con mayor precisión cuando se enfrenta a mensajes retrasados y desordenados
3. La cuestión de la cantidad de cálculo, como se mencionó anteriormente, miles de millones de claves, además Es También es necesario almacenar cierta información, estados intermedios de cálculo, etc. Si se pierde en redis, provocará cálculos inexactos.
Según las preguntas anteriores, la clave es cómo hacerlo mejor y optimizar mejor. Para ser honesto, no he encontrado la respuesta. Lo que se puede hacer es optimizar continuamente los cálculos de Redis (los big data no se pueden hacer). utilizados en este momento, como flink, spark, etc.) para reducir la sobrecarga de la red causada por las operaciones de redis.
De hecho, una última cosa a mencionar es que si se puede utilizar la computación en memoria en lugar de la computación distribuida, ¿será más rápido? Por ejemplo, la fragmentación se puede realizar según el negocio, de modo que el valor intermedio. de las estadísticas de cada instancia es Sin agregación, cada instancia solo necesita cálculo de memoria y no hay necesidad de sobrecarga de red causada por el acceso a Redis. Pero hacerlo también generará ajustes a nivel arquitectónico, como cómo implementar la tolerancia a fallas, cómo implementar la persistencia del estado y una serie de otras cuestiones. ?
A juzgar por los resultados del uso de Redis, el efecto no es tan malo sin considerar las teclas muy activas, el tps más alto alcanza más de 6000 (2 máquinas, 16 núcleos, 32 G de memoria), que es el promedio. El negocio de la empresa es realmente satisfactorio. Para las teclas muy activas, la optimización posterior es continuar dividiéndolas.
Un buen sistema de control de riesgos es muy difícil. Tomar notas con la esperanza de un crecimiento continuo.