0%

RWMutex RLock重入导致死锁

RWMutex,即读写锁,可以被多个的reader或一个writer获取使用。

死锁例子

在使用RWMutex的时候,同一个reader是不应该连续调用Rlock多次的,这样做不但没有意义,还有可能导致死锁,具体代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
func main() {
var l = sync.RWMutex{}
var wg sync.WaitGroup
wg.Add(2)

c := make(chan int)
go func() {
l.RLock()
defer l.RUnlock()
c <- 1
runtime.Gosched()

l.RLock()
defer l.RUnlock()
wg.Done()
}()

go func() {
<-c
l.Lock()
defer l.Unlock()
wg.Done()
}()

wg.Wait()
}
Read more »

之前有记录过python Queue的使用,以及multiprocessing.Process模块。现在看看multiprocessing.Queue的具体工作方式(本文基于Python 3.7.4)。

multiprocessing.Queue定义在queues.py中,除此之外还定义了SimpleQueueJoinableQueue,是FIFO队列。

类似multiprocessing.Process,首先导入了context,判断当前系统类型,并相应地使用对应的实现。使用的multiprocessing.Queue()的时候,实际上是调用了context中的Queue()方法,设置了ctx

Read more »

介绍

文章主要使用实验验证了raft是否如原论文所阐述的易于理解和实现。重新阐述了raft,使用OCaml实现了raft,开发了一个事件驱动的模拟器来进行测试,重现了raft原论文中的测试,并提出了几个优化。

性能

对于raft的性能,raft原论文中提到了两点,

  1. 典型的情况下,leader复制entry的时间。
  2. 最坏情况下,leader失败后,选举出新leader的时间。
    1. 选举能否快速收敛?
    2. 集群能达到的最小下线时间是什么?
Read more »

Readings - In Search of an Understandable Consensus Algorithm (Extended Version) (Section 6 to end)论文

集群成员变更

实际应用中,常常会有配置变更的需求,即:成员变更。手动的方式有下面两种,

  • 把集群整体下线,配置修改完毕以后再上线是可行的,但会造成服务不可用。
  • 新server可以通过获取其ip来替换集群成员,需要保证被替换的server不会再加入集群。
Read more »

数据密集型应用

现在的很多应用是数据密集型的,数据是这些应用的主要挑战-数据的总量、数据的复杂度和数据变化的速度。

很多数据密集型的应用都是基于已有的数据系统提供的常用功能来构建的。例如:

  • 存储数据,以便自己或其他应用能够找到(基于数据库实现此功能)
  • 记住一个昂贵操作的结果,来加速读取(缓存)
  • 允许用户通过关键词搜索数据,或多种方式过滤数据(搜索索引)
  • 发送消息到另一个进程进行异步处理(流式处理)
  • 定时处理大量累积的数据(批处理)
Read more »

Readings - In Search of an Understandable Consensus Algorithm (Extended Version) (to end of Section 5)论文

Introduction

共识算法(Consensus algorithms)允许一组机器作为一个一致的组工作,这个组可以在某些成员失败的情况下存活。Paxos是过去10多年最常被讨论的共识算法,但是难以理解且不便于实现。提出Raft的主要目标是可理解性。通过解耦leader选举、log复制和安全,以及减少状态空间,来增加可理解性。

Read more »

Readings - Practical System for Fault-Tolerant Virtual Machines Fault-Tolerant Virtual Machines论文

这篇论文讨论的主从复制与常见的相比,非常极端和雄心勃勃,论文基于vm构建了一个os级别的主从复制系统,较为细致的讨论了主从复制的设计和实现。

介绍

主从复制是实现server容错的常用方法,如果primary挂了,backup可以继续提供服务。将primary的全量数据同步到backup是比较耗费带宽的操作。更好的方法是将server视为确定状态机,基本思路是把primary和backup置为相同的初始状态,并保证二者都能以相同的顺序收到相同的输入。由于存在某些操作是非确定的(如:中断和获得当前时间),因此还需要额外的协同。

Read more »