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