现有方案是 mqtt 服务器。 但是今天仔细看了了一下 redis7 的 acl 控制。感觉权限可以缩小到很小 。另外 Stream 结构可以直接用 redis 解决消息持久化的问题。 所以在琢磨用 redis 直接做 mq 服务器。不再经过 mqtt 转发一次浪费性能。 直接给每一个用户的客户端分配一个 redis 账号,账号定时横换。
因为用户的客户端不可信,有几个问题不知道如何解决,独立的临时账号解决了客户端的安全问题,那么主要是客户端的资源占用的限制上。
暂时只想到这些,恳求各位赐教!
1
prenwang 2023-08-16 01:20:49 +08:00
不用考虑 redis ,mqtt 才是王道, 原因就一个, 行业规范, 客户端终端基本都会支持 mqtt 协议。
如果你是做的玩,随便用什么无所谓。 |
2
CEBBCAT 2023-08-16 01:27:07 +08:00
对 MQTT 不是非常熟悉,但我认为直接把「 Redis as MQ 」这样的解决方案暴露给客户端是不明智的,因为 Redis 不是设计给这种用途的。例如连接数、公网安全、弱网鲁棒性。
我觉得要么用经典方案,要么想想办法弄个网关 |
3
flyingfz 2023-08-16 09:22:41 +08:00
|
4
159526aa 2023-08-16 11:37:12 +08:00
mqtt 的订阅发布功能 qos1,2 怎么通过 redis 实现
|
5
pming1 2023-08-16 11:45:04 +08:00
如果是玩具的话,量不大,redis 随便折腾,redis 还有时序和号称性能堪比 elasticsearch 的 jsonsearch
|
6
winglight2016 2023-08-16 16:38:29 +08:00
你想直接暴露 redis 到外网?即使 MQ 也不建议如此做,前置一个 gateway 来转发吧,rate limit ,block ip 这些都是插件解决
|
7
xmt328 2023-08-16 17:56:31 +08:00
这方案哪怕是写着玩,也过于离谱了点
|
8
joyanhui OP 这几天 我 完成了 esp32 下 redis 集群客户端 。redis server 端口通过 redis 模块 重写了部分指令 ,进行了 qps 限制和 key 长度限制。
单个账号的重复登陆 和 连接内存占用也加了限制,也对 auth 指令的穷举次数做了限制。 客户端能用到的指令。都通过 redis module 进行了重写和限制。 算是解决了我正文里面提到的几个问题。 楼上各位大佬 都只是在说 不建议,但是没有人说原因和解决方案。 想知道 理由和原因。 |
13
joyanhui OP 感谢各位!
经过几天折腾和反复测试,redis 性能确实要比多数 mqtt 好很多,但是多并发的情况下,性能开支不低。虽然比部分 mqtt 还是好很多。但是依旧不客观。 目前自己用 golang+gnet 实现了针对物联网的消息服务器,性能满意。 |