最新文章
· 分类：分布式系统
记录消息队列在分布式架构中的核心作用、常见模式与选型思考。
消息队列的核心价值 异步解耦：上游不需要等待下游处理完成，降低系统耦合度。 削峰填谷：突发流量写入队列，消费者按自身能力匀速处理。 最终一致：通过消息重试与死信队列保证数据最终到达。 常见使用模式 点对点（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，处理完成后再确认。 消息重复消费 网络抖动可能导致重复投递，消费端必须实现幂等：
· 分类：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.
· 分类：分布式系统
记录分布式锁的常见实现方案、各自优缺点及选型思考。
为什么需要分布式锁 单机环境下可以用语言内置锁（如 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.
· 分类：云原生
记录使用 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.
· 分类：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.
· 分类：软件开发
记录团队 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.
· 分类：软件开发
记录日常软件开发中的工程实践与经验总结，包括代码规范、版本管理和测试策略。
代码质量的基本功 命名清晰：变量、函数命名表达意图，避免缩写歧义。 函数短小：单一职责，一个函数只做一件事。 及时重构：发现坏味道时尽早处理，避免技术债累积。 写有意义的注释：注释说明『为什么』，代码本身说明『怎么做』。 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 流水线搭建与代码评审的实践经验。
· 分类：分布式系统
记录分布式系统核心概念的学习笔记，以及在实践中的一些思考。
CAP 定理 分布式系统无法同时满足以下三个特性，只能三选二：
一致性（Consistency）：所有节点在同一时间看到相同的数据。 可用性（Availability）：每个请求都能收到响应，但不保证数据最新。 分区容错性（Partition tolerance）：网络分区发生时系统仍能继续运行。 由于网络分区不可避免，实际系统通常在 CP 和 AP 之间做权衡。
一致性模型 强一致性：写入完成后，所有读操作都能读到最新值（如 Zookeeper、etcd）。 最终一致性：经过一段时间后，所有副本收敛到相同状态（如 DNS、对象存储）。 因果一致性：有因果关系的操作按序可见，无因果关系的操作可以并发。 常见共识算法 算法 特点 典型应用 Raft 易理解，领导者选举 + 日志复制 etcd、TiKV Paxos 理论完备，工程实现复杂 Chubby、OceanBase Gossip 去中心化、最终一致 Cassandra、Redis Cluster 实践思考 优先明确业务对一致性的真实需求，避免过度设计。 幂等设计是分布式接口的必修课。 完善的监控与链路追踪是排查分布式问题的前提。 小结 分布式系统的复杂度来源于网络、并发与故障，后续会继续记录 Raft 论文阅读与一致性协议的实践内容。
· 分类：云原生
记录云原生技术体系的学习路径与基础实践，涵盖容器、编排与微服务相关笔记。
云原生的核心理念 云原生（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 流水线的实践过程。
· 分类：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 脚本实践的内容。