我有一个 Rails 应用程序，它实际上是一个流行的 IOS 应用程序的后端，该应用程序拥有 20 万用户 的用户群，需要不时通知他们。
每日 40-50k 用户 将使用推送通知收到通知。这些推送通知将是实时和计划的。例如:如果新用户注册，他将在几秒钟内收到通知。例如:预定通知将在每天晚上 10 点运行，用户数量有限，范围为 10k-30k，有时甚至高达 100k。
我还将进行业务报告以生成满足特定条件的用户列表，它需要触发可能需要 1-2 分钟时间的 mysql 查询。
我关心的领域是我是否应该有一个单独的应用程序和单独的镜像数据库来向这些用户发送推送通知，这样我的 IOS 用户在推送通知被触发或业务时使用这个应用程序时不会感到滞后报告查询被触发。
或者我应该使用后台作业，例如 Rails Active 作业、Sidekiq 或 Sucker Punch 来执行推送通知和触发业务报告查询。
rails 中的后台作业是否如此强大，以至于它可以管理这种情况并且不会让 App 用户感到体验滞后。
我的应用程序堆栈是:
Rails: 4.1.6
Ruby: 2.2
DB: Mysql
PaaS: AWS Elastic Beans
IOS Push gem: Houston
最佳答案
在我看来，有几个因素会影响我的决定。
1。您的服务是否需要保持许多持久连接？</h2>
如果您的回答是肯定的，那么请使用另一种具有更好异步 IO 的语言(如 Node.js)来实现您的推送服务。
如果您的答案是否定的，这意味着您只向第三方服务(如 APNS)发送请求，那么请考虑下一个因素。
2。您必须在推送服务中重用您的领域模型吗？
如果您的回答是肯定的，那么坚持使用 Active Job + Sidekiq。
如果你的答案是否定的，这意味着你只使用了一些表(如users)的一些字段(如id，name) ，然后考虑下一个因素。
3。您的服务器内存资源是否有限？
一个 Rails 进程通常会消耗数百 MB 的内存，而 Sidekiq 需要一个单独的 Rails 进程，该进程不能被预 fork (这意味着它不与您的 Rails 应用程序共享内存)。
因此，如果您的答案是肯定的，那么请考虑创建一个单独的轻量级推送服务。
镜像数据库，如果我在push前需要做大量的查询，我肯定会使用镜像数据库。
关于ruby-on-rails - 我应该制作一个单独的应用程序来向 RoR 应用程序中的 40-50k 用户发送推送通知还是使用后台作业，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37762857/