当前位置: 首页 > 面试题库 >

有关Python / Django和消息队列的建议

商畅
2023-03-14
问题内容

我在Django中有一个应用程序,需要在各种用例中向用户发送大量电子邮件。由于明显的原因,我不想在应用程序中同步处理此问题。

有没有人对与Python很好集成的消息队列服务器有任何建议,或者它们已经在Django项目中使用过?我其余的堆栈是Apache,mod_python,MySQL。


问题答案:

到目前为止,我还没有找到“好”的解决方案。我对软实时性有一些更严格的要求(从贴有标签的纸板箱中拍摄照片),因此其中一种方法可能对你来说足够快。我认为电子邮件可以等待几分钟。

  • 由cron作业处理的数据库中的“待办事项列表”。
  • 数据库中的“待办事项列表”由守护程序轮询永久处理的蜂。
  • 使用自定义守护程序,该守护程序通过UDP数据包由网络服务器通知(今天在生产中)。基本上是我自己的带有IP堆栈的Quing系统,用于处理队列。
  • 使用ActiveMQ作为消息代理 -由于稳定性问题,此方法无法解决。对我来说,Java守护程序通常也有些丰满
  • 在CouchDB中使用更新触发器。不错,但更新触发器并不意味着要进行大量图像处理,因此不适合我的问题。
    到目前为止,我还没有尝试过RabbitMQ和XMPP / ejabebrd来解决问题,但是它们在我接下来要尝试的列表中。RabbitMQ在2008年获得了不错的Python连接,并且有大量的XMPP库。

但也许你所需要的只是在本地计算机上正确配置的邮件服务器。这可能使你可以将邮件同步转储到本地邮件服务器中,从而使整个软件堆栈更加简单。



 类似资料:
  • 为什么已经拥有了共享内存时需要消息队列呢? 这将是多种原因,让我们将其分解为多个点来简化 - 据了解,一旦消息被一个进程接收到,它将不再可用于任何其他进程。 而在共享内存中,数据可供多个进程访问。 如果想使用小信息格式进行通信。 当多个进程同时进行通信时,共享内存数据需要同步保护。 使用共享内存的写入和读取频率很高,那么实现功能将会非常复杂。 在这种情况下不值得使用。 如果所有的进程不需要访问共享

  • 一、消息模型 点对点 发布/订阅 二、使用场景 异步处理 流量削锋 应用解耦 三、可靠性 发送端的可靠性 接收端的可靠性 参考资料 一、消息模型 点对点 消息生产者向消息队列中发送了一个消息之后,只能被一个消费者消费一次。 发布/订阅 消息生产者向频道发送一个消息之后,多个消费者可以从该频道订阅到这条消息并消费。 发布与订阅模式和观察者模式有以下不同: 观察者模式中,观察者和主题都知道对方的存在;

  • 一个线程会从消息队列中收取消息,另一个线程会定时给消息队列发送普通消息和紧急消息 一个线程会从消息队列中收取消息,另一个线程会定时给消息队列发送普通消息和紧急消息 源码/* * Copyright (c) 2006-2018, RT-Thread Development Team * * SPDX-License-Identifier: Apache-2.0 * * Change Logs: *

  • 消息队列接口 结构体 struct   rt_messagequeue   消息队列控制块 更多...   类型定义 typedef struct rt_messagequeue *  rt_mq_t   消息队列类型指针定义   函数 rt_err_t  rt_mq_init (rt_mq_t mq, const char *name, void *msgpool, rt_size_t msg_

  • rabbitmq 使用 定义handler实体 public class UserEvent : EventHandler { public string Name { get; set; } public string Job { get; set; } } 队列定义 [QueueConsumer(nameof(HelloEventHandler), QueueCon

  • 问题内容: 我的总体问题是: 使用Redis for PubSub,当发布者将消息推送到频道中的速度比订阅者能够阅读它们的速度快时,消息会如何处理? 例如,假设我有: 一个简单的发布者以2 msg / sec的速度发布消息。 一个简单的订户以1 msg / sec的速率读取消息。 我天真的假设是订户只会看到发布到Redis上的消息的50%。为了验证这一理论,我编写了两个脚本: pub.py 子py