Paxos是Leslie Lamport为解决集群各个节点共识提出的算法。其中最重要和最基础的是Basic Paxos。 首先给出伪代码简单说明整个Basic的算法细节。接下来接需要证明Basic Paxos确实能够保证使集群达成共识。

Basic Paxos算法展示

伪代码，参考[1],这里省去[1]中的instance，只列出在同一instance下，如何达成共识。

Proposer...
read more

02 Jun 2020 by John Brown

文件系统(本地)不适合做分布式存储后端:Ceph演变10年的经验教训

最近读了一篇关于Ceph后端BlueStore的论文，该论文发表在SOSP’19的会议上。讲了ceph分布式文件系统的存储后端的不断演变的经验教训，主要在这里做一个论文笔记。

Abstract

在过去的10年中，Ceph遵循了传统的本地文件系统作为Ceph分布式文件系统的后端。应为传统的文件系统久经沙场，非常的成熟。但是也带了了一些问题，最主要的有

1. 构建0开销的事务处理机制很难
2. 在本地级别的元数据性能会显著地影响整个分布式文件系统
3. 对新兴的存储设备文件系统的支持非常缓慢
...
read more

15 Apr 2020 by John Brown

Raft 只读操作优化

为什么需要优化只读操作

raft是一个为分布式集群达成一致性的协议。对于集群需要保证一致性的数据，每次一操作其实都要确认此操作是否在集群中达成了一致。从是否会改变数据的角度，操作就分两个只读操作与写操作。只读操作顾名思义就是不会对数据做任何的改动。写操作包含了增删改等需要修改数据的操作，通俗说就是这次操作处理完后，数据有可能跟操作前不一样。

正是因为只读操作不对数据进行修改，所以raft可以优化只读操作。

1. 因为只要客户端请求的是现集群真正的leader，那么获取到的数据就不会有错误。一个只读操作没有必要征求整个raft集群的共识。毕竟使用raft达成一个操作的共识还需要多节点网络请求与log持久化落磁盘等开销。

   ...
   read more

   08 Feb 2020 by John Brown

什么是LRU(Least-Recently Used)

• 缓存的队列长度(容量)为\(S\), 一共有\(K\)的项, K » S >...
  read more

  19 Dec 2019 by John Brown

为什么要”分片”

分片即将整体的数据分而治之。以多节点系统工作的方式共同完成一个工作。能够减轻节点服务器压力，提高整个集群节点利用率与性能。

这里引申出一个问题，为什么需要使用分片这一方式。在分布式系统中，有主副节点(master replica 数据上，Leader Follower raft一致性协议上)。能否在主副节点同时对数据进行操作，哪怕只是对副本进行读操作。至少在要求强一致或者线性一致的的存储系统中，答案是否定的(更改：可以对副本进行访问，只不过需要一些策略)。在这些系统中，副本只负责提高分布式系统的可用性，对系统的容灾性进行提升。client不能使用replica中的数据。因为副本节点没有向一致性propose的权利，无法保证这次操作已达成了共识。最主要的原因就是如果集群出现了脑裂,导致线性不一致。

这里需要提到一点，就是原始的paxos协议，没有raft的leader和follower的区别。paxos角色为proposer和acceptor，但是任何节点都同时扮演这两种角色，一个基础的paxos协议需要多次网络请求（prepare，accept…）。任何节点都可以进行propose的结果就是导致了非常容易发生冲突，在多请求时很很难达成共识。所以一般在工程实现时使用multi-paxos，即也是选出leader打头阵。