yogabytedb调研

引自 https://ericfu.me/yugabyte-db-introduction/

系统架构

逻辑上,Yugabyte 采用两层架构:查询层和存储层。不过这个架构仅仅是逻辑上的,部署结构中,这两层都位于 TServer 进程中。这一点和 TiDB 不同。

Yugabyte 的查询层支持同时 SQL 和 CQL 两种 API,其中 CQL 是兼容 Cassandra 的一种方言语法,对应于文档数据库的存储模型;而 SQL API 是直接基于 PostgresQL 魔改的,能比较好地兼容 PG 语法,据官方说这样可以更方便地跟随 PG 新特性,有没有官方说的这么美好我们就不得而知了。

Yugabyte 的存储层才是重头戏。其中 TServer 负责存储 tablet,每个 tablet 对应一个 Raft Group,分布在三个不同的节点上,以此保证高可用性。Master 负责元数据管理,除了 tablet 的位置信息,还包括表结构等信息。Master 本身也依靠 Raft 实现高可用。

img

基于 Tablet 的分布式存储

这一部分是 HBase/Spanner 精髓部分,Cockroach/TiDB 的做法几乎也是一模一样的。如下图所示,每张表被分成很多个 tablet,tablet 是数据分布的最小单元,通过在节点间搬运 tablet 以及 tablet 的分裂与合并,就可以实现几乎无上限的 scale out。每个 tablet 有多个副本,形成一个 Raft Group,通过 Raft 协议保证数据的高可用和持久性,Group Leader 负责处理所有的写入负载,其他 Follower 作为备份。

下图是一个例子:一张表被分成 16 个 tablet,tablet 的副本和 Raft Group leader 均匀分布在各个节点上,分别保证了数据的均衡和负载的均衡。

img

和其他产品一样,Master 节点会负责协调 tablet 的搬运、分裂等操作,保证集群的负载均衡。这些操作是直接基于 Raft Group 实现的。这里就不再展开了。

有趣的是,Yugabyte 采用哈希和范围结合的分区方式:可以只有哈希分区、也可以只有范围分区、也可以先按哈希再按范围分区。之所以这么设计,猜测也是因为 Cassandra 的影响。相比之下,TiDB 和 Cockroach 都只支持范围分区。

哈希分区的方式是将 key 哈希映射到 2 字节的空间中(即 0x00000xFFFF),这个空间又被划分成多个范围,比如下图的例子中被划分为 16 个范围,每个范围的 key 落在一个 tablet 中。理论上说最多可能有 64K 个 tablet,这对实际使用足够了。

img

哈希分区的好处是插入数据(尤其是从尾部 append 数据)时不会出现热点;坏处是对于小范围的范围扫描(例如 pk BETWEEN 1 AND 10)性能会比较吃亏。

基于 RocksDB 的本地存储

每个 TServer 节点上的本地存储称为 DocDB。和 TiDB/Cockroach 一样,Yugabyte 也用 RocksDB 来做本地存储。这一层需要将关系型 tuple 以及文档编码为 key-value 保存到 RocksDB 中,下图是对文档数据的编码方式,其中有不少是为了兼容 Cassandra 设计的,我们忽略这些,主要关注以下几个部分:

  • key 中包含
  • 16-bit hash:依靠这个值才能做到哈希分区
  • 主键数据(对应图中 hash/range columns)
  • column ID:因为每个 tuple 有多个列,每个列在这里需要用一个 key-value 来表示
  • hybrid timestamp:用于 MVCC 的时间戳
  • value 中包含
  • column 的值

img

如果撇开文档模型,key-value 的设计很像 Cockroach:每个 cell (一行中的一列数据)对应一个 key-value。而 TiDB 是每个 tuple 打包成一个 key-value。个人比较偏好 TiDB 的做法。

分布式事务:2PC & MVCC

和 TiDB/Cockroach 一样,Yugabyte 也采用了 MVCC 结合 2PC 的事务实现。

时间戳

时间戳是分布式事务的关键选型之一。Yugabyte 和 Cockroach 一样选择的是 Hybrid Logical Clock (HLC)。

HLC 将时间戳分成物理(高位)和逻辑(低位)两部分,物理部分对应 UNIX 时间戳,逻辑部分对应 Lamport 时钟。在同一毫秒以内,物理时钟不变,而逻辑时钟就和 Lamport 时钟一样处理——每当发生信息交换(RPC)就需要更新时间戳,从而确保操作与操作之间能够形成一个偏序关系;当下一个毫秒到来时,逻辑时钟部分归零。

不难看出,HLC 的正确性其实是由 Logical Clock 来保证的:它相比 Logical Clock 只是在每个毫秒引入了一个额外的增量,显然这不会破坏 Logical Clock 的正确性。但是,物理部分的存在将原本无意义的时间戳赋予了物理意义,提高了实用性。

个人认为,HLC 是除了 TrueTime 以外最好的时间戳实现了,唯一的缺点是不能提供真正意义上的外部一致性,仅仅能保证相关事务之间的“外部一致性”。另一种方案是引入中心授时节点(TSO),也就是 TiDB 使用的方案。TSO 方案要求所有事务必须从 TSO 获取时间戳,实现相对简单,但引入了更多的网络 RPC,而且 TSO 过于关键——短时间的不可用也是极为危险的。

HLC 的实现中有一些很 tricky 的地方,比如文档中提到的 Safe timestamp assignment for a read request。对于同一事务中的多次 read,问题还要更复杂,有兴趣的读者可以看 Cockroach 团队的这篇博客 Living Without Atomic Clocks

事务提交

毫不惊奇,Yugabyte 的分布式事务同样是基于 2PC 的。他的做法接近 Cockroach。事务提交过程中,他会在 DocDB 存储里面写入一些临时的记录(provisional records),包括以下三种类型:

  • Primary provisional records:还未提交完成的数据,多了一个事务ID,也扮演锁的角色
  • Transaction metadata:事务状态所在的 tablet ID。因为事务状态表很特殊,不是按照 hash key 分片的,所以需要在这里记录一下它的位置。
  • Reverse Index:所有本事务中的 primary provisional records,便于恢复使用

img

事务的状态信息保存在另一个 tablet 上,包括三种可能的状态:Pending、Committed 或 Aborted。事务从 Pending 状态开始,终结于 Committed 或 Aborted。

事务状态就是 Commit Point 的那个“开关”,当事务状态切换到 Commited 的一瞬间,就意味着事务的成功提交。这是保证整个事务原子性的关键。

完整的提交流程如下图所示:

img

另外,Yugabyte 文档中提到它除了 Snapshot Isolation 还支持 Serializable 隔离级别,但是似乎没有看到他是如何规避 Write Skew 问题的。

参考

  1. Yugabyte DB
  2. Yugabyte DB Documents
  3. Living Without Atomic Clocks - Cockroach Labs
  4. https://ericfu.me/yugabyte-db-introduction/

Read More

一个查看函数调用的新方案-操作compliation database

最近在网上看到一篇抓堆栈的脚本工具介绍

工具还挺漂亮的,但是我的问题在于

  1. perl写的,还依赖魔改ag,首先我看不懂,其次部署使用稍微有点成本(我看评论区有人帮忙打包),然后是参数费解有点学习成本
    1. 主要是我看不懂,不是我写的,我可能就只会简单的查
  2. 调用细节可能不够清晰,虽然足够用了

所以有了两个想法

  1. 学一下perl,改写成python的工具?搜了一圈perl2python没有工具能用

  2. 能不能用clang的工具?


PS:如何导出compliation database,也就是compile_commands.json

我折腾了半天导出,但是我根本用不到,这里把折腾记录放在下面

compilation database是clang/llvm的一个功能,作为一个语言后端支持language support protocol,需要有能力导出符号

所有的标记符号可以汇总成这个compilation database (clangd就是这个功能,对解析好的compilation database进行服务化,支持IDE的查询)

背后的技术是libclang,也有很多例子,这里就不展开了,可以看这个链接

既然都能支持IDE,难道还不能支持简单的函数调用查看,调用图生成吗,我似乎找到了新方案

但是这些方案都躲不开编译一遍,虽然只是简单的parser一遍,没有那么慢, 后面如果有时间,改写成python更好一些

如果编译环境是bazel,有https://github.com/grailbio/bazel-compilation-database支持

简单来说,就是改项目的BUILD和WORKSPACE

BUILD要加上

## Replace workspace_name and dir_path as per your setup.
load("@com_grail_bazel_compdb//:aspects.bzl", "compilation_database")

compilation_database(
    name = "compdb",
    targets = [
        "yourtargetname",
    ],
)

这里target写你自己的target,可以多个target分割,name随便,这里我写成compdb

然后WORKSPACE要加上

http_archive(
    name = "com_grail_bazel_compdb",
    strip_prefix = "bazel-compilation-database-master",
    urls = ["https://github.com/grailbio/bazel-compilation-database/archive/master.tar.gz"],
)

最后编译

bazel build //path/yourtargetnamedir:compdb

就生成compile_commands.json了

其他编译环境,用bear

bear本身支持macos和linux,尝试命令行安装一下,安装不上的话源码安装

如果是makefile系列的编译系统,直接

bear -- make

就可以了,这里以memcached为例子

用python解析

PS:

如果遇到报错

    raise LibclangError(msg)
clang.cindex.LibclangError: dlopen(libclang.dylib, 6): image not found. To provide a path to libclang use Config.set_library_path() or Config.set_library_file().

说明找不到libclang,需要指定一下,比如

export DYLD_LIBRARY_PATH=/usr/local/Cellar/llvm/11.0.0/lib/

Read More

(译)关于Linux IO 持久性的讨论,以及page cache

这篇文章很有干货,整理一下 https://www.evanjones.ca/durability-filesystem.html

flag\action page cache buffer cache inode cache directory cache
O_DIRECT write bypass write bypass write & no flush write & no flush
O_DSYNC/fdatasync() write & flush write & flush write & no flush write & no flush
O_SYNC/fsync() write & flush write & flush write & flush write & flush
sync_file_range() write & flush write & flush no write no write

flag和函数的区别是:flag表示每次io操作都会执行,函数是在执行函数的时候触发;

O_Direct优劣势:

  • 优势:直接绕过page cache/buffer cache,节省操作系统内存;使用O_DIRECT方式提示操作系统尽量使用DMA方式来进行存储设备操作,节省CPU;
  • 劣势:字节对齐写(logic block size);无法进行IO合并;读写绕过cache,小数据读写效率低;

关于函数的问题

  • fsync遇到过bug ,fsync可能报错EIO,系统没把脏页刷盘,但数据库层认为刷完了,导致这段数据丢了 https://wiki.postgresql.org/wiki/Fsync_Errors
  • sync_file_range这里有个原理 ,不刷元数据!rocksdb会用这个来刷盘,看这个注释,额外再用fdatasync。除非你知道你在做什么,否则不要用这个api

作者总结

  • fdatasync or fsync after a write (prefer fdatasync).
  • write on a file descriptor opened with O_DSYNC or O_SYNC (prefer O_DSYNC).

  • pwritev2 with the RWF_DSYNC or RWF_SYNC flag (prefer RWF_DSYNC).

结论,推荐使用O_DSYNC/fdatasync()

一些关于随机(写)的性能观察

  • 覆盖写比追加写快(~2-100% faster) 追加写要原子修改元数据。
  • 和system call相比,用flag更省,性能更好(~5% faster)

page cache

系统对page cache的管理,在一些情况下可能有所欠缺,我们可以通过内核提供的posix_fadvise予以干预。

#include <fcntl.h>

int posix_fadvise(int fd, off_t offset, off_t len, int advice);

posix_fadvise是linux上对文件进行预取的系统调用,其中第四个参数int advice为预取的方式,主要有以下几种:

POSIX_FADV_NORMAL 无特别建议 重置预读大小为默认值 POSIX_FADV_SEQUENTIAL 将要进行顺序操作 设预读大小为默认值的2 倍 POSIX_FADV_RANDOM 将要进行随机操作 将预读大小清零(禁止预读) POSIX_FADV_NOREUSE 指定的数据将只访问一次 (暂无动作) POSIX_FADV_WILLNEED 指定的数据即将被访问 立即预读数据到page cache POSIX_FADV_DONTNEED 指定的数据近期不会被访问 立即从page cache 中丢弃数据

/proc/sys/vm/dirty_writeback_centisecs:flush检查的周期。单位为0.01秒,默认值500,即5秒。每次检查都会按照以下三个参数控制的逻辑来处理。

/proc/sys/vm/dirty_expire_centisecs:如果page cache中的页被标记为dirty的时间超过了这个值,就会被直接刷到磁盘。单位为0.01秒。默认值3000,即半分钟。

/proc/sys/vm/dirty_background_ratio:如果dirty page的总大小占空闲内存量的比例超过了该值,就会在后台调度flusher线程异步写磁盘,不会阻塞当前的write()操作。默认值为10%。

/proc/sys/vm/dirty_ratio:如果dirty page的总大小占总内存量的比例超过了该值,就会阻塞所有进程的write()操作,并且强制每个进程将自己的文件写入磁盘。默认值为20%。


ref

  • linux IOhttps://www.scylladb.com/2017/10/05/io-access-methods-scylla/ 这几个图画的还行。不过原理也比较简单。不多说
  • page cache https://www.jianshu.com/p/92f33aa0ff52

Read More


(译)分布式系统的模式

看到网友推荐这篇博客,整理归纳一下 https://martinfowler.com/articles/patterns-of-distributed-systems/

我发现有人翻译了,但是翻译的不全。 https://xie.infoq.cn/article/f4d27dd3aa85803841d050825

这里的分布式系统是指所有的系统,共性问题

Type of platform/framework Example
Databases数据库 Cassandra, HBase, Riak
Message Brokers消息队列 Kafka, Pulsar
Infrastructure基础架构元信息管理 Kubernetes, Mesos, Zookeeper, etcd, Consul
In Memory Data/Compute Grids网格 Hazelcast, Pivotal Gemfire
Stateful Microservices微服务 Akka Actors, Axon
File Systems文件系统 HDFS, Ceph

面临的共性问题

  • 进程崩溃
    • 配置文件修改导致的暂时下线(大公司已经出过很多起了)
    • 异常场景没处理,比如磁盘满
    • 云场景下的其他影响的场景

这些场景下如何处理数据丢失?解决方案:WAL

  • 网络延迟问题
    • 不知道其他进程的状态是否正常 解决方案: 心跳
    • 脑裂导致的数据冲突 解决方案 Quorum
  • 另一种异常,进程暂停,可能是内部在忙,没有及时响应,可能是gc引起的延迟等等

  • Generation Clock 我的理解就是term 推进,老master检测自己不是最新的index,就自动降低身份 也就是Lamport’s timestamp

  • 时间同步问题,ntp是不准的甚至是会出错的,有原子钟方案,也有lamport逻辑时钟方案

    (其实原子钟方案比较简单,一个gps原子钟七八万,我之前的老项目用过,这个成本对于互联网公司还好吧,为啥都不用呢,不方便部署么)

一个整合方案,以及涉及到具体的设计细节

WAL

首先是WAL 也就是commit log commit log要保证持久性

每个日志要有独立的标记,依此来分段整理,方便写,但是不能无限长,所以要有个Low-Water-Mark标记,其实就是后台线程定期删日志

日志更新就相当于队列追加写了,为了吞吐可能要异步一些

img

考虑如何实现这样一个kv;

首先kv得能序列化成log,并且能从log恢复

需要支持指定snapshot/timestap恢复,这两种是淘汰判定的标准,也就是一个unit

Low-Water-Mark实现方案

  • 基于快照snapshot,每次成功的写入index都是一次快照,快照落盘就过期,可以删掉 有点像生产消费

zookeeper etcd都是这个方案,代码类似下面

public SnapShot takeSnapshot() {
    Long snapShotTakenAtLogIndex = wal.getLastLogEntryId();
    return new SnapShot(serializeState(kv), snapShotTakenAtLogIndex);
}

//Once a snapshot is successfully persisted on the disk, the log manager is given the low water mark to discard the older logs.

List<WALSegment> getSegmentsBefore(Long snapshotIndex) {
    List<WALSegment> markedForDeletion = new ArrayList<>();
    List<WALSegment> sortedSavedSegments = wal.sortedSavedSegments;
    for (WALSegment sortedSavedSegment : sortedSavedSegments) {
        if (sortedSavedSegment.getLastLogEntryId() < snapshotIndex) {
            markedForDeletion.add(sortedSavedSegment);
        }
    }
    return markedForDeletion;
}
  • 基于时间,有点像日志轮转

kafka就是这种方案

private List<WALSegment> getSegmentsPast(Long logMaxDurationMs) {
    long now = System.currentTimeMillis();
    List<WALSegment> markedForDeletion = new ArrayList<>();
    List<WALSegment> sortedSavedSegments = wal.sortedSavedSegments;
    for (WALSegment sortedSavedSegment : sortedSavedSegments) {
        if (timeElaspedSince(now, sortedSavedSegment.getLastLogEntryTimestamp()) > logMaxDurationMs) {
            markedForDeletion.add(sortedSavedSegment);
        }
    }
    return markedForDeletion;
}

private long timeElaspedSince(long now, long lastLogEntryTimestamp) {
    return now - lastLogEntryTimestamp;
}

读取?一致性方案 quorum

读大多数 判定数据

写WAL - 复制组

复制组要保证高可用性 心跳检查,节点间心跳以及自身心跳处理,如果自身僵住需要退位

复制组有主从,涉及到选举算法 zab raft之类


Read More

arangodb初体验

arangodb也是多模数据库,支持文档和图两种,支持mongodb式的操作json语法,也支持类似sql的方法

简单体验一下

在macos上非常好体验,直接brew就能安装

brew install arangodb
brew serivces start arangodb
brew services stop arangodb

注意是有密码的,我这里直接把密码关掉了,参考这个文档, 修改arangodb.conf 把authentication改成false重启就可以了

可以网页访问 http://localhost:8529/_db/_system/_admin/aardvark/index.html#collections

arangodb也提供了命令行 arangosh

备份 https://www.arangodb.com/docs/stable/backup-restore.html

replication appler是什么概念?https://www.arangodb.com/docs/stable/http/replications-replication-applier.html


Read More

分布式系统中的一致性模型,以及事务

经典图

  • Unavailable: 当出现网络隔离等问题的时候,为了保证数据的一致性,不提供服务。熟悉 CAP 理论的同学应该清楚,这就是典型的 CP 系统了。
  • Sticky Available: 即使一些节点出现问题,在一些还没出现故障的节点,仍然保证可用,但需要保证 client 不能更换节点。
  • Highly Available: 就是网络全挂掉,在没有出现问题的节点上面,仍然可用。

并发事务在没有隔离性保证时会导致哪些问题:

  • Dirty Write 脏写 - 一个事务覆盖了另一个事务还没提交的中间状态
  • Dirty Read 脏读 - 一个事务读到了另一个事务还没提交的中间值
  • Non-Repeatable Read 不可重复读 - 一个事务中连续读取同一个值时返回结果不一样(中途被其他事务更改了)
  • Phantom 幻读 - 当一个事务按照条件C检索出一批数据,还未结束。另外的事务写入了一个新的满足条件C的数据,使得前一个事务检索的数据集不准确。
  • Lost Update 写丢失 - 先完成提交的事务的改动被后完成提交的事务覆盖了,导致前一个事务的更新丢失了。
  • Cursor Lost Update - Lost Update的变种,和Cursor操作相关。
  • Read Skew 偏读 - 事务在执行a+b期间,a,b值被其他事务更改了,导致a读到旧值,b读到新值
  • Write Skew 偏写 - 事务连续执行if(a) then write(b) 时, a值被其他事务改了,类似超卖。

可以看到,由于隔离型相关的问题其实都是并发竞争导致的,所以和「多线程安全」问题非常相像,思路和方案也是共通的。 现代数据库系统已经将并发竞争问题抽象为隔离级别(Isolation level)来处理 ,也就是 ACID中的I。接下来我们看一下常见的隔离级别,以及能提供的保证:

  • Read Uncommitted - 能读到另外事务未提交的修改。
  • Read Committed - 能读到另外事务已经提交的修改。
  • Cursor Stability - 使用 cursor 在事务里面引用特定的数据,当一个事务用 cursor 来读取某个数据的时候,这个数据不可能被其他事务更改,除非 cursor 被释放,或者事务提交。
  • Monotonic Atomic View - 这个级别是 read committed 的增强,提供了一个原子性的约束,当一个在 T1 里面的 write 被另外事务 T2 观察到的时候,T1 里面所有的修改都会被 T2 给观察到。
  • Repeatable Read - 可重复读,也就是对于某一个数据,即使另外的事务有修改,也会读取到一样的值。
  • Snapshot - 每个事务都会在各自独立,一致的 snapshot 上面对数据库进行操作。所有修改只有在提交的时候才会对外可见。如果 T1 修改了某个数据,在提交之前另外的事务 T2 修改并提交了,那么 T1 会回滚。
  • Serializable - 事务完全按照顺序依次执行,相当于强锁。

这是那个经典论文描述的场景 图片介绍。另外知乎有篇验证文章

一致性面临的问题

server端视角

  • 线性一致性(Linearizability)- 最强的单对象一致性模型,要求任何写操作都能立刻同步到其他所有进程,任何读操作都能读取到最新的修改。简单说就是实现进程间的 Java volatile 语义。这是一种对顺序和实时性都要求很高的模型。要实现这一点,要求将所有读写操作进行全局排序。
  • 顺序一致性(Sequential Consistency):在线性一致性上放松了对实时性的要求。所有的进程以相同的顺序看到所有的修改,读操作未必能及时得到此前其他进程对同一数据的写更新。
  • 因果一致性(Causal Consistency):进一步放松了顺序要求,提高了可用性。读操作有可能看到和写入不同的顺序 。只对附加了因果关系的写入操作的顺序保证顺序性。“逻辑时钟”常用来为操作附加这种因果关系。
  • PRAM一致性(Pipeline Random Access Memory) :多进程间顺序的完全放松,只为单个进程内的写操作保证顺序,但不保证不同的写进程之间的顺序。这种放松可以大幅提高并发处理能力。例如Kafka保证在一个分区内读操作可以看到写操作的顺序 ,但是不同分区间没有任何顺序保证。

client端视角

  • 单调读一致性(Monotonic-read Consistency),如果一个客户端读到了数据的某个版本n,那么之后它读到的版本必须大于等于n。
  • 单调写一致性(Monotonic-write Consistency),保证同一个客户端的两个不同写操作,在所有副本上都以他们到达存储系统的相同的顺序执行。单调写可以避免写操作被丢失。
  • 写后读一致性、读己之写一致性(Read-your-writes Consistency),如果一个客户端写了某个数据的版本n,那么它之后的读操作必须读到大于等于版本n的数据。
  • 读后写一致性(Writes-follow-reads Consistency)保证一个客户端读到版本n数据后(可能是其他客户端写入的),随后的写操作必须要在版本号大于等于n的副本上执行。

PRAM一致性(Pipeline Random Access Memory)完全等同于读你的写、单调写和单调读。如果要追求读后写一致性,只能选择因果一致性。如果你需要完全的可用性,可以考虑牺牲阅读你的写,选择单调读 + 单调写。

分布式系统中的时间和顺序 Time and order

  • 时间和顺序
    • 像单机系统一样有同样的执行顺序
  • 全局有序和偏序
  • 什么是时间
  • 分布式节点的时间相同吗
    • 全局时钟
    • 本地时钟
    • 无时钟
  • 时间在分布式系统中的作用
    • 定义系统中的顺序
      • 系统的正确性取决于正确的顺序
      • 冲突协调需要顺序作为评判标准
    • 定义边界条件(故障检测器)
  • 矢量时钟(计数器+通信)
    • Lamport Clock
    • Vector Clock
  • 故障检测(心跳+定时器)
  • 时间,顺序和性能
    • 分布式系统天生是偏序的
    • 全局有序需要额外的通信
    • 利用Single Node 可降低顺序保证难度(将需要有序的操作部分放在单个节点上同步执行)

复制:强一致性模型

  • 复制
    • 复制要解决的是一组通信问题
      • 什么样的通信模式可以提供所需的性能和可用性?
      • 当网络分区或节点崩溃,如何保证容错性、持久性和一致性?
    • 复制的四个阶段
      • 客户端发送请求
      • 复制中的同步部分执行
      • 向客户端返回答复
      • 复制中的异步部分执行
  • 同步复制
    • 是一种悲观复制
    • 性能取决于最慢的一个节点(N of N)
    • 提供很好的持久性和一致性保证
  • 异步复制
    • 是一种乐观复制
    • 性能很快 (1 of N)
    • 提供很弱的持久性和一致性保证
  • 主要复制方法
    • 防止分歧的 Single-Copy Systems
    • 允许分歧的 Multi-Master Systems
  • Primay-Backup 主备复制协议
    • 异步主备复制(只需要一条信息 :更新)
    • 同步主备复制(需要两条信息:更新+确认收到)
      • 仍然需要额外的协调来应对故障,保证持久性(主节点在任意时间可能失效)
      • 需要日志和2pc来做额外保证(失败回滚)
  • 2PC 两阶段提交协议
    • 主要是允许失败回滚,防止故障导致的分歧
    • 无法做到分区容忍(N of N复制)
  • 分区容忍一致性复制协议
    • 什么是网络分区
      • 无法区分远程节点崩溃还是网络故障
    • 大多数仲裁 Quorums
      • 获得大多数投票即可进行(N/2+1 of N)
      • 通过奇数节点保证分区时只有一个集群是活跃的
      • 允许少数派数据不一致,但少数派的数据会被放弃来保证一致性。(放弃活跃性保证安全性)
    • 节点区分角色
      • 一个Leader角色和多个Follower角色
    • 为选举区分纪元 Term
      • 充当逻辑时钟用于识别出已经过期的选票和Leader角色
    • Leader 变更机制
      • 要保证一旦做出一个决策,即使因为崩溃而更换Leader也不能丢失这个决策
    • 将纪元内的提案编号
      • 要保证一旦做出一个决策,即使因为崩溃或分区也不能丢失这个决策
    • 通常的操作流程
  • 分区容忍一致性算法的代表:Paxos、Raft、ZAB
  • 总结:具有强一致性的复制方法
    • Primay-Backup 主备模型(MySQL)
      • 基于日志的复制,从节点只读
      • 有复制延迟
      • 有单一且静态指定的主
      • 无法容错
    • 2PC
      • 一致表决
      • 无复制延迟
      • 静态主
      • 无法容错
    • Paxos类
      • 大多数机制
      • 动态指定主
      • 允许一部分节点失败或分区

复制:弱一致性模型

  • 接受分歧
    • 允许暂时的分歧,找到某种处理分歧的方法,并最终返回一致可用的结果
    • 两种最终一致模型:
      • 概率最终一致
      • 保证最终一致
  • 协调不同操作的顺序
    • 分区时允许多个副本被不同客户端写入不同的值(AP)
    • 利用协调协议处理写入冲突并收敛成一个可用的值
  • Amazon’s Dynamo
    • 数据分布技术:一致性哈希
    • 一致性保证技术:部分大多数仲裁 Partial Quorums (R+W>N)
    • R+W>N 是强一致性吗
    • 冲突检测和Read-Repair
      • 允许副本分歧的系统必须有办法最终协调两个不同的值
      • 这种协调方法必须依赖一些元数据
        • 没有元数据:Last Write Win
        • 依赖时间戳: Global Clock
        • 依赖版本号:Lamport Clock
        • 依赖向量时钟:Vector Clock (准确跟踪因果关系的最小实现)
      • 读取修复依然可能会返回多个值
    • 副本同步技术:Gossip 协议和 Merkle Tree
  • 无序编程
    • 一些数据类型在任意操作顺序下都会收敛为同一个值
  • CRDT : Conflict-free replicated data types
    • CRDT的三律
      • 交换律、组合率、幂等律
    • 常见的CRDT结构
      • Counter
      • Register
      • Set / PN Set
  • CALM定理
  • 非单调性有什么好处

线性一致性

我们可以利用线性一致性的原子性约束来安全地修改状态。我们定义一个类似CAS(compare-and-set)的操作,当且仅当寄存器持有某个值的时候,我们可以往它写入新值。 CAS操作可以作为互斥量,信号量,通道,计数器,列表,集合,映射,树等等的实现基础,使得这些共享数据结构变得可用。线性一致性保证了变更的安全交错

顺序一致性,强调顺序,不是必须发生,但保持顺序发生

因果一致性,保证因果顺序,顺序一致性的子集

串行一致性,有条件必严格

最终一致性以及CRDTs数据结构


ref

  • https://zhuanlan.zhihu.com/p/48782892
  • “分布式一致性模型” 导论http://yuezhang.org/2019/05/17/consistency-model.html 解释了经典论文
  • 从复制的视角看一致性 http://yuezhang.org/2018/03/29/distributed-systems-for-fun-and-profit-note.html
  • 时间戳相关的问题 https://zhuanlan.zhihu.com/p/333471336
  • https://zhuanlan.zhihu.com/p/333471336
  • https://zhuanlan.zhihu.com/p/90996685
  • 经典论文 https://nan01ab.github.io/2017/08/ANSI-SQL-Isolation-Levels.html

Read More

C++ STL best and worst performance features and how to learn from them

视频地址

介绍stl好用和不好用的组件

  • 好用,简单
    • std::array std::is_trivial_copyable memcopy memmove

      • ` 如果可以,尽量让你的类是trivial `

        • trivial destructible 能让优化器复用

        对比看出,多用一个寄存器. 代码复制点这里

        • trivial copyable 有mem*加速
    • std::optional 析构函数也根据T特化了,如果trivial,就省事儿了

    有个bug std::optional<int>构造比std::pair<bool, int>重

    • why?
      • move copy语义补全
    • std::variant
    • std::atomic 有需求就用,别用volatile
    • std::span std::string_view
      • ` #3 尽可能使用std::string_view和std::span 避免SSO SOO`
    • <algorithm> 没有ABI问题,某些可能有点问题,比如std::sort std::nth_element但是继续用也没什么问题 尽可能用,免费的午餐
    • Std::sort竞品 pdqsort introsort countsort 根据自己需求抉择 比如clickhouse自由定制的select
      • libc++用了qsort改良,选了四个点sort 并发,这个技巧jvm也用了好像
      • minmax_element不如min_element+max_element
  • 可能有替代品
    • std::vector std::map std::set 对于性能取舍等方面还有很多讨论

    • std::string SSO

    • const std::string &应该被淘汰,用std::string_view更省 传值就行了

    这里和gcc表现不同,llvm/clang/libc++的实现和fbstring实现类似,是有短串校验的,为了让短串更长,复用了几个字段

    如果用gcc/gnu libstdc++是这样的

    关于libc++的string 的实现,见https://joellaity.com/2020/01/31/string.html,讨论见https://news.ycombinator.com/item?id=22198158 也有讨论到folly fbstring和这个实现很类似

    fbstring更激进

    - 很短的用SSO(0-22), 23字节表示字符串(包括’\0′), 1字节表示长度.
    - 中等长度的(23-255)用eager copy, 8字节字符串指针, 8字节size, 8字节capacity.
    - 很长的(>255)用COW. 8字节指针(指向的内存包括字符串和引用计数), 8字节size, 8字节capacit
    
    • ` 但是要明白可能潜在的SOO,所以捕获引用要小心`

    • std::string拼接问题 absl::StrJoin, folly::join 一开始就分配好内存,然后做拼接

  • 不建议用

    • std::pair std::tuple 信息丢失,赋值场景性能损失
      • why?没有default用了reference需要额外的寄存器?
      • 如果可以,尽可能使用 = default
  • std::unordered_* 数据规模大,性能糟糕
    • 性能糟糕,替代品absl::flat_hash_* 如果hashtable需求强烈,那就用外部的
      • Why?
    • std::regex 性能糟糕 别用 std::regex
      • CTRE吊打 boost::regex也比他强
      • 而且是ABI一部分了,天呐

回到现实世界

  • ClickHouse切换到libc++ 某些查询意外快了很多,整体快了%2,离谱 见https://github.com/ClickHouse/ClickHouse/pull/8311
  • 还是ClickHouse,切换标准到c++17 char8_t也快了很多

` 经常benchmark 慢了就找原因`

对于ABI问题,也有breakage的提案,建议能改动,但别太多

这个视频就是再复习复习一些c++ 一些点子还是很有意思的,重点关注了clickhouse,很多案例,要关注一下


Read More

bpf资料整理以及使用

这个文章 介绍了BPF的基本知识 概念,也有自己的学习资料repo 本文大部分抄自这里 自己的整理记录,复读等于自己也会了!

就是一种vm,之前是class bpf,只做抓数据包,典型应用 tcpdump

架构图

原理图

eBPF 相关的知名的开源项目:

  • Facebook 高性能 4 层负载均衡器 Katran
  • Cilium 为下一代微服务 ServiceMesh 打造了具备API感知和安全高效的容器网络方案;底层主要使用 XDP 和 TC 等相关技术;
  • IO Visor 项目开源的 BCCBPFTraceKubectl-TraceBCC 提供了更高阶的抽象,可以让用户采用 Python、C++ 和 Lua 等高级语言快速开发 BPF 程序;BPFTrace 采用类似于 awk 语言快速编写 eBPF 程序;Kubectl-Trace 则提供了在 kubernetes 集群中使用 BPF 程序调试的方便操作;
  • CloudFlare 公司开源的 eBPF Exporterbpf-toolseBPF Exporter 将 eBPF 技术与监控 Prometheus 紧密结合起来;bpf-tools 可用于网络问题分析和排查;

bcc bpf工具集

我公司的开发机器不支持回去用linux笔记本试试

yum install bcc-tools

/usr/share/bcc/tools/opensnoop 
In file included from <built-in>:2:
/virtual/include/bcc/bpf.h:13:10: fatal error: 'linux/bpf_common.h' file not found
#include <linux/bpf_common.h>
         ^~~~~~~~~~~~~~~~~~~~
1 error generated.
Traceback (most recent call last):
  File "/usr/share/bcc/tools/opensnoop", line 181, in <module>
    b = BPF(text=bpf_text)
  File "/usr/lib/python2.7/site-packages/bcc/__init__.py", line 320, in __init__
    raise Exception("Failed to compile BPF text")
Exception: Failed to compile BPF text

linux支持程度以及对应的版本

工具介绍

execsnoop抓调用,可以抓到slab dentry过大的问题 (经典问题,见过用systemtap抓的。现如今systemtap不如bpf工具好用)

profile抓系统耗时指标

$ profile -af 30 > out.stacks01
$ git clone https://github.com/brendangregg/FlameGraph
$ cd FlameGraph
$ ./flamegraph.pl --color=java < ../out.stacks01 > out.svg

tcplife/tcptracer/tcpstates 抓连接信息/tcp状态/tcp流转状态!这个很牛逼

如何使用bpf定制工具?

  • bpftrace 基本相当于systemtap那种用法了
# 统计进程调用 sys_enter 的次数
#bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
Attaching 1 probe...
^C

@[bpftrace]: 6
@[systemd]: 24
@[snmp-pass]: 96
@[sshd]: 125

# 统计内核中函数堆栈的次数
# bpftrace -e 'profile:hz:99 { @[kstack] = count(); }'
Attaching 1 probe...
^C

[...]
@[
filemap_map_pages+181
__handle_mm_fault+2905
handle_mm_fault+250
__do_page_fault+599
async_page_fault+69
]: 12
[...]
@[
cpuidle_enter_state+164
do_idle+390
cpu_startup_entry+111
start_secondary+423
secondary_startup_64+165
]: 22122
  • bcc工具可以照常用,新的工具,建议使用libbpf来写,bcc下面也有例子

https://github.com/iovisor/bcc/tree/master/libbpf-tools 按照

pingcap公司也提供了几个工具

参考

  • 这个文章列了非常多的资料 https://linux.cn/article-9507-1.html 我也转了,做记录备忘

Read More

(转)(译)深入理解 BPF:一个阅读清单

英语原文链接 https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/ 作者:Quentin Monnet 中文翻译 转自 https://linux.cn/article-9507-1.html 感谢 译者:qhwdw 校对:wxy 感谢 Linux中国-LCTT 原创编译!

什么是 BPF?

BPF,及伯克利包过滤器Berkeley Packet Filter,最初构想提出于 1992 年,其目的是为了提供一种过滤包的方法,并且要避免从内核空间到用户空间的无用的数据包复制行为。它最初是由从用户空间注入到内核的一个简单的字节码构成,它在那个位置利用一个校验器进行检查 —— 以避免内核崩溃或者安全问题 —— 并附着到一个套接字上,接着在每个接收到的包上运行。几年后它被移植到 Linux 上,并且应用于一小部分应用程序上(例如,tcpdump)。其简化的语言以及存在于内核中的即时编译器(JIT),使 BPF 成为一个性能卓越的工具。

然后,在 2013 年,Alexei Starovoitov 对 BPF 进行彻底地改造,并增加了新的功能,改善了它的性能。这个新版本被命名为 eBPF (意思是 “extended BPF”),与此同时,将以前的 BPF 变成 cBPF(意思是 “classic” BPF)。新版本出现了如映射和尾调用tail call这样的新特性,并且 JIT 编译器也被重写了。新的语言比 cBPF 更接近于原生机器语言。并且,在内核中创建了新的附着点。

感谢那些新的钩子,eBPF 程序才可以被设计用于各种各样的情形下,其分为两个应用领域。其中一个应用领域是内核跟踪和事件监控。BPF 程序可以被附着到探针(kprobe),而且它与其它跟踪模式相比,有很多的优点(有时也有一些缺点)。

另外一个应用领域是网络编程。除了套接字过滤器外,eBPF 程序还可以附加到 tc(Linux 流量控制工具)的入站或者出站接口上,以一种很高效的方式去执行各种包处理任务。这种使用方式在这个领域开创了一个新的天地。

并且 eBPF 通过使用为 IO Visor 项目开发的技术,使它的性能进一步得到提升:也为 XDP(“eXpress Data Path”)添加了新的钩子,XDP 是不久前添加到内核中的一种新式快速路径。XDP 与 Linux 栈组合,然后使用 BPF ,使包处理的速度更快。

甚至一些项目,如 P4、Open vSwitch,考虑 或者开始去接洽使用 BPF。其它的一些,如 CETH、Cilium,则是完全基于它的。BPF 是如此流行,因此,我们可以预计,不久之后,将围绕它有更多工具和项目出现 …

深入理解字节码

就像我一样:我的一些工作(包括 BEBA)是非常依赖 eBPF 的,并且在这个网站上以后的几篇文章将关注于这个主题。按理说,在深入到细节之前,我应该以某种方式去介绍 BPF —— 我的意思是,真正的介绍,在第一节所提供的简要介绍上更多地介绍在 BPF 上开发的新功能:什么是 BPF 映射?尾调用?内部结构是什么样子?等等。但是,在这个网站上已经有很多这个主题的介绍了,而且,我也不希望去写另一篇 “BPF 介绍” 的重复文章。

毕竟,我花费了很多的时间去阅读和学习关于 BPF 的知识,因此,在这里我们将要做什么呢,我收集了非常多的关于 BPF 的阅读材料:介绍、文档,也有教程或者示例。这里有很多的材料可以去阅读,但是,为了去阅读它,首先要去 找到 它。因此,为了能够帮助更多想去学习和使用 BPF 的人,现在的这篇文章给出了一个资源清单。这里有各种阅读材料,它可以帮你深入理解内核字节码的机制。

资源

简介

这篇文章中下面的链接提供了 BPF 的基本概述,或者,一些与它密切相关的一些主题。如果你对 BPF 非常陌生,你可以在这些介绍文章中挑选出一篇你喜欢的文章去阅读。如果你已经理解了 BPF,你可以针对特定的主题去阅读,下面是阅读清单。

关于 BPF

关于 eBPF 的常规介绍

BPF 内部结构

IO Visor 博客 有一些关于 BPF 的值得关注技术文章。它们中的一些包含了一点营销讨论。

内核跟踪:总结了所有的已有的方法,包括 BPF:

  • 邂逅 eBPF 和内核跟踪 (Viller Hsiao, July 2016):

    Kprobes、uprobes、ftrace

  • Linux 内核跟踪(Viller Hsiao, July 2016):

    Systemtap、Kernelshark、trace-cmd、LTTng、perf-tool、ftrace、hist-trigger、perf、function tracer、tracepoint、kprobe/uprobe …

关于 事件跟踪和监视,Brendan Gregg 大量使用了 eBPF,并且就其使用 eBPFR 的一些案例写了极好的文档。如果你正在做一些内核跟踪方面的工作,你应该去看一下他的关于 eBPF 和火焰图相关的博客文章。其中的大多数都可以 从这篇文章中 访问,或者浏览他的博客。

介绍 BPF,也介绍 Linux 网络的一般概念

硬件卸载offload(LCTT 译注:“卸载”是指原本由软件来处理的一些操作交由硬件来完成,以提升吞吐量,降低 CPU 负荷。):

  • eBPF 与 tc 或者 XDP 一起支持硬件卸载,开始于 Linux 内核版本 4.9,是由 Netronome 提出的。这里是关于这个特性的介绍:eBPF/XDP 硬件卸载到 SmartNICs(Jakub Kicinski 和 Nic Viljoen, netdev 1.2, Tokyo, October 2016)

  • 一年后出现的更新版:

    综合 XDP 卸载——处理边界案例(Jakub Kicinski 和 Nic Viljoen,netdev 2.2 ,Seoul,November 2017)

  • 我现在有一个简短的,但是在 2018 年的 FOSDEM 上有一个更新版:

    XDP 硬件卸载的挑战(Quentin Monnet,FOSDEM 2018,Brussels,February 2018)

关于 cBPF

关于 XDP

  • 在 IO Visor 网站上的 XDP 概述

  • eXpress Data Path (XDP) (Tom Herbert, Alexei Starovoitov, March 2016):

    这是第一个关于 XDP 的演讲。

  • BoF - BPF 能为你做什么? (Brenden Blanco, LinuxCon, Toronto, August 2016)。

  • eXpress Data Path (Brenden Blanco, Linux Meetup at Santa Clara, July 2016):

    包含一些(有点营销的意思?)基准测试结果!使用单一核心:

    • ip 路由丢弃: ~3.6 百万包每秒(Mpps)

    • 使用 BPF,tc(使用 clsact qdisc)丢弃: ~4.2 Mpps

    • 使用 BPF,XDP 丢弃:20 Mpps (CPU 利用率 < 10%)

    • XDP 重写转发(在端口上它接收到的包):10 Mpps

    (测试是用 mlx4 驱动程序执行的)。

  • Jesper Dangaard Brouer 有几个非常好的幻灯片,它可以从本质上去理解 XDP 的内部结构。

    • XDP − eXpress Data Path,介绍及将来的用法 (September 2016):

      “Linux 内核与 DPDK 的斗争” 。未来的计划(在写这篇文章时)它用 XDP 和 DPDK 进行比较。

    • 网络性能研讨 (netdev 1.2, Tokyo, October 2016):

      关于 XDP 内部结构和预期演化的附加提示。

    • XDP – eXpress Data Path, 可用于 DDoS 防护 (OpenSourceDays, March 2017):

      包含了关于 XDP 的详细情况和使用案例,以及 性能测试性能测试结果代码片断,以及使用 eBPF/XDP(基于一个 IP 黑名单模式)的用于 基本的 DDoS 防护

    • 内存 vs. 网络,激发和修复内存瓶颈 (LSF Memory Management Summit, March 2017):

      提供了许多 XDP 开发者当前所面对 内存问题 的许多细节。不要从这一个开始,但如果你已经理解了 XDP,并且想去了解它在页面分配方面的真实工作方式,这是一个非常有用的资源。

    • XDP 能为其它人做什么(netdev 2.1, Montreal, April 2017),及 Andy Gospodarek:

      普通人怎么开始使用 eBPF 和 XDP。这个演讲也由 Julia Evans 在 她的博客 上做了总结。

    • XDP 能为其它人做什么,第二版(netdev 2.2, Seoul, November 2017),同一个作者:

      该演讲的修订版本,包含了新的内容。

(Jesper 也创建了并且尝试去扩展了有关 eBPF 和 XDP 的一些文档,查看 相关节。)

  • XDP 研讨 — 介绍、体验和未来发展(Tom Herbert, netdev 1.2, Tokyo, October 2016)

    在这篇文章中,只有视频可用,我不知道是否有幻灯片。

  • 在 Linux 上进行高速包过滤 (Gilberto Bertin, DEF CON 25, Las Vegas, July 2017)

    在 Linux 上的最先进的包过滤的介绍,面向 DDoS 的保护、讨论了关于在内核中进行包处理、内核旁通、XDP 和 eBPF。

关于 基于 eBPF 或者 eBPF 相关的其它组件

  • 在边界上的 P4 (John Fastabend, May 2016):

    提出了使用 P4,一个包处理的描述语言,使用 BPF 去创建一个高性能的可编程交换机。

  • 如果你喜欢音频的演讲,这里有一个相关的 OvS Orbit 片断(#11),叫做 在边界上的 P4,日期是 2016 年 8 月。OvS Orbit 是对 Ben Pfaff 的访谈,它是 Open vSwitch 的其中一个核心维护者。在这个场景中,John Fastabend 是被访谈者。

  • P4, EBPF 和 Linux TC 卸载 (Dinan Gunawardena 和 Jakub Kicinski, August 2016):

    另一个 P4 的演讲,一些有关于 Netronome 的 NFP(网络流处理器)架构上的 eBPF 硬件卸载的因素。

  • Cilium 是一个由 Cisco 最先发起的技术,它依赖 BPF 和 XDP 去提供 “基于 eBPF 程序即时生成的,用于容器的快速内核强制的网络和安全策略”。这个项目的代码 在 GitHub 上可以访问到。Thomas Graf 对这个主题做了很多的演讲:

    在上述不同的演讲中重复了大量的内容;嫌麻烦就选最近的一个。Daniel Borkmann 作为 Google 开源博客的特邀作者,也写了 Cilium 简介

  • 这里也有一个关于 Cilium 的播客节目:一个是 OvS Orbit episode (#4),它是 Ben Pfaff 访谈 Thomas Graf (2016 年 5 月),和 另外一个 Ivan Pepelnjak 的播客,仍然是 Thomas Graf 关于 eBPF、P4、XDP 和 Cilium 方面的(2016 年 10 月)。

  • Open vSwitch (OvS),它是 Open Virtual Network(OVN,一个开源的网络虚拟化解决方案)相关的项目,正在考虑在不同的层次上使用 eBPF,它已经实现了几个概念验证原型:

    据我所知,这些 eBPF 的使用案例看上去仅处于提议阶段(并没有合并到 OvS 的主分支中),但是,看它带来了什么将是非常值得关注的事情。

  • XDP 的设计对分布式拒绝访问(DDoS)攻击是非常有用的。越来越多的演讲都关注于它。例如,在 2017 年 4 月加拿大蒙特利尔举办的 netdev 2.1 会议上,来自 Cloudflare 的人们的讲话(XDP 实践:将 XDP 集成到我们的 DDoS 缓解管道)或者来自 Facebook 的(Droplet:由 BPF + XDP 驱动的 DDoS 对策)都存在这样的很多使用案例。

  • Kubernetes 可以用很多种方式与 eBPF 交互。这里有一篇关于 在 Kubernetes 中使用 eBPF 的文章,它解释了现有的产品(Cilium、Weave Scope)如何支持 eBPF 与 Kubernetes 一起工作,并且进一步描述了,在容器部署环境中,eBPF 感兴趣的交互内容是什么。

  • CETH for XDP (Yan Chan 和 Yunsong Lu、Linux Meetup、Santa Clara、July 2016):

    CETH,是由 Mellanox 发起的,为实现更快的网络 I/O 而主张的通用以太网驱动程序架构。

  • VALE 交换机,另一个虚拟交换机,它可以与 netmap 框架结合,有 一个 BPF 扩展模块

  • Suricata,一个开源的入侵检测系统,它的旁路捕获旁特性依赖于 XDP。有一些关于它的资源:

    当使用原生驱动的 XDP 时,这个项目要求实现非常高的性能。

  • InKeV:对于 DCN 的内核中分布式网络虚拟化 (Z. Ahmed, M. H. Alizai 和 A. A. Syed, SIGCOMM, August 2016):

    InKeV 是一个基于 eBPF 的虚拟网络、目标数据中心网络的数据路径架构。它最初由 PLUMgrid 提出,并且声称相比基于 OvS 的 OpenStack 解决方案可以获得更好的性能。

  • gobpf - 在 Go 中使用 eBPF (Michael Schubert, fosdem17, Brussels, Belgium, February 2017):

    “一个来自 Go 库,可以去创建、加载和使用 eBPF 程序”

  • ply 是为 Linux 实现的一个小而灵活的开源动态 跟踪器,它的一些特性非常类似于 bcc 工具,是受 awk 和 dtrace 启发,但使用一个更简单的语言。它是由 Tobias Waldekranz 写的。

  • 如果你读过我以前的文章,你可能对我在这篇文章中的讨论感兴趣,使用 eBPF 实现 OpenState 接口,关于包状态处理,在 fosdem17 中。

文档

一旦你对 BPF 是做什么的有一个大体的理解。你可以抛开一般的演讲而深入到文档中了。下面是 BPF 的规范和功能的最全面的文档,按你的需要挑一个开始阅读吧!

关于 BPF

  • BPF 的规范(包含 classic 和 extended 版本)可以在 Linux 内核的文档中,和特定的文件 linux/Documentation/networking/filter.txt 中找到。BPF 使用以及它的内部结构也被记录在那里。此外,当加载 BPF 代码失败时,在这里可以找到 被校验器抛出的错误信息,这有助于你排除不明确的错误信息。

  • 此外,在内核树中,在 eBPF 那里有一个关于 常见问答 的文档,它在文件 linux/Documentation/bpf/bpf_design_QA.txt 中。

  • … 但是,内核文档是非常难懂的,并且非常不容易阅读。如果你只是去查找一个简单的 eBPF 语言的描述,可以去 IO Visor 的 GitHub 仓库,那儿有 它的概括性描述

  • 顺便说一下,IO Visor 项目收集了许多 关于 BPF 的资源。大部分分别在 bcc 仓库的 文档目录 中,和 bpf-docs 仓库 的整个内容中,它们都在 GitHub 上。注意,这个非常好的 BPF 参考指南 包含一个详细的 BPF C 和 bcc Python 的 helper 的描述。

  • 想深入到 BPF,那里有一些必要的 Linux 手册页。第一个是 bpf(2) man 页面 关于 bpf() 系统调用,它用于从用户空间去管理 BPF 程序和映射。它也包含一个 BPF 高级特性的描述(程序类型、映射等等)。第二个是主要是处理希望附加到 tc 接口的 BPF 程序:它是 tc-bpf(8) man 页面,是 使用 BPF 和 tc 的一个参考,并且包含一些示例命令和参考代码。

  • Jesper Dangaard Brouer 发起了一个 更新 eBPF Linux 文档 的尝试,包含 不同的映射他有一个草案,欢迎去贡献。一旦完成,这个文档将被合并进 man 页面并且进入到内核文档。

  • Cilium 项目也有一个非常好的 BPF 和 XDP 参考指南,它是由核心的 eBPF 开发者写的,它被证明对于 eBPF 开发者是极其有用的。

  • David Miller 在 xdp-newbies 邮件列表中发了几封关于 eBPF/XDP 内部结构的富有启发性的电子邮件。我找不到一个单独的地方收集它们的链接,因此,这里是一个列表:

    最后一个可能是目前来说关于校验器的最佳的总结。

  • Ferris Ellis 发布的 一个关于 eBPF 的系列博客文章。作为我写的这个短文,第一篇文章是关于 eBPF 的历史背景和未来期望。接下来的文章将更多的是技术方面,和前景展望。

  • 每个内核版本的 BPF 特性列表 在 bcc 仓库中可以找到。如果你想去知道运行一个给定的特性所要求的最小的内核版本,它是非常有用的。我贡献和添加了链接到提交中,它介绍了每个特性,因此,你也可以从那里很容易地去访问提交历史。

关于 tc

当为了网络目的结合使用 BPF 与 tc (Linux 流量控制traffic control</ruby>工具)时,它可用于收集 tc 的常规功能的信息。这里有几个关于它的资源。

关于 XDP

  • 对于 XDP 的一些 进展中的文档(包括规范) 已经由 Jesper Dangaard Brouer 启动,并且意味着将成为一个协作工作。正在推进的(2016 年 9 月):你期望它去改变,并且或许在一些节点上移动(Jesper 称为贡献,如果你想去改善它)。

  • 自来 Cilium 项目的 BPF 和 XDP 参考指南 … 好吧,这个名字已经说明了一切。

关于 P4 和 BPF

P4 是一个用于指定交换机行为的语言。它可以为多种目标硬件或软件编译。因此,你可能猜到了,这些目标中的一个就是 BPF … 仅部分支持的:一些 P4 特性并不能被转化到 BPF 中,并且,用类似的方法,BPF 可以做的事情,而使用 P4 却不能表达出现。不过,P4 与 BPF 使用 的相关文档,被隐藏在 bcc 仓库中。这个改变在 P4_16 版本中,p4c 引用的编辑器包含 一个 eBPF 后端

教程

Brendan Gregg 为想要 使用 bcc 工具 跟踪和监视内核中的事件的人制作了一个非常好的 教程第一个教程是关于如何使用 bcc 工具,它有许多章节,可以教你去理解怎么去使用已有的工具,而 针对 Python 开发者的一篇 专注于开发新工具,它总共有十七节 “课程”。

Sasha Goldshtein 也有一些 Linux 跟踪研究材料 涉及到使用几个 BPF 工具进行跟踪。

Jean-Tiare Le Bigot 的另一篇文章提供了一个详细的(和有指导意义的)使用 perf 和 eBPF 去设置一个低级的跟踪器 的示例。

对于网络相关的 eBPF 使用案例也有几个教程。有一些值得关注的文档,包括一篇 eBPF 卸载入门指南,是关于在 Open NFP 平台上用 Netronome 操作的。其它的那些,来自 Jesper 的演讲,XDP 能为其它人做什么(及其第二版),可能是 XDP 入门的最好的方法之一。

示例

有示例是非常好的。看看它们是如何工作的。但是 BPF 程序示例是分散在几个项目中的,因此,我列出了我所知道的所有的示例。示例并不是总是使用相同的 helper(例如,tc 和 bcc 都有一套它们自己的 helper,使它可以很容易地去用 C 语言写 BPF 程序)

来自内核的示例

内核中包含了大多数类型的程序:过滤器绑定到套接字或者 tc 接口、事件跟踪/监视、甚至是 XDP。你可以在 linux/samples/bpf/ 目录中找到这些示例。

现在,更多的示例已经作为单元测试被添加到 linux/tools/testing/selftests/bpf 目录下,这里面包含对硬件卸载的测试或者对于 libbpf 的测试。

Jesper 的 Dangaard Brouer 在他的 prototype-kernel 仓库中也维护了一套专门的示例。 这些示例与那些内核中提供的示例非常类似,但是它们可以脱离内核架构(Makefile 和头文件)编译。

也不要忘记去看一下 git 相关的提交历史,它们介绍了一些特定的特性,也许包含了一些特性的详细示例。

来自包 iproute2 的示例

iproute2 包也提供了几个示例。它们都很明显地偏向网络编程,因此,这个程序是附着到 tc 入站或者出站接口上。这些示例在 iproute2/examples/bpf/ 目录中。

来自 bcc 工具集的示例

许多示例都是 与 bcc 一起提供的

  • 一些网络的示例放在相关的目录下面。它们包括套接字过滤器、tc 过滤器、和一个 XDP 程序。

  • tracing 目录包含许多 跟踪编程 的示例。前面的教程中提到的都在那里。那些程序涉及了很大部分的事件监视功能,并且,它们中的一些是面向生产系统的。注意,某些 Linux 发行版(至少是 Debian、Ubuntu、Fedora、Arch Linux)、这些程序已经被 打包了 并且可以很 “容易地” 通过比如 # apt install bcc-tools 进行安装。但是在写这篇文章的时候(除了 Arch Linux),首先要求安装 IO Visor 的包仓库。

  • 也有一些 使用 Lua 作为一个不同的 BPF 后端(那是因为 BPF 程序是用 Lua 写的,它是 C 语言的一个子集,它允许为前端和后端使用相同的语言)的一些示例,它在第三个目录中。

  • 当然,bcc 工具 自身就是 eBPF 程序使用案例的值得关注示例。

手册页面

虽然 bcc 一般很容易在内核中去注入和运行一个 BPF 程序,将程序附着到 tc 接口也能通过 tc 工具自己完成。因此,如果你打算将 BPF 与 tc 一起使用,你可以在 tc-bpf(8) 手册页面 中找到一些调用示例。

代码

有时候,BPF 文档或者示例并不够,而且你只想在你喜欢的文本编辑器(它当然应该是 Vim)中去显示代码并去阅读它。或者,你可能想深入到代码中去做一个补丁程序或者为机器增加一些新特性。因此,这里对有关的文件的几个建议,找到你想要的函数只取决于你自己!

在内核中的 BPF 代码

  • 文件 linux/include/linux/bpf.h 及其相对的 linux/include/uapi/bpf.h 包含有关 eBPF 的 定义,它们分别用在内核中和用户空间程序的接口。

  • 相同的方式,文件 linux/include/linux/filter.hlinux/include/uapi/filter.h 包含了用于 运行 BPF 程序 的信息。

  • BPF 相关的 主要的代码片断linux/kernel/bpf/ 目录下面。系统调用的不同操作许可,比如,程序加载或者映射管理是在文件 syscall.c 中实现,而 core.c 包含了 解析器。其它文件的命名显而易见:verifier.c 包含 校验器(不是开玩笑的),arraymap.c 的代码用于与数组类型的 映射 交互,等等。

  • 有几个与网络(及 tc、XDP )相关的函数和 helpers 是用户可用,其实现在 linux/net/core/filter.c 中。它也包含了移植 cBPF 字节码到 eBPF 的代码(因为在运行之前,内核中的所有的 cBPF 程序被转换成 eBPF)。

  • 相关于 事件跟踪 的函数和 helpers 都在 linux/kernel/trace/bpf_trace.c 中。

  • JIT 编译器 在它们各自的架构目录下面,比如,x86 架构的在 linux/arch/x86/net/bpf_jit_comp.c 中。例外是用于硬件卸载的 JIT 编译器,它们放在它们的驱动程序下,例如 Netronome NFP 网卡的就放在 linux/drivers/net/ethernet/netronome/nfp/bpf/jit.c

  • linux/net/sched/ 目录下,你可以找到 tc 的 BPF 组件 相关的代码,尤其是在文件 act_bpf.c (action)和 cls_bpf.c(filter)中。

  • 我并没有在 BPF 上深入到 事件跟踪 中,因此,我并不真正了解这些程序的钩子。在 linux/kernel/trace/bpf_trace.c 那里有一些东西。如果你对它感 兴趣,并且想去了解更多,你可以在 Brendan Gregg 的演示或者博客文章上去深入挖掘。

  • 我也没有使用过 seccomp-BPF,不过你能在 linux/kernel/seccomp.c 找到它的代码,并且可以在 linux/tools/testing/selftests/seccomp/seccomp_bpf.c 中找到一些它的使用示例。

XDP 钩子代码

一旦装载进内核的 BPF 虚拟机,由一个 Netlink 命令将 XDP 程序从用户空间钩入到内核网络路径中。接收它的是在 linux/net/core/dev.c 文件中的 dev_change_xdp_fd() 函数,它被调用并设置一个 XDP 钩子。钩子被放在支持的网卡的驱动程序中。例如,用于 Netronome 硬件钩子的 ntp 驱动程序实现放在 drivers/net/ethernet/netronome/nfp/ 中。文件 nfp_net_common.c 接受 Netlink 命令,并调用 nfp_net_xdp_setup(),它会转而调用 nfp_net_xdp_setup_drv() 实例来安装该程序。

在 bcc 中的 BPF 逻辑

在 bcc 的 GitHub 仓库 能找到的 bcc 工具集的代码。其 Python 代码,包含在 BPF 类中,最初它在文件 bcc/src/python/bcc/__init__.py 中。但是许多我觉得有意思的东西,比如,加载 BPF 程序到内核中,出现在 libbcc 的 C 库中。

使用 tc 去管理 BPF 的代码

当然,这些代码与 iproute2 包中的 tc 中的 BPF 相关。其中的一些在 iproute2/tc/ 目录中。文件 f_bpf.cm_bpf.c(和 e_bpf.c)各自用于处理 BPF 的过滤器和动作的(和 tc exec 命令,等等)。文件 q_clsact.c 定义了为 BPF 特别创建的 clsact qdisc。但是,大多数的 BPF 用户空间逻辑 是在 iproute2/lib/bpf.c 库中实现的,因此,如果你想去使用 BPF 和 tc,这里可能是会将你搞混乱的地方(它是从文件 iproute2/tc/tc_bpf.c 中移动而来的,你也可以在旧版本的包中找到相同的代码)。

BPF 实用工具

内核中也带有 BPF 相关的三个工具的源代码(bpf_asm.cbpf_dbg.cbpf_jit_disasm.c),根据你的版本不同,在 linux/tools/net/ (直到 Linux 4.14)或者 linux/tools/bpf/ 目录下面:

  • bpf_asm 是一个极小的 cBPF 汇编程序。

  • bpf_dbg 是一个很小的 cBPF 程序调试器。

  • bpf_jit_disasm 对于两种 BPF 都是通用的,并且对于 JIT 调试来说非常有用。

  • bpftool 是由 Jakub Kicinski 写的通用工具,它可以与 eBPF 程序交互并从用户空间的映射,例如,去展示、转储、pin 程序、或者去展示、创建、pin、更新、删除映射。

阅读在源文件顶部的注释可以得到一个它们使用方法的概述。

与 eBPF 一起工作的其它必需的文件是来自内核树的两个用户空间库,它们可以用于管理 eBPF 程序或者映射来自外部的程序。这个函数可以通过 linux/tools/lib/bpf/ 目录中的头文件 bpf.hlibbpf.h(更高层面封装)来访问。比如,工具 bpftool 主要依赖这些库。

其它值得关注的部分

如果你对关于 BPF 的不常见的语言的使用感兴趣,bcc 包含 一个 BPF 目标的 P4 编译器以及 一个 Lua 前端,它可以被用以代替 C 的一个子集,并且(用 Lua )替代 Python 工具。

LLVM 后端

这个 BPF 后端用于 clang / LLVM 将 C 编译到 eBPF ,是在 这个提交 中添加到 LLVM 源代码的(也可以在 这个 GitHub 镜像 上访问)。

在用户空间中运行

到目前为止,我知道那里有至少两种 eBPF 用户空间实现。第一个是 uBPF,它是用 C 写的。它包含一个解析器、一个 x86_64 架构的 JIT 编译器、一个汇编器和一个反汇编器。

uBPF 的代码似乎被重用来产生了一个 通用实现,其声称支持 FreeBSD 内核、FreeBSD 用户空间、Linux 内核、Linux 用户空间和 Mac OSX 用户空间。它被 VALE 交换机的 BPF 扩展模块使用。

其它用户空间的实现是我做的:rbpf,基于 uBPF,但是用 Rust 写的。写了解析器和 JIT 编译器 (Linux 下两个都有,Mac OSX 和 Windows 下仅有解析器),以后可能会有更多。

提交日志

正如前面所说的,如果你希望得到更多的关于一些特定的 BPF 特性的信息,不要犹豫,去看一些提交日志。你可以在许多地方搜索日志,比如,在 git.kernel.org在 GitHub 上、或者如果你克隆过它还有你的本地仓库中。如果你不熟悉 git,你可以尝试像这些去做 git blame <file> 去看看介绍特定代码行的提交内容,然后,git show <commit> 去看详细情况(或者在 git log 的结果中按关键字搜索,但是这样做通常比较单调乏味)也可以看在 bcc 仓库中的 按内核版本区分的 eBPF 特性列表,它链接到相关的提交上。

排错

对 eBPF 的追捧是最近的事情,因此,到目前为止我还找不到许多关于怎么去排错的资源。所以这里只有几个,是我在使用 BPF 进行工作的时候,对自己遇到的问题进行的记录。

编译时的错误

  • 确保你有一个最新的 Linux 内核版本(也可以看 这个文档)。

  • 如果你自己编译内核:确保你安装了所有正确的组件,包括内核镜像、头文件和 libc。

  • 当使用 tc-bpf(用于去编译 C 代码到 BPF 中)的 man 页面提供的 bcc shell 函数时:我曾经必须添加包含 clang 调用的头文件:

    __bcc() {
            clang -O2 -I "/usr/src/linux-headers-$(uname -r)/include/" \
                      -I "/usr/src/linux-headers-$(uname -r)/arch/x86/include/" \
                    -emit-llvm -c $1 -o - | \
            llc -march=bpf -filetype=obj -o "`basename $1 .c`.o"
    }
    

    (现在似乎修复了)。

  • 对于使用 bcc 的其它问题,不要忘了去看一看这个工具集的 答疑

  • 如果你从一个并不精确匹配你的内核版本的 iproute2 包中下载了示例,可能会由于在文件中包含的头文件触发一些错误。这些示例片断都假设安装在你的系统中内核的头文件与 iproute2 包是相同版本的。如果不是这种情况,下载正确的 iproute2 版本,或者编辑示例中包含的文件的路径,指向到 iproute2 中包含的头文件上(在运行时一些问题可能或者不可能发生,取决于你使用的特性)。

在加载和运行时的错误

  • 使用 tc 去加载一个程序,确保你使用了一个与使用中的内核版本等价的 iproute2 中的 tc 二进制文件。

  • 使用 bcc 去加载一个程序,确保在你的系统上安装了 bcc(仅下载源代码去运行 Python 脚本是不够的)。

  • 使用 tc,如果 BPF 程序不能返回一个预期值,检查调用它的方式:过滤器,或者动作,或者使用 “直传” 模式的过滤器。

  • 还是 tc,注意不使用过滤器,动作不会直接附着到 qdiscs 或者接口。

  • 通过内核校验器抛出错误到解析器可能很难。内核文档或许可以提供帮助,因此,可以 参考指南 或者,万不得一的情况下,可以去看源代码(祝你好运!)。记住,校验器 不运行 程序,对于这种类型的错误,记住这点是非常重要的。如果你得到一个关于无效内存访问或者关于未初始化的数据的错误,它并不意味着那些问题真实发生了(或者有时候是,它们完全有可能发生)。它意味着你的程序是以校验器预计可能发生错误的方式写的,并且因此而拒绝这个程序。

  • 注意 tc 工具有一个 verbose 模式,它与 BPF 一起工作的很好:在你的命令行尾部尝试追加一个 verbose

  • bcc 也有一个 verbose 选项:BPF 类有一个 debug 参数,它可以带 DEBUG_LLVM_IRDEBUG_BPFDEBUG_PREPROCESSOR 三个标志中任何组合(详细情况在 源文件中)。 为调试该代码,它甚至嵌入了 一些条件去打印输出代码

  • LLVM v4.0+ 为 eBPF 程序 嵌入一个反汇编器。因此,如果你用 clang 编译你的程序,在编译时添加 -g 标志允许你通过内核校验器去以人类可读的格式去转储你的程序。处理转储文件,使用:

    $ llvm-objdump -S -no-show-raw-insn bpf_program.o
    
  • 使用映射?你应该去看看 bpf-map,这是一个为 Cilium 项目而用 Go 创建的非常有用的工具,它可以用于去转储内核中 eBPF 映射的内容。也有一个用 Rust 开发的 克隆

  • StackOverflow 上有个旧的 bpf 标签,但是,在这篇文章中从没用过它(并且那里几乎没有与新版本的 eBPF 相关的东西)。如果你是一位来自未来的阅读者,你可能想去看看在这方面是否有更多的活动(LCTT 译注:意即只有旧东西)。

更多!

请经常会回到这篇博客中,来看一看 关于 BPF 有没有新的文章!

特别感谢 Daniel Borkmann 指引我找到了 更多的文档,因此我才完成了这个合集。


via: https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/

作者:Quentin Monnet 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出


Read More

^