Architectural Breakdown: I Tried to Beat Peter Norvig and Accidentally Became Ryan Gosling

查看原文 / View Original 编辑 / Edit

Architectural Breakdown: I Tried to Beat Peter Norvig and Accidentally Became Ryan Gosling

架构解析：我试图挑战 Peter Norvig，却意外成了 Ryan Gosling

I Tried to Beat Peter Norvig and Accidentally Became Ryan Gosling: Scaling a Meme to 10K RPS on 8GB RAM. The internet moves fast. One moment you are a nobody with a cheese bread recipe, the next, Ryan Gosling’s Twitter fingers have turned your side project into a distributed systems stress test. This is how we survived 10,000 requests per second on 8GB RAM with bounded queues, race condition free SQLite, and a healthy fear of thread explosion. 我试图挑战 Peter Norvig，却意外成了 Ryan Gosling：在 8GB 内存上将一个模因（Meme）项目扩展至每秒 1 万次请求（RPS）。互联网的发展瞬息万变。前一刻你还是个只有奶酪面包食谱的无名小卒，下一刻，Ryan Gosling 的推特手指就将你的副业项目变成了一场分布式系统压力测试。本文将介绍我们如何通过有界队列、无竞态条件的 SQLite 以及对线程爆炸的敬畏，在 8GB 内存下扛住了每秒 1 万次请求。

The Gosling Effect: When Your Side Project Goes Supernova

Gosling 效应：当你的副业项目爆发时

The initial setup was simple: static files on Netlify, a Flask endpoint on Heroku for analytics. Traffic was a trickle. Then Gosling tweeted. 最初的架构很简单：Netlify 上的静态文件，以及 Heroku 上用于分析的 Flask 端点。流量原本微乎其微，直到 Gosling 发了那条推文。

Failure Walkthrough: The Threaded Flask Bottleneck

故障复盘：Flask 线程模式的瓶颈

Gosling tweets link → 50K concurrent users hit /track. Flask’s default Threaded mode spawns a new thread per request. Heroku dyno (512MB RAM) exhausts memory under thread explosion. Process OOM killed, restarts, crashes again. Static site remains up, mocking the backend’s fragility. Root Cause: Thread per request + unbounded memory growth. Solution: Async I/O + bounded resources. No magic, just constraints. Gosling 推送链接 → 5 万并发用户访问 /track。Flask 默认的线程模式会为每个请求创建一个新线程。Heroku dyno（512MB 内存）在线程爆炸下耗尽了内存。进程被 OOM（内存溢出）杀掉，重启，然后再次崩溃。静态站点依然在线，嘲笑着后端的脆弱。根本原因：每个请求一个线程 + 无限制的内存增长。解决方案：异步 I/O + 有界资源。没有魔法，只有约束。

Backend Architecture: AsyncIO + SQLite WAL Mode + Bounded Queues

后端架构：AsyncIO + SQLite WAL 模式 + 有界队列

SQLite can handle concurrency if you cap connections and avoid stupidity. Here is the server, stripped of fluff: 只要限制连接数并避免愚蠢的操作，SQLite 完全可以处理并发。以下是精简后的服务器代码：

import asyncio
import sqlite3
from collections import deque
import json

# HARD CONSTRAINTS
MAX_CONNECTIONS = 200 # No more, no less. 8GB RAM is not infinite.
DB_TIMEOUT = 5 # Fail fast if SQLite is locked.
WAL_CHECKPOINT = 1000 # Auto checkpoint WAL to avoid disk bloat.

# CONNECTION POOL (NO LEAKS)
class ConnectionPool:
    def __init__(self):
        self._pool = deque(maxlen=MAX_CONNECTIONS)
        self._lock = asyncio.Lock()

    async def get(self):
        async with self._lock:
            if self._pool:
                return self._pool.popleft()
            conn = sqlite3.connect("analytics.db", timeout=DB_TIMEOUT)
            conn.execute("PRAGMA journal_mode=WAL")
            conn.execute("PRAGMA synchronous=NORMAL")
            conn.execute(f"PRAGMA wal_autocheckpoint={WAL_CHECKPOINT}")
            return conn

    def put(self, conn):
        if len(self._pool) < MAX_CONNECTIONS:
            self._pool.append(conn)
        else:
            conn.close() # No mercy for excess.

pool = ConnectionPool()

# REQUEST HANDLER (NO RACE CONDITIONS)
async def handle_track(reader, writer):
    try:
        data = await reader.read(1024)
        recipe = json.loads(data.decode())["recipe"]
        conn = await pool.get()
        try:
            cursor = conn.cursor()
            cursor.execute(
                "INSERT INTO views (recipe, count) VALUES (?, 1) "
                "ON CONFLICT(recipe) DO UPDATE SET count = count + 1",
                (recipe,)
            )
            conn.commit()
        finally:
            pool.put(conn)
        writer.write(b"HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n")
    except Exception as e:
        writer.write(f"HTTP/1.1 500 Error\r\nContent-Length: {len(str(e))}\r\n\r\n{str(e)}".encode())
    finally:
        await writer.drain()
        writer.close()

# SERVER (BOUNDED BACKLOG)
async def run_server(host, port):
    server = await asyncio.start_server(
        handle_track, host, port, backlog=MAX_CONNECTIONS # OS level queue limit.
    )
    async with server:
        await server.serve_forever()

if __name__ == "__main__":
    asyncio.run(run_server("0.0.0.0", 8000))

Why This Works

为什么这样做有效

  • Bounded Connection Pool (MAX_CONNECTIONS=200): SQLite connections are ~10MB each. 200 = ~2GB max. Safe on 8GB. deque + asyncio.Lock ensures thread safety without overhead.
  • WAL Mode + Checkpointing: PRAGMA wal_autocheckpoint prevents WAL files from growing unbounded.
  • Fail Fast Timeouts (DB_TIMEOUT=5): No hanging under lock contention. Failures are explicit.
  • Backlog Bounding (backlog=200): OS rejects excess connections early. No false promises.
  • 有界连接池 (MAX_CONNECTIONS=200)： 每个 SQLite 连接约占用 10MB。200 个连接最大占用约 2GB，在 8GB 内存下很安全。deque + asyncio.Lock 在没有额外开销的情况下确保了线程安全。
  • WAL 模式 + 检查点： PRAGMA wal_autocheckpoint 防止了 WAL 文件无限制增长。
  • 快速失败超时 (DB_TIMEOUT=5)： 在锁竞争下不会挂起，故障反馈明确。
  • 积压队列限制 (backlog=200)： 操作系统会尽早拒绝多余的连接，不做出无法兑现的承诺。

Memory Profiling on 8GB RAM

8GB 内存下的性能分析

Tested on a DigitalOcean 8GB droplet with wrk: 在 DigitalOcean 8GB 云主机上使用 wrk 进行测试：

MetricValue
RPS12,000
RAM Usage180MB (stable)
CPU60% (4 vCPUs)
Errors0 (after 10 mins)

Failure Mode Test: Simulate OOM: Set MAX_CONNECTIONS=10000 → RAM spikes to 6GB → OOM killer terminates process. Fix: Pool cap at 200 keeps RAM under 200MB. No surprises. 故障模式测试： 模拟 OOM：将 MAX_CONNECTIONS 设置为 10000 → 内存飙升至 6GB → OOM Killer 终止进程。修复：将连接池上限设为 200，内存保持在 200MB 以下。没有意外。

Frontend: The Static Site That Saved Us

前端：拯救我们的静态站点

No React. No Vue. Just vanilla JS and sendBeacon() for fire and forget analytics. 没有 React，没有 Vue。只有原生 JS 和用于“即发即忘”分析的 sendBeacon()。

Lessons Learned

经验教训

  • Bound Everything: Queues, connections, retries. The cloud is not infinite.
  • SQLite is Production Ready: WAL mode + connection pooling equals reliability.
  • Static > Dynamic: Offload work to the client. The browser is a free worker.
  • Test Failure Modes: Simulate OOM, disk full, network partitions. Assume the worst.
  • 一切皆需有界： 队列、连接、重试。云资源并非无限。
  • SQLite 已可用于生产： WAL 模式 + 连接池 = 可靠性。
  • 静态优于动态： 将工作卸载给客户端。浏览器是一个免费的劳动力。
  • 测试故障模式： 模拟 OOM、磁盘满、网络分区。永远做最坏的打算。
← 返回新闻列表 / Back to news list