前提:安装并启动redis,不同机器对应的安装方式可自行百度,mac下安装redis可通过
配置sidekiq所依赖的redis位置,必须同时定义sidekiq的server和client
config/initializers/sidekiq.rb
如果要使用 UNIX socket，URL 应该类似于 unix://#{Rails.root}/tmp/sockets/redis.sock
配置config/sidekiq.yml文件,一般只有在需要配置高级选项的时候才需要配置这个文件(如果不使用这个名字,可以使用-c指定 sidekiq -c config/name.yml)
文件中会生成如下内容
将耗时的程序写到perform里
注意:perform是一个实例方法,但是在调用的时候是用类调用
adapter默认使用的adapter是Active Job Inline需要指定为sidekiq才支持异步(如果是使用worker这一步可以省略)
另外由于sidekiq的进程并不是非常稳定,可定会自己断掉,所以可以配合监控工具Monit(可以监控任何进程,只需要设定启动和重开的方式即可)使用,详情还请自行百度
gemfile添加sinatra
执行
tips:
之前直接添加 gem 'sinatra' 运行时导致报错,google之后判断可能是由于sinatra gem的版本问题,导致运行时报错,修正后的sinatra gem 的为 gem 'sinatra', '2.0.0.beta2',require: false
routes.rb添加
打开Sidekiq web界面，检查该作业是否被处理,浏览器中输入
(以下纯属翻译)
注:本文讲的是Sidekiq结合ActiveJob使用的方式,也可以单独使用Sidekiq Worker
文章中注释掉的是单独使用Sidekiq Worker创建任务跟使用ActiveJob的不同部分
参考
https://github.com/mperham/sidekiq/wiki/Getting-Started
(worker)
https://ihower.tw/rails/background-process.html
(active_job)
看过这个文章 是不是这个
易于学习，但不可能完全掌握
Node很容易学习。特别是如果你已经懂得一些JavaScript知识的话。用Google搜索一些初学
者教程，摆弄一下Express，然后你就可以开始你的征程了。然后你会意识到你需要选择一个数据库。没问题，我们可以搜索NPM。哦，那里已经有不少优
雅的SQL软件包了。之后你会发现所有的ORM工具烂极了，而基本的驱动程序是你最好的选择。现在，你被困在了实施冗余模型和验证逻辑中。在那不久，你开
始编写更复杂的查询，并开始迷失在callbacks中。你终于冲出了callbacks地狱，并开始使用promises库。现在，你差不多可以
“promise化”所有事情，并且美滋滋地小酌一杯。
所有这些是想说明，Node生态系统感觉像总是在不断前进中。却不是用一种很好的
途径。“胜过”旧工具的新工具似乎每天都在问世。总会有一个新的闪亮的东西来替代另一个。你会惊讶于这种情况的发生有多么容易，你和社区看上去都在鼓励
它。你使用Grunt！？每个人都使用Gulp！？不要等待，现在就使用本地NPM脚本！
包括琐碎代码——即不超过10行代码——的软件包每天都数以千计地从NPM下载。说真的！？你需要用于数组类型检查的依赖关系？并且这些软件包被一些大型工具，例如React和Babel所用。
你永远不可能用一种极快的速度掌握一些东西，更不要说潜在的依赖关系的不稳定了。
处理错误时，祝你好运
以
前使用其他语言如Python，Ruby或PHP的你，还在期望抛出和捕获错误，或甚至是从函数返回错误作为错误处理的简单的方法吗？Node可不这样。
相反，你需要四处传递错误在你的callbacks（或promises）中——对，不抛出异常。直到你了解的不仅仅是callbacks，并且试图遵循
堆栈跟踪，这才不起效用。更不必说，如果你忘了在错误上返回callbacks，那么它就会继续运行并触发另一错误设置，在你返回最初的错误设置之后。你
需要让你的客户多加一倍的钱以弥补用来调试的时间。
即使你设法想出了针对自己错误的坚实标准，你也不能确认（而不读取源）你安装的许多NPM软件包遵循相同的模式。
这些问题导致了“catchall”异常处理程序的使用，这样就会记录问题。请记住，Node是单线程的。如果有什么东西锁定了该进程，那么一切就会轰然倒下。但是使用Forever，Upstar和Monit很酷，不是吗？
callbacks，promises还是generators！？
为
了处理callbacks地狱，错误处理和通常难以阅读的逻辑，越来越多的开发人员已经开始使用Promises。这基本上是编写看上去像同步码但没有疯
狂的callbacks逻辑的一种方式。不幸的是，没有任何“标准”（一切都像在Javascript中其他东西）用来实施或使用Promises。
现在最明显的库是Bluebird。它相当不错，速度快，又能刚好完成工作任务。不过，我发现不得不封装需求到Promise.promisifyAll（）特别有黑客范。
在大多数情况下，我会使用优秀的async库，以避免callbacks。这感觉更自然。
最后，我对于Node的经验是，Generators变得越来越流行。我并没有深入了解Generators，因此无法给出太多的反馈。非常期待听到大家关于Generators的经验。
糟糕的标准
最后一件令我沮丧的事情是缺乏标准。每个人对上述个要点该如何处理似乎都有自己的看法。Callbacks？Promises？错误处理？构建脚本？无穷无尽。
那也只是抓住了表明的东西而已。似乎彼此之间也不同意如何编写标准的JavaScript代码。不妨快速Google检索“JavaScript编码标准”，你就会明白我的意思。
我意识到很多语言都没有严格的结构，但它们通常却都具有由语言的实际维护人员创建的标准指南。
我认为只有一个确实有助于JavaScript，它是由Mozilla编写的。
关于Node的最后一些想法
我花了一年时间试图使用Javascript以及更特别的Node为我们的团队工作。但是不幸的是，在此期间，我们的时间更多的是花在了攻读文档，提出标准，讨论库还有调试琐碎的代码上。
那么我会推荐它用于大规模的产品吗？绝对不会。其他人有没有试着这样做呢？当然有过。我也尝试过。
但是，我建议JavaScript用于前端开发，例如Angular和React（或者你也可以有其他选择）。
此
外，我认为Node适合简单的后端服务器，并且服务器主要用于webSockets或API
ray。这使用Express很容易快速完成，并且我们正是用在了我们的Quoterobot
PDF处理服务器上。这是一个单独的文件，包含186行代码，其中还包括了空格和注释。Node用得真心顺手。
回归Python
你可能会想，现在的我在干什么呢？好吧，我依然在使用Python编写web产品和API的主要部分。主要在Flask或Django中，使用Postgres或MongoDB。
它经受住了时间的考验，有一些伟大的标准和库，它易于调试并且表现良好。当然它也有它的缺点。但世上没有完美的东西。出于某种原因，Node抓住了我的眼球，让我深陷其中。我不后悔曾拥抱过它，但我确实觉得我本不应该花费这么多的时间在它上面。
参考了 《Rails 程序部署之道》这个书的许多内容，直接使用脚本安装，并改进了里面的一些内容，上手很简单。安装过程也贴在了wiki上。
包含Nginx+Passenger nginx+unicorn Mysql Postgres MongoDB
Redis Memcached Postfix fail2ban ufw monit upstart 等安装和部署过程
