支付系统设计：高并发解决方案与分布式事务处理 | 技术指南
· 3 min read
为了解决支付系统中高并发、容错、事务一致性等复杂问题，我们可以尝试应用以下设计模式和关键概念:
消息模型详解：Pub/Sub、P2P、请求/响应等常见模式比较与应用场景
· 4 min read
消息模型是消息中间件中用于定义消息传递方式的抽象模式，常见的除了**订阅/发布模式（Pub/Sub）和点对点模式（P2P）**外，还有其他衍生或组合模型。
| 模式 | 消息传递 | 耦合度 | 可靠性 | 扩展性 | 典型实现 | 典型应用 |
|---|---|---|---|---|---|---|
| 点对点， P2P | 一对一 | 低 | 高 | 中 | ActiveMQ, RabbitMQ | 异步任务、队列缓冲 |
| 发布/订阅 | 一对多 | 低 | 中 | 高 | Kafka, RabbitMQ | 事件通知、广播 |
| 请求/回复 | 双向 | 中 | 高 | 中 | RabbitMQ, ZeroMQ | RPC 调用 |
| 推/拉 | 可配置 | 低 | 可配置 | 高 | Kafka, RocketMQ | Fan-out |
| 流处理 | 连续 | 低 | 中到高 | 高 | Kafka Streams, Apache Flink | 日志处理、实时监控 |
数据序列化与反序列化：原理、应用及二进制处理全指南 | 2025最新
· 6 min read
序列化(Serialization)和反序列化(Deserialization)是数据处理中的两个核心概念，特别是在分布式系统和网络通信中尤为重要。
基本概念
AWS核心服务全指南：计算、存储、数据库与安全服务详解 | 云架构实践
· 5 min read
Azure常用服务完整指南：与AWS对照表+典型架构场景
· 5 min read
系统设计中的软硬件限制与性能指标
· 5 min read
在系统设计中，了解硬件资源限制、数据库性能指标和常见数据规模是至关重要的。以下是整理的关键参数和参考范围，涵盖数据规模、硬件配置、数据库性能等方面：
一、数据规模参考
1. 中英文字符的存储大小
| 字符类型 | 编码方式 | 存储大小 | 备注 |
|---|---|---|---|
| 英文字符 | ASCII 编码 | 1 个字符 = 1 byte | 适用于拉丁字母、数字和基本符号 |
| UTF-8 编码 | 1 个字符 = 1 byte | 兼容 ASCII，英文仍为单字节 | |
| 中文字符 | UTF-8 编码 | 1 个字符 = 3 bytes | 常用汉字占 3 字节，极少数生僻字可能占 4 字节 |
| GBK/GB2312 编码 | 1 个字符 = 2 bytes | 仅支持简体中文，非 Unicode 标准 | |
| 示例计算 | VARCHAR(100) UTF-8 | ||
| 英文 100 字 | 100 * 1B + 长度标识 ≈ 101B | ||
| 中文 100 字 | 100 * 3B + 长度标识 ≈ 303B |
说明：
- 英文字符 在 ASCII 和 UTF-8 编码下均占 1 字节。
- 中文字符 在 UTF-8 编码下通常占 3 字节，而在 GBK/GB2312 编码下占 2 字节。
- 示例计算 展示了
VARCHAR(100)字段在存储不同字符时的近似大小（包含长度标识）。
2. 数据库常见数据类型大小
| 数据类型 | 存储空间 | 示例 |
|---|---|---|
| CHAR(n) | 固定长度，不足补空格。英/中文均按定义的长度分配空间。 | CHAR(10) 英文=10B，中文=10B（实际存储内容可能更少，但空间固定） |
| VARCHAR(n) | 可变长度，按实际字符数+长度标识（通常 1-2 字节开销）。 | VARCHAR(10) 英文"Hi"=2B+1B，中文"你好"=6B+1B |
| TEXT | 可变长度，适合大文本（额外开销存储长度）。 | 英文长文本按实际字符数+开销 |
| INT | 通常 4 bytes（固定） | INT = 4B |
| BIGINT | 8 bytes | BIGINT = 8B |
| DATE/DATETIME | DATE=3B --> 4B, DATETIME=8B | DATETIME = 8B |
3. 文件/数据大小
| 数据类型 | 数据大小范围 | 备注 |
|---|---|---|
| 单条用户数据（JSON 记录） | 1 KB - 10 KB | |
| 高清图片 | 1 MB - 5 MB | |
| 短视频（1 分钟） | 10 MB - 100 MB | |
| 长视频（1080p，1 小时） | 1 GB - 3 GB | |
| 数据库单表容量限制 | ||
| - MySQL/PostgreSQL | 单表建议 ≤ 500GB | 性能下降临界点 |
| - 分布式数据库（如 Cassandra） | 单表可支持 PB 级 |
OSI Model
· One min read
系统设计知识框架与案例全指南（2025最新版） | 小卡UP技术博客
· One min read
运维工程师核心能力框架：稳定性保障与高可用系统管理
· 11 min read
运维工程师需要掌握的知识体系非常广泛且不断演进，核心在于保障系统/服务的稳定性、安全性、效率和成本可控。以下是一个结构化的框架和表格，帮助你系统性地理解和拆分运维所需掌握的核心内容：
核心框架：四大能力域 + 两大支撑域
- 基础设施管理： 支撑应用运行的物理/虚拟基础。
- 系统与平台管理： 操作系统、数据库、中间件等核心软件平台的管理。
- 应用部署与运维： 应用的发布、运行监控、问题排查、性能调优。
- 自动化与流程： 提升效率、减少人为错误、保证一致性的关键。
- 网络与安全： 贯穿所有层次的连接和安全保障。
- 监控与可观测性： 系统的“眼睛”和“听诊器”，是稳定性的基石。
详细拆分表格
DevOps实践指南：如何保证系统稳定性、高可用性与一致性 | 运维工程师必备技能
· 7 min read
一、 核心目标分解
- 稳定性 (Stability):
- 系统抵御故障、快速恢复的能力。
- 目标：降低故障发生率 (MTBF - Mean Time Between Failures)。
- 可用性 (Availability):
- 系统在需要时可被正常使用的程度。
- 目标：最大化正常运行时间 (Uptime)，通常用 SLA (如 99.9%, 99.99%) 衡量。
- 一致性 (Consistency):
- 确保环境、配置、部署流程、行为在开发、测试、生产等所有阶段高度一致。
- 目标：消除“在我机器上是好的”问题，减少环境差异导致的故障。