面试总结

面试介绍总结：百度poi商业化数据清洗平台（架构级别描述）

项目描述 or 项目定位

主要负责地图 商业化POI 数据清洗，平台整体是一个多阶段的数据处理流水线。数据以文件形式在各个处理环节之间流转，每一步都会读取上一步的结果文件进行处理，并生成新的结果文件。整个流程包括数据请求、结构解析、diff判断、策略判重、人工审核以及数据上线等

做了哪些数据库相关的优化

• 性能优化

  • 解决数据量激增需要面临的分库分表问题
    • 从mysql迁移到百度的gaiaDB，增加读写分离
      • 增加只读节点
        • 把大量查询请求从 RW（Read Write）节点分流出去，
        • 让 RW 专注于写事务和少量必须读取最新数据的查询，
        • 从而提升整个集群的吞吐能力

• gaiaDB优势：

  • 通过数据库代理统一管理连接池、读写分离、故障切换、读写分离
  • 无需分库分表
  • 采用存储和计算分离架构，单实例最大数据量超 500TB，存储自动扩容
  • 支持列存索引，实现复杂查询性能相比MySQL提升100倍以上
  • 支持按需扩展、按需付费，综合成本降低50%

• 索引优化

  • explain 判断是否使用索引、索引类型、扫描多少行、连接方式、是否需要排序、是否使用临时表等。
    • type 的常见值

    type	含义	好坏
    const	主键唯一查询	⭐⭐⭐⭐⭐
    eq_ref	主键关联	⭐⭐⭐⭐⭐
    ref	普通索引	⭐⭐⭐⭐
    range	范围查询	⭐⭐⭐
    index	全索引扫描	⭐⭐
    ALL	全表扫描	❌

    • key 使用了那个索引
    • extra
      • use index
      • use where
      • use tempory
      • use filesort

• sql优化

  • 接口响应优化从23s到 300ms的实现
  • sql LIMIT offset, size查询导致的频繁扫表问题

为什么使用 Celery：

1. 每个处理步骤都是耗时操作，Celery可以实现异步执行，避免阻塞主流程
2. 支持多worker并发处理，提高批量数据处理效率
3. 支持分布式扩展，随着数据量增长可以横向扩容worker就可以了
4. 通过redis作为broke任务队列实现削峰填谷，避免系统过载
5. 提供失败重试机制，提高任务执行的稳定性

cpu异常如何排查 golang为例，可能存在的问题

• 存在死循环或者忙等待
• gorontinue的数量太多
• GC过于频繁：大量对象创建导致 GC 压力大
• 锁竞争严重
• 频繁的系统调用
• Channel 阻塞 / select 空转

百度内部微服务的通信方式

• 微服务通信框架是 bRPC, 核心特性和通信机制：
  • 多协议兼容（单端口多协议）：
    • 一个 bRPC Server 可以在同一个端口上同时接收和解析多种协议请求。
    • 主推协议： baidu_std（基于 Protobuf 的二进制标准协议）。
    • 兼容/历史协议： hulu_pbrpc、sofa_pbrpc、public_pbrpc、ubrpc 以及基于 nshead 的各类传统 C/C++ 协议。
    • 工业标准/跨语言协议： gRPC (HTTP/2)、RESTful HTTP/HTTPS、Thrift、Redis/Memcached 协议等。
  • M
    协程调度（bthread）：
    • bRPC 内置了高性能轻量级协程库 bthread。
    • 微服务接收到请求后直接运行在 bthread 上，消除了传统多线程模型中的线程切换开销与锁竞争，能够支撑超高 QPS。
    • 高度并发与 Wait-Free IO： 对同一个 socket/fd 的读写支持完全并发解析与写出，
  • 请求发送采用 wait-free 托付机制，在极高并发下也能保持超低延时
• 微服务之间的寻址与服务发现不依赖 Consul 或 Eureka，而是统一使用 BNS。
• BNS工作流程：
  • 服务提供方（Server）启动时，将自身的机房、IP、PORT 及实例状态注册到 BNS。
  • 服务消费方（Client）在发起通信时，不直接访问 IP，而是传入 BNS 名字（如 group.service.all）。
  • bRPC 内置的 Naming Service 插件会自动从 BNS 拉取最新的实例列表，并在本地进行动态感知与缓存。