Celery：你什么时候应该选择Redis作为RabbitMQ的消息代理？
我的粗略理解是，如果您需要内存中的键值存储特性，Redis会更好，但是我不确定这与分布任务有什么关系？
这是否意味着如果我们已经将Redis用于其他用途，那么我们应该将其用作消息代理？
共有2个答案
Redis代理在不同队列之间以公平的循环方式向工作人员分配任务。兔子总是先入先出。对我来说，公平的循环赛更可取，我两种都试过了。不过兔子看起来有点稳定。
我最近（2017-2018）都用过，它们在Celery 4中都非常稳定。因此，您的选择可以基于托管设置的详细信息。
- 如果您必须使用Celery版本2或版本3，请使用RabbitMQ。否则...
- 如果您出于任何其他原因使用Redis，请使用Redis
- 如果您在AWS托管，请使用Redis，以便您可以使用托管的Redis即服务
- 如果你讨厌复杂的安装，请使用Redis
- 如果您已经安装了RabbitMQ，请继续使用RabbitMQ
过去，我会推荐RabbitMQ，因为它比Redis更稳定，更容易用Celery进行设置，但我不相信这是真的。
AWS现在有一个相当于RabbitMQ的托管服务，称为Amazon MQ，它可以减少在生产中将其作为服务运行的头痛。如果您对此和芹菜有任何经验，请在下面发表评论。
-
问题内容： 流式XML解析器（例如SAX和StAX）比构建像DOM解析器之类的树结构的解析器更快，内存效率更高。SAX是推送分析器，这意味着它是观察者模式（也称为侦听器模式）的实例。SAX首先出现，然后是StAX- 拉式解析器，这意味着它基本上像迭代器一样工作。 您可以找到在任何地方都偏爱StAX而不是SAX的原因，但是通常可以归结为：“更易于使用”。 在JAXP上的Java教程中，StAX被模糊
-
我是芹菜、Redis和RabbitMQ的新手。 目前，我正在使用RabbitMQ作为消息代理，并且在配置中没有设置任何内容。（使用Django、MySQL） 我想知道是否有可能使用Redis作为后端的结果存储，同时将RabbitMQ用作消息代理。 我知道的只是添加一些设置，
-
问题内容： 我知道他们两个都禁用了Nagle的算法。 我什么时候应该/不应该使用它们中的每一个？ 问题答案： 首先，不是所有人都禁用Nagle的算法。 Nagle的算法用于减少有线中更多的小型网络数据包。该算法是：如果数据小于限制（通常是MSS），请等待直到收到先前发送的数据包的ACK，同时累积用户的数据。然后发送累积的数据。 这将对telnet等应用程序有所帮助。但是，在发送流数据时，等待A
-
问题内容： 在该类中，有两个字符串，和。 有什么不同？我什么时候应该使用另一个？ 问题答案： 如果你的意思是和则： 用于在文件路径列表中分隔各个文件路径。考虑在上的环境变量。您使用a分隔文件路径，因此在上将是;。 是或用于拆分到特定文件的路径。例如在上，或
-
我们应该在什么时候选择抛出一个异常？ 我们可以在try catch中捕获此异常。 在哪种情况下，我们选择使用投掷而不是立即接球？是否与设计模式相关？
-
假设你有一些焊剂和monos 从WebFlux控制器返回一个单声道 在应用程序中，将通量和单声道分别解析为List和Int的合适位置在哪里？您只是阻止（）所有内容吗？有没有办法获得解决所有问题的框架？ 编辑：我想我的主要困惑是，我看到的所有教程中，响应对象内的字段实际上都不是反应性的，所以似乎我需要在从控制器返回对象之前解决所有问题。如果响应对象看起来像这样，我会觉得更有意义