Redis或其他方式实现简易的消息队列

[北京-工程师-小帅哥]
好像不建议用redis的pub,sub吧

[北京-后端-z良]
场景不在乎消息丢失，不需要消息持久化。
  
[北京-工程师-小帅哥]
是不是有超时导致的  或者服务端主动断开连接，

[北京-后端-z良]
我查了服务端设置了timeout，但是官方说 这个timeout不对pub/sub生效。 这个timeout是多久关闭空闲连接。

[北京-工程师-小帅哥]
那你在sub断开连接之后重新建立链接吗
场景不在乎消息丢失，不需要消息持久化。 我觉得这个你可以自己实现，也就是说你对这个场景的高可用的需求是比较低的

[北京-后端-z良]
主要是维护集群的字典树。

[北京-工程师-小帅哥]
你可以自己搭一个简单的消息总线，或者消息中心， 或者直接调用对方接口

[北京-后端-z良]
是个办法，不过这样就划不来了。 我原本就是为了偷懒才没用kafka

[北京-工程师-小帅哥]
消息量不大的话自己搭是最省事的,2-3台机器负载，没有多订阅方或者多发布方的话，就简单了. 消息格式，消费方式都由你自己定, 或者你基于redis的其他机制，把redis当做消息的存储也行，先轮训，然后删除消息, 或者基于redis的数据过期策略自动删除.
我们部门原来做过基于业务的消息中心，就是好几个业务系统发消息到消息中心，然后有个首页工作台系统展示消息，来消费的，这个系统不直接对接这些业务系统，不用公司的mq,也不用开源的，消息中心就是也存redis,mysql,但是不是那种kafka或者pub/sub的形式，相当于有个中转.因为消息量不是很多，所以可以这么搞，比如谁审批了你的单子，谁在内网评论了你的动态，你可以在工作台的系统上看到有多少条消息提醒，这种的.

来源：云原生后端社区https://www.yuque.com/server_mind/answer