欢迎来到我的 Go 语言实践仓库！
这个项目的起点是为了一个清晰的目标：将 MIT 6.824 (Distributed Systems) 课程中的核心理论，用 Go 语言在实践中彻底锤炼。
在这里，理论不只是停留在论文上，而是被转化为了需要处理网络分区、节点崩溃和并发写入的真实代码。本仓库是我的学习笔记、我的试验场，也是我构建可靠、可扩展系统的作品集。
随着我不断深入，这里会包含更多 Go 语言在系统编程、后端服务等领域的探索。
这个仓库目前包含了三个受 6.824 启发的旗舰项目。
一个受 Celery 和 RabbitMQ 启发的简化版任务队列。它允许客户端异步提交任务，并由一组工作节点（Workers）来执行。系统的核心是一个高可用的 Broker，确保任务在节点崩溃时也不会丢失。
💡 核心概念实践：
- Raft 共识 (Lab 3): 任务队列的状态（待处理、进行中）在 Broker 集群中通过 Raft 协议进行复制，确保 Broker Leader 崩溃后，系统也能无缝切换并继续服务。
- RPC 通信 (Lab 1): Client, Broker, Worker 之间使用
gRPC和Protobuf进行高效、强类型的通信。 - 容错设计:
- Worker 故障: Broker 通过心跳或租约（Lease）检测 Worker 崩溃，并将未完成（或未确认）的任务重新放回队列，实现“至少一次” (At-least-once) 交付。
- Client 重试: 通过幂等性设计，处理客户端因网络问题导致的重复任务提交。
- 状态机持久化: Raft 日志被持久化存储，允许整个系统在断电重启后恢复到宕机前的状态。
一个受 6.824 Lab 4 启发的分布式 K/V 数据库。数据通过哈希被分片（Sharded）到不同的节点组（Groups）中。每个分片组本身都是一个高可用的复制状态机。
💡 核心概念实践：
- 数据分片 (Sharding): 使用一致性哈希（Consistent Hashing）将 Key 空间映射到不同的分片组。
- Raft per Shard (Lab 3): 每一个分片组都是一个独立的 Raft 集群。这保证了分片内部的强一致性。
- 配置管理 (Lab 4): 实现了一个（同样由 Raft 保证高可用的）配置管理器（Shard Master），用于跟踪分片在组之间的迁移。
- 动态配置变更: 实现了当数据需要重新平衡（Re-balancing）时，分片从一个组“推送”到另一个组的复杂过程。
- 两阶段提交 (2PC) (可选): 如果实现了跨分片的事务，会在这里用到。
一个基于 Google File System (GFS) 论文核心思想的微型实现。它完美地诠释了“数据与元数据分离”的架构，并解决了大规模数据存储中的容错问题。
💡 核心概念实践：
- 架构设计:
- Master: 中心化的元数据管理器。存储文件名、目录树、Chunk 句柄以及 Chunk 的位置。
- Chunkservers: 存储实际数据（固定大小的 Chunks）。
- Raft + Master (Lab 3): Master 节点不再是 GFS 论文中的单点故障。Master 的状态（元数据）通过 Raft 复制，实现了高可用。
- 容错与数据复制:
- 心跳机制: Master 通过心跳检测 Chunkserver 的存活。
- Chunk 复制: 文件 Chunk 被复制到多个（例如 3 个）Chunkserver。当 Master 检测到有节点下线，它会立即触发“重新复制”流程，以保持副本数。
- 并发控制: 实现了 GFS 论文中的“租约 (Lease)”机制。Master 将一个 Chunk 的写入租约授予某个副本（Primary），由它来控制并发写入的顺序。
这个仓库不会止步于此。我将继续使用 Go 来探索和构建：
- ... (例如：一个简单的 API 网关？)
- ... (例如：基于 Gossip 协议的服务发现？)
- ... (例如：一个流处理引擎？)
- ... (任何你感兴趣的新 Go 项目！)
本项目是一个 Monorepo（单一代码库）。
每个子项目（如 distri-queue, shard-kv）都是一个独立的 Go Module，并在其各自的目录中包含一个专属的 README.md。
请进入你感兴趣的项目目录，以获取详细的构建、测试和运行指南。
# 示例：
cd ./shard-kv
go build
go test