我一直在考虑一个设计，包括：
向端点发出post请求的客户端
然后，路由发布（从返回请求对象的构造函数，我将其字符串化）到redis通道。例如。
( {request: String, transid: String, data: Object } )另一个侦听该通道的服务器解析json->从obj切换请求键
验证凭证等功能；
调用一个类，该类返回一个预先生成的响应对象，该对象被转换为str，并通过相同的（或另一个通道）发送回路由处理程序（通过该通道发送原始请求），路由处理程序正在异步等待（在本例中为fastfy）。 ( { "transid": "1234-Abcd-5678-de", "state": Boolean, data: <data> } ) 时间线
路由处理程序向redis侦听器发出pub请求： ( {request: "auth", transid: "1234-Abcd-5678-de", data: { email: "test@test.com", "password": "pass" } ) 另一台服务器上的订阅侦听器执行内部凭据验证
发布回redis频道 ( {transid: "1234-Abcd-5678-de", state: false, data: { error: "Incorrect" } } ) 路由处理程序使用特定于库的方法（如request.send（200））回复客户端
我的问题是我不太明白如何才能达到上述时间表中第4步的结果；i、 e.在路由处理程序中几乎可以等待消息吗？我已经非常接近了，但我怀疑这是否是一个实际的方式去做的事情，当我设计的东西，能够扩展(用户将详细信息发送到/endpoint，/endpoint route handler将json消息发布到channel，外部侦听服务器解析消息并将其发送到switch语句，即[switch（data.request）]，该语句调用执行db操作的函数，然后使用类构造函数生成一个对象，通过redis通道发送回等待回复的路由处理程序，然后回复给客户端。）
请问有没有人对此有什么意见？
1条答案
按热度按时间khbbv19g1#
pub/sub背后的概念是解耦和执行异步任务，但是您正在强制系统采用同步样式，这就消除了他的所有优点。
例如：如果发布消息，则所有订户都不会收到它。。你是做什么的？重试？-客户端的超时正在计时，错误？-但是用户只想登录并且数据库正在运行
此外，当通信量增加时，响应会变慢，因为所有这些消息只有一个订户，因为pub/sub是广播的，您不想处理登录逻辑两次(我猜想）
所以要解决这个问题，你应该实现一个peer2peer逻辑，其中：-所有订阅者都收到消息-每个订阅者都认识彼此-一个订阅者说“我会做这个工作”-一个“主要”订阅者说它是好的-其他订阅者丢弃消息-主要订阅者崩溃，你需要一个选择来拥有一个新的订阅者主要..-等。。。
但是这是消息代理或redis streamapi所做的，所以您不需要自己实现。我以前做过，但Redis5还不存在。
基于这些原因，我认为你应该用同步的方式来做同步工作。pub/sub不适合您的用法示例。