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)
