Prefacio
En el proceso de operar nuestro sistema, cuando los usuarios agregan, eliminan, modifican y verifican algunos datos comerciales importantes, esperamos registrar el comportamiento de operación del usuario para que podamos encontrar la base en el momento en que ocurre un problema. Este registro es el registro de operaciones del sistema empresarial.
En este artículo, discutiremos la implementación y la viabilidad de los registros de operaciones comunes.
Tipos de registros de operaciones comunes
- Registro de inicio de sesión de usuario
- Registro de consultas de datos importantes (pero el comercio electrónico puede no ser datos importantes para ser enterrados, como qué productos busca en Taobao, incluso si no compra, la página de inicio le recomendará cosas similares durante un período de tiempo)
- Registro de cambios de datos importantes (como cambio de contraseña, cambio de permiso, modificación de datos, etc.)
- Registro de eliminación de datos
- ......
En resumen, es importante agregar, eliminar, modificar y verificar el registro de operaciones según las necesidades del negocio.
Comparación del plan de implementación
Basado en el esquema de implementación tradicional AOP (Aspect)
- Ventajas: ideas de implementación simples;
- Desventajas: aumenta la carga de la base de datos, depende en gran medida de la transferencia de parámetros del front-end, expansión inconveniente, no admite operaciones por lotes, no admite asociación de múltiples tablas;
Basado en la base de datos Binlog
- Ventajas: se libera el acoplamiento entre los cambios nuevos y antiguos en los datos, se admite la operación por lotes y la expansión de la asociación de múltiples tablas es conveniente y no depende de los lenguajes de desarrollo;
- Desventajas: el diseño de tablas de bases de datos requiere un acuerdo unificado;
Detalles de implementación del esquema
1. Solución tradicional basada en el aspecto AOP + anotación
El enfoque tradicional es el método de aspecto + anotación, el cual no es muy intrusivo al código, generalmente registra ip, módulo de negocio, cuenta de operación, escenario de operación, fuente de operación, etc., generalmente estos valores se obtienen en la anotación + interceptor ,Como se muestra abajo:
Podemos manejar este método común en general, pero en términos de cambio de datos, no ha habido una mejor manera de implementarlo, como cuántos datos hay antes del cambio y cuánto después del cambio.
Tomando un conjunto de soluciones que hemos implementado anteriormente, el método de registro basado en cambios de datos no solo debe coincidir en una plantilla con el lado de la demanda (es imposible mostrar y registrar cientos de campos), sino también hacer algún acuerdo con el front-end. , como en Cuál es el valor antes de la modificación y cuál es el valor después de la modificación, consulte el siguiente código:
@Valid
@NotNull(message = "新值不能为空")
@UpdateNewDataOperationLog
private T newData;
@Valid
@NotNull(message = "旧值不能为空")
@UpdateOldDataOperationLog
private T oldData;
Problemas existentes:
- 1. Si el valor anterior no consulta la base de datos más de una vez, debe confiar en la interfaz para encapsular el valor anterior en el objeto oldData, que probablemente no sea el valor antes de la modificación;
- 2. No se pueden procesar lotes de datos de lista;
- 3. No es compatible con el funcionamiento de varias mesas;
Tome otra escena como ejemplo. Antes de eliminar, debe registrar el valor antes de eliminar. ¿Tiene que verificarlo nuevamente?
@PostMapping("/delete")
@ApiOperation(value = "删除用户信息", notes = "删除用户信息")
@DeleteOperationLog(system = SystemNameNewEnum.SYS_JMS_LMDM, module = ModuleNameNewEnum.LMDM_AUTH, table = LogBaseTableNameEnum.TABLE_USER, methodName = "detail")
Dos, basado en el programa Binlog de la base de datos
El diagrama de la arquitectura del sistema es el siguiente:
"Principalmente dividido en 3 partes:"
- 1: La aplicación comercial genera el traceid de cada operación, lo actualiza a la tabla de negocios de la operación y envía un mensaje comercial que contiene información sobre el operador de la operación actual;
- 2: La aplicación de recopilación de registros integra registros comerciales y registros binlog convertidos, y proporciona API de búsqueda y consulta de registros externos;
- 3: La aplicación de procesamiento de registros utiliza canal para recopilar y analizar el registro binlog de la biblioteca empresarial y entregarlo a Kafka. El registro analizado registra el tipo de operación de la operación actual, como el registro de eliminación, modificación, adición y nueva y valores antiguos, formatee de la siguiente manera:
{"data":[{"id":"122158992930664499","bill_type":"1","create_time":"2020-04-2609:15:13","update_time":"2020-04-2613:45:46","version":"2","trace_id":"exclude-f04ff706673d4e98a757396efb711173"}],
"database":"yl_spmibill_8",
"es":1587879945200,
"id":17161259,
"isDdl":false,
"mysqlType":{"id":"bigint(20)",
"bill_type":"tinyint(2)",
"create_time":"timestamp",
"update_time":"timestamp",
"version":"int(11)",
"trace_id":"varchar(50)"},
"old":[{"update_time":"2020-04-2613:45:45",
"version":"1",
"trace_id":"exclude-36aef98585db4e7a98f9694c8ef28b8c"}],
"pkNames":["id"],"sql":"",
"sqlType":{"id":-5,"bill_type":-6,"create_time":93,"update_time":93,"version":4,"trace_id":12},
"table":"xxx_transfer_bill_117",
"ts":1587879945698,"type":"UPDATE"}
El registro de operaciones después de procesar la conversión de registros de binlon es el siguiente:
{
"id":"120716921250250776",
"relevanceInfo":"XX0000097413282,",
"remark":"签收财务网点编码由【】改为【380000】，
签收网点名称由【】改为【泉州南安网点】，签收网点code由【】改为【2534104】，运单状态code由【204】改为【205】，签收财务网点名称由【】改为【福建代理区】，签收网点id由【0】改为【461】，签收标识,1是，0否由【0】改为【1】，签收时间由【null】改为【2020-04-24 21:09:47】，签收财务网点id由【0】改为【400】，",
"traceId":"120716921250250775"
}
Diseño de mesa de biblioteca
- 1: Todas las tablas del sistema empresarial deben agregar el campo trace_id, y cada operación genera una cadena aleatoria y la guarda en la tabla empresarial;
- 2: Diseño de tabla de biblioteca de aplicaciones de colección de registros
CREATE TABLE `table_config` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
`database_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '数据库名',
`table_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ' 数据库表名',
PRIMARY KEY (`id`),
UNIQUE KEY `unq_data_name_table_name` (`database_name`,`table_name`) USING BTREE COMMENT '数据库名表名联合索引'
) ENGINE=InnoDB AUTO_INCREMENT=35 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='数据库配置表';
CREATE TABLE `table_field_config` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`table_config_id` bigint(20) DEFAULT NULL,
`field` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '字段 数据库',
`field_name` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '字段 中文名称',
`enum_flag` tinyint(2) DEFAULT NULL COMMENT '是否枚举字段(1:是,0:否)',
`relevance_flag` tinyint(2) DEFAULT NULL COMMENT '是否是关联字段(1:是,0否)',
`sort` int(11) DEFAULT NULL COMMENT '排序',
PRIMARY KEY (`id`),
KEY `idx_table_config_id` (`table_config_id`) USING BTREE COMMENT '表ID索引'
) ENGINE=InnoDB AUTO_INCREMENT=2431 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='数据库字段配置表';
CREATE TABLE `table_field_value` (
`id` bigint(20) NOT NULL,
`field_config_id` bigint(20) DEFAULT NULL,
`field_key` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ' 枚举',
`filed_value` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '枚举名称',
PRIMARY KEY (`id`),
KEY `ids_field_config_id` (`field_config_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='数据字典配置表';
efecto
Basado en binlog para realizar el plan futuro del programa
- Optimice la realización del envío de mensajes comerciales y utilice la interceptación de aspectos para reducir la intrusión del código comercial;
- Actualmente, no admite registros de registro de operaciones de asociación de varias tablas y debe ampliarse;