我们的电子商务市场应用程序正在从单体架构转变为微服务架构。我们选择 Redis pub/sub 用于微服务到微服务的通信以及一些推送通知目的。推送通知策略如下：
无论何时创建订单（即客户创建订单），后端都会在相应的通道（队列）中发布一个事件，并且特定的推送通知微服务会使用此事件（json 消息）并将推送通知发送到卖家手机。
目前我们正在使用安装在我们的 ubuntu 机器上的 redis-server，没有任何麻烦。但令人头疼的是，未来一个时间点会产生数百万个订单，我们该如何处理这种情况呢？这意味着，我们需要扩展 Redis 队列，对吧？
我的确切问题（不管上述情况）是：
如何横向扩展 Redis 队列而不是增加同一台机器的 RAM？
【问题讨论】：
标签： redis microservices message-queue publish-subscribe redis-cluster
无论何时创建订单（即客户创建订单）， 后端在相应的通道（队列）中发布一个事件，并且 具体推送通知微服务消费这个事件（json 消息）并向卖家手机发送推送通知。
IIUC 您正在通过 Redis PUB/SUB 发送消息，这不是持久的，这意味着如果唯一的生产者启动而其他服务/消费者关闭，那么消费者将错过消息。任何宕机的服务都将丢失该服务宕机时发送的所有消息。
现在让我们假设，您正在使用 Redis LIST 和其他数据结构组合来解决缺少事件的问题。
扩展 Redis 队列有点棘手，因为整个数据都存储在一个列表中，该列表驻留在单个 Redis 机器/主机上。您可以做的是创建自己的分区方案并按照分区方案设计您的 Redis 键，就像我们在集群中添加新主节点时 Redis 在内部所做的那样，创建一致的哈希需要一些努力。
非常简单，您可以根据 userId 分配负载，例如，如果 userId 介于 0 和 1000 之间，则使用 queue_0、1000-2000 queue_1 等。这是一个手动过程，您可以使用一些脚本自动执行。每当向集合中添加新队列时，都必须通知所有消费者，并且发布者也将被更新。
基于数量的划分是范围分区方案，您也可以使用散列分区方案，您可以使用范围或散列分区方案，每当将新队列添加到队列集中时，必须通知消费者潜在的更新。消费者可以为新队列生成一个新的工作人员，移除一个队列可能会很棘手，因为所有消费者必须已经耗尽了他们各自的队列。
您可以考虑使用Rqueue
【讨论】：