Seastar on Laputa

Seastar: sharded service(2)

Thu, 15 Dec 2022 00:00:00 +0000

Preface

第一篇里面介绍了一下 seastar::sharded 的基本概念和用法, 一般情况下我们用这些就足够了, 但是 Seastar 还为其他一些特殊的使用场景提供了支持, 当程序功能越来越复杂, 碰到这些场景的概率肯定会更大, 所以从完备的层面考虑, 还是得介绍一些他们; 其实也并不困难, Seastar 是秉持实用主义的, 也就是说在里面的组件一定是有现实中的使用场景的, 用到他们只是时间的问题(了解了这些组件之后可以在 redpanda 和 scylladb 的 codebase 里搜索一下具体的使用场景)

sharded parameter

前面并没有特别说明 seastar::sharded 的 start() 以及 invoke_on_* 系列函数允许传递哪些参数, 笼统地说只要是支持拷贝构造的类型(包括内置数据类型)都支持, 但是可以更具体地分为三类:

arbitrary constant values - these are copied to all instances
other sharded<> values - these are transformed before passing to the functor; the local instance is extracted and passed
shard-dependent parameter

第一类是最简单也是也是最常用的, 所有除了第二类和第三类说明的类型(sharded 和 sharded_parameter)外的其他类型都属于第一类, 比如 int、std::string 以及自定义类型 class Widget 等, 他们会被拷贝到各个 shard

Seastar: sharded service(1)

Thu, 01 Dec 2022 00:00:00 +0000

Preface

Seastar 是一个多线程异步库, 基于它的 App 通常都有在多个 shard(也称 logic core) 上对称部署服务的诉求; 为此我们需要在多个 shard 上创建服务的实例, 并且让这些实例执行某些操作; 这些涉及到 shard 之间的通信, Seastar 提倡使用显式的消息传递(message passing)而不是传统多线程编程常用的共享内存&加锁的方式进行通信, 为此提供了 smp 工具; 所以我们其实可以这样写:

c++

std::vector<Service> instances; 
instances.resive(smp::count);

smp::invoke_on_all([&instances]() {
 instance[this_shard_id()] = new Service();
});

使用 smp 中的工具, 我们可以实现这些操作, 但是如果有很多这样的服务, 那么就需要重复大量类似的代码(以上代码只是该场景下很小的一部分), 所以我们应该将其沉淀为一个通用的组件, 而 Seastar 也是这样做的, 这就是 seastar::sharded.

一开始它并不叫这个名字, 而是 seastar::distributed, 即分布式服务, 后面考虑到 distributed 经常用于跨机器的场景, 而这里实际上是同机器跨核, 所以改名为 seastar::sharded, 不过考虑到向前兼容还是把 seastar::distributed 作为 seastar::sharded 的一个别名保留, 只是不再推荐使用

一个 🌰

在了解它的实现之前, 先看看它的一些用法, Seastar 提供了一个简易的 HTTP server, 以此为例, 看看如何使用 sharded 在多个 core 上部署它; 为了简化逻辑, 使用 seastar::async 以串行的方式写:

Seastar: network stack

Sun, 13 Nov 2022 00:00:00 +0000

Seastar: network stack

Preface

Seastar 中提供了两种协议栈:

native stack
posix stack

其中 native stack 是 seastar 自己实现的一套协议栈, 一般是和 DPDK 配合使用; 而 posix stack 则是传统的内核协议栈; 由于我并不了解 DPDK, 暂时也没有学习/使用的需要, 所以目前还是先关注 posix stack 的实现(只关注 TCP, unix socket/UDP/SCTP 暂时不管), 以及 seastar 是如何抽象 network stack 这个概念从而统一 native stack 和 posix stack 二者的.

network stack API

为了统一 native stack 与 posix stack, seastar net 模块中抽象除了如下实体：

socket: 可以视作调用了 socket(2) 但是还没有 connect(2) 的 fd, 通过它我们可以发起网络连接得到 connected_socket
connected_socket: 一个处于连接状态的 TCP/SCTP 全双工流
server_socket : TCP/SCTP 监听描述符, 等待 accept(2) 新的网络连接
udp_channel: udp 管道, 用于读写数据
udp_datagram: udp 数据报
network_stack:

socket

This class is responsible for establishing a connection between two endpoints. It allows for the connection attempt to be canceled.

Seastar: temporary buffer

Sat, 16 Jul 2022 00:00:00 +0000

Preface

temporary_buffer 是 Seastar 提供的一种自我管理(self-managed)字节缓冲区，它类似于 std::string 或者 std::unique_ptr<char[]>，但是提供了一些更加灵活的内存管理机制，比如它可以独占底层的缓冲区，也可以和其他 temporary_buffer 共享底层缓冲区、甚至只共享其他 temporay_buffer 底层缓冲区的一部分…，因为这些功能，这个数据结构在 Seastar 以及 Scylla/RedPanda 等基于 Seastar 的项目中使用得非常广泛

temporary buffer

首先来看看其结构定义：

c++

template<typename CharType>
temporary_buffer {
 CharType *_buffer;
 size_t _size;
 deleter _deleter;
};

非常简单的一个结构，其中 _buffer 就是其底层缓冲区，_size 就是该缓冲区的大小；但是需要注意的是，由于 temporay_buffer 是可以从其他 temporary_buffer 共享的(甚至只共享一部分)，所以 _buffer 可能并是最初分配的内存的起始地址，因此 _size 也可能并不是最初分配内存的大小

二者的关系可能是这样：

而 deleter 自然就是用来释放该内存的工具了，相关逻辑暂且按下不表，后面会用另外一个 section 来解读，还是很有趣的

构造 & 析构

首先来看看它的构造和析构函数：

c++

explicit temporary_buffer(size_t size)
 : _buffer(static_cast<CharType*>(malloc(size * sizeof(CharType)))), _size(size)
 , _deleter(make_free_deleter(_buffer)) {
 if (size && !_buffer) {
 throw std::bad_alloc();
 }
 }

temporary_buffer(CharType* buf, size_t size, deleter d) noexcept
 : _buffer(buf), _size(size), _deleter(std::move(d)) {}

temporary_buffer() noexcept
 : _buffer(nullptr)
 , _size(0) {}

一个是默认构造函数，另一个则是指定缓冲区的大小，然后用 malloc 分配指定大小的缓冲区，此时 deleter 通过 make_free_deleter 构造出来，它的功能和它的名字一样：通过 std::free 释放 _buffer；还有一个则是直接传入 raw buffer 和 size，以及自定义deleter

Seastar: 用户线程

Sun, 22 May 2022 00:00:00 +0000

Preface

通常我们在 seastar 中写代码是不能阻塞的，如果我们希望在一段异步代码之后执行完毕之后开始执行另外一个逻辑，那么我们就需要通过 continuation 的方式将其串联起来，比如：

c++

seastar::sleep(2s).then([]() {
 /* another code piece */
})

而不能直接调用 future::get() 或者 future::wait()：

c++

seastar::sleep(2s).wait();

/* another code piece */

以上代码在 wait() 的过程中就会 core dump。

但是 seastar 提供了 seastar::thread 这个工具，通过它，我们可以正常执行可能导致阻塞(即 future::wait())的代码：

c++

ss::thread th([]() {
 using namespace std::chrono_literals;
 ss::sleep(2s).wait();
 std::cout << "Hello, seastar thread!" << std::endl;
});
return ss::do_with(std::move(th), [](seastar::thread &th) {
 return th.join();
});

实际上其内部并没有阻塞，但是却产生了以同步方式写异步代码的效果(通过 ucontext)，有点 async/await 的感觉；这个工具在单测中用的非常普遍，而且像 scylla 和 redpanda 的 main 函数都是通过它启动的。

`seastar::async`

虽然我们可以像上面一样直接使用 seastar::thread，但是却要处理等待 thread 结束(join())、生命周期管理等问题，所以 seastar 更推荐我们使用 seastar::async 这个函数，比如之前的代码通过该函数可以改写成这样：

Seastar: semaphore

Wed, 04 May 2022 00:00:00 +0000

Preface

最近在实现 fetch 接口时, 需要对单个 JS 脚本的单次执行过程中可以发起的 fetch 操作数进行限制(和 CloudFlare Workers 类似):

总量限制：超过了则后续的 fetch 操作都将直接失败
并发限制：超过了则后续的 fetch 请求将会被延迟(postpone)执行，直到有其他执行着的 fetch 请求结束

第一点很简单, 用一个计数器即可解决; 关键在于第二个, 要将超出了并发限制的 fetch 操作阻塞住, 直到有其他 fetch 操作结束(即返回的 promise 被 resolve)再唤醒它们执行.

这个需求听起来似乎很熟悉？可以换一种说法，将「同一个时刻可运行的 fetch 请求」视为一种资源，这个资源是可以重复利用的(这一点是并发限制和总量限制的主要区别)：发起一个 fetch 请求相当于拿走一份资源，结束一个 fetch 请求相当于归还一份资源；且这个资源并非无限，所以当资源被拿完之后再想拿就等着直到有人归还资源。

说到这里就很清晰了，这个问题就是信号量(semaphore)¹要解决的：

In computer science, a semaphore is a variable or abstract data type used to control access to a common resource by multiple threads and avoid critical section problems in a concurrent system such as a multitasking operating system.

Seastar: 系统调用线程

Mon, 18 Apr 2022 00:00:00 +0000

Preface

在 Seastar 中，文件相关的操作并不直接由 reactor 线程(工作线程)执行，而是被 offload 到一个专门的线程中去执行，为此 Seastar 在 reactor 中提供了诸多文件操作相关的方法；比如重命名一个文件就可以使用 rename_file 方法：

c++

static ss::future<> f() {
 return ss::engine()
 .rename_file("hello.txt", "world.txt")
 .then_wrapped([](ss::future<> &&fut) {
 if (fut.failed()) {
 fmt::print("rename file failed: {}", fut.get_exception());
 }
 return ss::make_ready_future<>();
 });
}

所有这些文件操作相关的函数都返回 future

源码剖析

每个 reactor 中都有一个类型为 thread_pool 的变量，但是我觉得有点名不副实，因为它并不是一个 pool，而只是一个单独的线程——仅仅用于执行文件相关的 syscall，所以叫 syscall thread 或许会更好一些；不过这些都是细枝末节，先看看 rename_file 的实现：

c++

future<>
reactor::rename_file(std::string_view old_pathname, std::string_view new_pathname) noexcept {
 // Allocating memory for a sstring can throw, hence the futurize_invoke
 return futurize_invoke([old_pathname, new_pathname] {
 return engine()._thread_pool->submit<syscall_result<int>>([old_pathname = sstring(old_pathname), new_pathname = sstring(new_pathname)] {
 return wrap_syscall<int>(::rename(old_pathname.c_str(), new_pathname.c_str()));
 }).then([old_pathname = sstring(old_pathname), new_pathname = sstring(new_pathname)] (syscall_result<int> sr) {
 sr.throw_fs_exception_if_error("rename failed", old_pathname, new_pathname);
 return make_ready_future<>();
 });
 });
}

逻辑非常简单，就是往 syscall thread 中提交一个任务，该任务也不过是简单地调用了一下 rename¹ 这个系统调用；如果该调用出错，则抛出异常——当然被 futurize_invoke 捕获并转换为一个 exceptional future 返回给调用方。

Seastar：核间通信

Sat, 02 Apr 2022 00:00:00 +0000

Preface

虽然 Seastar 号称 share-nothing¹，但是现代服务器开发中仍免不了需要核间通信；Seastar 为此在 smp 类中提供了 submit_to 方法用于向其他线程的 reactor 提交任务并执行：

c++

static futurize_t<std::invoke_result_t<Func>>
submit_to(unsigned t, Func&& func) noexcept;

比如下面的代码：

c++

ss::future<> f() {
 std::cout << "run on shard-" << ss::this_shard_id() << std::endl;
 return ss::smp::submit_to(1, []() {
 std::cout << "run on shard-" << ss::this_shard_id() << std::endl;
 });
}

首先在当前 shard 打印其 id，然后往 id 为 1 的 shard 提交一个异步任务，该异步任务也只是简单地打印出所在 shard 的 id

使用 app_template 执行该函数得到结果：

shell

% sudo ./my_app -c 2
run on shard-0
run on shard-1

的确第二句 std::cout 是在 shard-1 上执行的；这里需要注意由于使用了两个 shard，所以至少需要使用两个核(-c 2)。

源码剖析

这里涉及到两个核之间的通信，所以有必要先规定几个叫法：

local core/local shard/local reactor：指发起通信的一方
remote core/remote shard/remote reactor：指接收方

前面提到的 submit_to 函数实际上是以默认的 smp_submit_to_options 参数调用的下面这个函数：

Seastar: loop utility

Sat, 26 Mar 2022 00:00:00 +0000

Preface

循环是绝大多数编程语言中必不可少的控制结构，比如 C++ 对数组中的元素求和：

c++

int sum(const std::vector<int> &ints) {
 int res = 0;
 for (size_t i = 0; i < ints.size(); i++) {
 res += ints[i];
 }
 return res;
}

然而在 Seastar 中，写循环却不是一件容易的事情——当然不是上面这种不涉及到任何的异步操作的循环，而是指循环重复执行一个异步操作。比如我们想实现这样一个 search 函数：它依次从 Google、Bing 和 Baidu 搜索，有一个成功则将其内容输出至标准输出并停止搜索；或许我们可以马上写出下面这样一段代码：

c++

extern ss::future<std::string> fetch(const std::string &domain,
 const std::string &object);

void search(const std::string &object) {
 static std::vector<std::string> domains = {
 "www.google.com",
 "www.bing.com",
 "www.baidu.com",
 };
 for (size_t i = 0; i < domains.size(); i++) {
 auto fut = fetch(domains[i]);
 if (!fut.is_failed()) {
 std::cout << fut.get0() << std::endl;
 return;
 }
 }
}

然而 fetch 函数是一个异步操作，也就是说，这个函数不会阻塞，而是立即返回；而它返回的 future 很大程度上不是 ready 的，所以我们无法判断其状态，除非我们等待，然而这就失去了异步的意义(而且 Seastar 不允许我们在非 seastar::thread 环境中等待一个 future)。

再退一步，就算我们不考虑「有一个成功则返回」这个逻辑，而只是「依次向 Google、Bing 和 Baidu 发起请求」，我们也做不到：

c++

for (size_t i = 0; i < domains.size(); i++) {
 (void) fetch(domains[i]).then_wrapped([](ss::future<std::string> &&fut) {
 if (fut.failed()) {
 std::cout << "fetch FAILED: " << fut.get_exception() << std::endl;
 } else {
 std::cout << "fetch SUCCEEDED: " << fut.get0() << std::endl;
 }
 });
}

还是之前的原因，fetch 是一个异步操作不会阻塞而是直接返回，所以这里无法保证「在前一个操作完成之后再进行下一个」这个逻辑。

Seastar: FPC(2)

Wed, 09 Mar 2022 00:00:00 +0000

Preface

这里不打算完整地解释 Seastar 中 future&promise 的实现，里面旁枝末节实在太多，比如：

API 的兼容性处理
针对不同平台的优化
针对 Debug 编译的特殊处理
各种 Modern C++ 特性的使用
针对 GCC/Clang 做的各种编译优化
…

所以还是希望抓住其中的一些重难点以及做的一些优化进行分析。

这个系列的第一篇文章¹中已经 future&promise 的大致实现流程进行了解释，Seastar 整体思想与之类似，但是还是有一些不同²：

Seastar 作为一个网络框架，绝大多数时候面对的是重 I/O 的任务，所以它并不使用扩展性并不强的多线程模型，而是采用事件驱动的方式异步执行用户代码
因为 future&promise 都在同一个线程中操作，所以也不需要加锁，所以忘记前面的 std::mutex 和 std::condition_variable 吧
为了极致的性能，Seastar 中的 future&promise 并不需要动态分配内存，所以也忘记前面的 std::shared_ptr<SharedState> 吧

类层次结构

首先看看 FPC 的类结构，这里直接放出其 UML 图：

非常复杂的层次结构，关于图片有几点注意：

对于模板类，在 UML 图矩形的右上角标注了其模板类型参数
uninitialized_wrapper_base 有两种偏特化实现，但是这里只标注了其一
存在 public 和 private 继承，但是在 UML 图中没有表示出来

从之前的 SharedState 我们可以总结出，future 和 proimise 的共享状态需要包含 future 的状态，异常值、数据；在 Seastar 中这一角色由 future_state 承担：其中数据从 uninitialize_wrapper 中继承，状态、异常值则从 future_state_base 中继承。

Seastar: FPC(1)

Sun, 06 Mar 2022 00:00:00 +0000

Preface

主要讲的是 future&promise 一些基本概念以及设计原理，但是因为 Seastar 中的实现¹非常复杂(毕竟是工业级产品，且经过了 LLVM 大牛的大量优化，多了许多与核心实现其实并没有关系的逻辑)，所以我并不打算直接硬上(其实之前尝试过好几次，但是看完了之后还是迷迷糊糊一知半解，所以打算换一种方法)，而是打算借助 CppCon 2015 上的一个 presentation² 来介绍它的基本原理和简易实现；BTW，这个 presentation 的确讲的非常好，力荐！

Future and Promise

标题中的 FPC 指的是 Future、Promise 和 Continuation 这三个概念，这是并发编程中非常常见的一种编程模型；首先不管 Continuation 是什么，先了解 Future 和 Promise；Wikipedia 是这样解释³的：

In computer science, future, promise, delay, and deferred refer to constructs used for synchronizing program execution in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is not yet complete.