3个不稳定版本

0.2.0 2019年5月1日
0.1.1 2019年3月29日
0.1.0 2019年3月25日

#29 in #tcp-client

MIT 许可证

77KB
2K SLoC

meilies

MeiliES

基于Rust和Redis协议的事件存储

Build Status Dependency Status

meilies-client crate meilies-client documentation

简介

该项目不再维护,请考虑寻找其他工具。

MeiliES是一个使用RESP(REdis Serialization Protocol)进行通信的事件源数据库。这样可以通过重用现有的协议来创建客户端。例如,可以使用官方Redis命令行界面程序与MeiliES通信。如果您想了解更多信息,请参阅发布博客文章

事件存储类似于Kafka或Rabbit MQ,但它在磁盘上无限期地存储事件。服务器的主要目的是将流事件发布给所有已订阅的客户端,请注意事件按接收顺序保存。客户端还可以指定从哪个事件编号(递增)开始读取,因此可以通过读取和重建仅包含新事件的状态来恢复崩溃。请记住,消息队列不适合事件源

MeiliES demo

功能

  • 事件发布
  • 从可选事件编号开始的TCP流订阅
  • 弹性连接(在关闭时重新连接)
  • 基于Redis的协议
  • 全Rust,使用sled作为内部存储
  • 编译时间接近2分钟

构建MeiliES

要运行MeiliES,您需要Rust,您可以通过https://rustup.rs上的步骤进行安装。一旦Rust已添加到您的PATH,您就可以克隆并构建MeiliES二进制文件。

git clone https://github.com/meilisearch/MeiliES.git
cd MeiliES
cargo install --path meilies-server
cargo install --path meilies-cli

基本事件存储使用方法

一旦MeiliES安装并可在您的PATH中找到,您可以通过执行以下命令来运行它。

meilies-server --db-path my-little-db.edb

现在您的机器上正在运行一个MeiliES服务器,并监听在 127.0.0.1:6480。在另一个终端窗口中,您可以指定客户端只监听新事件。

meilies-cli subscribe 'my-little-stream'

再次在另一个窗口中,您可以发送新事件。所有订阅了相同流的客户端都将看到这些事件。

meilies-cli publish 'my-little-stream' 'my-event-name' 'Hello World!'
meilies-cli publish 'my-little-stream' 'my-event-name' 'Hello Cathy!'
meilies-cli publish 'my-little-stream' 'my-event-name' 'Hello Kevin!'
meilies-cli publish 'my-little-stream' 'my-event-name' 'Hello Donut!'

但这并不是事件源的一个真正有趣的用法,对吧?!让我们看看更有趣的用法。

真实事件存储使用

MeiliES按接收顺序存储所有客户端发送的所有流的全部事件。

所以让我们检查一下,并指定一个客户端从哪个时间点开始读取事件。一旦流中没有更多事件,服务器就会在接收到事件的时刻开始发送事件。

流名称指定

流名称由以下组成。

{名称}{:}{:}

  • 名称:流的名称,区分大小写,不得包含空格(建议使用短横线分隔单词)。
  • 从:指定开始读取的第一个事件号。可选,如果没有设置,MeiliES将从末尾开始。
  • 到:指定要发送的最后一个事件号(范围不包括该号)。可选值,如果没有给出,将永远不会停止。

示例

我们可以通过在起始事件号前加上冒号来完成这个操作。

meilies-cli subscribe 'my-little-stream:0'

在这个例子中,我们将从流的第一个事件开始读取。但我们也可以指定从第三个事件开始读取。

meilies-cli subscribe 'my-little-stream:2'

或者从尚不存在的事件开始!尝试向此流发送事件,您将看到:只有第五个事件会出现。

meilies-cli subscribe 'my-little-stream:5'

也可以读取到某个事件号为止的流。

meilies-cli subscribe 'my-little-stream:3:5'

当前限制

当前实现有一些与订阅的流总数相关的限制。问题是每个流和每个客户端都会启动一个线程。例如,如果有两个客户端订阅了同一个流,服务器将启动两个线程,每个客户端一个,而不是只启动一个线程并将新事件发送到客户端池。

更糟糕的是,如果一个客户端关闭连接,启动的线程不会立即停止,而是在一些流活动后才会停止。

支持

对于商业支持,请发送电子邮件至 [email protected]

依赖关系

~5MB
~74K SLoC