杰特JET的博客

PivotalGreenplum Database(GPDB)**Greenplum Database(GPDB)**是一款基于开源 PostgreSQL 扩展的 MPP(massively parallel processing)，可支持大规模水平扩展的分布式数据库。 GPDB 采用的是 master-worker 模式，每个 worker process 运行在不同的机器上，拥有各自的存储和运算资源。**客户端通过 master 把查询语句分发到各个机器上，以达到并行计算来处理海量数据。**集群节点

分布式事务的原子性保证实现事务原子性的协议面向应用层的 TCC2PC 数据库领域最常用的事务方案两者比较改进Percolator (NewSQL)PGXC如果分开来看的话，事务可以理解为包含一系列操作的序列，原子则代表不可分割的最小粒度。而合起来看的话，事务的原子性就是让包含若干操作的事务表现得像一个最小粒度的操作。这个操作一旦被执行，只有“成功”或者“失败”这两种结果。这就好像比特（bit），只能代表 0 或者 1，没有其他选择。关于事务的原子性，图灵奖得主、事务处理大师詹姆斯·格雷（Jim Gr

分布式文件系统HDFS解析设计目标Namenode 和 DatanodeHDFS HAHDFS Federation读写流程Replication元数据副本均衡元数据磁盘错误快照流水线复制参考链接HDFS作为分布式文件系统，主要是为了方便海量上层计算节点存取而设计的。提供posix api，将元数据（存放在NameNode）和数据（存放在DataNodes）分开存放。所有Node之间通过tcp通信。设计目标存储非常大的文件：这里非常大指的是几百M、G、或者TB级别。实际应用中已有很多集群存储的数据

理解zookeeper的一致性及缺点综述zookeeper保证理解zookeeper的顺序一致性zookeeper的缺点参考链接综述zookeeper不是为高可用性设计的，但它使用ZAB协议达到了极高的一致性。所以它经常被选作注册中心、配置中心、分布式锁等场景。zookeeper是最终一致性系统，而很多实际应用需要保证强一致。zookeeper保证根据zookeeper官方文档，zookeeper提供了如下保证：Sequential Consistency - Updates from a cl

Amazon Aurora 论文解读复制与一致性计算与存储分离架构存储引擎基本操作WritesCommitsReadsReplicas总结Aurora是一个OLTP的分布式数据库。Amazon认为随着分布式系统的发展以及架构的演进，传统数据库的磁盘IO瓶颈已经变成了计算存储分离架构下网络IO（以及事务先关的IO处理的过程）。的Aurora通过计算节点和存储节点分离，计算节点scale up，存储节点scale out的理念将公有云的关系数据库产品推向了一个新的高度。传统关系数据库三宗罪，扩展性、可

Google Spanner 论文笔记架构复制与一致性TrueTime事务数据迁移Google Spanner是谷歌的全球级分布式数据库（Golbally-Distributed Database）。Spanner的扩展性达到了全球级，可以扩展到数百个数据中心，数百万台机器，上万亿行数据，除了夸张的可扩展性之外，他还能通过同步复制和多版本控制MVCC来满足外部一致性。支持垮数据中心的事务。是一个大规模分布式技术和传统关系型数据库技术的完美融合。架构Spanner的模型和MegaStore系统较为相似

Microsoft SQL Azure本笔记出自论文《Extreme Scale with Full SQL Language Support in Microsoft SQL Azure》和一些网络资料。论文在开头就提到了，很多互联网行业做出的存储产品如Google Bigtable、Yahoo PNUTS、Amazon Dynamo等，其提供的ACID事务、一致性保证是和传统的关系型数据库有很大区别的。互联网行业通过其上层业务的抽象，将一致性及事务限制在特定的consistency domain中，从

谷歌GFS论文笔记前言masterchunkserver一致性模型data integrity下线mmap读写锁FAQ参考链接前言本篇文章主要讲解谷歌经典论文The Google File System，它构建在廉价的普通pc服务器上，并且可以自动容灾容错。其对于整个存储界具有里程碑的意义。masterGFS 为了简化设计，在整个系统中只有一个 master 进行管理。Master 不提供读写操作，它只会告诉 client，它所请求操作的文件在哪个 chunkserver 上，然后 clien

分布式事务简介事务BASE理论2PC第一阶段：投票阶段第二阶段：提交/执行阶段（成功流程）第二阶段失败回滚流程2pc可能出现的三种问题3PCTCC悲观锁与乐观锁参考链接事务BASE理论BASE 理论是 Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。基本可用（Basically Available）：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。软状态（Soft State）

Windows Azure Storage论文解读整体架构文件流层 stream layer存储引擎存储优化分区层 Partition Layer存储引擎WAS总结WAS是微软开发的云存储系统，提供Blob、Table、Queue三种类型的服务，它广泛部署与微软内部。其论文发表于2011年SOSP。整体架构WAS主要分为两个部分：定位服务（Location Service LS）和存储区（Storage Stamp）定位服务管理用户到存储区之间的映射，负责负载均衡，并且服务跨地域、高可用存储

不使用zookeeper的kafka集群前言ZooKeeper的缺点Kakfa Without ZooKeeper简介Kakfa Without ZooKeeper的优势总结参考链接前言大名鼎鼎的Kafka作为最出名的消息处理中间件，Zookeeper在其中提供一致性服务，并且承担了选主、服务发现、服务注册、存储各种Kafka的各种元数据。随着Kafka的演进，Kafka自己也变成了一个复杂的分布式系统，它和zookeeper一样，都对外提供一致性服务。Kafka在其系统内再维护一套zookeepe

副本放置策略CopySet论文解读及工程实践概述CopySet论文解读术语定义Random ReplicationCopyset ReplicationPremutationReplication工程实践参考链接概述分布式存储追求在系统成本允许的范围内（一般存储集群都是三副本，还想方设法的使用条带化、压缩等方式降低成本），降低数据丢失的概率，降低故障恢复的时间。好的副本放置策略可以优化整个集群的可用性和一致性。斯坦福大学曾经出过一篇论文，Copysets: Reducing the Frequenc

Google Megastore介绍概述策略对比异步主从 Asynchronous Master/Slave同步主从 Synchronous Master/Slave乐观复制 Optimistic ReplicationMegastore的选择Megastore系统架构实体组EG并发控制（事务）读事务写事务索引协调者读写流程读流程写流程Megastore总结概述Megastore是在Bigtable的基础上提供了友好的数据库功能支持。是介于关系型数据库（RDBMS）和NoSQL之间的存储技术。其引入了

分布式表格系统Google Bigtable详解概述Bigtable架构数据分布保证副本位置与负载均衡存储表的分裂与合并存储引擎垃圾回收总结概述bigtable系统由表格组成，每行有一个主键（Row Key），每行又包含很多列(Column)，某一行的某一列构成一个单元（Cell），每个单元包含多个版本的数据。整体上看，Bigtable是一个分布式多维映射表：(row:string,column:string,timestamp:int64)−>string(row:string, colum

分布式键值系统Amazon Dynamo简介@[TOC](分布式键值系统Amazon Dynamo简介)Dynamo采用的技术虚拟节点Gossip协议NRWVector Clock读写流程参考链接Dynamo采用的技术问题采用的技术数据分布改进的一致性哈希（DHT），采用了虚拟节点技术复制协议复制写协议（Replicated-write protocal，NRW参数可调）数据冲突处理向量时钟临时故障处理数据回传机制（Hinted handoff）永久故

一致性协议paxos和raft的异同前言leader选举日志同步Commit Index推进崩溃恢复成员变更前言我一直在讲学习paxos和raft最好的方式就是看作者的论文和视频，只有看原滋原味的文章，才能真正体会到作者的设计思路，才能在现代繁杂的工程实践中抓住精髓。这篇文章作为系列文章的最后一篇，我想谈谈paxos与raft的异同。算法在变，但是其中的核心思想是不变的。一致性协议raft详解（一）：raft整体介绍一致性协议raft详解（二）：安全性一致性协议raft详解（三）：raft中的

一致性协议Paxos详解（三）：Multi-Paxos的优化前言Multi-Paxos leader 优化client的规则client的保证幽灵复现OceanBase为何采用paxos前言有关一致性协议的资料网上有很多，当然错误也有很多。笔者在学习的过程中走了不少弯路。现在回过头来看，最好的学习资料就是Leslie Lamport和Diego Ongaro的数篇论文、Ongaro在youtube上发的三个视频讲解，以及何登成的ppt。本系列文章是只是笔者在学习一致性协议过程中的摘抄和总结，有疏漏之处

一致性协议Paxos详解（二）：Multi-Paxos协议流程详解前言Multi-Paxos什么是Multi-PaxosMulti-Paxos 介绍accpectoracceptor持久化状态proposerproposer持久化的状态proposer存储的易失状态rpc流程及优化1. prepare2. accept3. SuccessMulti-Paxos系统消息流程 *write(inputValue) → bool*集群变动 Reconfiguration前言有关一致性协议的资料网上有很多，当然

一致性协议Paxos详解（一）：Basic Paxos协议详解前言Paxos是什么Paxos算法原理与推导Basic PaxosProposal Numbersprepare阶段prepare阶段的意义Accept阶段paxos算法的关键特性safetylivenessnotesBasic Paxos 只负责达成一个决议薛定谔的提案与2pc的关系参考链接前言有关一致性协议的资料网上有很多，当然错误也有很多。笔者在学习的过程中走了不少弯路。现在回过头来看，最好的学习资料就是Leslie Lamport和D

一致性协议raft详解（四）：raft在工程实践中的优化前言性能优化client对raft集群的读写参考链接前言有关一致性协议的资料网上有很多，当然错误也有很多。笔者在学习的过程中走了不少弯路。现在回过头来看，最好的学习资料就是Leslie Lamport和Diego Ongaro的数篇论文、Ongaro在youtube上发的三个视频讲解，以及何登成的ppt。本系列文章是只是笔者在学习一致性协议过程中的摘抄和总结，有疏漏之处敬请谅解，欢迎讨论。性能优化TiKV 源码解析系列 - Raft 的优化

介绍Raft中使用到的RPC的类型

一致性协议raft详解（一）：raft介绍前言安全性log recovery为什么no-op能解决不一致的问题？成员变更Single mempership changeraft用到的随机时间raft 脑裂数据到达 Leader 节点前数据到达 Leader 节点，但未复制到 Follower 节点数据到达 Leader 节点，成功复制到 Follower 所有节点，但还未向 Leader 响应接收数据到达 Leader 节点，成功复制到 Follower 部分节点，但还未向 Leader 响应接收前言有

一致性协议raft详解（一）：raft介绍前言概述raft独特的特性raft集群的特点raft中commit何意？raft leader electionlog replication网络分区Symmetric network partitioningAsymmetric network partitioningStepDownraft冲突解决方法前言有关一致性协议的资料网上有很多，当然错误也有很多。笔者在学习的过程中走了不少弯路。现在回过头来看，最好的学习资料就是Leslie Lamport和Dieg

raft引入no-op解决了什么问题1. 问题的由来2. 引入no-op之后3. 总结4. 参考链接1. 问题的由来raft论文In Search of an Understandable Consensus Algorithm中的figure8描述了如下场景，可能会违反raft协议的一致性保证。(a):S1是Term2的Leader，将LogEntry部分复制到S1和S2的2号位置，然后Crash。(b):S5被S3、S4和S5选为Term3的Leader，并只写入一条LogEntry到本地