如何设计一个基于Paxos的KV存储系统

1978年5月11日，《光明日报》发表本报特约评论员文章《实践是检验真理的唯一标准》，由此引发了一场关于真理标准问题的大讨论。

在各个平台，以并发笔记的ID分享过很多关于共识算法的内容了，所以接下来我准备分享Paxos的实战内容，如何基于Paxos设计一个分布式系统。

当然，这篇文章最主要的目的是：希望有更多感兴趣的小伙伴参与到这个项目来，我们可以一起讨论如何优化Paxos。

Klein介绍

1. 介绍

Klein是一个基于Paxos分布式共识类库，我使用它实现了KV存储、缓存。

项目地址：https://github.com/shihuili1218/klein

你可以独立部署Klein，像使用Redis一样使用它；但是仅仅是这样的话，也太没有新意了，它有趣的地方在于：Klein可以内嵌入你的项目中，你可以不依赖任何中间件，保证各个成员之间的数据一致。

基于此，你可以有无限多的想法，例如用Klein来实现KV存储，或者用它来实现分布式缓存，甚至用它来实现分布式锁，etc anything.

2. 玩点不一样的

众所周知，Paxos是存在一些局限的，诸如活锁、RPC交互次数过多，这使得Paxos让人望而却步。尽管对于这些问题，已经有了标准的解决方案，但是不玩些花样，造什么轮子呢？

• 是否真的能支持并行协商？
• Confirm阶段（应用状态转移）是否真的可以异步执行？
• 如何为一个运行的系统创建快照？
• Group的拆分是否有必要完全隔离？
• 到底哪个提案会达成共识？

3. 愿景

愿景呢，当然是希望维护一个标准的共识类库，开箱即用。

同时希望可以进入Apache孵化器。

进度

1. Paxos

• • 写请求、乱序协商，顺序确认【完成】
• • 读请求，使用协商log完成【完成】
• • 批量协商【完成】
• • 优化prepare阶段【完成】
• • 快照【完成】
• • 拆分Group，proposer等角色无须隔离，只需隔离instance【完成】
• • 增加Master：成员变更、优化读请求【进行中】
• • 成员自动发现(调研)
• • 数据对齐：成员上线、落后成员对齐
• • NWR
• • confirm优化读请求
• • 不存在干扰key，无需执行一轮Prepare

2. 缓存

• • 读、写、等基础功能【完成】
• • 配合持久化实现LRU
• • TTL自动过期

3. 待优化

• • LogManager行锁
• • 监控协商效率
• • 监控线程池指标(DefaultTimer, ThreadExecutor)