前提:安装并启动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)
Python和
Ruby
也有这样的框架，但因为在实际使用中会不可避免地用到含有同步代码的库，因此没能成长起来，而在
Node.js
之前，JavaScript
的服务器端编程几乎是空白，所以
Node.js
才得以建立起了一个所有
IO
均为异步的代码库。
大部分
Web
应用的瓶颈都在
IO,
即读写磁盘，读写网络，读写数据库。使用怎样的策略等待这段时间，就成了改善性能的关键点。
PHP
的策略：多进程运行，直接原地等待
IO
完成。缺点：多个进程会消耗多份内存，进程间难以共享数据。
C/C++
通常的策略：多线程运行，程序自己维护锁的状态。缺点：开发成本高，容易出错，不易调试。
Python(Tornado):
多个请求在单个进程中轮流执行，遇到
IO
时切换到另一个请求。缺点：对于单个请求而言，依然没有最高效地利用时间。
何谓「最高效地利用时间」？比如现在有两个不相关的数据库查询，在
PHP
中通常会先执行一个，执行完成后再执行第二个(总时间是
a
+
b).
显然这不是最高效的，应该同时执行两个查询，时间是
max(a,
b).
Python
和其他支持多线程的语言的问题就在于，在语言层面，程序员很难告诉虚拟机，应当将两个操作同时执行，即使有办法，也相当麻烦，大多数人懒得去用(也不值得去用)。而因为
Node.js
丧心病狂地强制所有
IO
异步执行，Node.js
的程序员也可以说是轻车熟路，配合一些改善代码可读性库(promise,
async),
可以很轻松地让不相干的操作并行执行。
上面讲了异步
IO
的实现，那么异步
IO
的优势究竟体现在哪里呢。实际上异步
IO
并不能神奇地减轻服务器的压力，该加服务器还是一样要加服务器，只不过异步
IO
会减少单个请求的时间，去掉单个请求中那些无意义的等待时间。所以单位时间内处理的请求没有变化，但每个请求的处理时间却减少了。从这个角度，服务器也节约了一些资源——即维持每个请求的连接消耗的内存。
system（“.ruby”）或者load 'another.rb'具体代码如下：
# 返回ls的输出
s=`ls`
cmd= "ls"
s= `#{cmd}`
# 返回true or false
s= system('ls')
cmd= 'ls'
s= system(cmd)
#返回输出
s= %x[uptime]
#用top进程替换当前ruby进程
exec "top"
cmd = 'top'
exec cmd
