如何跟踪API端点调用触发的数值更新及时段统计？

针对你当前仅存储累计调用次数、旧值被覆盖无法统计时间段调用量的问题，给你几个实用的解决思路：

1. 新增调用日志表（最推荐的常规方案） #

直接新增一张api_call_logs表，每次API被调用时，除了更新总次数表，同时往日志表里插入一条带时间戳的记录。后续统计单日/单周调用量时，只需按时间范围查询日志表的行数即可。

示例表结构（以MySQL为例）：

CREATE TABLE api_call_logs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    api_endpoint VARCHAR(255) NOT NULL, -- 可选，记录具体API路径
    caller_enterprise VARCHAR(255), -- 可选，记录调用方企业标识
    call_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

每次API调用时执行插入操作：

INSERT INTO api_call_logs (api_endpoint, caller_enterprise) VALUES ('/your-target-api', '某外部企业');

统计单日调用量的SQL：

SELECT COUNT(*) AS daily_calls FROM api_call_logs WHERE DATE(call_time) = '2024-05-20';

优点：逻辑简单直观，数据追溯性强，可扩展统计多维度数据（如不同调用方的调用量）；缺点：需要修改业务代码，高并发场景下会增加数据库写入压力。

2. 改造原表为历史快照表 #

如果不想新增表，可以把原有的累计次数表改成存储每次更新的快照。每次API调用时，不覆盖旧值，而是插入新行，记录当前累计次数和更新时间。

示例表结构：

CREATE TABLE api_call_history (
    id INT AUTO_INCREMENT PRIMARY KEY,
    total_count INT NOT NULL,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

每次调用时插入新的累计值：

INSERT INTO api_call_history (total_count) SELECT total_count + 1 FROM api_call_history ORDER BY id DESC LIMIT 1;

统计单日调用量时，可通过当天最早和最晚的累计值做差：

SELECT 
    (SELECT total_count FROM api_call_history WHERE DATE(updated_at) = '2024-05-20' ORDER BY id DESC LIMIT 1) -
    (SELECT total_count FROM api_call_history WHERE DATE(updated_at) = '2024-05-20' ORDER BY id ASC LIMIT 1) AS daily_calls;

优点：无需新增表，同时保留累计值和历史变化轨迹；缺点：累计值需通过最新行获取，数据量会随调用次数线性增长。

3. 用数据库触发器自动记录日志 #

如果不想修改业务代码，可以在总次数表上创建触发器，当累计值被更新时，自动往日志表插入记录。

示例MySQL触发器（假设总次数表为api_total_calls，核心字段为total_count）：

-- 先创建日志表
CREATE TABLE api_call_trigger_logs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    old_count INT,
    new_count INT,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 创建触发器
DELIMITER //
CREATE TRIGGER after_api_count_update
AFTER UPDATE ON api_total_calls
FOR EACH ROW
BEGIN
    INSERT INTO api_call_trigger_logs (old_count, new_count) VALUES (OLD.total_count, NEW.total_count);
END //
DELIMITER ;

后续统计时间段调用量时，直接统计该时间段内日志表的行数即可。

优点：无需修改业务代码，对业务逻辑完全透明；缺点：触发器逻辑在数据库层面，排查问题相对麻烦，高并发下可能影响数据库性能。

4. 高并发场景：缓存+异步日志 #

如果API调用量极大，直接写数据库日志会成为性能瓶颈，可以先将调用事件写入Redis队列（比如用LPUSH），然后后台启动异步任务消费队列，批量写入日志表。

示例伪代码：

# API调用时的核心逻辑
def handle_api_request():
    # 用Redis原子更新总次数
    redis_client.incr('api_total_count')
    # 写入异步日志队列
    redis_client.lpush('api_call_log_queue', json.dumps({
        'endpoint': '/your-target-api',
        'call_time': datetime.now().isoformat()
    }))

# 后台异步消费任务
def consume_log_queue():
    while True:
        # 阻塞式获取队列消息
        _, log_data = redis_client.brpop('api_call_log_queue', 0)
        # 可批量收集后再写入数据库，提升性能
        batch_insert_to_db([json.loads(log_data)])

优点：不影响API主流程性能，适配高并发场景；缺点：引入中间件增加架构复杂度，需处理队列消费失败的异常情况。

内容的提问来源于stack exchange，提问作者WeegyGW