问题
I have two separate applications running on heroku and pointing to same database, first one responsible for user interfaceand second one for admin interface, I am using sidekiq with redis for background job processing, I have added one worker and I am able to share 'redis-server' by setting environment variable pointing to same Redis providing Addon, Now i wish to share worker too, because adding the extra worker will cost double.
Please suggest, whether this is even possible or not?
回答1:
If both apps are using the same Redis URL and same namespace, you can spin up one worker with that same Redis config and it will be shared by both.
Note that your Sidekiq process will boot one app or the other. The code for your Workers must be in that app. The other app won't be able to reference the code but can push jobs using:
Sidekiq::Client.push('class' => 'SomeWorker', 'args' => [1,2,3])
Note that 'class' is a String so SomeWorker can actually be defined in the other app.
回答2:
How about using 3 different heroku apps?
- User Interface App (ui repository)
- web: bundle exec rails server
- Admin Interface App (admin repository)
- web: bundle exec rails server
- Worker (admin repository)
- worker: bundle exec sidekiq (documentation)
Even if 2 and 3 use the same code base, you can have 2 different heroku apps. One that starts the admin, one that actually starts sidekiq. Would that solve your problem?
回答3:
Mike's answer is still a safe bet, though having to include all relevant sidekiq options inline everywhere you enqueue this class is a bit gross.
Here's a blog post that goes into more detail, and offers a second approach:
http://coderascal.com/ruby/using-sidekiq-across-different-applications/
Basically the alternative is to have a "proxy" class on the enqueueing application that controls the sidekiq behavior (queue, retries, etc.). Then there would be a matching class name on the receiving/de-queueing application.
The author of the blog post overrides some standard Sidekiq logic to redirect from the proxy class to the non-proxy class on the receiving side. Overriding the gem's behavior is a bit risky, and it enforces an extra convention on your class naming. But you may be able to get away with not doing that part.
来源：https://stackoverflow.com/questions/25907596/how-to-share-worker-among-two-different-applications-on-heroku