我即将发布一个具有常见网络功能（消息、墙等）的 Rails 应用程序。我想使用某种后台处理（很可能是 Bj）从请求/响应周期中卸载任务。
当用户通过电子邮件邀请朋友加入并获得电子邮件通知时，就会发生这种情况。
我不确定我是否应该使用模型将这些邀请和通知放入我的数据库中，然后每 x 分钟使用一个工作进程处理它，或者我是否应该使用 Amazon SQS，将消息和邀请存储在那里并让我的工作人员从 Amazon SQS 检索它进行处理（发送邀请/通知）。
亚马逊的方法会从我的数据库中卸载，但我想从那里检索消息会更慢。
你怎么看？
您的标题表明您有 Rails 性能问题，但您确定吗？从您的问题的其余部分来看，您似乎正在尝试预测未来可能出现的性能问题。明智地处理性能问题的唯一方法是让您的应用程序投入使用并对其进行分析。这样做将为您提供有关实际性能问题的经验数据。
鉴于 Amazon SQS 不是免费的，而且使用它几乎肯定会增加应用程序的复杂性，如果数据库负载成为问题，我会迁移到它。不要试图在问题出现之前对其进行第二次猜测，因为您会发现当您的应用程序上线时您可能会面临不同的问题，其中一些您可能没有考虑过。
要点是您已经决定使用后台处理，这是正确的决定，因为任何类型的非即时处理都不属于 Rails 的请求/响应周期，因为它会阻塞 Rails过程。如果需要，您以后可以随时使用 Amazon 进行扩展。
您的应用程序是否已经托管在 Amazon EC2 上？我可能不会为了使用 SQS 将现有应用程序迁移到 AWS，但如果您已经在使用 Amazon 的基础设施，那么 SQS 是一个不错的选择。您当然可以设置自己的消息传递系统（例如 RabbitMQ），但是通过使用 SQS，您不必担心这一点。
有很多选项可以向 Rails 应用程序添加后台处理，例如延迟作业或背景作业，但我个人最喜欢的是Workling。它为您提供了一个很好的抽象层，允许您插入不同的后台运行器，而无需更改作业的实际实现。
我维护一个添加 SQS 客户端的 Workling 分支。有一些缺点（请阅读评论或我的博客文章了解更多详细信息），但总体而言，它在我上次创业时对我们来说效果很好。
我还将 SQS 用于一个单独的 Ruby（非 Rails）项目，并且通常发现它足够可靠且足够快。就像 James 上面指出的那样，您一次最多可以读取 10 条消息，因此您肯定会想要这样做（我的 Workling SQS 客户端会执行此操作并在本地缓冲消息）。
我同意 John Topley 的观点，即如果您不需要，您不想让您的应用程序过于复杂。话虽如此，有时尽早做出这种决定是好的，您是否从一开始就预计高负载？您是将其推广到现有的用户群，还是可能会或可能不会起飞的公共网站？
如果您知道从一开始就需要处理大量流量，那么这可能是一个很好的步骤。如果您不想花钱使用 SQS，请查看一些免费的队列解决方案，例如 RabbitMQ。
我目前每月通过 SQS 推送几百万条消息，而且效果很好。确保您计划它不时下降或变慢，因此您需要在一些重试设施和指数退避中工作。一件好事是您一次可以获得 10 条消息，这可以加快处理队列的速度，您可以使用一个请求来获取 10 条消息并逐个处理它们。
Amazon SQS 是一项很好的服务，除非以下事项变得重要：
如果其中任何一项很重要，您需要查看真正的企业 MQ 服务，例如 StormMQ、RabbitMQ 甚至 onlinemq.com。
我发现这个博客系列很有趣，因为它将 Amazon SQS 与 StormMQ 进行了比较，没有任何回击：http: //blog.stormmq.com/2011/01/06/apples-and-oranges-performance/
如果您在迁移到 EC2 时遇到问题，您可以使用其他服务，例如 onlinemq.com。