AIGC标识 System Design - BlackList

System Design - BlackList

CREATED 2022/01/25

UPDATED 2026/07/22

Problem Statement

设计一个 Blacklist Service，供多个业务系统查询某个对象是否在黑名单中。

黑名单对象可能包括：

  • User ID
  • Email
  • Phone Number
  • IP Address
  • Device ID
  • Credit Card Hash

业务系统会在请求过程中调用 Blacklist Service：

if (BlacklistService.isBlocked(userId)) {
    rejectRequest();
}

要求系统能够支持海量查询，并保证低延迟。

Functional Requirements

Core APIs

1. 判断对象是否在黑名单

isBlocked(key)

返回：

true / false

2. 添加黑名单

add(key)

3. 删除黑名单

remove(key)

4. 查询黑名单详情

GET /blacklist/{key}

返回：

  • Key
  • Type
  • Status
  • Created Time
  • Created By
  • Reason
  • Expire Time (TTL)

5. 支持 TTL

例如：

封禁 24 小时

TTL 到期后自动解除封禁。

Non-functional Requirements

Requirement Target
Read QPS 100K/s
Write QPS 500/s
Read Latency P99 < 10ms（最好 <5ms）
Availability 99.99%
Scalability Horizontal Scaling
Durability Persistent Storage

Clarification Questions

面试开始时建议先问：

  1. Blacklist 是否需要永久保存？
  2. 是否支持 TTL？
  3. 更新是否要求实时生效？
  4. 是否需要保存 Audit Log？
  5. 是否支持批量导入？
  6. 是否支持 Prefix / Wildcard（如 IP Range、Email Domain）？

Capacity Estimation

假设：

  • 100M Blacklist Entries
  • 每条数据约 200 Bytes
100M × 200B
≈ 20GB

完全可以存储。

若 Redis 全量缓存：

20GB

Redis Cluster 即可支持。

API Design

Check

GET /check?key=abc

Response

{
    "blocked": true
}

Add

POST /blacklist

Request

{
    "key":"abc",
    "reason":"fraud",
    "ttl":"24h"
}

Delete

DELETE /blacklist/abc

Get Metadata

GET /blacklist/abc

High-Level Design

                +----------------------+
                |     Client Service   |
                +----------+-----------+
                           |
                    Load Balancer
                           |
                +----------+-----------+
                |   Blacklist API      |
                +----------+-----------+
                           |
          +----------------+----------------+
          |                                 |
     Redis Cluster                  Metadata Database
          |                                 |
          +----------------+----------------+
                           |
                         Kafka
                           |
                Cache Invalidation

Data Model

BlacklistEntry

- key
- type
- status
- reason
- createdBy
- createdTime
- expireTime

Database Design

Redis

存储：

Key -> blocked

或者：

Key -> Metadata

优点：

  • O(1) 查询
  • 支持 TTL
  • 超低延迟

缺点：

  • 内存成本较高

Persistent Storage

可以选择：

  • MySQL
  • PostgreSQL
  • Cassandra
  • DynamoDB

主要保存：

  • Metadata
  • Audit Log
  • History

Read Flow

Client
    |
    v
API Server
    |
    v
Redis
    |
    +------ Hit ------> Return
    |
    +------ Miss -----+
                      |
                      v
                     DB
                      |
                 Populate Cache
                      |
                      v
                   Return

Write Flow

Admin
    |
    v
API
    |
    v
Database
    |
    +------ Update Redis
    |
    +------ Publish Kafka Event

其他实例收到 Kafka 消息后：

Invalidate Local Cache

Cache Strategy

Cache Aside（推荐）

Read:

Cache

↓

Miss

↓

Database

↓

Update Cache

优点：

  • 简单
  • 最常见

Write Through

Write DB

↓

Write Cache

适用于要求更新立即生效。

Write Behind

通常不建议。

存在数据丢失风险。

TTL

Redis：

SETEX

自动过期。

数据库：

保存：

expire_time

后台定时任务：

DELETE

或者：

status = expired

Partitioning

根据：

hash(key)

进行分片。

例如：

Shard1

Shard2

Shard3

Shard4

Redis Cluster 天然支持。

Scaling

API：

  • Stateless
  • Horizontal Scaling

Redis：

  • Redis Cluster

Database：

  • Sharding
  • Read Replica

Kafka：

  • Multiple Partitions

Failure Handling

Redis Down

Read DB

性能下降但服务仍可用。

Database Down

Read Cache

允许短时间最终一致。

Kafka Down

  • Retry
  • Dead Letter Queue (DLQ)

Security

管理员接口：

  • Authentication
  • Authorization (RBAC)

所有操作记录：

Audit Log

例如：

  • Add
  • Delete
  • Update

不可删除。

Monitoring

监控指标：

  • Read QPS
  • Write QPS
  • Cache Hit Rate
  • Redis Latency
  • DB Latency
  • Error Rate
  • Kafka Lag

Bottlenecks

可能瓶颈：

Redis Hot Key

解决：

  • Local Cache
  • Redis Cluster
  • Key Replication

Cache Penetration

解决：

  • Negative Cache
  • Bloom Filter

Cache Breakdown

解决：

  • Mutex Lock
  • Request Coalescing

Cache Avalanche

解决：

  • Random TTL
  • Multi-level Cache

Follow-up Questions

1. 如何支持 Prefix Blacklist？

例如：

*@spam.com

可以使用：

  • Trie
  • Prefix Tree

2. 如何支持 IP Range？

例如：

192.168.0.0/16

可以使用：

  • CIDR Tree
  • Radix Tree

3. 如何保证更新 1 秒内生效？

方案：

  • Write Through Cache
  • Kafka Event
  • Redis Pub/Sub
  • CDC

4. 如何支持千万级 QPS？

优化：

  • Local Cache (Caffeine)
  • Redis
  • Bloom Filter
  • Multi-region Deployment

5. Redis 是否可以作为唯一存储？

一般不建议。

原因：

  • Redis 可能丢数据
  • Metadata 查询困难
  • Audit Log 无法保存

通常采用：

Redis
        +
Persistent Database

Final Architecture

                 Clients
                    |
             Load Balancer
                    |
            Stateless API Layer
                    |
          +---------+----------+
          |                    |
      Local Cache         Redis Cluster
          |                    |
          +---------+----------+
                    |
             Persistent DB
                    |
                 Kafka
                    |
         Cache Invalidation

Interview Evaluation Points

Category What Interviewer Looks For
Requirement Clarification 是否主动确认需求和边界
API Design API 是否合理、幂等、可扩展
Data Model 是否包含 TTL、Metadata、Audit
Storage Redis + Persistent DB 的设计
Cache Cache Aside、TTL、失效策略
Scalability 分片、水平扩展、热点 Key
Consistency 强一致 vs 最终一致
Reliability Failover、Retry、DLQ
Optimization Bloom Filter、多级缓存、本地缓存

Key Takeaways

  • Read-heavy 系统（100K+ Read QPS）
  • Redis 作为主查询层，提供 O(1) 查询和 TTL 支持
  • Persistent Database 保存 Metadata 与 Audit Log
  • Kafka 用于缓存失效通知和事件传播
  • Hash Sharding 实现水平扩展
  • Bloom Filter + Local Cache + Redis 支撑超高 QPS
  • Cache Aside 是最经典且最常见的缓存策略
posted @ 2022-01-26 13:44  YBgnAW  阅读(55)  评论(0)    收藏  举报