系统设计实战 177：177. 设计来电显示系统（Truecaller）

🚀 系统设计实战 177：177. 设计来电显示系统（Truecaller）

摘要：本文深入剖析系统的核心架构、关键算法和工程实践，提供完整的设计方案和面试要点。

你是否想过，设计来电显示系统背后的技术挑战有多复杂？

系统概述

设计一个智能来电显示系统，支持号码数据库、实时查询、用户贡献、垃圾电话识别和隐私保护，为用户提供准确的来电信息和骚扰电话拦截服务。

核心功能需求

基础功能

• 来电号码识别
• 垃圾电话检测
• 用户数据贡献
• 实时查询服务
• 隐私保护机制

高级功能

• 智能分类算法
• 社区举报系统
• 个性化拦截规则
• 企业号码验证
• 跨平台同步

系统架构

整体架构

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   移动客户端     │    │   API 网关      │    │   核心服务层     │
│                │    │                │    │                │
│ • Android App   │◄──►│ • 认证鉴权      │◄──►│ • 号码查询服务   │
│ • iOS App       │    │ • 限流控制      │    │ • 垃圾识别服务   │
│ • Web 端        │    │ • 请求路由      │    │ • 用户管理服务   │
└─────────────────┘    └─────────────────┘    │ • 数据收集服务   │
                                             └─────────────────┘
                              │
                              ▼
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   数据处理层     │    │   机器学习层     │    │   数据存储层     │
│                │    │                │    │                │
│ • 数据清洗      │◄──►│ • 分类模型      │◄──►│ • 号码数据库     │
│ • 数据验证      │    │ • 异常检测      │    │ • 用户数据库     │
│ • 数据聚合      │    │ • 推荐算法      │    │ • 举报数据库     │
└─────────────────┘    └─────────────────┘    └─────────────────┘

数据库设计

号码信息表 (phone_numbers)

CREATE TABLE phone_numbers (
    phone_id BIGINT PRIMARY KEY,
    phone_number VARCHAR(20) UNIQUE NOT NULL,
    country_code VARCHAR(5),
    number_type ENUM('mobile', 'landline', 'toll_free', 'premium'),
    owner_name VARCHAR(200),
    organization VARCHAR(300),
    category ENUM('personal', 'business', 'spam', 'scam', 'telemarketing'),
    confidence_score DECIMAL(3,2) DEFAULT 0.5,
    verification_status ENUM('unverified', 'user_verified', 'official_verified'),
    spam_score DECIMAL(3,2) DEFAULT 0.0,
    report_count INT DEFAULT 0,
    last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

用户举报表 (spam_reports)

CREATE TABLE spam_reports (
    report_id BIGINT PRIMARY KEY,
    reporter_user_id BIGINT NOT NULL,
    phone_number VARCHAR(20) NOT NULL,
    report_type ENUM('spam', 'scam', 'telemarketing', 'harassment', 'wrong_number'),
    description TEXT,
    call_time DATETIME,
    report_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    is_verified BOOLEAN DEFAULT FALSE,
    FOREIGN KEY (reporter_user_id) REFERENCES users(user_id)
);

核心服务设计

1. 号码查询服务

// 时间复杂度：O(N)，空间复杂度：O(1)

class PhoneNumberLookupService:
    def __init__(self):
        self.db = DatabaseConnection()
        self.cache = RedisCache()
        self.ml_classifier = SpamClassifier()
    
    def lookup_number(self, phone_number, user_id=None):
        """查询号码信息"""
        # 标准化号码格式
        normalized_number = self.normalize_phone_number(phone_number)
        
        # 检查缓存
        cache_key = f"phone_lookup:{normalized_number}"
        cached_result = self.cache.get(cache_key)
        if cached_result:
            return json.loads(cached_result)
        
        # 数据库查询
        phone_info = self.db.query_one("""
            SELECT * FROM phone_numbers 
            WHERE phone_number = %s
        """, [normalized_number])
        
        if not phone_info:
            # 使用ML模型预测
            prediction = self.ml_classifier.predict_spam_probability(normalized_number)
            phone_info = {
                'phone_number': normalized_number,
                'category': 'unknown',
                'spam_score': prediction['spam_probability'],
                'confidence_score': prediction['confidence']
            }
        
        # 缓存结果
        self.cache.set(cache_key, json.dumps(phone_info), ex=3600)
        
        return phone_info

这个来电显示系统设计提供了完整的号码识别、垃圾检测和用户贡献功能。

---

🎯 场景引入

你打开App，

你打开手机准备使用设计来电显示系统服务。看似简单的操作背后，系统面临三大核心挑战：

• 挑战一：高并发——如何在百万级 QPS 下保持低延迟？
• 挑战二：高可用——如何在节点故障时保证服务不中断？
• 挑战三：数据一致性——如何在分布式环境下保证数据正确？

---

📈 容量估算

假设 DAU 1000 万，人均日请求 50 次

指标	数值
数据总量	10 TB+
日写入量	~100 GB
写入 TPS	~5 万/秒
读取 QPS	~20 万/秒
P99 读延迟	< 10ms
节点数	10-50
副本因子	3

---

❓ 高频面试问题

Q1：来电显示系统的核心设计原则是什么？

参考正文中的架构设计部分，核心原则包括：高可用（故障自动恢复）、高性能（低延迟高吞吐）、可扩展（水平扩展能力）、一致性（数据正确性保证）。面试时需结合具体场景展开。

Q2：来电显示系统在大规模场景下的主要挑战是什么？

1. 性能瓶颈：随着数据量和请求量增长，单节点无法承载；2) 一致性：分布式环境下的数据一致性保证；3) 故障恢复：节点故障时的自动切换和数据恢复；4) 运维复杂度：集群管理、监控、升级。

Q3：如何保证来电显示系统的高可用？

1. 多副本冗余（至少 3 副本）；2) 自动故障检测和切换（心跳 + 选主）；3) 数据持久化和备份；4) 限流降级（防止雪崩）；5) 多机房/多活部署。

Q4：来电显示系统的性能优化有哪些关键手段？

1. 缓存（减少重复计算和 IO）；2) 异步处理（非关键路径异步化）；3) 批量操作（减少网络往返）；4) 数据分片（并行处理）；5) 连接池复用。

Q5：来电显示系统与同类方案相比有什么优劣势？

参考方案对比表格。选型时需考虑：团队技术栈、数据规模、延迟要求、一致性需求、运维成本。没有银弹，需根据业务场景权衡取舍。

---

---

| 方案一 | 简单实现 | 低 | 适合小规模 | | 方案二 | 中等复杂度 | 中 | 适合中等规模 | | 方案三 | 高复杂度 ⭐推荐 | 高 | 适合大规模生产环境 |

🚀 架构演进路径

阶段一：单机版 MVP（用户量 < 10 万）

• 单体应用 + 单机数据库
• 功能验证优先，快速迭代
• 适用场景：产品早期验证

阶段二：基础版分布式（用户量 10 万 - 100 万）

• 应用层水平扩展（无状态服务 + 负载均衡）
• 数据库主从分离（读写分离）
• 引入 Redis 缓存热点数据
• 适用场景：业务增长期

阶段三：生产级高可用（用户量 > 100 万）

• 微服务拆分，独立部署和扩缩容
• 数据库分库分表（按业务维度分片）
• 引入消息队列解耦异步流程
• 多机房部署，异地容灾
• 全链路监控 + 自动化运维

---

✅ 架构设计检查清单

检查项	状态	说明
高可用	✅	多副本部署，自动故障转移，99.9% SLA
可扩展	✅	无状态服务水平扩展，数据层分片
数据一致性	✅	核心路径强一致，非核心最终一致
安全防护	✅	认证授权 + 加密 + 审计日志
监控告警	✅	Metrics + Logging + Tracing 三支柱
容灾备份	✅	多机房部署，定期备份，RPO < 1 分钟
性能优化	✅	多级缓存 + 异步处理 + 连接池
灰度发布	✅	支持按用户/地域灰度，快速回滚

---

⚖️ 关键 Trade-off 分析

🔴 Trade-off 1：一致性 vs 可用性

• 强一致（CP）：适用于金融交易等不能出错的场景
• 高可用（AP）：适用于社交动态等允许短暂不一致的场景
• 本系统选择：核心路径强一致，非核心路径最终一致

🔴 Trade-off 2：同步 vs 异步

• 同步处理：延迟低但吞吐受限，适用于核心交互路径
• 异步处理：吞吐高但增加延迟，适用于后台计算
• 本系统选择：核心路径同步，非核心路径异步