设计 zmq.rs ——用 Rust 实现的 ZeroMQ（一）

从今年 3 月份看到有人打算用 Rust 重写 ZeroMQ、我开始认真学习 Rust 语言，到后来 6 月份开始着手实现，再到现在 0.1 版即将达成，前后也有小半年了。今天，我打算在这里把当前的设计总结一下，也顺便试图招募志愿者一起来做开发。

项目地址：https://github.com/zeromq/zmq.rs

没错木哈哈，被收编成了 ZeroMQ 官方项目了，所以一定来一起做哦。

关于本文：8 月份的草稿啊！这都年底了，真是醉了。下个月（2015 年 1 月）北京有个 Rust 的聚会，打算分享这个项目，所以现在果断删掉未完成章节，把能发的先发出来。

Rust 语言

忽然意识到之前几篇《Rust 语言学习笔记》一直没有介绍过 Rust 语言，这里一并补齐。

Rust 语言是几种下一代编程语言中较为优秀的一款系统级编程语言，最显著的特点就是运行时几乎不崩溃、高并发无数据竞争，还有就是跑的贼拉快。

相较于应用级编程语言如 Java 或 Python，Rust 作为一款系统级编程语言，天生被设计用来开发系统软件诸如操作系统、设备驱动或编译器等，与 D 语言、Go 语言齐名（大家对 Go 语言是否是系统级编程语言有争议），是 C++ 继位者的候选人。因此，Rust 理所应当是编译型的语言。依托于 LLVM，Rust 在编译器（Rust 编译器前端系 Rust 语言本身实现，即所谓的自举）上大下功夫，通过“所有权”的概念将内存管理的最佳实践整合在了编译期，在编译期保证了运行时的内存安全，且没有使用垃圾回收机制（垃圾回收是 Rust 的一种可选的额外工具），运行速度不打折扣。这种对内存管理的高要求，也让程序员可以更容易地用 Rust 语言编写正确的高并发程序，自然地实现类似 Erlang 的并发模型。另外受 Haskell 的熏陶，Rust 语言对函数式编程也是非常友好的——我自己认为要比 Python 函数式多了。另外，Rust 的语法一点也不诡异，如果您写过 C/C++/Java/Python/Ruby，您会觉得很多语法似曾相识，上手较快。

不多说了，毕竟不是《半小时，介绍 Rust》——有兴趣大家可以移步这里继续阅读。

ZeroMQ

ZeroMQ 乍一看是一种消息队列，但实际上它并不是传统意义上的消息队列——开一个消息服务器，所有消息都经过它，可以离线什么的。上述传统消息队列主要部分只是 ZeroMQ 指南中的一个叫做泰坦尼克的模式概念，ZeroMQ 的库中甚至都没有这种模式的实现。其实 ZeroMQ 是一种内嵌式的网络库，关注于怎样将程序连在一起。简单来说，您可以认为 ZeroMQ 是对普通 socket 的一种封装和抽象，将常规的通信工具封装成了 ZeroMQ 的 socket。您可以通过 ZeroMQ 的 socket 来实现通信，ZeroMQ 的 socket 则内置了消息排队、流量控制、收发模型、断线重连等机制，方便您设计出自己适合的消息通信模型。

介绍再细一点。

每个 ZeroMQ 的 socket 都有一个类型，决定了它内置的收发模型，比如创建一个用于发送请求的 REQ：

pythonsocket = context.socket(zmq.REQ)

REQ 就限制了，这个 socket 必须得先发送一个消息，然后才能——且必须——接收一个消息。发一个请求、收一个响应，绝对不能乱套：

python# print(socket.recv_multipart()) -- 这会失败

socket.send_multipart(["Hello"])
# socket.send_multipart(["Hello2"]) -- 这会失败

print(socket.recv_multipart())
# print(socket.recv_multipart()) -- 这会失败

socket.send_multipart(["Hello2"])

当然了，在收发消息之前，我们得先把我们的 socket 跟别的 socket 连上才行：

pythonsocket.connect("tcp://192.168.3.27:8868")

意思就是说，跟监听在 192.168.3.27:8868 上的 ZeroMQ socket 建立 TCP 链接。另外，ZeroMQ 还支持进程间通信（ipc）、进程内通信（inproc）和多播。

有趣的是，ZeroMQ 允许先 connect，再创建监听端的 socket（因为内置了断线重连机制）：

pythonserver_socket = context.socket(zmq.REP)
server_socket.bind("tcp://192.168.3.27:8868")

这个 REP 的 socket 也只是又一个普通的 ZeroMQ 的 socket，只不过 REP 的要求与 REQ 正好相反，必须得先收再发——收一个请求，返回一个响应。这里我们就不多做示例了。

每一个 ZeroMQ 的 socket 都（特例除外）可以多次做 connect 或/和 bind，只要 socket 之间建立了连接，他们就可以在各自类型的约束下实现通信。对 REQ 来说，发送时会轮流使用所有连接，接收时必须从上一次发送去的连接来接收；而对 REP 来说，所有连接上进来的请求都会被公平的排队，REP 会公平地接收，而发送时则保证将响应发送回请求的来源。这些就是所谓的收发模型，这对用户都是透明的，您只需要调用 send 或 recv 就可以了。

除了请求-响应模式的 REQ 和 REP，ZeroMQ 常用的一些 socket 类型还有：高级请求-响应模式的 DEALER 和 ROUTER、发布-订阅模式的 PUB 和 SUB、流水线模式的 PUSH 和 PULL 等。

实际应用中，我们通常会将上述这些基本模式综合使用，组成各种各样的高级模式——比如一开头提到的泰坦尼克模式——去解决很多实际中的问题。这些就不多说了，大家有兴趣可以再次移步这里来观摩学习。

Task 模型的小纠结

该进入正题了。这一部分跟之前的那篇英文博文的第一部分对应的。这一部分和接下来的一部分主要做两个关键的技术选型。

我对 zmq.rs 的设计“借鉴”了 libzmq 很多——为了保留借鉴痕迹便于参照，有些名词我连名字都没有改（呃，这句英文博文里没有……）。之前的几篇《Rust 语言学习笔记》中，其实我已经在试图搭 zmq.rs 的架子了，有个关键性的问题在当时就已经出现了：

怎么样正确使用 Rust 的 Task。

目前来看，针对于我的项目，C++（libzmq 的实现语言）和 Rust 有两点重要的不同：

1. Rust 还没有提供一个可用的、用于轮询文件描述符的 select() 接口，以及
2. Rust 默认提供了一个可选的库 libgreen ——提供了微线程的实现。

作为一个 Gevent 的重度用户，我自然而然地选择了微线程模型，通过创建大量 Task 来实现并发，底层与直接使用 select() 来实现异步并发并无实质区别。这听起来非常理想，但遗憾的是 libgreen 并不是 Rust 的默认选项—— libnative 才是。这样的话，如果用户选择默认使用 libnative，那么 zmq.rs 轻轻松松就可以帮用户创建数百个操作系统级的线程，因为 libnative 1:1 的模型下，一个 Task 就是一个线程嘛。

这就不是一件很令人愉快的事了。那我们先放下这个，看看另外一条路吧：完全借（zhao）鉴（ban）libzmq，Rust 里缺什么再补什么，比如 select()。1:1 的 libnative 模型自然就不会有问题了，因为我们将要自己重新实现异步，所以开启的 Task 数屈指可数。虽然没有了协作式的异步编码优势，但这条路上的代码也可以写的干净整洁——至少不会比 libzmq 差吧。可是，这个时候假如用户又选择了使用 libgreen，又会怎么样呢？咣当！几个协作式的异步 Task 在分别执行一段手动实现的异步代码，何其诡异！因为协作式的异步 Task（即微线程）是应该被主事件循环驱动的，而不是用来跑一个自己写的事件循环！微线程本来就是设计用来将异步代码同步化、提高可读性、降低编程复杂度，而不是像现在这样又全都搞回去了。libgreen 在底层已经使用了 libuv 作为主循环来调度所有的 Task，而我们现在为了实现 select()，还得想办法把 libuv 底层的接口给暴露上来。最后，我们还得使用这些接口，重新自己实现一遍异步任务调度。

就我来看，上述方法有可能是在 libgreen 下实现 select() 的最合理的方法，但这让我觉得非常别扭，感觉好像把 1:1 的 libnative 跟 M:N 的 libgreen 做出统一的接口是个糟糕的主意。这里不深究了，问题交给 Rust 1.0 之后打算实现 select() 的人去吧。这里呢，我选择了第一种方案，也就是把 Task 当微线程的方案，因为目前来看这种方案需要写的代码更少，而且感觉更像是 Rust 期望的样子。

补充：其实也没有必要整个程序全都一致要求要么 libnative 要么 libgreen 的，为什么不能混着用呢？我的 zmq.rs 内部自己搞一个 libgreen 的 Scheduler 好了，自己强制使用微线程模型；调用的人爱咋咋地呗。所以也就不纠结了。

基于接口的继承

这个事儿也让我纠结了很久，也别扭了很久：Rust 里的继承只包括成员方法，不包括成员变量。换句话说，Rust 里没有类，只有接口（Trait）和数据结构（Struct），struct 可以实现 trait，trait 可以继承 trait，但是 struct 不能继承 struct。这让用惯了 Python 的我非！常！不！爽！怎么能这样呢，父类里根本不能定义数据！难道父类搞个多态还得每次要数据的时候调用一个 self.getData() 吗？这据说还是面向对象编程的一个演化方向呢，求高人点解啊……

这里碰到的问题主要是定义 SocketBase 啦，人家 libzmq 里洋洋洒洒几个文件，轻松搞定了漂亮的继承关系。到我这里死活搞不漂亮了：作为父类的 SocketBase 必须得自己负责一部分数据，而子类跟 SocketBase 又是息息相关的。

怎么办嘞？

拆！还是顺应了那句老话，先组合后继承。现在呢，我的 socket 长这样：

所以呢，ReqSocket 和 RepSocket 的 bind() 里只有相同的一句：self.base.bind()，connect() 也是类似。而对于 send() 和 recv() 的实现，两种不同的 socket 则有了不同的实现，且调用 self.base 的函数也不尽相同。

用这种组合的方式固然解决了当下的问题，但不知以后能不能学会 Rust 里基于接口的继承。