网关希望根据 IP 限制一些恶意的 IP。
要求是 1min 内出现 5000 次的，被视为恶意 IP。
那么应该如何实现大量的 IP 信息累加呢？
一种方式是基于 redis 累加，比如 IP 作为 key，然后定时过期累加。
好处是 redis 相对来说比较节省空间。
不过当时的系统架构并没引入 redis。
而是时序数据库，那么如何优化，降低存储的压力呢？
最基本的版本，我们每一个请求，对应到 vm 中的一条数据：
我们如何实现日志的自动化解析？
答案是前提需要标准化。
但是希望所有的日志都是标准的，这显然非常不现实。
那么，有没有什么办法，稍微让这个情况好一些呢？
我们场景的中间件，比如 mq cache rpc database config 等，可以提供一些中间件层面的标准的日志输出。
因为这部分不需要用户太多额外的工作量，一般公司提前埋点好，耗时比较好推进的。
所有的数据不标准化，是一个常见的现状。
一种非常自然的解决方案就是 ETL，对日志加工处理为标准化的日志。
我们一般的控台系统，实时查询接口/数据库，返回对应的配置信息等，一般时间上都是可以接受的。
但是如果是一个实时链路，那么就必须尽可能的降低这种耗时的远程访问。比如查询数据库
比较自然的思考方式就是引入 redis 之类的缓存。
不过真的只有这一种方式吗？redis 有什么缺点？
redis 快，那也只是相对于数据库这种查询比较快。
但是网络耗时实际上是不能忽略的，几毫秒有时候相对内存访问，还是比较慢的。
我们在配置数据源的时候，希望可以默认加载好一些内置的数据源。
一个是为了方便，一个是为了安全。
安全层面可以是避免密码的泄露，或者是用户手动连接一些业务主库之类的。
如果我们可以控制这些，那么就会方便很多。
最简单的思路就是我们让用户可以提前配置一些数据源。
这个数据源隶属于某一个业务域之类的。这个限制信息可选。
如果想控制，可以在数据层加一层限制，比如用户的业务域下的已有数据源之类的。
除却加密的安全性。
我们希望存储对应的数据源信息，这里我们设计一下对应的数据源表。
初期可以简单些，只管理基本的信息，不做应用间的引用关系限制。
这里以 mysql 为例
清空
drop table if exists jdbc_datasource_info;
CREATE TABLE jdbc_datasource_info (
id bigint(20) PRIMARY KEY auto_increment comment '物理主键',
config_name varchar(64) NOT NULL comment '配置名称',
config_status varchar(2) NOT NULL comment '配置状态(Y:启动;N:禁用)',
config_remark varchar(512) NULL comment '配置备注',
jdbc_driver VARCHAR(100) NOT NULL comment '驱动信息',
jdbc_username VARCHAR(50) NOT NULL comment '数据源用户',
jdbc_password VARCHAR(256) NOT NULL comment '数据源密码',
jdbc_url VARCHAR(500) NOT NULL comment '链接信息',
database_type VARCHAR(128) NOT NULL comment '数据库类型',
initial_pool_size INT DEFAULT 4 comment '线程池初始化大小',
max_pool_size INT DEFAULT 20 comment '线程池最大大小',
max_wait_time_ms INT DEFAULT 5000 comment '获取连接超时时间(ms)',
idle_timeout_ms INT DEFAULT 60000 comment '空闲连接自动回收时间(ms)',
validation_query VARCHAR(100) comment '验证查询',
create_time datetime comment '创建时间',
update_time datetime comment '更新时间',
create_by VARCHAR(64) comment '创建人',
update_by VARCHAR(64) comment '更新人',
UNIQUE KEY (config_name)
) COMMENT '数据源信息';上一节我们初步定义了相关的数据库表，这一节我们一起来看一下，如何实现对应的表信息管理。
我们针对上述的 4 张表，实现最基础的增删改查功能。
todo...
测试验证功能
SQL 脚本还是使用以前的，将新增的部分拆分出来。
mysqldump -u root -p sql_execute > "D:\db\sql_execute_v20250501.sql"我们如果想设计一个 SQL 指标/规则 系统，应该有哪些核心能力？
一些系统级别的常量+枚举
相关应用管理
人工维护数据源
前期不失为一种过渡方案
所有的模板支持自定义
审计日志留痕
方便查问题+找出变更记录
报警就是报警
我们可以考虑设计一套 SQL 指标。
不过SQL指标个人感觉设计的比较好的就是类似于 grafana 这种，可以内置支持常见的数据源最好。
grafana stack grafana-01-The open and composable observability and data visualization platform.
在单机时代，我们如果想实现一个调度系统，那么并不难。
但是在分布式服务的今天，如何实现一个分布式调度的服务呢？