为什么比特币可以防篡改 · Why's THE Design?

如果我们对比特币等区块链技术稍有了解,就会发现它是一个设计巧妙的分布式数据库。作为在公网运行的分布式数据库,比特币和其它区块链网络都会面对网络中的恶意节点的攻击。因为比特币需要面对复杂的网络环境以及不可靠的节点,所以它在设计和实现上也做出了应对,我们可以看看它是如何组合现有的技术防止恶意节点对交易和账户数据进行篡改的。 »

为什么你应该使用 Git 进行版本控制 · Why's THE Design?

Git 是 Linus 在 2005 年开发出的版本控制系统(Version Control System),演化至今已经成为了最流行和最先进的开源版本控制工具,不过仍然有很多的公司和团队还在使用 SVN 或者 CVS 对项目进行版本控制,部分公司确实有一些可能合理的原因来维持现状,但是使用 Git 在绝大多数的场景下都能让我们的开发和合作变得更加高效。很多关于 Git 与其他版本控制工具的对比文章和讨论都已经有着相当久的年头了,我们目前面对的开发场景与几年前有很多不同,而这些不同的版本控制工具也各自演化,不过作者始终认为 Git 是目前最高效的工具,这都是由顶层的设计思想决定的,我们今天就来看一看『为什么你应该使用 Git 进行版本控制』。 »

高可用分布式存储 etcd 的实现原理

etcd 是一个定可信赖的分布式键值存储服务,它能够为整个分布式集群存储一些关键数据,协助分布式集群的正常运转。这篇文章将会介绍 etcd 的实现原理,其中包括 Raft 协议、存储两大模块,在最后我们也会简单介绍 etcd 一些具体应用场景,例如:服务发现、发布订阅、分布式锁以及分布式协调等功能。 »

详解分布式协调服务 ZooKeeper

我们在这篇文章中简单介绍了 Google 的分布式锁服务 Chubby 以及同样能够提供分布式锁服务功能的 Zookeeper。作为分布式协调服务,Zookeeper 的应用场景非常广泛,不仅能够用于服务配置的下发、命名服务、协调分布式事务以及分布式锁,还能够用来实现微服务治理中的服务注册以及发现等功能,这些其实都源于 Zookeeper 能够提供高可用的分布式协调服务,能够为客户端提供分布式一致性的支持。 »

分布式系统与消息的投递

消息是一个非常有趣的概念,它是由来源发出一个离散的通信单元,被发送给一个或者一群接受者,无论是单体服务还是分布式系统中都有消息的概念,只是这两种系统中传输消息的通道方法或者通道不同;单体服务中的消息往往可以通过 IO、进程间通信、方法调用的方式进行通信,而分布式系统中的远程调用就需要通过网络,使用 UDP 或者 TCP 等协议进行传输。我们一般都会认为,消息的投递语义有三种,分别是最多一次(At-Most Once)、最少一次(At-Least Once)以及正好一次(Exactly Once),文章分别会介绍这三种消息投递语义究竟是如何工作的。 »

分布式事务的实现原理

事务是数据库系统中非常有趣也非常重要的概念,它是数据库管理系统执行过程中的一个逻辑单元,它能够保证一个事务中的所有操作要么全部执行,要么全不执行;在 SOA 与微服务架构大行其道的今天,在分布式的多个服务中保证业务的一致性就需要我们实现分布式事务。从广义上来看,分布式事务其实也是事务,只是由于业务上的定义以及微服务架构设计的问题,所以需要在多个服务之间保证业务的事务性,也就是 ACID 四个特性;从单机的数据库事务变成分布式事务时,原有单机中相对可靠的方法调用以及进程间通信方式已经没有办法使用,同时由于网络通信经常是不稳定的,所以服务之间信息的传递会出现障碍。 »

分布式键值存储 Dynamo 的实现原理

这篇文章会分析 Amazon 开发的分布式数据库 Dynamo 的实现,同时还会介绍 Dynamo 的设计理念以及架构等问题,还会就其中的部分问题与 Bigtable 中相对应的概念进行对比,这样能够让我们更加清楚地了解不同的数据库对不同问题,因设计理念的差异做出的权衡。 »

浅析 Bigtable 和 LevelDB 的实现

在 2006 年的 OSDI 上,Google 发布了名为 Bigtable 的论文,其中描述了一个用于管理结构化数据的分布式存储系统 Bigtable 的数据模型、接口以及实现等内容。本文会先对文中描述的分布式存储系统进行简单的描述,然后对 Google 开源的 KV 存储数据库 LevelDB 进行分析;LevelDB 可以理解为单点的 Bigtable 的系统,虽然其中没有 Bigtable 中与 tablet 管理以及一些分布式相关的逻辑,不过我们可以通过对 LevelDB 源代码的阅读增加对 Bigtable 的理解。 »