请分享你参与的一个高并发项目（如360手机卫士的推送服务），描述其技术选型、遇到的挑战（如延迟、资源瓶颈）以及解决方案。

1) 【一句话结论】在360手机卫士推送服务中，通过采用消息队列（Kafka）解耦请求与处理、异步任务队列（Redis+Go Worker）降低延迟、资源隔离（进程级CPU亲和性+线程池）保障稳定性，成功解决了百万级用户下的推送延迟（平均<100ms）和资源瓶颈（CPU利用率<70%），支撑高并发场景。

2) 【原理/概念讲解】老师会解释高并发推送的核心挑战是“请求洪峰”导致服务器阻塞，需通过“解耦+异步+资源隔离”解决：

• 消息队列（如Kafka）的作用：像“缓冲区”，将突发请求暂存，避免服务器直接处理导致过载，类比“交通疏导站”，把车流（请求）分批处理，避免堵死。
• 异步处理模型：推送逻辑拆分为“请求接收-消息投递-推送执行”三步，前两步快速完成（客户端立即返回），第三步异步执行，降低客户端感知延迟。
• 资源隔离：为不同优先级推送分配独立进程（如紧急通知用高优先级进程），每个进程固定占用CPU核心，避免资源争抢导致CPU利用率飙升。

3) 【对比与适用场景】

特性	同步处理模式	异步处理模式
定义	请求发送后，客户端等待服务器返回结果	请求发送后，客户端立即返回，服务器后续处理
延迟	较高（需等待推送完成）	较低（客户端快速返回）
适用场景	请求量小、对延迟敏感低（如查询类）	请求量大、对延迟敏感高（如推送、通知）
注意点	需要服务器处理能力足够，否则易阻塞	需要消息队列和消费者保障可靠性

4) 【示例】

// 推送服务核心流程（伪代码）
func PushNotification(userID, msg string) error {
    // 1. 将推送请求放入消息队列（Kafka）
    err := kafkaProducer.SendMessage(fmt.Sprintf("user_%d", userID), msg)
    if err != nil {
        return fmt.Errorf("failed to send to kafka: %v", err)
    }
    // 2. 返回成功（异步处理，客户端无需等待）
    return nil
}

// 消费者处理逻辑（Go Worker）
func KafkaConsumer() {
    consumer := kafkaConsumer.NewConsumer()
    for msg := range consumer.Messages() {
        userID, content := parseMessage(msg)
        // 异步推送（通过Go Worker池并行处理）
        go sendPushAsync(userID, content)
    }
}

// 异步推送函数
func sendPushAsync(userID, content string) {
    err := pushService.SendPush(userID, content)
    if err != nil {
        log.Errorf("push failed for user %s: %v", userID, err)
    }
}

5) 【面试口播版答案】
面试官您好，我参与过360手机卫士的推送服务项目，核心是解决百万级用户的高并发推送问题。首先，我们采用消息队列（Kafka）作为请求缓冲，把突发请求暂存，避免服务器直接处理导致阻塞。然后，推送逻辑分为两步：第一步快速将请求投递到消息队列，客户端立即返回成功；第二步由消费者异步处理，通过Go Worker池并行推送，这样延迟控制在100ms以内。另外，为了解决资源瓶颈，我们给不同优先级的推送分配独立进程，比如紧急通知用高优先级进程，每个进程固定占用2个CPU核心，这样CPU利用率稳定在70%以下，不会因为资源争抢导致延迟飙升。通过这些设计，我们成功支撑了百万级用户的推送需求，平均延迟低于100ms，资源利用率合理。

6) 【追问清单】

• 问题1：消息队列选型为什么选Kafka而不是RabbitMQ？
  回答要点：因为推送服务需要高吞吐和持久化，Kafka更适合大规模数据流。
• 问题2：如何保证消息不丢失？
  回答要点：通过消息持久化（Kafka的日志存储）和消费者确认机制（acks参数设置）。
• 问题3：如果消费者处理失败，如何恢复？
  回答要点：设置重试机制（如指数退避）和死信队列（处理无法恢复的消息）。
• 问题4：如何监控推送服务的延迟和资源？
  回答要点：使用Prometheus监控延迟指标（如latency_p95），使用Grafana可视化CPU/内存使用率。
• 问题5：如果推送API（如APNs）临时不可用，如何处理？
  回答要点：通过重试机制（如指数退避）和降级策略（暂时不推送，后续重试）。

7) 【常见坑/雷区】

• 忽略消息队列的积压问题：消息队列积压过多会导致消费者处理不过来，进而影响延迟和资源。
• 未考虑资源隔离：所有推送逻辑在一个进程中会导致CPU争抢，推送量增大时CPU利用率飙升。
• 延迟优化不足：只关注吞吐量，而忽略客户端感知的延迟（如推送延迟超过500ms会影响体验）。
• 消息丢失处理不当：未设置消息持久化和确认机制，可能导致部分推送失败。
• 未考虑容灾：消息队列宕机时，未设计备份方案导致请求丢失。