项目介绍
Rudis 是一个高性能内存数据库。
Rudis 是采用 Rust 语言开发的项目，旨在利用 Rust 语言的优势来重新实现 Redis 的核心功能，以满足用户对高性能、可靠性和安全性的需求，同时保持与 Redis API 的兼容。
项目地址
Gitee：https://gitee.com/Jmysy/rudis
Github：https://github.com/sleeprite/rudis
备注：release 目录，发行包
官网前瞻
项目特性
- 跨平台，兼容 windows、linux 系统架构。
- 兼容 字符串、集合、哈希、列表、等结构。
- 提供 rdb 与 aof 机制以支持数据备份和恢复。
- 兼容 Redis 的命令和协议规范。
- 内置 40+ 操作命令。
快速入门
参数启动
start rudis-server.exe --port 6379
指定配置
start rudis-server.exe rudis-server.properties
启动成功
启动参数
-
port 端口, 默认: 6379
-
save RDB 保存策略, 默认：none
-
password 密码, 默认：none
-
databases 数据库数量, 默认：16
-
appendfilename 持久化日志路径
-
appendonly 开启持久化，默认：false
-
dbfilename 数据文件名，默认：dump.rdb
-
maxclients 会话上限，默认 1000
-
hz 定时任务的频率，默认 10（次/秒）
-
dir 数据持久化目录，默认 "./"
-
bind 绑定的主机地址
项目结构
command
command 包是一个用Rust编写的模拟Redis服务器的组件，主要负责实现Redis协议的解析、数据库操作的执行以及相关结果的响应。该包内部包含了针对不同Redis命令的实现，如SELECT、GET、SET等。其核心功能是根据Redis协议规范，解析来自客户端的命令请求，并在模拟的Redis数据库上执行相应的操作，再将结果返回给客户端。通过实现各个Redis命令处理器，实现了对Redis协议的完整支持，并提供了一个简单而有效的策略来处理不同类型的命令。
db
db 包是一个基于内存的数据库管理系统。该模块提供了基础的数据结构约定，以及数据库操作功能，包括对数据的增、删、改、查等操作。
Persistence
persistence 包实现了 AOF 和 RDB 的核心逻辑，该包负责将操作写入和追加到 AOF 文件中，以及 dump.rdb 文件，确保 Redis 数据库的数据持久性和一致性。
session
session 模块的设计目的是提供一个简单的会话管理功能，用于跟踪用户的操作状态，例如用户所选的数据库索引以及用户是否已认证等信息。这对于需要进行用户认证或者跟踪用户操作状态的系统是非常有用的。
tools
tools 包是一个工具包，其中包含了一些通用的工具函数或工具类，用于辅助实现系统功能或处理特定任务。这些工具可以被其他模块或组件调用，以提高代码复用性和降低重复编写相似功能的工作量。
操作命令
echo 命令
127.0.0.1:6379> echo helloword
helloword
ping 命令
127.0.0.1:6379> ping
PONG
set 命令
127.0.0.1:6379> set user bailiang
OK
set 命令 [过期]
127.0.0.1:6379> set user bailiang px 10000
OK
127.0.0.1:6379> set user bailiang ex 10
OK
get 命令
127.0.0.1:6379> get user
bailiang
del 命令
127.0.0.1:6379> del username
(integer) 1
127.0.0.1:6379> del username password
(integer) 2
exists 命令
127.0.0.1:6379> exists user
(integer) 0
keys 命令
127.0.0.1:6379> keys *
(empty list or set)
auth 命令
127.0.0.1:6379> auth 123456
OK
expire 命令
127.0.0.1:6379> expire user 10000
(integer) 0
select 命令
127.0.0.1:6379> select 1
OK
dbsize 命令
127.0.0.1:6379> dbsize
(integer) 2
flushdb 命令
127.0.0.1:6379> flushdb
OK
flushall 命令
127.0.0.1:6379> flushall
OK
append 命令
127.0.0.1:6379> append user bailiang
(integer) 10
move 命令
127.0.0.1:6379> move user 0
OK
rename 命令
127.0.0.1:6379> rename username new_username
OK
rpush 命令
127.0.0.1:6379> rpush key value1 value2
OK
lpush 命令
127.0.0.1:6379> lpush key value3 value4
OK
llen 命令
127.0.0.1:6379> llen key
(integer) 4
文章结语
项目的相关事项都在紧锣密鼓的筹备中，包括文档的编写，官网的构建。在首次发布的版本中，你可以认作这是一次的公开性的测试。我们期望产品与用户产生链接，以帮助我们进入到一个正向的循环。
评论区
写评论...一个最简单的事情你都没有想明白，你用arcMutex,操作同一个数据，那单位时间内就是一个线程在跑，怎么可能出现多核性能线性增长的情况，剩下的核心和线程都在等锁的释放，你咋就是不明白呢
--
👇
lithbitren: 你到底测过没有，就敢下多核拉低性能的结论，你不会觉得所有lockfree的hashmap的性能全是假的吧。单核计算硬件有加速，但对于一些lockfree的hashmap来说，多线程数量在核心数七八成之前，总性能基本是线性增长的，只有跑满核心数后单核性能才会下降到真实水平，但总性能仍然是最高的，如果协程数量远超线程数，比如数万数十万协程并发，总性能反倒会被协程调度拖累。
而且我之前说了，即便是最慢的管道法，也有几百万的tps，本身很难成为整个系统的性能瓶颈。原子操作也是数据竞争的表现，只是数据竞争的烈度更小，
AtomicI32用Ordering::SeqCst进行原子操作和Arc<Mutex<i32>>的性能差不多，用Ordering::Relaxed能强个两三倍一些，但可能会有其他问题，需要更合理的系统设计。--
👇
kwsc98: 多线程io处理，和单线程命令处理模型，本身就是分开讨论的，我看来一下当时大家讨论的也都是单线程命令处理的优势，这一点一直没有变也是redis设计之初的核心。引入多线程io处理也并没有改变命令处理的单线程处理模型，而如果做多线程的命令处理的话，就会遇到多线程抢锁的问题，也确实会拉低性能，大家表示的其实没有问题，tokio的mpsc管道，其实就是一个典型的"多线程io处理，单线程命令处理"模型，我写的redis就是基于mpsc管道写的https://github.com/kwsc98/kedis-rust，包括我写的微服务框架里的注册中心异步监听也大量运用的mpsc管道来实现无锁的并发读取修改
你到底测过没有，就敢下多核拉低性能的结论，你不会觉得所有lockfree的hashmap的性能全是假的吧。单核计算硬件有加速，但对于一些lockfree的hashmap来说，多线程数量在核心数七八成之前，总性能基本是线性增长的，只有跑满核心数后单核性能才会下降到真实水平，但总性能仍然是最高的，如果协程数量远超线程数，比如数万数十万协程并发，总性能反倒会被协程调度拖累。
而且我之前说了，即便是最慢的管道法，也有几百万的tps，本身很难成为整个系统的性能瓶颈。原子操作也是数据竞争的表现，只是数据竞争的烈度更小，
AtomicI32用Ordering::SeqCst进行原子操作和Arc<Mutex<i32>>的性能差不多，用Ordering::Relaxed能强个两三倍一些，但可能会有其他问题，需要更合理的系统设计。--
👇
kwsc98: 多线程io处理，和单线程命令处理模型，本身就是分开讨论的，我看来一下当时大家讨论的也都是单线程命令处理的优势，这一点一直没有变也是redis设计之初的核心。引入多线程io处理也并没有改变命令处理的单线程处理模型，而如果做多线程的命令处理的话，就会遇到多线程抢锁的问题，也确实会拉低性能，大家表示的其实没有问题，tokio的mpsc管道，其实就是一个典型的"多线程io处理，单线程命令处理"模型，我写的redis就是基于mpsc管道写的https://github.com/kwsc98/kedis-rust，包括我写的微服务框架里的注册中心异步监听也大量运用的mpsc管道来实现无锁的并发读取修改
多线程io处理，和单线程命令处理模型，本身就是分开讨论的，我看来一下当时大家讨论的也都是单线程命令处理的优势，这一点一直没有变也是redis设计之初的核心。引入多线程io处理也并没有改变命令处理的单线程处理模型，而如果做多线程的命令处理的话，就会遇到多线程抢锁的问题，也确实会拉低性能，大家表示的其实没有问题，tokio的mpsc管道，其实就是一个典型的"多线程io处理，单线程命令处理"模型，我写的redis就是基于mpsc管道写的https://github.com/kwsc98/kedis-rust，包括我写的微服务框架里的注册中心异步监听也大量运用的mpsc管道来实现无锁的并发读取修改
👇
lithbitren: https://www.zhihu.com/question/23162208?utm_psn=1799991864016891905
不说完全失效，但按时间搜索排序，起码2018以前，对redis总是在找各种理由说多线程没必要的，单线程自己足够好了，甚至不少人表达了多线程抢锁模式反而会拉低性能，2020以后的各类讨论起码不再说多线程没必要了。
pika是按照redis协议用多线程实现的计算模型，除了大key写性能表现一般，其他情况下性能和核心数成正相关增长，多核性能远超redis。
--
👇
kwsc98: 目前为止redis本质还是单线程模型啊，引入多线程io也并没有让这方面八股文都失效，就是很经典的一个无锁并发安全模型。
https://www.zhihu.com/question/23162208?utm_psn=1799991864016891905
不说完全失效，但按时间搜索排序，起码2018以前，对redis总是在找各种理由说多线程没必要的，单线程自己足够好了，甚至不少人表达了多线程抢锁模式反而会拉低性能，2020以后的各类讨论起码不再说多线程没必要了。
pika是按照redis协议用多线程实现的计算模型，除了大key写性能表现一般，其他情况下性能和核心数成正相关增长，多核性能远超redis。
--
👇
kwsc98: 目前为止redis本质还是单线程模型啊，引入多线程io也并没有让这方面八股文都失效，就是很经典的一个无锁并发安全模型。
目前为止redis本质还是单线程模型啊，引入多线程io也并没有让这方面八股文都失效，就是很经典的一个无锁并发安全模型。
👇
lithbitren: redis在实现上是软件工程学的杰作，但在实现策略的选择上，很多时候就是简单。以前没有多线程io的时候，各种论证纯单线程的好，有了多线程io以后以前这方面的八股文都失效了。还有跳表也是，之前各种八股文论证跳表比红黑树以及其他对数容器这里好那里好，后来作者本人即答最主要的原因就是跳表实现简单。
lz大佬，如果可以的话，出一份类似这样的接口兼容表，可以方便功能对照。
https://github.com/OpenAtomFoundation/pika/wiki/pika-%E6%94%AF%E6%8C%81%E7%9A%84redis%E6%8E%A5%E5%8F%A3%E5%8F%8A%E5%85%BC%E5%AE%B9%E6%83%85%E5%86%B5
如果有精力的话，还可以考虑出一个rust版的local_redis/mock_redis的库，很多时候测试项目的时候不想单独再启动redis，但业务代码里又有很多时候需要缓存操作，如果一开始就在本地启动一个内存版的redis就好了，能兼容redis的命令，这样在真正上线的时候再调整初始化代码连接到正式的服务器就行。
其他语言多少都有点类似的的库，我之前也想弄来着，但把常用的redis命令实现出来就是个很繁琐的过程，lz大佬既然已经实现了大多数常用命令，再实现一下redis-rs客户端的接口就完成了，工作量理论上来说应该不是太大。
而且把计算模型抽象出来，理论上也可以方便二次开发搞个其他传输协议的rudis，不一定非得是tcp。
redis在实现上是软件工程学的杰作，但在实现策略的选择上，很多时候就是简单。以前没有多线程io的时候，各种论证纯单线程的好，有了多线程io以后以前这方面的八股文都失效了。还有跳表也是，之前各种八股文论证跳表比红黑树以及其他对数容器这里好那里好，后来作者本人即答最主要的原因就是跳表实现简单。
单线程处理命令在架构上更有序，而且容器内的子类型的实现也更轻松，如果用Arc<Mutex>或者是其他的一些无锁结构，在非读相关的命令里，处理起来更复杂，需要要求所有子容器类型都得实现数据共享。而单线程模型就简单了，只需要处理操作命令就完事了。
c语言本身的性能是毋庸置疑的，但redis的tps也就是几万到十几万每秒。redis的io可以是多线程的，但计算模型是单线程，中间过程肯定是有数据竞争的，tcp读写序列化以及数据竞争才是拉低redis里整体性能的主要原因。
rust即便是我说的最慢的tokio的教学项目mini-redis，不算tcp的io，也能达到数百万每秒的操作。 而在多核心的实例里，多协程高并发操作，dashmap这种无锁结构可以轻松达到数千万的tps。 即使是
Arc<std::sync::Mutex<HashMap<_, _>>>这样的同步锁结构，几百万每秒的tps也是轻轻松松。这种基础数据结构大多数操作原子性都很强，只要不是频繁使用扫描、快照相关的操作，同步锁的竞争对于rust来说基本不太可能整个架构的瓶颈。--
👇
kwsc98: 怎么可能用单线程模式纯粹是为了简单呢。。。肯定是用Arc<Mutex>实现最简单啊，无锁模型解决的高并发导致的锁竞争的问题，10个线程去竞争一个锁和10w个线程（异步线程）去竞争一把锁可不是一个概念，我不知道你和题主是怎么测的，如果单纯的一个线程去循环读写的话，那可能用Arc<Mutex>还真可能快一点，因为tokio可能也搞了一些类似java锁升级的东西，实例只被单线程请求的话，可能就走类似自旋锁的逻辑了。
怎么可能用单线程模式纯粹是为了简单呢。。。肯定是用Arc<Mutex>实现最简单啊，无锁模型解决的高并发导致的锁竞争的问题，10个线程去竞争一个锁和10w个线程（异步线程）去竞争一把锁可不是一个概念，我不知道你和题主是怎么测的，如果单纯的一个线程去循环读写的话，那可能用Arc<Mutex>还真可能快一点，因为tokio可能也搞了一些类似java锁升级的东西，实例只被单线程请求的话，可能就走类似自旋锁的逻辑了。
--
👇
lithbitren: 计算模型还是采用单线程模型吗？
redis采取单线程模型纯粹是实现比较简单，实际上肯定是lockfree的数据结构更快，当然具体肯定需要测试，包括性能和开销之类的，我测过很多rust实现的map，很多号称lockfree高性能map，实际不一定打得过
Arc<Mutex<HashMap>>,当然垫底肯定是类似于tokio教学项目里mini-redis这种用channel实现的单线程模型，我去年在win10测得最快的是leapfrog，其次是dashmap，不知道linux下表现怎样。持久化层面是什么策略？
有没有了解过类似于pika这样的redis相关项目，pika的持久化是通过rocksdb做的，理论上和kv数据库没啥大的区别，但性能比mongodb更好，不过用的人肯定没mongodb这么多，也不敢做太多可靠性保障。
搞webGUI我是四脚支持的。
关于可视化，键值的crud其实没有什么可说，顶多是常用key可以缓存在前端或web服务器内存里，方便每次打开GUI查看，当然也可以搞些对键值修改的实时监控，比如某些键值修改的日志之类的。
如果从运维角度出发，比较重要的还是集群节点状态可视化，比如动态监控和修改集群拓扑结构之类的。
感觉大部分情况下，1-3秒轮询一次比websocket更好，反正前端肉眼也不需要看到太过于实时的信息。
哈哈哈，是多线程加锁的架构，先抛开上边的线程模型，我对服务自带的 WEB UI 也更看重，毕竟在这个性能吊炸天的环境下，差一点也没关系，不过我经过实际测试，同环境，单实例要比 redis 快 1/3
我还在考虑，如何在启动 rudis-server 的同时，提供一个内置的 WEB 管理面板，对此你有什么建议
--
👇
sleeprite: 感谢
--
👇
he11olx: 点赞！
计算模型还是采用单线程模型吗？
redis采取单线程模型纯粹是实现比较简单，实际上肯定是lockfree的数据结构更快，当然具体肯定需要测试，包括性能和开销之类的，我测过很多rust实现的map，很多号称lockfree高性能map，实际不一定打得过
Arc<Mutex<HashMap>>,当然垫底肯定是类似于tokio教学项目里mini-redis这种用channel实现的单线程模型，我去年在win10测得最快的是leapfrog，其次是dashmap，不知道linux下表现怎样。持久化层面是什么策略？
有没有了解过类似于pika这样的redis相关项目，pika的持久化是通过rocksdb做的，理论上和kv数据库没啥大的区别，但性能比mongodb更好，不过用的人肯定没mongodb这么多，也不敢做太多可靠性保障。
搞webGUI我是四脚支持的。
感谢
--
👇
he11olx: 点赞！
感谢
--
👇
hohowt: 已star
我也是这么考虑的，在启动 rudis-server 的同时，如果能在内部启动一个 web 服务来提供可视化的界面，是个真棒的想法，但是目前没有理清楚应该怎么去加入到现有的代码中
--
👇
zhuxiujia: 感觉可以加个web GUI界面
感觉可以加个web GUI界面
已star
点赞！