Tech Future主题开发实战：我如何在3周内把API响应时间从1200ms压到230ms

改造后的代码长这样：

async function getUserDevices(userId) {
    // 第一板斧：批量查询
    const [user, statuses] = await Promise.all([
        db.query('SELECT * FROM users WHERE id = ?', [userId]),
        db.query(`
            SELECT ds.* FROM device_status ds
            INNER JOIN (
                SELECT device_id, MAX(created_at) as latest 
                FROM device_status 
                WHERE device_id IN (SELECT device_id FROM user_devices WHERE user_id = ?)
                GROUP BY device_id
            ) latest ON ds.device_id = latest.device_id AND ds.created_at = latest.latest
        `, [userId])
    ]);
    
    // 第二板斧：缓存处理
    const cacheKey = `user:${userId}:devices`;
    const cached = await redis.get(cacheKey);
    if (cached) return JSON.parse(cached);
    
    // 处理数据...
    const result = { /* 组装数据 */ };
    
    // 设置缓存（带5分钟过期）
    await redis.setex(cacheKey, 300, JSON.stringify(result));
    return result;
}

那些让我掉头发的并发问题

你以为解决了数据库查询就完事了？Too young！他们的订单系统有个更隐蔽的坑：并发创建订单时会出现重复扣款。有次半夜三点被报警叫醒，就是因为这个bug导致公司一晚上损失了800多美元。

问题出在这段"经典"代码：

// 检查余额是否充足
function createOrder(userId, amount) {
    const balance = getBalance(userId);
    if (balance < amount) throw new Error('余额不足');
    
    // 扣款和创建订单不是原子操作！
    deductBalance(userId, amount);
    return generateOrder(userId, amount);
}

我是如何解决的

最终方案是用数据库事务+乐观锁，关键改动点：

// 使用事务确保原子性
async function createOrder(userId, amount) {
    const tx = await db.beginTransaction();
    
    try {
        // SELECT...FOR UPDATE 加行锁
        const [user] = await tx.query(
            'SELECT * FROM users WHERE id = ? FOR UPDATE', 
            [userId]
        );
        
        if (user.balance < amount) {
            throw new Error('余额不足');
        }
        
        await tx.query(
            'UPDATE users SET balance = balance - ? WHERE id = ?',
            [amount, userId]
        );
        
        const order = await generateOrder(tx, userId, amount);
        await tx.commit();
        return order;
    } catch (err) {
        await tx.rollback();
        throw err;
    }
}

这个方案虽然性能会受点影响，但相比资金损失的风险，这点性能代价完全可以接受。后来我们还加了分布式锁来应对集群部署的情况，不过那就是另一个故事了...

前端优化的骚操作

你以为后端优化完就结束了？他们的前端代码同样惨不忍睹。首页加载要请求23个接口！其中有个智能灯泡的控制面板，居然用setInterval每500毫秒轮询一次状态。

我的优化策略：

• 接口聚合：用BFF层合并同类接口请求
• WebSocket替代轮询：对于实时性要求高的设备状态
• 智能预加载：根据用户行为预测下一步可能需要的资源

最让我得意的是这个WebSocket连接管理方案：

class DeviceSocket {
    constructor() {
        this.sockets = new Map();
        this.reconnectTimers = new Map();
    }
    
    connect(deviceId) {
        if (this.sockets.has(deviceId)) return;
        
        const ws = new WebSocket(`wss://api.example.com/devices/${deviceId}/stream`);
        
        ws.onmessage = (event) => {
            this.updateDeviceState(JSON.parse(event.data));
        };
        
        ws.onclose = () => {
            this.sockets.delete(deviceId);
            // 指数退避重连
            const delay = Math.min(30, 2 ** this.reconnectCount.get(deviceId) || 1) * 1000;
            this.reconnectTimers.set(deviceId, setTimeout(() => this.connect(deviceId), delay));
        };
        
        this.sockets.set(deviceId, ws);
    }
    
    // 其他方法...
}

这个方案不仅减少了80%的无用请求，还让设备状态更新的延迟从平均1.2秒降到了200毫秒以内。用户最直观的感受就是："灯泡反应变快了！"

监控体系的建设

性能优化最怕什么？优化完不知道效果！原来的监控系统简陋得令人发指，就一个看板显示"系统正常"四个大字...

我给他们搭的监控体系包含：

最有价值的是一套自定义的报警规则：

# Prometheus报警规则示例
groups:
- name: api_alert
  rules:
  - alert: HighAPIResponseTime
    expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[1m])) by (le)) > 0.5
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "API响应时间超过500ms (instance {{ $labels.instance }})"

这套系统上线后，我们成功在用户投诉前就发现了3次潜在故障。CTO看到仪表盘时眼睛都亮了："这才叫专业！"