在Ruby中延迟处理作业：多少不会阻止我的路径
我有这个项目仍然使用延迟作业作为处理作业队列。 我最近发现了一个让我质疑几件事的边界案例：我有这个AR（我使用MySQL，顺便说一下）对象，它在更新时向has_many关联的所有元素发送消息。 为了做到这一点，我必须实例化这个关联的所有元素，并在其上调用消息。 这似乎只是足够公平的推迟这个消息的每一个电话。
现在这个协会已经发展了很多，在一个边缘案例中，我有40000个属于这个协会的对象。 现在发送的消息涉及（同步）创建40000个延迟作业。 由于这些发生在更新后的回调中，而不是在提交之后，因此它们（ab）使用相同的连接，而没有利用任何上下文切换。 短版本，我有一个更新语句管道和40000插入同一连接。 由于这个原因，这个更新在生产中耗费了几分钟的时间。
现在，有很多方法可以解决这个问题：将回调更改为提交后，创建1个（同步）延迟作业，这将创建40000个作业（我不想在一个作业中处理40000个AR对象） 40000现在将是明天的120000，这就是内存世界末日）等等等等......
但我真正考虑的是将我的延迟处理队列切换到resque或sidekiq。 他们使用redis，所以编写性能要好得多。 他们使用的不是MySQL，这意味着连接不会彼此阻塞。 我唯一的问题是：40000一次写入redis会花费我多少钱？ 并且：这些选项中的任何一个是否首先将作业存储在内存中，而不是阻止对客户端的响应，并将其存储在redis中？ 所以，我真正的问题是：这种拖延会让我在这样的边缘情况下拖延多久？
事实上，Redis可以比MySQL更快地处理写入。 尝试运行redis-benchmark ，你会看到数字为100k +写入/秒。
这些选项中的任何一个是否首先将作业存储在内存中，而不是阻止对客户端的响应，并将其迟迟存储在redis中？
不，他们是同步做的。
我不想在一份工作中处理40000（AR）对象
也许你应该尝试混合方法：处理每个作业的N个对象块。 批量写入速度应快于单个写入40k。 它的尺寸很好（批量大小将保持不变，不管是40k还是400k）。
链接地址: http://www.djcxy.com/p/65779.html上一篇: Delayed Processing Jobs in Ruby: How much is not blocking my path
下一篇: ruby on rails