分类存档: 分布式

时间戳实现

分布式事务中时间戳是非常关键的点,来解决版本控制和事务顺序。整理几种常见的时间戳机制。

Hybrid Logical Clock (HLC)

HLC 将时间戳分成物理(高位)和逻辑(低位)两部分,物理部分对应 UNIX 时间戳,逻辑部分对应 Lamport 时钟。在同一毫秒以内,物理时钟不变,而逻辑时钟就和 Lamport 时钟一样处理——每当发生信息交换(RPC)就需要更新时间戳,从而确保操作与操作之间能够形成一个偏序关系;当下一个毫秒到来时,逻辑时钟部分归零。
HLC 的正确性其实是由 Logical Clock 来保证的:它相比 Logical Clock 只是在每个毫秒引入了一个额外的增量,显然这不会破坏 Logical Clock 的正确性。但是,物理部分的存在将原本无意义的时间戳赋予了物理意义,提高了实用性。

缺陷:

可以保证同一个进程内部事件的时钟顺序,但是解决不了系统外事件发生的逻辑前后顺序与物理时间前后顺序的一致性,因此做不到Linearizability,也就做不到外部一致性。

行业公司:

YugabyteDB,Cockroach

TrueTime

可以做到外部一致性,同时能做到全球化部署。
可线性化:支持原子读取和写入操作的并发对象。
每个数据中心有若干个time master机器。大部分time master机器安装了GPS天线和接收器。剩下的time master机器安装了原子钟。time master之间会相互校验时间,如果某个time master发现自己的本地时间和其他time master相比差异很大,会把自己设置为离线,停止工作。客户端向多个time master查询,防止某个time master出现故障影响结果

行业公司

Google

TSO

全局集中式授时服务,对网络要求比较高,不能跨地域,理论上可以做到外部一致性;
TSO的全局版本号由 physical time + logical time 两个部分组成。
physical time :真实的时间戳,毫秒级
logical time:毫秒之外的逻辑时间
整体的方案是跟HLC差不多的。
TSO节点是位于PD模块,通过raft来保障可用性。

行业公司:

TIDB



阅读全文…

kafka2.0源码计划之-broker总览

用了近两年的kafka 0.10.1.1版本后,我们终于要废弃它了。在这个版本上,可以说是吃尽了苦头,其中的问题有自身对于kafka的理解不深入,也有kafka自己的bug问题。当流量小的时候,一切看起来都是那么美好,当流量到千亿级别时候,就是另一回事情。

阅读全文…

Flume – 0.9.4 解析

现在自己手上维护的一个项目是基于Flume0.9.4这个版本做的数据传输,所以必须去了解下Flume这个版本的一些设计.下面提到的Flume都指0.9.4这个版本,除非特别指出是其他版本。
这个世界上,没有坏的工具,只有把工具用坏的人。能做一个简单系统的才是牛逼的人。做设计其实跟读书没什么不同,读书的过程是先把书读厚,再读薄,设计也是如此,先把系统做复杂,再把系统做简单。
这篇不会按部就班的去解构Flume的一些东西,没什么意义。会按照自己的理解过程来做剖析。

阅读全文…

设计–断路器模式

一 面临问题

分布式服务的容错是一个不得不考虑的问题,通常的做法有两种。
重试机制:预期是因为一些短暂的故障问题,通过重试是可以解决的。
断路器模式:发生故障,而且故障是不可预期的,设置一个超时时间来等待返回结果,若是失败的话返回一个null值来解决服务调用。
继续延伸的看断路器充当可能失败操作的代理。代理应监测最近发生的故障数量,然后使用这个信息来决定是否允许该操作继续进行,或简单地立即返回一个异常。

阅读全文…

HDFS

HDFS能解决的问题
1.可以存储几百万个大型文件,每个文件可以超过几十G,文件系统的容量可以达数十PB
2.利用横向扩展模式,使用基于磁盘簇而非磁盘整列的普通商用服务器实现大规模数据存储,同时在应用层完成数据的复制以实现存储的可用性和高吞吐量。
3.优化是针对大型文件的流式读写处理,而非满足小文件的低延时访问。批量的处理能力比互动响应的实时性更加重要
4.能容忍机器某些部件故障和磁盘失效
5.支持M/P处理锁需要的功能和规模要求

阅读全文…

zookeeper的简单集群搭建

1.zookeeper安装和使用
包下载地址 :http://zookeeper.apache.org/releases.html#download

阅读全文…