我们正在为我们的电子商务市场应用程序从单片架构转向微服务架构。我们选择redis pub/sub用于微服务到微服务的通信，也用于一些推送通知的目的。推送通知策略如下：
无论何时创建订单（即客户创建订单），后端都会在相应的通道（队列）中发布一个事件，并且特定的推送通知微服务会使用该事件（json消息）并将推送通知发送给卖家移动设备。
目前我们使用的是安装在ubuntu机器上的redis服务器，没有任何麻烦。但令人头痛的是，当未来某个时间点将产生数以百万计的订单时，我们如何处理这种情况？这意味着，我们需要扩展redis队列，对吗？
我明确的问题（不管上述情况）是：
如何水平扩展redis队列而不是在同一台机器上增加ram？
1条答案
按热度按时间cgh8pdjw1#
无论何时创建订单（即客户创建订单），后端都会在相应的通道（队列）中发布一个事件，并且特定的推送通知微服务会使用该事件（json消息）并将推送通知发送给卖家移动设备。
iiuc您通过redis pub/sub发送一条消息，这是不持久的，这意味着如果唯一的生产商处于上升状态，而其他服务/消费者处于下降状态，那么消费者将错过消息。任何关闭的服务都将丢失所述服务关闭时发送的所有消息。
现在让我们假设，您正在使用redis列表和其他数据结构组合来解决缺少事件的问题。
缩放redis队列有点棘手，因为整个数据都存储在一个列表中，该列表驻留在一台redis机器/主机上。您可以创建自己的分区方案，并按照redis内部的分区方案设计redis密钥当我们在集群中添加一个新的主节点时，创建一致的哈希需要一些努力。
非常简单，您可以基于userid分配负载，例如，如果userid介于0和1000之间，则使用queue\u 0、1000-2000 queue\u 1，依此类推。这是一个手动过程，可以使用一些脚本自动执行。每当向集合中添加新队列时，都必须通知所有使用者，并更新发布者。
基于数字的划分是一个范围分区方案，您也可以使用哈希分区方案，您可以使用范围分区方案或哈希分区方案，每当向队列集中添加新队列时，都必须通知使用者可能的更新。使用者可以为新队列生成一个新的worker，删除队列可能很棘手，因为所有使用者都必须耗尽各自的队列。
您可以考虑使用rqueue