具有故障模拟功能的RPC实现分析 | Charles的技术博客 

作者:JerryXia | 发表于 , 阅读 (0)
引言分布式系统学习中,需要理解如何对各种故障进行正确地处理,包括网络故障,机器故障等等。如何能方便的模拟故障,来验证自己的原型系统是否能够正确的应对这些故障就非常重要。本文将分析一个基于golang实现,具有故障模拟的RPC实现原理,源码来自MIT 6.824课程的labrpc。
RPC基本原理在了解RPC实现之前,我们先来了解下RPC的基本原理。
在分布式系统中,RPC(remote procedure call)是当一个计算机程序触发在其他地址空间(通常是通过网络相连的其他计算机)执行一个计算过程,用户无需了解其实现细节,就像调用本机的函数一样,通常,一个RPC的调用类似如下
1234567Client:  z = fn(x, y)Server:  fn(x, y) {    compute    return z  }如上所示,Client执行函数fn(x,y),通过RPC,最终在Server端执行此函数,并获取结果。如上所示的调用,其消息流如下
123Client             Server  request--->     <---responseClien...阅读全文

 gfs原理 | Charles的技术博客 

作者:JerryXia | 发表于 , 阅读 (0)
2. Design Motivationgoogle对现有系统的运行状态以及应用系统进行总结,抽象出对文件系统的需求,主要分为以下几个方面。
普通商用的机器硬件发生故障是常态存储的问题普遍比较大,几个G的文件很常见大部分的文件操作都是在追加数据,覆盖原来写入的数据的情况比较少见,随机写几乎不存在读操作主要包括两种,large streaming read和small random read为了应用使用方便,多客户端并行地追加同一个文件需要非常高效带宽的重要性大于时延,目标应用是高速读大块数据的应用,对响应时间没有过多的需求3. Architecture本部分讨论gfs的总体架构,以及在此架构上需要考虑的一些问题。
3.1 OverviewGFS的整体架构如下图:

(图片来源:gfs论文)
GFS中有四类角色,分别是
GFS chunkserverGFS masterGFS clientApplication3.1.1 GFS chunkserver在GFS chunkserver中,文件都是分成固定大小的chunk来存储的,每个chunk通过全局唯一的64位的chunk ...阅读全文

 raft原理(一):选主与日志复制 | Charles的技术博客 

作者:JerryXia | 发表于 , 阅读 (0)
Introduction本文收录在paper项目中,papers项目旨在学习和总结分布式系统相关的论文;同时本文也是DSTORE项目的必备知识,DSTORE的目标是自己动手实现一个分布式KV存储引擎。
本文为raft系列文章第一篇,本系列其他文章为
raft原理(二):安全性和集群成员变更raft原理(三):日志合并及客户端交互golang实现raft(一):选举和日志同步golang实现raft(二):集群成员变更本文介绍了分布式一致性算法raft的选主和日志复制原理,raft算法的主要目标是为了让分布式一致性算法更易理解和用于工程实践。
raft算法的主要特性为
strong leader:raft算法使用的是strong leader方式,日志只能从leader同步到followerleader election:使用随机定时器来选主Membership changes:采用的是两阶段更新配置信息的方式本文的组织结构如下
Replicated state machinesStrenthens and weaks of PaxosUnderstandabilityRaft...阅读全文

 raft原理(三):日志合并和客户端交互 | Charles的技术博客 

作者:JerryXia | 发表于 , 阅读 (0)
Log compactionRaft的日志会随着处理客户端请求数量的增多而不断增大,在实际系统中,日志不可能会无限地增长,原因如下:
占用的存储空间随着日志增多而增加日志越多,server当掉重启时需要回放的时间就越长因此,需要定期地清理日志,Raft采用最简单的快照方法。对系统当前做快照时,会把当前状态持久化到存储中,然后到快照点的日志项都可以被删除。

Raft算法中每个server单独地做快照,即把当前状态机的状态写入到存储中(状态机中的状态都是已提交的log entry回放出来的)。除了状态机的状态外,Raft快照中还需要一些元数据信息,包括如下:
快照中包含的最后一个log entry的index和term,记录这些信息的目的是为了使得AppendEntriesRPC的一致性检查能通过,因为,在复制紧跟着快照后的log entry时,AppendEntries RPC带上需要复制的log entry前一个log entry的(index, iterm),即快照的最后一个log entry的(index,term),因此,快照中需要记录最后一个log entry的(in...阅读全文

 自己动手写分布式KV存储引擎(二):网络框架中的定时器原理和实现 | Charles的技术博客 

作者:JerryXia | 发表于 , 阅读 (0)
定时器的功能设计本节主要分析了服务端程序对定时器的需求,定时器的算法选择。
需求在服务端编程中,很多地方会使用到定时器,例如:
服务端定时发送心跳,证明自身在线服务器检测到某些连接在一定时间内不活跃后,可以关闭其连接这些功能都是使用频率非常高的功能,其性能的好坏与定时器本身的性能好坏密不可分,因此,实现一个高性能的定时器是非常有必要的。接下来分析影响定时器性能最重要的因素:定时器的算法选择。
定时器算法选择在一个网络框架中,对定时器的操作主要包括:
插入定时器,记做INSERT更新定时器的超时时间,维持定时器超时时间按照从小到大的顺序,记做UPDATE按照超时时间获取下一个定时器,记做GET删除定时器,记做DELETE以维持心跳功能为例,讨论定时器功能采用何种算法才能获得高性能。
一个典型的连接之间维持心跳的事件发生序列如下:
建立连接,设置定时器,并注册到网络框架中,即INSERT操作网络框架在定时器到期时,需要从其维护的定时器池中取出来,调用相应的处理接口,然后,更新定时器的超时时间,维持定时器池中按照定时器超时时间,即GET+UPDATE操作在链接关闭前,重复步骤2多...阅读全文