-
-
Jepsen测试
2020年12月19日 阅读(1,419)在线性一致性理论中我们已经介绍了Jepsen测试的理论基础。通过本文我们来看下怎么编写运行一个简单的Jepsen测试。
1.Clojure语言介绍及入门
Jepsen本身基于Clojure开发,如果想要了解Jepsen测试框架的内部实现以及其他一些开源项目的Jespen测试代码,需要能够看懂Clojure。首先我们来介绍下Clojure,Clojure是一种函数式编程语言,本身运行基于jvm,跟java可以进行很好的交互,关于Clojure的更多优点可以参考此文。Clojure这个单词,C L J分别用了代表C Lisp Java,同时又跟Closure的拼写近似。除了Jepsen之外,另一个比较有名的采用了Clojure的开源系统是Storm,这里有一个Storm采用Clojure的原因介绍。
Jepsen的作者Aphyr也写过一篇关于Clojure入门相关的文章。
下面推荐几篇关于Clojure入门的文章:
clojure-by-example 结合Clojure解释器实际运行试试应该可以更快上手,第2节我们会介绍怎么准备一个Clojure运行环境
Reading Clojure Characters Clojure本身有很多语法糖,各种符号对于初学者来说容易造成困扰,此文是关于各种语法糖的一个总结
2.Jepsen运行环境搭建
要运行Jepsen测试首先要有java和Clojure运行环境,通过安装lein(Clojure集成开发工具),可以把它们都准备好。我们可以参考Jepsen代码中的DockerFile制作一个docker image,该image包含运行Jepsen测试程序需要的所有环境依赖,同时将jepsen源代码copy到/jepsen目录。通过该docker image我们可以直接在测试机上启动容器,在容器里面运行Jepsen测试。
进入容器执行如下命令
#启动容器 sudo docker run -ti -d --hostname=jepsen_control --name=jepsen_control docker_image /usr/sbin/init #进入容器 docker exec -ti jepsen_control bash #进入demo代码 cd /jepsen/jepsen.etcdemo #启动Clojure解释器 lein repl
通过Clojure解释器,可以运行一些示例代码,帮助学习Clojure语言。
2.3 运行Jepsen测试
2.3.1 启动控制节点和DB节点容器
运行Jepsen测试,我们需要至少启动两个docker容器,一个作为控制节点,另一个作为DB节点。
#启动控制节点 sudo docker run -ti -d --hostname=jepsen_control --name=jepsen_control docker_image /usr/sbin/init #启动一个DB节点 sudo docker run -ti -d --hostname=n1 --name=n1 docker_image /usr/sbin/init
-
深度探索分布式理论经典论文
2019年8月3日 阅读(3,623)1.序
通过对Google发表的论文进行梳理,我们了解到了当前分布式系统领域的一些最新热点和发展趋势。梳理下这些论文,我们会发现它们主要发表在OSDI、SOSP、SIGMOD、VLDB、Macro、Eurosys、SIGCOMM、CIDR、SIGARCH、SIGCOMM等顶级期刊和会议上。反过来通过关注这些会议和期刊,我们就可以持续跟踪该领域的最新进展。但是也会发现这些会议和期刊每个每年都会发表几十上百篇文章,让人应接不暇。同时如在第一篇文章所指出的,这些文章背后的理论基础却很少发生变化,基本上还是几十年前就已提出的。为了更好更快地理解这些层出不穷的新论文,理清其所依赖的理论基础显得尤为重要。正如前文所述,”如果要真正理解这些论文,除了论文本身内容之外,也还需要去了解传统的分布式系统和关系数据库理论”。
-
Google论文、开源与云计算
2019年8月3日 阅读(3,182)1.Google论文与开源
自1998年成立,至今Google已走过20个年头。在这20年里,Google不断地发表一些对于自己来说已经过时甚至不再使用的技术的论文,但是发表之后总会有类似系统被业界实现出来,也足以说明google的技术至少领先业界数年。在Amazon不断引领全球云计算浪潮开发出一系列面向普罗大众的云产品的同时;Google也在不断引领构建着满足互联网时代海量数据的存储计算和查询分析需求的软硬件基础设施。
-
-
-
-
-
Solution of a Problem in Concurrent Programming Control(译)
2018年9月27日 阅读(2,253)作者:Edsger W. Dijkstra 1965
原文:https://www.di.ens.fr/~pouzet/cours/systeme/bib/dijkstra.pdf
译者:phylips@bmy 2018-9-27
相互之间可以通过有限方式进行通信的一组独立的sequential-cyclic进程,可以通过某种方式使得在任意时刻它们只有一个进入它们自己的“critical-section”。
-
线性一致性理论
2018年6月30日 阅读(4,449)图片无法查看,可以访问这个链接阅读:https://zhuanlan.zhihu.com/p/338057286
Jepsen(项目主页)是开源的分布式测试框架,基于Clojure语言,支持各种错误注入。目前广泛应用在各种分布式系统的测试中,尤其是一致性协议实现的测试中。Jepsen测试中支持验证系统的线性一致性,关于线性一致性,中文的介绍非常少,目前网上能搜到的大概只有tidb(一个创业公司PingCAP研发的分布式数据库)的一篇Linearizability 一致性验证。
要理解理论,最好的方法还是直接去看建立这个理论的原始论文,于是在业余时间对相关论文进行了阅读。其中第1)篇我做了一个完整的翻译,其他几篇由于篇幅和时间的原因仅进行了阅读。本文下面的内容主要源自阅读如下4篇论文后的理解,如果你觉得还有不好理解的地方欢迎指出,想深入了解一下的也可以再看下原文。首先简单介绍下每篇论文涉及的内容: -
How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs(译)
2018年6月30日 阅读(1,294)作者:Leslie Lamport 1979
原文:
make-multiprocessor-computer-correctly-executes-multiprocess-programs
译者:phylips@bmy 2018-03-24
译文:http://duanple.blog.163.com/blog/static/70971767201822515346732/
高速处理器可能乱序执行程序。如果处理器满足如下条件就可以保证执行的正确性:执行的结果与按照程序描述的顺序执行的结果一致。满足该条件的处理器我们就认为是sequential的。假设一台计算机由共享内存的多个这样的处理器组成。在设计和证明运行在该计算机上的多进程算法[1]-[3]的正确性时,通常基于如下假设:执行结果与这些处理器以某一串行顺序执行的结果相同,同时每个处理器内部操作的执行看起来又与程序描述的顺序一致。满足该条件的多处理器系统我们就认为是sequential consistent的。每个处理器内部满足sequential并不保证多处理器系统是sequential consistent的。在本文中,我们描述了一种sequential处理器(具有内存模块)之间的互联方法,可以保证最终的多处理器系统是sequential consistent的。
-
Consensus on Transaction Commit(译)
2014年2月9日 阅读(1,965)作者:Jim Gray & Leslie Lamport 2004
原文:http://research.microsoft.com/pubs/64636/tr-2003-96.pdf
译者:phylips@bmy 2013-10-07
译文:http://duanple.blog.163.com/blog/static/70971767201419111256135/
[序:很早之前就注意到这篇文章了,冲着这超豪华的作者阵容当时二话不说就将它加入到了待读列表中,只是最近才有时间将它看完。提到Paxos,人们会禁不住想到Lamport,提到事务,那当仁不让就是Jim Gray了。而由这两位所写的关于Paxos和事务提交的文章,还有让你错过的理由吗?
-
Single-Message Communication(译)
2013年11月1日 阅读(1,009)作者:DAG BELSNES 1976
原文:http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=23863
译者:phylips@bmy 2012-11-28
译文:http://duanple.blog.163.com/blog/static/70971767201310194243109/
摘要
当通信系统需要传输大量短消息时,减少进程间连接(connection)的创建和销毁以及消息可靠性方面的控制开销是非常重要的。本文描述了几种不同的端到端控制流程,同时研究了它们是否会导致消息丢失及收到重复消息。结果表明(基于对通信网络的一定假设)所有的端到端协议要么会产生消息丢失,要么会导致重复。
-
MillWheel: Fault-Tolerant Stream Processing at Int
2013年10月18日 阅读(1,533)作者:Tyler Akidau, Alex Balikov etc. Google Inc.
原文:http://research.google.com/pubs/pub41378.html
译者:phylips@bmy 2013-10-1
译文:http://duanple.blog.163.com/blog/static/709717672013918101253853/
[说明:最近Google在VLDB上发表了两篇文章,其中一篇是F1,另外一篇就是此文。关于流处理,目前业界也已有如下多个系统:Storm,Samza,Summingbird,Spark Streaming,StreamBase。另外,highscalability.com上也有个关于这篇paper的推荐文章Paper: MillWheel: Fault-Tolerant Stream Processing At Internet Scale,Zeitgeist。]
-
Photon: Fault-tolerant and Scalable Joining of Con
2013年9月25日 阅读(643)作者:Rajagopal Ananthanarayanan, Venkatesh Basker etc. Google Inc.
原文:http://www.mpi-sws.org/~areznich/files/photon-sigmod13.pdf
译者:phylips@bmy 2013-9-1
译文:http://duanple.blog.163.com/blog/static/70971767201382591541823/
摘要
Photon是Google开发的用于实时地对多个连续数据流进行join的部署于多个地理位置的分布式系统,具有高扩展性和低延迟的特点。该系统可以在不需要人工干预的情况下,完全容忍设施降级和数据中心级的故障。在Google内部,该系统是与广告系统一起部署的,可以用来对像网页搜索请求和广告点击这样的数据流进行join,它的输出结果是进行广告客户费用结算的重要依据。目前的线上环境中,峰值情况下每分钟要处理数百万的事件,平均延迟低于10秒。本文我们会描述在跨地理位置情况下,维护大规模持久化状态遇到的那些挑战和解决方案,并着重讲述下那些源于实践过程的设计原则。
-
Storm原理与实现
2013年9月25日 阅读(521)作者:phylips@bmy 2013-02
本文主要是从内部实现的角度来认识下Storm(0.7.1版本),因此需要用户对Storm的基本原理和使用具有一定的了解。如果缺乏这方面的知识,建议首先阅读下Storm的官方wiki:https://github.com/nathanmarz/storm/wiki
-
On Designing and Deploying Internet-Scale Services
2013年6月11日 阅读(724)James Hamilton – Windows Live Services Platform 2007
原文:http://www.mvdirona.com/jrh/TalksAndPapers/JamesRH_Lisa.pdf
译者:phylips@bmy 2013-06-10
译文:http://duanple.blog.163.com/blog/static/709717672013511101045985/
发布周期和测试
在生产环境下的测试是必需的,所有的大规模服务都应该把它作为QA方案的一部分。对于大多数服务来说,都至少会有一个尽可能接近生产的测试环境,同时所有优秀的工程团队都会用实际的生产负载来驱动测试系统。但我们的经验表明,无论测试环境有多好,总是不可能会与生产环境完全一致。与生产相比,总是或多或少会有些差别。随着测试环境与生产系统的接近,成本也会逐步与生产系统相当。
-
On Designing and Deploying Internet-Scale Services
2013年6月2日 阅读(620)作者:James Hamilton – Windows Live Services Platform 2007
原文:http://www.mvdirona.com/jrh/TalksAndPapers/JamesRH_Lisa.pdf
译者:phylips@bmy 2013-06-01
译文:http://duanple.blog.163.com/blog/static/70971767201352105348729/
[序:James Hamilton,连线,主页,blog。James Hamilton目前是亚马逊AWS的VP和杰出工程师,专注于基础设施的效率、可靠性和可伸缩性。
-
Why Do Computers Stop and What Can be Done About It
2013年5月18日 阅读(921)作者:Jim Gray 1985
原文:http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf
译者:phylips@bmy 2013-04-30
译文:http://duanple.blog.163.com/blog/static/7097176720134189481819/
[序:早在互联网出现以前,Tandem Computers 就已经构建了具有高度容错性和可用性的系统。Tandem Computers 是最早从事容错服务器制造的厂商,它制造的机器广泛应用在银行证券等在线处理交易领域。本文即是Jim Gray在Tandem Computers工作期间所撰写的,文中揭示了Tandem Computers 的“NonStop”神话所依赖的那些重要技术:isolation、failing fast、transactional updates、process pairs、supervision。同时提出了容错领域的很多重要概念,诸如:Availability 、Reliability 、MTBF、MTTR。虽然这篇文章是写在1985年,距今已30年,但是影响深远,其中的很多内容即使在今天看来依然非常有意义。
-
The Tail at Scale(译)
2013年4月5日 阅读(1,805)作者:Jeffrey Dean, Luiz André Barroso Google Inc 2013-2
原文:http://cacm.acm.org/magazines/2013/2/160173-the-tail-at-scale/fulltext
译者:phylips@bmy 2013-02-23
译文:http://duanple.blog.163.com/blog/static/7097176720133511217445/
序
那些可以对用户动作进行快速响应(100ms以内)的系统与那些响应慢的系统相比,可以提供更自然流畅的体验。随着Internet连通性的提高以及warehouse-scale 计算系统的出现,使得web服务可以在访问存在数千台服务器上的TB级数据的同时还能保持流畅的响应;比如Google搜索系统会根据用户类型对查询结果进行交互式更新,会基于用户当前已经输入的前缀预测用户查询意图,在数十毫秒的时间内执行该查询并完成结果展示。新兴的增强现实(augmented-reality )设备(比如Google Glass)为保证无缝的交互,对相关web服务的快速响应提出了更高要求。