1 简介

Protobuf 是由 Google 设计的一种高效、轻量级的信息描述格式,起初是在 Google 内部使用,后面开源,它具有语言中立、平台中立、高效、可扩展等特性,它非常适合用来做数据存储、RPC 数据交换等。与 json、xml 相比, Protobuf 的编码长度更短、传输效率更高,其实严格意义上讲,json、xml、并非是一种「编码」,而只能称之为「格式」,json、xml 的内容本身都是字符形式,它们的编码采用的是 ASCII 编码。

- xml json protobuf
数据结构 结构一般复杂 结构简单 结构比较复杂
数据存储方式 文本 文本 二进制
数据存储大小 大 一般 小
解析效率 慢 一般 快
跨语言支持 非常多 多 一般
开发成本 比较繁琐 非常简单 一般
学习成本 一般 低 一般

一旦定义了要处理的数据的数据结构之后,就可以利用 Protobuf 的代码生成工具生成相关的代码。只需使用 Protobuf 对数据结构进行一次描述,即可利用各种不同语言 (proto3 支持 C++、Java、Python、Go、Ruby、Objective-C、C#) 或从各种不同流中对你的结构化数据轻松读写。

本文讲述 Protobuf 的底层编码原理,以便于了解 Protobuf 为什么编码长度短并且扩展性强,与此同时我们也将了解到它有哪些不足?

Read more »

摘要

Bigtable 是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的 PB 级的数据。Google 的很多项目使用 Bigtable 存储数据,包括 Web 索引、Google Earth、Google Finance。这些应用对 Bigtable 提出的要求差异非常大,无论是在数据量上(从 URL 到网页到卫星图像)还是在响应速度上(从后端的批量处理到实时数据服务)。尽管应用需求差异很大,但是,针对 Google 的这些产品,Bigtable 还是成功的提供了一个灵活的、高性能的解决方案。本论文描述了 Bigtable 提供的简单的数据模型,利用这个模型,用户可以动态的控制数据的分布和格式;我们还将描述 Bigtable 的设计和实现。

Read more »

1 硬盘存储知识

计算机的主存基本都是随机访问存储器 (Random-Access Memory,RAM),分为两类:静态随机访问存储器(SRAM)和动态随机访问存储器(DRAM)。SRAM 比 DRAM 快,但是也贵的多,一般作为 CPU 的高速缓存,DRAM 通常作为内存。这类存储器他们的结构和存储原理比较复杂,基本是使用电信号来保存信息的,不存在机械操作,所以访问速度非常快,具体的访问原理可以查看 CSAPP,另外,他们是易失的,即如果断电,保存 DRAM 和 SRAM 保存的信息就会丢失。

Read more »

1 背景

对于存储介质为磁盘或 SSD 的数据库,长期以来主流使用 B + 树这种索引结构来实现快速数据查找。当数据量不太大时,B + 树读写性能表现非常好。但是在海量数据情况下,B + 树越来越高,由于 B + 树更新和删除数据时需要沿着 B + 树逐层进行页分裂和页合并,严重影响数据写入性能。为了应对这种情况,google 在论文《Bigtable: A Distributed Storage System for Structured Data》中介绍了一种新的数据组织结构 LSM Tree(Log-Structured Merge Tree),随后,Bigtable 主要作者 Jeffrey Dean 和 Sanjay Ghemawat 开源了一款基于 LSM Tree 实现的数据库 LevelDB,让大家对 LSM Tree 的思想和实现理解得更为透彻、深入。当前,比较流行的 NoSQL 数据库,如 Cassandra、RocksDB、HBase、LevelDB 等,newSQL 数据库,如 TiDB,均是使用 LSM Tree 来组织磁盘数据的。

Read more »

1 引言(什么是 Paxos)

分布式系统流行的当下,集群的机器总会发生诸如机器宕机或网络异常(还有消息延迟、丢失、重复、乱序)等问题。分布式式一致性(强一致性)算法就是在系统中出现以上异常情况时,如何快速且正确地在集群内部对某个数据或者命令达成一致,并且保证不会破坏整个集群的一致性。Paxos 就是此类算法中一种,并且在分布式领域有着非常重要的地位。

Paxos 算法是基于消息传递且具有高度容错特性的一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。

Read more »

1 引言

分布式系统(Distributed System)已经变得非常常见和重要,现在市面上的大型网站与一些重要的系统几乎都是分布式的。

分布式系统最大的难点就是各个节点的状态如何同步。CAP 理论就是这方面的基本定理,也是理解分布式的起点。

2000 年 7 月,加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。两年后,麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后,CAP 理论正式成为分布式计算领域的公认定理。

Read more »

1 什么是布隆过滤器

布隆过滤器 (BloomFilter) 是 1970 布隆(Burton Howard Bloom )提出的,它是一种节省空间(space efficient)的概率性数据结构,为一个很长的二进制向量,主要用于判断一个元素是否在一个集合中。相比于我们平时常用的的 List、Map 、Set 等数据结构,它占用空间更少并且效率更高,但是缺点是其返回的结果是概率性的,而不是非常准确的。理论情况下添加到集合中的元素越多,误报的可能性就越大。并且,存放在布隆过滤器的数据不容易删除。

在程序的世界中,布隆过滤器是程序员的一把利器,利用它可以快速地解决项目中一些比较棘手的问题。如网页 URL 去重、垃圾邮件识别、大集合中重复元素的判断和缓存穿透等问题。

Read more »

1 实际场景

1.1 发送提示信息

考虑一个发送提示消息的实际业务功能。基本所有带业务流程处理的系统都会有这样的功能。

从业务上来看,消息可以分为普通消息、加急消息、特急消息多种。不同的消息类型,业务功能处理逻辑不一样。如:加急消息会在消息上添加加急;特急消息处理在消息上添加特急标识之外,还在会另外发送一条催促的消息。其中发送消息的方式可以分为系统消息,手机消息,邮件等。

如何实现?

Read more »

1 实际场景

1.1 日志管理系统

考虑一个记录日志的应用,由于用户对日志记录的要求很高,使得开发人员不能简单的采用一些已有的日志工具或日志框架来满足用户的要求,而需要按照用户的要求重新开发新的日志管理系统。为案例展示,只是抽取跟适配器模式相关的部分来讲述。

Read more »

1 实际场景

1.1 代码模板生成

很多平台代码工具可以根据配置生成相应的模板代码,用户则只需要关注特定的业务功能实现,降低用户使用的复杂度以及提高效率。

假设生成的模板代码都具有基本的三层架构,即:表现层、逻辑层和数据层,所以代码生成工具应该具有相应代码生成的处理模块,另外代码工具还需要有相应的配置管理模块,定义配置模板,用来决定生成代码的逻辑。

如何实现该代码生成工具?

Read more »