2026-11-10
· 分类：分布式系统
记录消息队列在分布式架构中的核心作用、常见模式与选型思考。
消息队列的核心价值 异步解耦：上游不需要等待下游处理完成，降低系统耦合度。 削峰填谷：突发流量写入队列，消费者按自身能力匀速处理。 最终一致：通过消息重试与死信队列保证数据最终到达。 常见使用模式 点对点（Work Queue） 一个消息只被一个消费者消费，适合任务分发：
Producer → [Queue] → Consumer1 Consumer2 Consumer3 发布订阅（Pub/Sub） 一个消息被所有订阅者消费，适合事件广播：
Producer → [Topic] → Subscriber1 (邮件服务) Subscriber2 (数据分析) Subscriber3 (审计日志) 主流消息队列对比 维度 Kafka RabbitMQ RocketMQ Pulsar 吞吐量 极高（百万级/s） 中等（万级/s） 高（十万级/s） 高 延迟 毫秒级 微秒级 毫秒级 毫秒级 顺序性 分区内有序 队列内有序 分区内有序 分区内有序 持久化 磁盘日志 可选 磁盘 分离存储 协议 自定义 AMQP 自定义 自定义 适用场景 日志/流处理 业务消息 电商/金融 多租户/流处理 实践中的关键问题 消息可靠性 生产端：开启确认机制（Kafka acks=all，RabbitMQ confirm）。 Broker：持久化存储 + 副本机制。 消费端：手动 ack，处理完成后再确认。 消息重复消费 网络抖动可能导致重复投递，消费端必须实现幂等：
2026-11-10
· 分类：Linux
记录 systemd 服务管理的常用操作与配置方法，涵盖服务创建、日志查看与故障排查。
基础操作 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 启动/停止/重启服务 sudo systemctl start nginx sudo systemctl stop nginx sudo systemctl restart nginx # 查看服务状态 sudo systemctl status nginx # 设置开机自启/禁止自启 sudo systemctl enable nginx sudo systemctl disable nginx # 重新加载配置（不中断服务） sudo systemctl reload nginx 创建自定义服务 以一个 Node.js 应用为例，创建 /etc/systemd/system/myapp.service：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [Unit] Description=My Node.
2026-11-10
· 分类：分布式系统
记录分布式锁的常见实现方案、各自优缺点及选型思考。
为什么需要分布式锁 单机环境下可以用语言内置锁（如 Java synchronized、Go Mutex）保证临界区互斥。多实例部署后，进程分布在不同机器上，需要跨进程的协调机制——分布式锁。
典型场景：库存扣减、定时任务防重复执行、配置热更新互斥。
三种主流实现 1. Redis 分布式锁 最简单的实现是 SET key value NX PX：
1 2 3 4 5 # 加锁（key=资源标识, value=唯一标识, NX=不存在才设置, PX=过期时间） SET lock:order:123 uuid-xxx NX PX 30000 # 解锁（Lua 脚本保证原子性：校验 value 后删除） EVAL "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end" 1 lock:order:123 uuid-xxx 优点：性能高，实现简单。
风险：
锁过期但业务未完成 → 需要看门狗续期（如 Redisson）。 主从切换丢锁 → Redlock 算法（多节点半数以上加锁成功）。 2. Zookeeper 分布式锁 基于临时顺序节点实现：
1. 创建临时顺序节点 /lock/node-0001 2. 获取 /lock 下所有子节点，判断自己是否序号最小 3.
2026-11-10
· 分类：云原生
记录使用 Docker Compose 编排多服务应用的实践经验，涵盖配置编写、网络管理与数据持久化。
基本概念 Docker Compose 通过一个 YAML 文件定义多个容器服务及其依赖关系，适合本地开发、CI 测试和小规模部署。
典型项目结构 myapp/ ├── docker-compose.yml ├── .env ├── web/ │ ├── Dockerfile │ └── app.py ├── api/ │ ├── Dockerfile │ └── main.go └── nginx/ └── nginx.conf 完整示例：Web + API + Redis 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 version: "3.
2026-11-10
· 分类：Linux
记录 Nginx 反向代理与负载均衡的常用配置和实践经验。
反向代理基础配置 将客户端请求转发到后端服务：
1 2 3 4 5 6 7 8 9 10 11 12 server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } 关键 header 说明：
Host：传递原始域名，后端可识别请求来源。 X-Real-IP：传递客户端真实 IP。 X-Forwarded-For：代理链路 IP 记录。 X-Forwarded-Proto：传递原始协议（http/https）。 负载均衡配置 轮询（默认） 1 2 3 4 5 upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; } 加权轮询 1 2 3 4 5 upstream backend { server 192.
2026-11-10
· 分类：软件开发
记录团队 Git 工作流的实践总结，涵盖分支模型、提交规范与冲突处理。
分支模型选择 Git Flow（适合发布周期长的项目） main：生产环境代码，每次合并打 tag。 develop：集成测试分支。 feature/*：功能开发分支，从 develop 拉出。 hotfix/*：紧急修复分支，从 main 拉出。 GitHub Flow（适合持续部署的项目） main：始终可部署。 feature/*：功能分支，通过 PR 合并到 main。 合并即部署，强调 CI 自动化。 提交信息规范 推荐使用 Conventional Commits 格式：
<type>(<scope>): <subject> <body> <footer> 常见 type：
type 说明 feat 新功能 fix 修复缺陷 docs 文档变更 refactor 重构（不改变功能） test 测试相关 chore 构建/工具变更 示例：
feat(auth): 添加 OAuth2 登录支持 集成 Google 和 GitHub OAuth2 登录， 用户可选择第三方账号登录。 常用协作命令 1 2 3 4 5 6 7 8 9 10 11 # 同步远程分支并清理已删除的远程分支引用 git fetch --prune # 交互式 rebase 整理提交历史 git rebase -i origin/develop # cherry-pick 挑选特定提交到当前分支 git cherry-pick <commit-hash> # 查看分支差异 git log --left-right --graph --cherry-pick --oneline main.
2026-11-09
· 分类：软件开发
记录日常软件开发中的工程实践与经验总结，包括代码规范、版本管理和测试策略。
代码质量的基本功 命名清晰：变量、函数命名表达意图，避免缩写歧义。 函数短小：单一职责，一个函数只做一件事。 及时重构：发现坏味道时尽早处理，避免技术债累积。 写有意义的注释：注释说明『为什么』，代码本身说明『怎么做』。 Git 常用实践 1 2 3 4 5 6 7 8 9 # 查看提交历史的图形化展示 git log --oneline --graph --all # 将多个提交合并为一个 git rebase -i HEAD~3 # 暂存当前修改，切换分支处理紧急问题 git stash git stash pop 测试策略分层 层级 特点 占比建议 单元测试 快速、隔离、定位精确 70% 集成测试 验证模块间协作 20% 端到端测试 模拟真实用户场景，成本高 10% 小结 工程化能力的提升来自持续实践与复盘，后续会记录 CI/CD 流水线搭建与代码评审的实践经验。
2026-11-09
· 分类：分布式系统
记录分布式系统核心概念的学习笔记，以及在实践中的一些思考。
CAP 定理 分布式系统无法同时满足以下三个特性，只能三选二：
一致性（Consistency）：所有节点在同一时间看到相同的数据。 可用性（Availability）：每个请求都能收到响应，但不保证数据最新。 分区容错性（Partition tolerance）：网络分区发生时系统仍能继续运行。 由于网络分区不可避免，实际系统通常在 CP 和 AP 之间做权衡。
一致性模型 强一致性：写入完成后，所有读操作都能读到最新值（如 Zookeeper、etcd）。 最终一致性：经过一段时间后，所有副本收敛到相同状态（如 DNS、对象存储）。 因果一致性：有因果关系的操作按序可见，无因果关系的操作可以并发。 常见共识算法 算法 特点 典型应用 Raft 易理解，领导者选举 + 日志复制 etcd、TiKV Paxos 理论完备，工程实现复杂 Chubby、OceanBase Gossip 去中心化、最终一致 Cassandra、Redis Cluster 实践思考 优先明确业务对一致性的真实需求，避免过度设计。 幂等设计是分布式接口的必修课。 完善的监控与链路追踪是排查分布式问题的前提。 小结 分布式系统的复杂度来源于网络、并发与故障，后续会继续记录 Raft 论文阅读与一致性协议的实践内容。
2026-11-09
· 分类：云原生
记录云原生技术体系的学习路径与基础实践，涵盖容器、编排与微服务相关笔记。
云原生的核心理念 云原生（Cloud Native）是一套构建和运行应用的方法论，核心要素包括：
容器化：应用与依赖打包为容器镜像，保证环境一致性。 微服务架构：将单体应用拆分为独立部署、独立演进的服务。 声明式 API：通过描述期望状态而非操作步骤来管理系统。 弹性与可观测性：系统具备自愈能力，并暴露完善的监控指标。 容器基础实践 1 2 3 4 5 6 7 8 9 10 11 # 查看本地镜像 docker images # 运行一个 Nginx 容器 docker run -d --name web -p 8080:80 nginx:latest # 查看容器日志 docker logs -f web # 进入容器排查 docker exec -it web /bin/sh Kubernetes 基本概念 概念 说明 Pod 最小调度单元，包含一个或多个容器 Deployment 管理 Pod 副本与滚动更新 Service 为 Pod 提供稳定的访问入口 ConfigMap / Secret 配置与敏感信息管理 小结 本文仅为基础入门，后续计划记录 K8s 集群搭建、Ingress 配置以及 CI/CD 流水线的实践过程。
2026-11-09
· 分类：Linux
记录 Linux 系统学习与日常运维中的常用命令和排查思路，持续更新。
系统信息查看 1 2 3 4 5 6 7 8 9 # 查看系统版本 lsb_release -a # 查看内核版本 uname -r # 查看 CPU 与内存 lscpu free -h 磁盘与文件系统 1 2 3 4 5 # 查看磁盘使用情况 df -h # 查看目录占用 du -sh /var/log/* 性能排查思路 当系统负载升高时，可按以下顺序排查：
看整体负载：uptime、top，关注 load average 与 CPU 使用率。 看进程：ps aux --sort=-%cpu | head，定位高占用进程。 看 IO：iostat -x 1，关注 util 与 await 指标。 看网络：ss -tlnp，确认端口监听与连接状态。 看日志：journalctl -u <服务名> 或 /var/log/ 下的应用日志。 小结 熟练掌握基础命令是运维排障的第一步，后续会补充 systemd 服务管理与 Shell 脚本实践的内容。
2023-03-15
Occaecat aliqua consequat laborum ut ex aute aliqua culpa quis irure esse magna dolore quis. Proident fugiat labore eu laboris officia Lorem enim. Ipsum occaecat cillum ut tempor id sint aliqua incididunt nisi incididunt reprehenderit. Voluptate ad minim sint est aute aliquip esse occaecat tempor officia qui sunt. Aute ex ipsum id ut in est velit est laborum incididunt. Aliqua qui id do esse sunt eiusmod id deserunt eu nostrud aute sit ipsum.
2023-02-15
Anim eiusmod irure incididunt sint cupidatat. Incididunt irure irure irure nisi ipsum do ut quis fugiat consectetur proident cupidatat incididunt cillum. Dolore voluptate occaecat qui mollit laborum ullamco et. Ipsum laboris officia anim laboris culpa eiusmod ex magna ex cupidatat anim ipsum aute. Mollit aliquip occaecat qui sunt velit ut cupidatat reprehenderit enim sunt laborum. Velit veniam in officia nulla adipisicing ut duis officia.
Exercitation voluptate irure in irure tempor mollit Lorem nostrud ad officia.
2023-01-15
Tempor proident minim aliquip reprehenderit dolor et ad anim Lorem duis sint eiusmod. Labore ut ea duis dolor. Incididunt consectetur proident qui occaecat incididunt do nisi Lorem. Tempor do laborum elit laboris excepteur eiusmod do. Eiusmod nisi excepteur ut amet pariatur adipisicing Lorem.
Occaecat nulla excepteur dolore excepteur duis eiusmod ullamco officia anim in voluptate ea occaecat officia. Cillum sint esse velit ea officia minim fugiat. Elit ea esse id aliquip pariatur cupidatat id duis minim incididunt ea ea.