今天太开心了，因为我知道了seastar框架

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

今天听说了一个新的C++语言开发的网络框架，叫做seastar。

seastar有何特别之处呢？先看看官网提供的性能数据：

性能

HTTPD benchmark:
cpu # request/sec
2 637,430(相当于单核性能318715/s )
4 1,303,761
6 1,907,912
8 2,493,690
12 3,495,012
16 4,385,829
20 5,359,786
24 6,291,073
28 6,826,827
32 6,869,199

cpu #	request/sec
2	637,430(相当于单核性能318715/s )
4	1,303,761
6	1,907,912
8	2,493,690
12	3,495,012
16	4,385,829
20	5,359,786
24	6,291,073
28	6,826,827
32	6,869,199

Memcached Benchmark:

CPU	Seastar Memcached with DPDK	Stock Memcached (multi process)	Stock memcached (multi threaded)
2	553,175(单核性能276587/s)	350,844	321,287
4	1,021,918	615,270	573,149
6	1,703,790	857,428	709,502
8	2,149,162	1,102,417	741,356
10	2,629,885	1,335,069	608,014
12	2,870,919	1,528,598	608,968
14	3,217,044	1,726,642	440,658
16	3,460,167	1,887,060	603,479
18	4,049,397	2,167,573	902,192
20	4,426,457	2,281,064	1,128,469

网络框架单核的极限性能我做过很多次，我几年前测试得到的数据大约是：

http网络服务，单核极限性能7万~9万/s
tcp协议网络服务，单核极限性能21万~24万/s

以上的测试是简单的echo服务，没有任何业务逻辑。TCP服务更是简单，每个请求仅50字节。

在seastar框架中，http协议的单核处理能力上涨了约4.5倍。这虽然让人欣喜，但并不惊奇。令人惊奇的地方在于，框架的处理性能随着核数的增加而线性增加！

通常而言，随着操作系统和业务的复杂性，网络框架的处理性能并不会因为核数线性增加，应该类似于对数曲线的效果：

而从官方测试数据看，几乎是达到了线性增长的效果。如果是使用现在的上百核的服务器，单机性能超过千万每秒是毫无疑问的。

单机网络处理性能超过千万每秒，这就是我激动的原因。

C10K问题与C10M问题

这时就要谈起高性能网络服务器的两个经典问题，称为C10K问题和C10M问题。

C10K就是指单机网络处理性能达到1万/每秒的并发处理能力
C10M指单机网络处理性能达到1000万/每秒的并发处理能力

The C10K problem 由 Dan Kegel 于2003/11/03 提出。在当时的硬件水平和操作系统能力上，单机支持1万并发是很有难度的事情。由这个问题开始，催生了epoll为核心网络编程技术的推广。

The C10M problem 由 Robert Graham 于2013/02提出。十年过去了，硬件、网络、操作系统都有大幅的提升，如何做到单机1000万并发呢？当时讨论的可行方案是多队列网卡+多核IO+用户态协议栈。后来，intel放出了DPDK这个网络包处理的神器，陆续开始有团队基于DPDK挑战C10M的具体实现。

而今，seastar出现了，这就意味着后台程序员可以以很低的门槛轻松写出具备C10M性能的网络服务！！！令人惊叹。

seastar的牛叉之处

对于其内部理念的介绍，我推荐阅读这篇：《Seastar：多核机器上编写高效复杂的服务器应用程序的 C++ 库》

通过官方文档可以了解到这些特性：

底层包处理的API不是epoll，而是DPDK

有了DPDK，网卡中的包直接被传输到用户空间的buffer中，免去了内核协议栈的层层处理。当然这里还需要一个用户态的协议栈，使得可以以更少的内存和更小CPU消耗来处理大量的网络包。

DPDK的使用门槛还是比较高的，而seastar已经把这个神器封装在了框架之中，实在是皆大欢喜。
无共享设计

这也就是网络框架处理性能随着核数增加而增加的秘诀。

首先，处理上是多核IO的，充分发挥出了服务器的IO能力；

其次，各个核的处理逻辑独立，减少了操作系统调度和NUMA结构的影响；

就算各个核之间需要通讯，seastar也提供了很好的通讯机制来避免加锁。
充分利用了C++语言的新特性

高性能的网络框架毫无疑问应该设计成纯异步非阻塞的。但是异步代码难写难调试，开发周期太长。seastart利用了Futures and promises这样的C++语言特性，使得代码可以同步编写异步执行，降低了心智负担，又不会带来性能的损失。

seastar会带来什么改变

我认为seastar并不仅仅只是又一个网络框架的轮子而已，它的出现将会改变一些领域的玩法：

倍数的性能提升，以及可以随着核数增加而线性增加的性能，使得很多不得不依赖分布式解决的问题可以依赖单机解决，并且获得更高的吞吐量和更低的成本。特别是纯网络服务一类的应用，例如DNS POD分享的经验，之前做了很多分布式的方案来解决大量域名托管的问题，后来硬件水平上去了就可以简单粗暴的单机解决。

典型的应用有：NTP服务，DNS服务，cache服务，内存数据库等。seastar能够让这类服务的硬件成本缩减数倍。
云上的微服务，其通讯不再使用TCP/IP了，而是有特定的系统调用来专门发给特定的类似seastar写成的服务进程。让微服务的开发更简单，又能充分榨干网络服务器的性能。
在高带宽低延迟的场景，seastar能够让团队快速开发出满足要求的应用。典型的是实时音视频传输的场景，流量又大，对延迟又敏感，传统的nginx一类的网络服务框架，在seastar面前黯然失色。

对这个框架也有一些期待：