許多開發者好奇騰訊 QQ 這樣擁有上億用戶、極高並發訪問的即時通訊系統,其用戶信息究竟存儲在什麼數據庫中?表結構如何設計?部署架構是怎樣的?
按用戶 ID(UIN)哈希取模分片,將用戶基礎信息(暱稱、頭像、狀態等)分散到數千張表、數百個數據庫實例中。單表數據量控制在千萬級以內。
-- 用戶基礎信息表(分片表示例)
CREATE TABLE `user_profile_0001` (
`uin` BIGINT UNSIGNED NOT NULL PRIMARY KEY COMMENT '用戶唯一標識',
`nick_name` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '暱稱',
`face_id` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '頭像ID',
`gender` TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '性別 0未知 1男 2女',
`birthday` DATE NULL COMMENT '生日',
`reg_time` DATETIME NOT NULL COMMENT '註冊時間',
`last_login` DATETIME NOT NULL COMMENT '最後登錄時間',
`status` TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '帳號狀態',
`ext_data` BLOB NULL COMMENT '擴展字段(JSON序列化)',
INDEX `idx_last_login` (`last_login`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
| 挑戰 | 解決方案 |
|---|---|
| 億級用戶寫入壓力 | 寫入請求先入消息隊列(Kafka),異步批量落庫 |
| 熱點用戶讀放大 | 多級緩存 + 一致性哈希路由 + 緩存預熱 |
| Schema 變更 | Online DDL 工具(如 gh-ost)無鎖變更 + 版本兼容 |
| 跨分片事務 | 避免分布式事務,採用最終一致性補償機制 |
QQ 用戶信息存儲並非單一數據庫,而是一套經過大規模實戰驗證的分佈式存儲體系。核心思想:分片解決容量、緩存解決性能、中間件解決路由、異步解決寫入壓力。對於中小項目,可參考其分層思想,根據業務量級選擇適合的技術棧。