Initial commit: System Design documentation site

- Docusaurus v3 site with Chinese architecture design content
- GitHub Pages deployment configuration
- Custom domain: sd.winterio.com.cn

Co-Authored-By: Claude <noreply@anthropic.com>

Author: trend-winter-wang

.github/workflows/deploy.yml

@@ -0,0 +1,41 @@
+name: Deploy to GitHub Pages
+
+on:
+  push:
+    branches:
+      - main
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: npm
+      - run: npm ci
+      - run: npm run build
+      - uses: actions/upload-pages-artifact@v3
+        with:
+          path: build
+
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - uses: actions/deploy-pages@v4
+        id: deployment

.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

README.md

@@ -0,0 +1,41 @@
+# Website
+
+This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
+
+## Installation
+
+```bash
+yarn
+```
+
+## Local Development
+
+```bash
+yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+## Build
+
+```bash
+yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+## Deployment
+
+Using SSH:
+
+```bash
+USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```bash
+GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

docs/caching/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "缓存层场景实战",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "主要讲解大流量时，如何避免流量直接压垮数据库层。学完这部分内容后，当遇到缓存层场景问题，就知道如何进行架构设计了。"
+  }
+}

docs/caching/data-collection.md

@@ -0,0 +1,189 @@
+---
+sidebar_position: 3
+title: 第6章 数据收集
+description: 日亿万级请求日志收集架构设计，解决长期高频插入数据的问题
+keywords: [数据收集, Kafka, Flink, Logstash, 日志采集, 实时计算, Elasticsearch, HBase]
+---
+
+# 第6章 数据收集
+
+上一章详细讨论了写缓存的架构解决方案，它虽然可以减少数据库写操作的压力，但也存在一些不足。比如**需要长期高频插入数据**时，这个方案就无法满足，接下来将围绕这个问题逐步提出解决方案。
+
+![数据收集概念](/img/chapter6/01_data_collection_concept.png)
+
+## 6.1 业务背景：日亿万级请求日志收集如何不影响主业务
+
+因业务快速发展，某天某公司的日活用户高达 **500万**，基于当时的业务模式，业务侧要求根据用户的行为做埋点，旨在记录用户在特定页面的所有行为，以便开展数据分析，以及与第三方进行费用结算。
+
+### 业务需求
+
+在数据埋点的过程中，业务侧还要求在后台能**准实时**查询用户行为数据及统计报表。
+
+需收集的原始数据结构：
+
+| 字段 | 说明 |
+|------|------|
+| 用户ID | 用户唯一标识 |
+| 时间戳 | 事件发生时间 |
+| 经纬度 | 用户位置信息 |
+| 目标类型 | 页面/按钮/链接等 |
+| 目标ID | 具体目标标识 |
+| 事件动作 | 点击/浏览/滑动等 |
+
+通过以上数据结构，业务侧可以：
+- 将城市、性别、年龄、目标类型、目标ID、事件动作等作为查询条件
+- 从时间、性别、年龄等维度查看统计报表
+
+## 6.2 技术选型思路
+
+根据业务场景，项目组提炼出了 6 点业务需求：
+
+| 业务需求 | 技术选型思路 |
+|----------|--------------|
+| 原始数据海量 | 使用 HBase 进行持久化 |
+| 埋点记录请求响应要快 | 存放到缓存层（本地日志） |
+| 可通过后台查询原始数据 | 使用 Elasticsearch 保存查询条件字段 |
+| 各种统计报表需求 | 自己设计功能（灵活性高） |
+| 根据埋点日志生成费用结算数据 | 保存在 MySQL 中 |
+| 需要处理框架将数据迁移到持久化层 | 实时处理工具（Flink） |
+
+![日志存储](/img/chapter6/02_log_storage.png)
+
+### 6.2.1 使用什么技术保存埋点数据的第一现场
+
+目前快速保存埋点数据的技术主要分为 3 种：
+
+| 技术 | 优点 | 缺点 |
+|------|------|------|
+| Redis | 读写快 | 需要配置持久化，响应要求高时性能受影响 |
+| Kafka | 吞吐量大 | 需要等待数据同步，响应可能变慢 |
+| **本地日志** | 响应最快 | 需要额外收集 |
+
+**Redis 的 AOF 机制分析**：
+- `appendfsync=everysec`：每秒落盘一次，可能丢失一秒数据
+- `appendfsync=always`：每次操作落盘后返回，系统运行会很慢
+
+**Kafka 的 acks 配置分析**：
+- `acks=0`：不等落盘直接返回，响应快但数据无保障
+- `acks=1`：等 Leader 落盘，不等 Follower 同步
+- `acks=all`：等所有副本同步，数据有保障但响应慢
+
+最终决定把埋点数据保存到**本地日志**中——性能和可靠性兼得。
+
+### 6.2.2 使用什么技术收集日志数据到持久化层
+
+最简单的方式是通过 Logstash 直接把日志文件迁移到 Elasticsearch，但会有问题：
+
+- Elasticsearch 需要包含城市、性别、年龄等业务数据
+- 这些数据日志文件中没有，需要调用业务系统获取
+
+不直接使用 Logstash 到持久化层的原因：
+
+1. 需要同时输出到 Elasticsearch 和 HBase 两个源，一个出错会影响另一个
+2. MySQL 中需要动态计算费用结算数据，Logstash 不适用
+
+**最终方案**：引入计算框架
+- 通过 Logstash 把日志文件迁移到 MQ
+- 通过实时计算框架处理 MQ 中的数据
+- 保存处理后的数据到持久层
+
+:::tip 提示
+Logstash 资源消耗大（Ruby 语言编写），官方推出了轻量化的 Filebeat。但 Filebeat 使用轮询方式采集，存在一定延时，所以该项目最终选择继续使用 Logstash。
+:::
+
+### 6.2.3 为什么使用 Kafka
+
+![Kafka结构](/img/chapter6/03_kafka_structure.png)
+
+Kafka 是 LinkedIn 推出的开源消息中间件，它天生是为收集日志而设计的，具备：
+- **超高吞吐量**：3台便宜的机器每秒写入两百万条记录
+- **数据量扩展性**：被称作无限堆积
+
+**Kafka 为什么吞吐量这么高？**
+
+Kafka 的存储结构：
+- 每个 Topic 分区相当于一个巨型文件
+- 每个巨型文件由多个 Segment 小文件组成
+- Producer 负责对该巨型文件进行"**顺序写**"
+- Consumer 负责对该文件进行"**顺序读**"
+
+**好处**：读操作不会阻塞写操作，这也是其吞吐量大的原因。
+
+### 6.2.4 使用什么技术把 Kafka 的数据迁移到持久化层
+
+需要使用一个**分布式实时计算框架**，原因有两点：
+1. 数据量特别大，需要多个节点并发处理
+2. 业务要求实时查询统计报表数据
+
+![Flink特性](/img/chapter6/04_flink_features.png)
+
+目前流行的分布式实时计算框架：
+
+| 框架 | 特点 |
+|------|------|
+| Storm | 最早的流处理框架 |
+| Spark Streaming | 微批处理 |
+| **Apache Flink** | 性能强、容错好、时间窗口支持 |
+
+**选择 Apache Flink 的原因**：
+
+1. **性能强**：阿里活动期间一秒内能够处理 17 亿条数据
+2. **容错机制**：能保证每条数据仅仅处理一次（Exactly-Once）
+3. **时间窗口**：基于消息的事件时间，而不是处理时间
+
+#### 流处理的容错机制
+
+| 容错级别 | 说明 |
+|----------|------|
+| At-Most-Once | 至多一次，可能丢失数据 |
+| **Exactly-Once** | 精确一次，最优选择 |
+| At-Least-Once | 至少一次，可能重复消费 |
+
+#### 时间窗口计算
+
+日志中事件发生的时间可能与计算框架处理消息的时间不一致。
+
+**示例**：一条消息事件时间是 6:30，处理时间延后 2 秒变成 6:32
+- 如果按处理时间统计 6:01~6:30 的数据，这条消息不会被计算在内
+- Apache Flink 使用**事件时间**，确保统计准确
+
+## 6.3 整体方案
+
+![整体方案总结](/img/chapter6/05_summary.png)
+
+整个架构的流程如下：
+
+1. **后台服务端**记录所有的请求数据，存放到本地的日志文件
+2. 使用数据收集框架 **Logstash**，从日志文件抽取原始的日志数据，不加工直接存放到 Kafka
+3. 通过 **Apache Flink** 从 Kafka 中拉取原始的日志数据，并且经过业务加工
+4. 分别存放到 **Elasticsearch**、**HBase** 和 **MySQL** 中
+
+各存储的用途：
+
+| 存储 | 用途 |
+|------|------|
+| Elasticsearch | 处理用户针对请求日志的查询请求，存放查询关键字段和请求ID |
+| HBase | 存放详细的请求数据 |
+| MySQL | 存放组合加工后的结算数据 |
+
+**查询流程**：
+1. 根据查询关键字在 Elasticsearch 中获得结果 ID 列表
+2. 通过结果 ID 去 HBase 中获取详细的请求数据
+
+## 6.4 小结
+
+本章并没有讲解特别深入的架构设计方面的注意事项，而是主要阐述**技术选型背后的思考过程**。
+
+学架构的过程就是经历一些基础的场景，而那些复杂的场景其实是简单场景的叠加复用。
+
+**方案落地后的效果**：
+- 丢数据的情况并不多
+- 架构的扩展性很好
+- 之后日活达到了几千万，系统仍然可以使用（需多加机器，定时清理旧数据）
+
+### 写缓存解决的问题回顾
+
+| 问题 | 解决章节 |
+|------|----------|
+| 长期高并发写数据 | 本章已解决 |
+| 高并发且请求需要抢资源 | [秒杀架构](./seckill-architecture.md) |