0

我一直在考虑一个涉及到的设计：

  1. 客户端向端点发出 POST 请求
  2. 然后该路由（从返回我字符串化的请求对象的构造函数）发布到 redis 通道。例如 
( {request: String, transid: String, data: Object } )
  1. 侦听该通道的另一台服务器解析 JSON -> 从 obj 切换请求密钥
  2. 是否具有验证凭据等功能；
  3. 调用一个类，该类返回一个预制的响应对象，该对象转换为 str，并通过同一（或另一个通道）发送回正在异步侦听等待的路由处理程序（通过该通道发送原始请求）（在这种情况下，禁食。）例如
    ( { "transid": "1234-Abcd-5678-abcde", "state": Boolean, data: <data> } )

时间线

路由处理程序向 redis 侦听器发出 Pub 请求：

  1. ( {request: "auth", transid: "1234-Abcd-5678-abcde", data: { email: "test@test.com", "password": "pass" } )

  2. 另一台服务器上的订阅侦听器执行内部凭据验证

发布回 redis 频道

  1. ( {transid: "1234-Abcd-5678-abcde", state: false, data: { error: "Incorrect" } } )

  2. 路由处理程序使用库特定方法回复客户端，即 request.send(200)

我的问题是我不完全了解如何在上述时间线中实现第 4 步的结果；即是否有可能在路由处理程序中几乎等待消息？我已经非常接近了，但是当我设计能够扩展的东西时，我质疑这是否是一种实用的方法。（用户将详细信息发送到 /endpoint，/endpoint 路由处理程序将 json 消息发布到通道，外部服务器侦听解析消息并将其发送到 switch 语句，即 [switch(data.request)]，该语句调用执行 DB 的函数操作，然后使用类构造函数生成一个对象，通过 redis 通道发送回路由处理程序，该处理程序将等待回复，然后回复给客户端。）

请问有人对此有意见吗？

4

1 回答 1

1

pub/sub 背后的概念是解耦和执行异步任务，但是你强迫系统采用同步风格，这让他的所有优点都消失了。

例如：如果您发布消息，则没有订阅者收到它..您会做什么？重试？- 客户端超时，错误？- 但用户只想登录并且数据库正在运行

此外，当流量增加时，响应会变慢，因为所有这些消息都只有一个订阅者，因为发布/订阅是广播的，并且您不想处理两次登录逻辑！（我假设）

因此，要解决它，您应该实现一个 peer2peer 逻辑，其中： - 所有订阅者都收到消息 - 每个订阅者彼此认识 - 一个订阅者说“我会做这项工作” - 一个“主要”订阅者说没关系 - 另一个订阅者丢弃消息 - 主要订阅者崩溃，您需要选举才能拥有新的主要...... - 等等......

但这是消息代理或redis 流 api 所做的，因此您不需要自己实现。我过去做过，但 Redis 5 还不存在。

由于这些原因，我认为您应该以同步的方式进行同步工作。pub/sub 不适合您的使用示例。

于 2020-03-30T07:08:50.783 回答