Auto-sync: 2026-04-28 16:03

2026-04-28 16:03:03 +08:00
parent f8b421ece6
commit 365caa800a
48 changed files with 1942 additions and 1249 deletions
--- a/wiki/concepts/Aurora-Global.md
+++ b/wiki/concepts/Aurora-Global.md
@@ -0,0 +1,50 @@
+---
+title: "Aurora Global"
+type: concept
+tags:
+  - AWS
+  - Aurora
+  - Database
+  - Disaster Recovery
+  - Multi-Region
+sources:
+  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
+last_updated: 2026-04-23
+---
+
+## Overview
+Aurora Global 是 Amazon Aurora 的跨区域数据库部署方案，允许将一个 Aurora 集群复制到其他 AWS 区域，支持低延迟的全局读取和快速的区域级故障转移。
+
+## Core Features
+- **跨区域复制**：异步复制数据到最多 5 个辅助区域
+- **托管式切换（Managed Switchover）**：支持干净的故障转移，无需重新复制数据
+- **快速故障转移**：AZ 故障时可在约 30 秒内完成 RTO；区域级故障通过 Aurora Global 切换
+- **全局读取加速**：辅助区域可就近提供读取流量，降低读取延迟
+
+## Key Capabilities
+
+### Managed Switchover
+Aurora Global 支持托管式切换（Managed Switchover），主区域发生故障时：
+1. 将辅助区域提升为新的主区域
+2. 故障区域恢复后，作为新的辅助区域重新加入全球集群
+3. 无需重新复制数据，切换过程干净快速
+
+### vs RDS Cross-Region Replication
+| 特性 | Aurora Global | RDS Cross-Region |
+|------|-------------|-----------------|
+| 复制类型 | 异步 | 异步 |
+| 故障切换 | 托管式切换，无需重新复制 | 需阻断访问，重建集群 |
+| 辅助区域数量 | 最多 5 个 | 依赖具体配置 |
+| 读取扩展 | 支持（辅助区域读取） | 支持（读副本） |
+
+## Related Concepts
+- [[Amazon Aurora]]：Aurora Global 的宿主数据库
+- [[RTO]]：Aurora Global 帮助实现低 RTO
+- [[Multi-AZ]]：AZ 级高可用 vs Aurora Global 区域级灾备
+- [[Blue-Green Deployment]]：Aurora MySQL 支持的部署策略
+
+## Aliases
+- Aurora Global Database
+- Aurora Global Cluster
+- Aurora Cross-Region Replication
+- Aurora Multi-Region
--- a/wiki/concepts/Backlinks.md
+++ b/wiki/concepts/Backlinks.md
@@ -0,0 +1,41 @@
+---
+title: "Backlinks（双向链接）"
+type: concept
+tags: [知识管理, 笔记系统, 图谱构建]
+sources:
+  - "[[obsidian-官方-cli-命令全景速查表]]"
+last_updated: 2026-04-28
+---
+
+## Definition
+**Backlinks（反向链接 / 双向链接）** 是一种笔记间的引用机制：当笔记 A 通过 `[[B]]` 链接到笔记 B 时，B 会自动生成一条指向 A 的反向链接记录，从而形成双向关系网络。
+
+## Aliases
+- 反向链接
+- Backlink
+- Bidirectional Links
+- 双向链接
+- Wikilinks
+- `[[WikiLinks]]`
+
+## Core Mechanism
+- **正向链接（Outgoing Links）**：从当前笔记指向其他笔记
+- **反向链接（Backlinks）**：其他笔记指向当前笔记的链接列表
+- Obsidian 在编辑器侧边栏自动展示 Backlinks 面板
+
+## Key Commands (Obsidian CLI)
+- `obsidian backlinks file=Index` — 列出指向目标文件的所有反向链接
+- `obsidian links file=Index` — 列出目标文件包含的所有出站链接
+- `obsidian move/rename` — 重命名/移动文件时 CLI 自动更新全库双链，绝不断链
+- `obsidian unresolved` — 提取未创建实体文件的死链接节点
+
+## Value in Knowledge Management
+- 构建知识图谱：揭示笔记间的隐性关联
+- 上下文追溯：通过反向链接顺藤摸瓜找到相关笔记
+- 支持本地 RAG：Agent 通过 `backlinks` + `read` 构建准确的背景知识库
+- 发现孤立笔记：`orphans` 命令找出没有被任何笔记引用的"死"笔记
+
+## Related Concepts
+- [[Zettelkasten]] — 双链是卡片盒笔记法的核心技术
+- [[Graph-View]] — 图谱视图可视化双链网络
+- [[Local-RAG]] — Backlinks + search:context 是本地 RAG 的关键组件
--- a/wiki/concepts/Blue-Green-Deployment.md
+++ b/wiki/concepts/Blue-Green-Deployment.md
@@ -1,84 +1,50 @@
---
-title: "Blue-Green Deployment"
-type: concept
-tags: [devops, deployment, release-management, high-availability]
-date: 2025-03-01
---
-
-## Definition
-
-蓝绿部署（Blue-Green Deployment）是一种零停机发布策略，维护两套相同的生产环境（蓝环境和绿环境），通过负载均衡器切换流量实现无缝部署和快速回滚。
-
-## Architecture
-
-```
-                    Load Balancer
-                         │
-              ┌──────────┴──────────┐
-              │                     │
-           Blue Env             Green Env
-         (Production)          (Staging)
-              │                     │
-           v1.0                v1.1 (New)
-              │
-         Traffic ON         Traffic OFF
-```
-
-## Deployment Flow
-
-```
-1. Blue (v1.0) serving all traffic
-2. Deploy to Green (v1.1)
-3. Test/Verify Green
-4. Switch LB to Green
-5. Blue becomes standby (or update to next version)
-```
-
-## Key Benefits
-
-| 优势 | 描述 |
-|------|------|
-| 零停机 | 流量切换瞬间完成 |
-| 快速回滚 | 切换回蓝色环境即可 |
-| 测试完整性 | 完整生产环境测试 |
-| 风险可控 | 新版本未暴露给全部用户 |
-
-## Comparison: Blue-Green vs Canary
-
-| 维度 | Blue-Green | Canary |
-|------|-----------|--------|
-| 流量切换 | 全量切换 | 渐进式 |
-| 回滚速度 | 秒级 | 秒级 |
-| 资源成本 | 2x | 增量 |
-| 适用场景 | 关键系统 | 持续迭代 |
-| 风险 | 全量暴露 | 逐步暴露 |
-
-## In ITSM Context
-
-在[[ITSM 2.0]]的[[Release-Management]]中，蓝绿部署是关键实践：
-
-```
-Release Management 2.0
-├── Blue-Green Deployment
-│   ├── 零停机发布
-│   ├── 秒级回滚
-│   └── 全量验证
-├── Canary Release
-│   ├── 渐进式发布
-│   └── 实时监控
-└── DevOps-integrated ITSM
-    ├── CI/CD Pipeline
-    └── Automated Governance
-```
-
-## Related Concepts
-
- [[Release-Management]] — 发布管理总框架
- [[Canary-Release]] — 金丝雀发布
- [[High-Availability]] — 高可用架构
- [[Failover]] — 故障转移
- [[Deployment-Automation]] — 部署自动化
-
-## Sources
-
- [[understanding-complete-itsm]] — Blue-Green在现代ITSM中的应用
+---
+title: "Blue-Green Deployment"
+type: concept
+tags:
+  - AWS
+  - Aurora
+  - Database
+  - Deployment
+  - Release Management
+sources:
+  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
+last_updated: 2026-04-23
+---
+
+## Overview
+Blue-Green Deployment（蓝绿部署）是一种零停机部署策略，通过维护两套相同环境（Blue 和 Green）实现快速、平滑的版本切换，最小化部署风险。
+
+## How It Works
+1. **Blue 环境**：当前生产环境
+2. **Green 环境**：与 Blue 完全相同的新版本副本
+3. **部署过程**：
+   - 在 Green 环境部署和验证新版本
+   - 验证通过后，将流量从 Blue 切换到 Green
+   - Blue 环境保留作为即时回滚的备用
+
+## Aurora Blue-Green Deployment
+Aurora MySQL 支持数据库层的 Blue-Green Deployment，用于 Major Version Upgrade（Maj-Vu）：
+- **原理**：通过逻辑复制（基于 Binlog）将 Blue 环境的变更同步到 Green 环境
+- **Guardrails**：内置保护机制防止数据丢失
+- **限制**：仅 Aurora MySQL 支持；**Aurora PostgreSQL 不支持**
+
+### vs Traditional Database Upgrade
+| 方式 | 停机时间 | 风险 | 数据保护 |
+|------|---------|------|---------|
+| In-place Major Upgrade | 分钟级，取决于数据大小 | 高，需执行升级脚本 | 依赖备份 |
+| Blue-Green Deployment | 接近零 | 低，可即时回滚 | 自动保护 |
+
+## Related Concepts
+- [[Canary Deployment]]：渐进式流量分配，另一种低风险部署策略
+- [[Amazon Aurora]]：Aurora MySQL 支持 Blue-Green Deployment
+- [[Amazon RDS]]：RDS PostgreSQL 不支持 Blue-Green Deployment
+- [[Release Management]]：蓝绿部署属于发布管理的工具之一
+- [[RTO]]：Blue-Green Deployment 可将数据库升级的 RTO 降至接近零
+
+## Aliases
+- Blue-Green
+- Blue Green Deployment
+- 蓝绿部署
+- 双环境部署
+- Zero-Downtime Deployment
--- a/wiki/concepts/DBA-Role-Evolution.md
+++ b/wiki/concepts/DBA-Role-Evolution.md
@@ -1,64 +1,53 @@
---
-title: "DBA Role Evolution"
-type: concept
-tags:
-  - AWS
-  - Cloud
-  - Database
-  - Career
-sources:
-  - ctp-topic-51-architecting-with-aws-purpose-built-databases
-last_updated: 2026-04-23
---
-
-## Definition
-云时代 DBA 角色演变（Cloud DBA Evolution）是指数据库管理员（Database Administrator）的职能从传统的底层平台管理（备份、补丁、容量规划）向现代的应用层创新（架构设计、查询优化、性能调优）转变的过程。
-
-## Traditional DBA Responsibilities (On-Premises)
-传统 DBA 的核心职责：
- **平台管理**：数据库安装、配置、补丁升级
- **备份恢复**：执行备份、验证恢复、灾难演练
- **容量规划**：存储计算资源规划、采购
- **性能监控**：数据库指标监控、瓶颈诊断
- **安全合规**：用户权限管理、合规审计
-
-## Cloud-Native DBA Responsibilities (AWS)
-云时代 AWS 环境下的 DBA 职能转变：
-
-| 传统职责 | 云时代处理方式 | DBA 新焦点 |
-|---------|--------------|-----------|
-| 备份恢复 | AWS 自动备份（ RDS/Aurora 内置） | 制定备份策略、验证 RTO/RPO |
-| 补丁升级 | AWS 自动打补丁（Managed Service） | 评估补丁影响、安排维护窗口 |
-| 容量规划 | 按需扩展（Auto Scaling / Serverless） | 成本优化、右规格选型 |
-| 故障恢复 | Multi-AZ 自动故障转移 | 架构设计、演练自动化 |
-| 硬件维护 | AWS 负责 | 更高层次的架构决策 |
-
-## New DBA Focus Areas
-云时代 DBA 应聚焦的领域：
-
-1. **数据库架构设计**：专用数据库选型（[[Purpose-Built-Databases]]）、多数据库混合架构
-2. **查询优化**：慢查询分析、索引策略、执行计划优化
-3. **性能调优**：Aurora Serverless、DynamoDB On-Demand 的合理使用
-4. **安全加固**：VPC 安全组、加密（KMS）、IAM 权限最小化
-5. **成本优化**：Reserved Instances、Savings Plans、冷热数据分层
-6. **应用集成**：连接池配置（ RDS Proxy）、读写分离、缓存策略
-7. **数据治理**：Schema 设计规范、数据生命周期管理
-
-## Key Quote
-> "The role of the DBA is evolving in the cloud." — Femi George, AWS Database Sales Specialist
-
-AWS 负责底层平台管理，DBA 的价值转移到**应用创新**而非平台维护。
-
-## Aliases
- Cloud DBA
- 云时代 DBA
- DBA 职能转变
- Database Administrator Evolution
- Database Reliability Engineer
-
-## Related Concepts
- [[Purpose-Built-Databases]]：云时代 DBA 需要掌握多种专用数据库的选型能力
- [[Multi-Database-Architecture]]：DBA 负责设计多数据库混合架构
- [[RTO]]：云时代 DBA 关注的关键灾备指标
- [[Amazon-RDS]]：托管关系型数据库，DBA 从平台管理转向应用优化
- [[Amazon-Aurora]]：云原生数据库，存储计算分离架构
+---
+title: "DBA Role Evolution"
+type: concept
+tags:
+  - Cloud
+  - Database
+  - DevOps
+  - Career
+sources:
+  - ctp-topic-51-architecting-with-aws-purpose-built-databases
+last_updated: 2026-04-28
+---
+
+## Overview
+云时代数据库管理员（DBA）的角色正经历深刻转变：从底层平台运维转向应用层创新和架构设计，成为 DevOps/平台工程的桥梁。
+
+## Traditional DBA Responsibilities (On-Premises)
+传统 DBA 的核心工作：
+- 物理服务器和存储的采购、配置、维护
+- 数据库引擎安装、补丁管理、版本升级
+- 备份策略制定与恢复演练
+- 性能调优（索引、查询优化）
+- 安全管理（用户、权限、审计）
+
+## Cloud-Native DBA Responsibilities (AWS)
+云时代 AWS 上的 DBA 职能转变：
+
+| 传统职责 | 云时代转变 |
+|----------|------------|
+| 物理硬件管理 | AWS 全托管服务自动处理 |
+| 备份/补丁 | RDS/Aurora/DynamoDB 自动备份和滚动补丁 |
+| 容量规划 | 自动扩展或按需容量 |
+| **新增职责** | |
+| 数据库选型 | 根据数据模型选择最优专用数据库 |
+| 架构设计 | 设计多数据库混合架构 |
+| 查询优化 | 应用层性能优化 |
+| 数据治理 | 跨数据库的数据合规和生命周期管理 |
+
+## Key Insight
+> "The role of the DBA is evolving in the cloud." — 云时代 DBA 的核心价值从平台管理转向应用创新
+
+## Focus Shift
+DBA 应将精力从：
+- ❌ 手动备份、补丁、容量管理
+- ✅ 架构设计、查询优化、数据建模、跨服务集成
+
+## Connections
+- [[Purpose-Built-Databases]]：云时代 DBA 需要掌握多种专用数据库的选型和特性
+- [[Multi-Database-Architecture]]：DBA 在多数据库架构设计中承担架构师角色
+- [[Amazon-RDS]] / [[Amazon-Aurora]] / [[Amazon-DynamoDB]]：云托管数据库减轻了 DBA 的平台运维负担
+
+## Referenced In
+- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]
--- a/wiki/concepts/Docker-Compose.md
+++ b/wiki/concepts/Docker-Compose.md
@@ -1,70 +1,32 @@
-# Docker Compose
-
-## Description
-Docker Compose 是 Docker 官方提供的多容器 Docker 应用定义和运行工具。通过 `docker-compose.yml`（或 `compose.yaml`）配置文件，使用 YAML 格式声明式定义多容器服务的网络、卷、端口映射、环境变量等，实现一键部署复杂应用。
-
-## Version
- **V1 (独立包)**：`docker-compose` 命令（已弃用）
- **V2 (插件)**：`docker compose` 命令（当前主流），通过 `docker-compose-plugin` 包安装，集成到 Docker CLI
-
-## V1 vs V2 Command Reference
-| V1 (独立包) | V2 (插件) |
-|------------|-----------|
-| `docker-compose up -d` | `docker compose up -d` |
-| `docker-compose ps` | `docker compose ps` |
-| `docker-compose down` | `docker compose down` |
-| `docker-compose -f xxx.yml config` | `docker compose -f xxx.yml config` |
-
-## Core Concepts
- **Services**: 定义每个容器服务（镜像、构建、端口、卷、环境变量）
- **Volumes**: 命名数据卷，持久化容器数据
- **Networks**: 容器网络配置（bridge、host、overlay）
- **Version**: `version: '3.8'` 为当前主流版本规范
-
-## Example
-```yaml
-version: '3.8'
-services:
-  it-tools:
-    image: corentinth/it-tools:latest
-    container_name: it-tools
-    restart: unless-stopped
-    stdin_open: true
-    tty: true
-    ports:
-      - "8999:80"
-    deploy:
-      resources:
-        limits:
-          memory: 128M
-```
-
-## Used By
- [[用docker安装it-tools]]
- [[用docker安装transmission]]
- [[如何删除旧的废弃的docker-container-volume]]
- [[Navidrome]]
- [[Jellyfin]]
- [[RSSHub]]
- [[Portainer]]
-
-## External Mode
-Compose 文件中声明 `external: true` 可让 Docker 复用已存在的 Volume 或 Network 而非创建新的，避免重装时的命名冲突警告：
-```yaml
-volumes:
-  portainer_data:
-    external: true
-
-networks:
-  portainer_network:
-    external: true
-```
-
-## Related Concepts
- [[Docker-Image]]
- [[Docker-Save]]
- [[Docker-Load]]
- [[容器资源限制]]
- [[容器重启策略]]
- [[端口映射]]
- [[桥接网络]]
+---
+title: "Docker Compose"
+type: concept
+tags: [docker, devops, orchestration]
+last_updated: 2026-04-23
+---
+
+## Overview
+Docker Compose 是一个用于定义和运行多容器 Docker 应用的工具。通过 YAML 文件（`docker-compose.yml`）声明服务、网络、卷等配置，一条命令即可启动整套应用栈。
+
+## Key Commands
+```bash
+docker-compose up -d      # 启动服务（后台）
+docker-compose down       # 停止并移除容器
+docker-compose restart    # 重启服务
+```
+
+## Key Concepts
+- **Services**: 每个容器定义为一个 service
+- **Network Mode**: 可使用 `network_mode: host` 将容器网络直接绑定到宿主机
+- **Environment Variables**: 通过 `environment` 字段注入环境变量（如 `YOUTUBE_KEY`、`HTTP_PROXY`）
+- **Volumes**: 通过 `volumes` 字段将宿主机文件/目录挂载到容器内
+- **Restart Policy**: `restart: unless-stopped` 确保容器在宿主机重启后自动恢复
+
+## Usage in This Wiki
+- RSSHub 部署配置使用 Docker Compose 作为主机上的容器编排工具
+- n8n、Portainer、Jellyfin 等服务均通过 Docker Compose 管理
+
+## Aliases
+- docker-compose
+- Docker Compose
+- docker compose
--- a/wiki/concepts/Domain-Join.md
+++ b/wiki/concepts/Domain-Join.md
@@ -0,0 +1,32 @@
+---
+title: "Domain Join"
+type: concept
+tags:
+  - AWS
+  - Active-Directory
+  - IAM
+  - Automation
+sources:
+  - ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs
+last_updated: 2026-05-05
+---
+
+## Definition
+Domain Join（域加入）是将计算机或云实例加入 Active Directory（AD）域的过程，使其能够使用 AD 账号进行身份认证和访问控制。
+
+## Mechanism
+在 Gruntwork AWS Landing Zones 架构中，域加入通过以下方式实现自动化：
+- **Windows 实例**：使用 SRE 团队预制的 AMI + Terraform `user_data` 中的 PowerShell 脚本，在实例启动时自动完成域加入、命名分配、管理员权限分配及旧对象清理
+- **Linux 实例**：通过 SRE 预制 Shell 脚本 + 安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录到 Windows DNS 服务器
+
+## Key Claims
+- 自动化域加入消除了手动干预，提升了实例部署效率
+- 不同环境（R&D vs 生产/SAS）使用不同的 AD 域名规范
+
+## Related Entities
+- [[swinford.net]]：R&D Labs 环境 AD 域名
+- [[intsas.local]]：生产/SAS 环境 AD 域名
+- [[Gruntwork]] Landing Zones：自动化域加入的基础架构框架
+
+## References
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]
--- a/wiki/concepts/Multi-AZ.md
+++ b/wiki/concepts/Multi-AZ.md
@@ -0,0 +1,48 @@
+---
+title: "Multi-AZ"
+type: concept
+tags:
+  - AWS
+  - RDS
+  - Database
+  - High Availability
+  - Disaster Recovery
+sources:
+  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
+last_updated: 2026-04-23
+---
+
+## Overview
+Multi-AZ 是 AWS RDS 的一种高可用部署方案，在多个可用区（AZ）部署数据库实例的主节点和备用节点，当主节点发生故障时自动切换到备用节点，以实现数据库的高可用性。
+
+## How It Works
+- **主节点（Primary）**：处理所有读写操作
+- **备用节点（Standby）**：通过同步复制保持数据一致，处于热备状态
+- **自动故障转移**：主节点不可用时，RDS 自动将连接路由到备用节点（约 1-2 分钟）
+
+## RDS Multi-AZ vs Aurora Architecture
+| 特性 | RDS Multi-AZ | Aurora |
+|------|-------------|--------|
+| 备用节点 | 独立计算 + 独立 EBS 存储 | 共享集群卷（6 副本跨 3 AZ） |
+| 数据复制 | 同步复制到备用 | 分布式写入所有副本 |
+| 故障转移时间 | 约 2 分钟 | 约 30 秒 |
+| 读副本 | 需重新复制数据 | 共享存储，无需数据复制 |
+| 端点 | 单个端点 | 分离的 Writer/Reader 端点 |
+
+## Key Insights
+- RDS Multi-AZ 的备用节点**不能用于读取扩展**（同步复制保证数据一致性）
+- Aurora 的共享存储架构使其读副本可以立即上线，无需数据复制
+- 故障转移期间，DNS 缓存可能导致短暂连接中断（建议将 DNS TTL 设置为 1 秒以加速切换）
+
+## Related Concepts
+- [[Amazon RDS]]：RDS Multi-AZ 的宿主服务
+- [[Amazon Aurora]]：采用不同的架构实现更高可用性
+- [[RTO]]：Multi-AZ 的 RTO 约为 2 分钟
+- [[Aurora Global]]：Aurora 的跨区域灾备方案
+- [[High Availability]]：高可用性设计
+
+## Aliases
+- Multi-AZ Deployment
+- Multi Availability Zone
+- 多可用区部署
+- RDS Multi-AZ
--- a/wiki/concepts/Multi-Database-Architecture.md
+++ b/wiki/concepts/Multi-Database-Architecture.md
@@ -1,89 +1,72 @@
---
-title: "Multi-Database Architecture"
-type: concept
-tags:
-  - AWS
-  - Database
-  - Architecture
-  - Microservices
-sources:
-  - ctp-topic-51-architecting-with-aws-purpose-built-databases
-last_updated: 2026-04-23
---
-
-## Definition
-多数据库混合架构（Multi-Database Architecture）是指在单一应用中根据各部分的数据特征选用不同类型专用数据库的架构模式，以实现最优的数据层性能。
-
-## Core Principle
-每个数据模型应使用最适合它的数据库类型：
- **关系型数据** → 关系型数据库（Aurora / RDS）
- **高频读取** → 内存缓存（ElastiCache）
- **无结构键值** → 键值数据库（ DynamoDB）
- **高度互连** → 图数据库（Neptune）
-
-## Real-World Case Studies
-
-### Duolingo 案例（来源：[[ctp-topic-51-purpose-built-databases]]）
-| 数据类型 | 数据库 | 选型原因 |
-|---------|--------|---------|
-| 个性化学习进度 | DynamoDB | 高写入、低延迟、弹性扩展 |
-| 高频词/短语 | ElastiCache | 微秒级读取缓存 |
-| 事务数据（购买、订阅）| Aurora | ACID 强一致性、复杂查询 |
-
-### Netflix 案例（来源：[[ctp-topic-51-purpose-built-databases]]）
-| 数据类型 | 数据库 | 选型原因 |
-|---------|--------|---------|
-| JSON 文档（用户数据、偏好）| DynamoDB | 高弹性、低延迟、JSON 原生支持 |
-
-### Peloton 案例（来源：[[ctp-topic-51-purpose-built-databases]]）
-| 数据类型 | 数据库 | 选型原因 |
-|---------|--------|---------|
-| 实时健身反馈 | ElastiCache Redis | 微秒级响应、即时用户体验 |
-
-## Architecture Patterns
-
-### Cache-Aside Pattern（旁路缓存）
-```
-应用 → DynamoDB/RDS（主数据库）
-     ↘ ElastiCache（缓存层）
-```
- 读取：先查缓存，未命中则查数据库并回填缓存
- 写入：先写数据库，再失效/更新缓存
-
-### CQRS Pattern（命令查询职责分离）
-```
-写入 → DynamoDB（优化写入）
-读取 → DynamoDB + ElastiCache（优化读取）
-     ↘ Aurora（复杂查询读取）
-```
-
-### Event-Driven Data Sync
-```
-DynamoDB Streams → Lambda → Aurora
-                  → Lambda → Elasticsearch（搜索）
-                  → Lambda → S3（归档）
-```
-
-## Trade-offs
-| 优势 | 挑战 |
-|------|------|
-| 最优性能：每个场景用最佳数据库 | 复杂度：多数据库运维成本 |
-| 弹性扩展：各层独立扩展 | 一致性：跨数据库事务管理 |
-| 成本优化：按需选择规格 | 学习曲线：团队需掌握多种数据库 |
-| 容错隔离：单库故障不扩散 | 数据迁移：服务间数据同步 |
-
-## Aliases
- Polyglot Persistence
- 多数据库混合架构
- 数据库混合部署
- Database Polyglot
- Mixed Database Architecture
-
-## Related Concepts
- [[Purpose-Built-Databases]]：多数据库架构的基础——专用数据库选型原则
- [[Amazon-DynamoDB]]：多数据库架构中的键值/文档数据存储
- [[Amazon-ElastiCache]]：多数据库架构中的缓存层组件
- [[Amazon-Aurora]]：多数据库架构中的关系型事务数据存储
- [[Amazon-Neptune]]：多数据库架构中的图数据存储
- [[Amazon-Timestream]]：多数据库架构中的时序数据存储
- [[DBA-Role-Evolution]]：云时代 DBA 需要掌握多数据库架构设计能力
+---
+title: "Multi-Database Architecture"
+type: concept
+tags:
+  - AWS
+  - Database
+  - Architecture
+  - Polyglot
+sources:
+  - ctp-topic-51-architecting-with-aws-purpose-built-databases
+last_updated: 2026-04-28
+---
+
+## Overview
+多数据库混合架构（Polyglot Persistence）是一种架构模式：在同一个应用系统中，根据不同数据类型和访问模式，选择多个专用数据库组合使用，而非依赖单一数据库。
+
+## Aliases
+- Polyglot Persistence
+- Multi-Database Architecture
+- Polyglot Database Architecture
+
+## Core Pattern
+为正确的工作选择正确的工具：
+- **事务数据** → 关系型数据库（Aurora/RDS）
+- **高频缓存** → 内存数据库（ElastiCache Redis）
+- **灵活文档** → 文档数据库（DocumentDB）
+- **图关系** → 图数据库（Neptune）
+- **时序数据** → 时序数据库（Timestream）
+
+## Real-World Case Study: Duolingo
+
+Duolingo 的多数据库架构：
+
+```
+┌─────────────────────────────────────────────────┐
+│                  Duolingo App                   │
+└──────────────────────┬────────────────────────┘
+                       │
+         ┌─────────────┼─────────────┐
+         ▼             ▼             ▼
+   ┌──────────┐  ┌───────────┐  ┌──────────┐
+   │DynamoDB  │  │ElastiCache│  │  Aurora   │
+   │          │  │ (Redis)   │  │          │
+   │个性化数据 │  │高频词/短语 │  │事务数据   │
+   │          │  │           │  │(支付/账户)│
+   └──────────┘  └───────────┘  └──────────┘
+```
+
+- **DynamoDB**：用户个性化学习数据，高并发读写
+- **ElastiCache Redis**：高频词/短语缓存，减少数据库访问
+- **Aurora**：支付、用户账户等强一致性事务
+
+## Benefits
+- **性能最优**：每个数据层使用专门优化的引擎
+- **成本效率**：按需选择，避免为不需要的功能付费
+- **扩展灵活**：各数据库独立扩展，互不干扰
+- **技术适配**：最合适的技术栈解决最合适的场景
+
+## Challenges
+- **运维复杂度**：多数据库意味着多套运维工具和技能
+- **数据一致性**：跨数据库的分布式事务处理
+- **团队技能**：DBA 需要掌握多种数据库技术
+- **连接管理**：应用层需要管理多个数据库连接池
+
+## Connections
+- [[Purpose-Built-Databases]]：多数据库架构是专用数据库理念的组织形式
+- [[DBA-Role-Evolution]]：多数据库架构要求 DBA 具备更广的技术视野
+- [[Duolingo]]：Duolingo 是多数据库混合架构的经典生产案例
+- [[Netflix]]：Netflix 也采用多数据库架构支撑大规模流媒体平台
+
+## Referenced In
+- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]
--- a/wiki/concepts/Purpose-Built-Databases.md
+++ b/wiki/concepts/Purpose-Built-Databases.md
@@ -1,70 +1,54 @@
---
-title: "Purpose-Built Databases"
-type: concept
-tags:
-  - AWS
-  - Database
-  - Architecture
-  - Cloud-Native
-sources:
-  - ctp-topic-51-architecting-with-aws-purpose-built-databases
-last_updated: 2026-04-23
---
-
-## Definition
-专用数据库（Purpose-Built Databases）是一种数据库选型原则——根据应用的数据模型、访问模式和性能需求，选择最适合该用例的专用数据库类型，而非用单一数据库解决所有问题。
-
-## Core Principle
-> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist
-
-核心理念：**从用例出发，选择最佳工具，避免一刀切（One-Size-Fits-All）**。
-
-## AWS Database Categories
-
-| 类别 | AWS 产品 | 适用场景 |
-|------|---------|---------|
-| 关系型 | RDS, Aurora | 固定 schema、ACID 事务、复杂关联查询 |
-| 键值 | DynamoDB | 高吞吐量、简单键值访问、无 schema 约束 |
-| 文档 | DocumentDB | 半结构化 JSON、灵活 schema、嵌套查询 |
-| 宽列 | Keyspaces | 大规模写入、Cassandra 兼容工作负载 |
-| 内存缓存 | ElastiCache | 微秒级延迟、高频读取、会话存储 |
-| 图数据库 | Neptune | 高度互连数据、欺诈检测、推荐引擎 |
-| 时序数据库 | Timestream | IoT 遥测、监控指标、时间序列分析 |
-| 账本数据库 | QLDB | 不可变事务日志、审计追踪 |
-
-## Selection Criteria
-选择专用数据库时应考虑：
-1. **应用规模**：用户数量、请求量、数据量
-2. **访问模式**：读密集 vs 写密集、点查 vs 范围查询
-3. **数据模型**：结构化 vs 半结构化、关系复杂度
-4. **性能需求**：延迟、吞吐量、可用性
-5. **运维成本**：托管 vs 自管理、团队技能
-
-## Multi-Database Architecture
-现代应用常采用多数据库混合架构：
-
-**Duolingo 案例**（来源：[[ctp-topic-51-purpose-built-databases]]）：
- **DynamoDB**：存储个性化学习进度数据（键值访问）
- **ElastiCache**：缓存高频词/短语（内存缓存）
- **Aurora**：处理事务性数据（关系型）
-
-**Netflix 案例**（来源：[[ctp-topic-51-purpose-built-databases]]）：
- **DynamoDB**：高弹性、低延迟 JSON 文档访问
-
-## Aliases
- Purpose-Built Databases
- 专用数据库
- 专用数据库选型
- Database Polyglot
- Polyglot Persistence
-
-## Related Concepts
- [[Multi-Database-Architecture]]：多数据库混合架构模式
- [[Amazon-DynamoDB]]：AWS 专用键值数据库
- [[Amazon-Aurora]]：云原生关系型数据库
- [[Amazon-Neptune]]：AWS 图数据库
- [[Amazon-Timestream]]：AWS 时序数据库
- [[Amazon-Keyspaces]]：AWS 宽列数据库
- [[Amazon-DocumentDB]]：AWS 文档数据库
- [[Amazon-ElastiCache]]：AWS 内存缓存数据库
- [[DBA-Role-Evolution]]：云时代数据库架构师角色的转变
+---
+title: "Purpose-Built Databases"
+type: concept
+tags:
+  - AWS
+  - Database
+  - Architecture
+  - Multi-Model
+sources:
+  - ctp-topic-51-architecting-with-aws-purpose-built-databases
+last_updated: 2026-04-28
+---
+
+## Overview
+专用数据库（Purpose-Built Databases）是一种架构理念：针对不同的数据模型、访问模式和性能需求，选择专门优化的数据库，而非用单一通用数据库解决所有问题。
+
+## Core Principle
+> "为正确的应用选择正确的专用数据库" — Femi George, AWS Database Sales Specialist
+
+## AWS Database Categories
+
+| 类别 | AWS 服务 | 适用场景 |
+|------|----------|----------|
+| 关系型 | RDS, Aurora | 固定 schema，引用完整性，ACID 事务 |
+| 键值 | DynamoDB | 高并发，任意规模，低延迟 |
+| 文档 | DocumentDB (MongoDB兼容) | 灵活 schema，嵌套 JSON |
+| 宽列 | Keyspaces (Cassandra兼容) | 大规模写入，结构化/半结构化 |
+| 内存缓存 | ElastiCache (Redis/Memcached) | 毫秒级响应，会话/排行榜 |
+| 图数据库 | Neptune | 复杂关系，欺诈检测，推荐 |
+| 时序数据库 | Timestream | IoT/监控，高吞吐量时序数据 |
+| 账本数据库 | QLDB | 不可变事务记录，审计日志 |
+
+## Selection Criteria
+选择专用数据库时需考虑：
+- **应用规模**：用户量、数据量、请求量
+- **访问模式**：读写比例、查询复杂度、延迟要求
+- **数据模型**：结构化/半结构化/非结构化
+- **一致性需求**：强一致性 vs 最终一致性
+- **运维能力**：团队数据库管理能力
+- **成本模型**：按查询/存储/实例计费
+
+## Why Not One-Size-Fits-All?
+- 传统单一关系型数据库在所有场景下存在性能瓶颈
+- NoSQL 牺牲强一致性换取扩展性和性能
+- 不同数据模型（文档/图/时序）有最优专用引擎
+- 现代微服务架构天然支持多数据库混用
+
+## Connections
+- [[Multi-Database-Architecture]]：专用数据库理念的直接实践形式
+- [[Amazon-Aurora]] / [[Amazon-DynamoDB]] / [[Amazon-ElastiCache]] 等：AWS 专用数据库品类中的具体产品
+- [[DBA-Role-Evolution]]：专用数据库多样化增加了 DBA 的选型职责
+
+## Referenced In
+- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]
--- a/wiki/concepts/Secure-Dynamic-Updates.md
+++ b/wiki/concepts/Secure-Dynamic-Updates.md
@@ -0,0 +1,36 @@
+---
+title: "Secure Dynamic Updates"
+type: concept
+tags:
+  - DNS
+  - AWS
+  - Active-Directory
+  - Security
+sources:
+  - ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs
+last_updated: 2026-05-05
+---
+
+## Definition
+Secure Dynamic Updates（安全动态更新）是 DNS 协议的一种扩展，允许客户端计算机在通过 Kerberos 身份验证后，自动向 Windows DNS 服务器注册和更新其 A 记录和 PTR 记录。
+
+## Mechanism
+- **用途**：Linux 实例在加入 AD 域后，通过 Secure Dynamic Updates 机制自动向 Windows DNS 服务器注册其 DNS A 记录，无需手动配置
+- **前提条件**：客户端必须使用有效的 Kerberos 票据（由 AD 域控制器颁发），确保只有经过认证的域成员才能更新 DNS 记录
+- **安全性**：与无安全的动态更新（允许任何人注册任意 DNS 记录）相比，Secure Dynamic Updates 防止了 DNS 污染和欺骗攻击
+
+## Key Claims
+- Linux 实例通过 Secure Dynamic Updates 实现无人值守的 DNS 记录注册
+- 该机制是零接触自动化域管理的关键组成部分
+
+## Related Entities
+- [[intsas.local]]：提供 DNS 服务的生产/SAS AD 域名
+- [[swinford.net]]：提供 DNS 服务的 R&D Labs AD 域名
+- [[Domain Join]]：Secure Dynamic Updates 依赖于成功的域加入
+
+## Related Concepts
+- [[DNS托管]]
+
+## References
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]
+- [[ctp-topic-19-configuring-dns-within-aws-lzs]]
--- a/wiki/concepts/YouTube-Data-API-v3.md
+++ b/wiki/concepts/YouTube-Data-API-v3.md
@@ -0,0 +1,40 @@
+---
+title: "YouTube Data API v3"
+type: concept
+tags: [youtube, google-cloud, api, data]
+last_updated: 2026-04-23
+---
+
+## Overview
+YouTube Data API v3 是 Google 官方提供的 YouTube 编程接口，允许开发者通过 API Key 访问 YouTube 频道、视频、播放列表等数据，是解决 YouTube 爬虫限制的最稳定方案。
+
+## Key Capabilities
+- 获取频道信息（标题、描述、缩略图）
+- 获取频道最新视频列表
+- 获取播放列表内容
+- **免费额度**: 每月 10,000 单位（足够个人用户正常使用）
+
+## How to Get API Key
+1. 访问 [Google Cloud Console](https://console.cloud.google.com/)
+2. 创建新项目，命名如 `My-RSSHub`
+3. 启用 **YouTube Data API v3**
+4. 在「凭据」页面创建 API 密钥
+5. （推荐）为密钥设置 API 限制，仅允许 YouTube Data API v3
+
+## Usage in This Wiki
+- RSSHub 通过 `YOUTUBE_KEY` 环境变量使用此 API 稳定获取 YouTube 频道更新
+- 配合本地 HTTP 代理（`HTTP_PROXY`）可在容器内绕过网络限制
+
+## Security Best Practice
+- 为 API Key 设置 HTTP 来源限制（Referrer Restrictions）
+- 仅在 YouTube Data API v3 中启用该密钥，防止 Key 泄露后被滥用
+
+## Connections
+- [[RSSHub]] ← requires ← [[YouTube Data API v3]]
+- [[YouTube Content Pipeline]] ← uses ← [[YouTube Data API v3]]
+
+## Aliases
+- YouTube API
+- YouTube Data API
+- YouTube Data API v3
+- YOUTUBE_KEY