iamtomas (iamtomas)

Liquid::Template 渲染数组的小问题

iamtomas — Wed, 16 Mar 2022 11:32:08 +0800

data = { :users => [{:id=>1},{:id=>2}] }
payload = {users: "{% for user in users %} {{ user.id }} {% endfor %}" }

@template = Liquid::Template.parse(payload.to_json)
@payload = @template.render(data.deep_stringify_keys)

JSON.parse(@payload) # => {"users"=>" 1  2 "}

可以看到最后输出是 {"users"=>" 1 2 "} ，如何返回 {"users"=>[1,2]} 这种格式（liquid 语法小白，个人认为需要改动payload格式）

Sidekiq 浅析（二）

iamtomas — Tue, 17 Aug 2021 23:04:20 +0800

前言

继第一篇 Sidekiq 浅析（一），准备展开 Poller 、 Manager 及 Processor 的分析，在版本上源码并没发现太多不同，这篇更像是记录学习的过程。Sidekiq 的核心部分，Martin 大佬讲得会更清楚易懂，感兴趣得可跳转至 Sidekiq 任务调度流程分析

为了方便理解，挂上时序图

继续分析 `Sidekiq::Launcher#run`

# lib/sidekiq/launcher.rb


def run
  @thread = safe_thread("heartbeat", &method(:start_heartbeat)) # 监测 Sidekiq 心跳
  @poller.start
  @manager.start
end

第一步，执行 start_heartbeat 方法，专门创建了线程用于监测 Sidekiq 心跳，截取了部分代码，感兴趣得可以来看看~

# lib/sidekiq/launcher.rb


def start_heartbeat
  loop do
    heartbeat
    sleep 5
  end
  Sidekiq.logger.info("Heartbeat stopping...")
end

习惯性放上有意思的代码


def heartbeat
  $0 = PROCTITLES.map { |proc| proc.call(self, to_data) }.compact.join(" ")

  ❤
end

def ❤
# ..
end

第二步，执行 Sidekiq::Scheduled::Poller#start , Poller 类充当的更像是轮询器，定时得从 Redis 中检查是否有重复 (retry) 或延时 (scheduled) 的任务

# lib/sidekiq/scheduled.rb


def start
  @thread ||= safe_thread("scheduler") {
    initial_wait # 避免同时 IO 操作

    until @done
      enqueue
      wait
    end
    Sidekiq.logger.info("Scheduler exiting...")
  }
end

def initial_wait
  total = 0
  total += INITIAL_WAIT unless Sidekiq.options[:poll_interval_average]
  total += (5 * rand)

  @sleeper.pop(total)
rescue Timeout::Error
end

def enqueue
  @enq.enqueue_jobs
  # ..
end

class Enq
  def enqueue_jobs(now = Time.now.to_f.to_s, sorted_sets = SETS)
    Sidekiq.redis do |conn|
      sorted_sets.each do |sorted_set
        until (jobs = conn.zrangebyscore(sorted_set, "-inf", now, limit: [0, 100])).empty?
          jobs.each do |job|
            if conn.zrem(sorted_set, job) # 集合中移除
              Sidekiq::Client.push(Sidekiq.load_json(job)) # 用于将作业推送到 Redis
              Sidekiq.logger.debug { "enqueued #{sorted_set}: #{job}" }
            end
          end
        end
      end
    end
  end
end

主要分为两步：初始化等待、检查重试以及定时任务队列并按照执行时间 score 排序推送到 Redis

初始化等待：值得注意的细节之一，通过加入随机时间错开 Redis IO 操作

检查并推入 redis：采取的策略，遍历获取前 100 个任务（retry 重试跟 schedule 延时的集合）推入到相关的队列等待拉取

第三步，执行 Sidekiq::Manager#start ，Manager 充当的是负责按照 concurrency 数量配置 worker，并加以管理的角色

# lib/sidekiq/manager.rb

require "sidekiq/processor"

def initialize(options = {})
  logger.debug { options.inspect }
  @options = options
  @count = options[:concurrency] || 10
  raise ArgumentError, "Concurrency of #{@count} is not supported" if @count < 1

  @done = false
  @workers = Set.new
  @count.times do
    @workers << Processor.new(self, options) 
  end
  @plock = Mutex.new
end

def start
  @workers.each do |x|
    x.start
  end
end

生成了多个 Sidekiq::Processor 实例，并执行了 #run ，Processor

# lib/sidekiq/processor.rb


def run
  process_one until @done

  # ..
end

def process_one
  @job = fetch # 获取任务
  process(@job) if @job # 处理任务
  @job = nil
end

#fetch 的作用是获取任务，再将其作为参数执行 #process 完成对任务的处理，否则就重新获取新的任务

先来看看 #fetch

 # lib/sidekiq/processor.rb


 def get_one
  work = @strategy.retrieve_work
  # ..

  work

  #..
end

def fetch
  j = get_one
  if j && @done
    j.requeue
    nil
  else
    j
  end
end

可以看出先通过 @strategy.retrieve_work 获取任务，若没获取到或 worker 停止了，则将任务重新放到队列

到这，因为调用层特别多，我拾取了几个我感兴趣的点，其他的感兴趣可以继续阅读源码~

在处理 Sidekiq::Processor#process_one 的 process(@job) 时，跟踪源码到最后是 #perform ，也就是我们最后定义任务时传进来的代码块
针对错误和异常，最好都阅读阅读 https://github.com/mperham/sidekiq/wiki/Error-Handling ，看完有所心得，比如在 通过 Gems（比如 Sentry）附加到 Sidekiq 的全局错误处理程序的方式，以便在 Sidekiq 内部出现错误时随时通知他们
发现了两处不同，其一是重试机制（咳咳，阅读到这，发觉对 server_middleware 的理解有误，目前暂未真正理解它真正的作用，对前篇已做修正！）

# v4.2.3
# https://github.com/mperham/sidekiq/blob/5ebd857e3020d55f5c701037c2d7bedf9a18e897/lib/sidekiq/processor.rb

def process(work)
   # ..

   stats(worker, job, queue) do
     Sidekiq.server_middleware.invoke(worker, job, queue) do # 在 `server_middleware` 进行了重试处理，具体的分析可以查看 Martin 大佬的
       # ..
       execute_job(worker, cloned(job['args'.freeze]))
     end
   end

   # ..
 end


 # v6.0.2
 # https://github.com/mperham/sidekiq/blob/13e2b564c8ab9275de910a5b60cf12412062d4e5/lib/sidekiq/processor.rb

 def process(work)
   # ..

   dispatch(job_hash, queue, jobstr) do |worker| # 重试处理放在了 `#dispatch` 中
     Sidekiq.server_middleware.invoke(worker, job_hash, queue) do
       execute_job(worker, job_hash["args"])
     end
   end

   # ..
 end

 def dispatch(job_hash, queue, jobstr)
   # since middleware can mutate the job hash
   # we need to clone it to report the original
   # job structure to the Web UI
   # or to push back to redis when retrying.
   # To avoid costly and, most of the time, useless cloning here,
   # we pass original String of JSON to respected methods
   # to re-parse it there if we need access to the original, untouched job

   @job_logger.prepare(job_hash) do
     @retrier.global(jobstr, queue) do
       @job_logger.call(job_hash, queue) do
         stats(jobstr, queue) do
           # Rails 5 requires a Reloader to wrap code execution.  In order to
           # constantize the worker and instantiate an instance, we have to call
           # the Reloader.  It handles code loading, db connection management, etc.
           # Effectively this block denotes a "unit of work" to Rails.
           @reloader.call do
             klass = constantize(job_hash["class"])
             worker = klass.new
             worker.jid = job_hash["jid"]
             @retrier.local(worker, jobstr, queue) do
               yield worker
             end
           end
         end
       end
     end
   end
 end

可以看到官方解释：因为中间件可以修改 Job Hash，所以采用 clone 的方式将 Job 上报给 Web UI 或者重试时推回 Redis

所以到这里，假设 server_middleware 的作用如 Martin 理解的那出（通过中间件，及时捕捉失败的任务，针对允许再次重试的任务，按失败次数计算新的重试时间），那么新版本其实就是针对这个 bug（中间件可以修改 Job Hash），做了替换的方式

其二是下次重试时间间隔的计算调整

# v4.2.3
# https://github.com/mperham/sidekiq/blob/5ebd857e3020d55f5c701037c2d7bedf9a18e897/lib/sidekiq/middleware/server/retry_jobs.rb#L177-L179

def seconds_to_delay(count)
  (count ** 4) + 15 + (rand(30)*(count+1))
end


# v6.0.2
# https://github.com/mperham/sidekiq/blob/13e2b564c8ab9275de910a5b60cf12412062d4e5/lib/sidekiq/job_retry.rb#L225

def delay_for(worker, count, exception)
  jitter = rand(10) * (count + 1)
  if worker&.sidekiq_retry_in_block
    custom_retry_in = retry_in(worker, count, exception).to_i
    return custom_retry_in + jitter if custom_retry_in > 0
  end
  (count**4) + 15 + jitter
end

最后想总结的是一个值得去实践摸索的尝试，先拿出 Martin 的实践：

缺省情况下，一个首次失败任务下次重回队列（不是执行）的理论最大时间间隔大概是 67.5 秒！（固定的 15 秒 + 最大随机时间 30 秒 + 最大理论检查时间 22.5 秒）。所以，如果你的任务很重要，又需要尽快重试，就需要对几部分时间的相关配置参数进行调优了哦！在我自己的工作中，我针对某个队列任务设置的 sidekiq_retry_in 公式为线性时间，即 1s、2s、...50s，然后在重试检查那里设置了 :poll_interval_average 为 5 秒，新的下次执行时间理论最大时间间隔就是 8.5 秒！不过这些配置需要慎重调整，综合考虑业务以及业务量，既要尽可能保证任务尽早处理完，又得保证 Redis 没被 IO 压垮。

注：最大时间间隔最好再重新计算！

在对时间的相关配置参数调优的过程，最好结合 Sentry 等（Sidekiq 内部出现错误时随时通知）错误服务，避免出现诡异报错导致任务丢失~

Sidekiq 浅析（一）

iamtomas — Mon, 16 Aug 2021 17:02:59 +0800

本着提高阅读源码能力和欣赏大佬的代码，打算在此分享处女篇 Sidekiq 浅析（一） ，希望大佬能指出不足之处

前言

参考的 Martin 大佬的文章 Sidekiq 的源码分析，其对应版本是 4.2.3，此篇笔记主要是与分析当前版本 6.0.2 并比较不同之处及疑问

通过时序图理清关系的习惯，get ✅ （后续分析完附上自己理解的时序图）

不同之处及疑问

1、启动 bin/sidekiq ，另外执行了 #integrate_with_systemd

在该方法中引入了 sidekiq/sd_notify ，通过文档注释，我们可以暂时了解到该模块主要是用于通知 systemd 状态变化，其中进程间的通信是通过 socket 传递，感兴趣的同学可以阅读下源码 (纯 ruby 实现)

# bin/sidekiq


begin
  cli = Sidekiq::CLI.instance
  cli.parse # 解析 sidekiq 的配置参数，其中包括 :concurrency、:queue 等、初始化日志及校验参数

  integrate_with_systemd

  cli.run # 继续下一步
rescue => e

# ..

# integrate_with_systemd

Sidekiq.configure_server do |config|
  Sidekiq.logger.info "Enabling systemd notification integration"
  require "sidekiq/sd_notify"
  config.on(:startup) do
    Sidekiq::SdNotify.ready
  end
  config.on(:shutdown) do
    Sidekiq::SdNotify.stopping
  end
  Sidekiq.start_watchdog if Sidekiq::SdNotify.watchdog?
end

岔个题外话，感觉 Sidekiq 的作者是个挺有性格的人，包括他的代码 0.0，大家也可以分享下平时写了啥骚代码


# lib/sidekiq/cli.rb


def self.banner
  %{
  #{w}         m,
  #{w}         `$b
  #{w}    .ss,  $$:         .,d$
  #{w}    `$$P,d$P'    .,md$P"'
  #{w}     ,$$$$$b#{b}/#{w}md$$$P^'
  #{w}   .d$$$$$$#{b}/#{w}$$$P'
  #{w}   $$^' `"#{b}/#{w}$$$'       #{r}____  _     _      _    _
  #{w}   $:     ,$$:      #{r} / ___|(_) __| | ___| | _(_) __ _
  #{w}   `b     :$$       #{r} \\___ \\| |/ _` |/ _ \\ |/ / |/ _` |
  #{w}          $$:        #{r} ___) | | (_| |  __/   <| | (_| |
  #{w}          $$         #{r}|____/|_|\\__,_|\\___|_|\\_\\_|\\__, |
  #{w}        .d$$          #{r}                             |_|
  #{reset}}
end

alias_method :☠, :exit

# ..

2、创建 pipe 并启动信号的捕获

疑问一：Sidekiq 的信号量机制是怎么发送、捕获，到底是通过 pipe 还是 socket（前边 systemd 状态变化是通过 socket）来实现进程的通信（原谅我操作系统菜 = =），这一过程有没大佬能简单明了得描述下？

疑问二：Redis 线程池数量 < concurrency + 2 性能会显著降低，那么 concurrency 在各个环境下应该设置为多少？

疑问三：在哪、又是如何控制进程的？


# lib/sidekiq/cli.rb


def run

# ..

# 疑问一！！
self_read, self_write = IO.pipe
sigs = %w[INT TERM TTIN TSTP]
# USR1 and USR2 don't work on the JVM
sigs << "USR2" if Sidekiq.pro? && !jruby?
sigs.each do |sig|
  trap sig do
    self_write.puts(sig)
  end
rescue ArgumentError
  puts "Signal #{sig} not supported"
end

# ..

# Redis 版本检查，需要 v4.0.0 或更高版本

# 内存策略 检查是否为 “noeviction”，若不是，则 Redis 可能会清除 Sidekiq 的数据，具体可以查看：https://github.com/mperham/sidekiq/wiki/Using-Redis#memory

# 疑问二！！
cursize = Sidekiq.redis_pool.size
needed = Sidekiq.options[:concurrency] + 2
raise "Your pool of #{cursize} Redis connections is too small, please increase the size to at least #{needed}" if cursize < needed

# 用于及时捕捉失败的任务，针对允许再次重试的任务，按失败次数计算新的重试时间
Sidekiq.server_middleware

# 疑问三！！
# 在这之前，进程仅使用主线程进行初始化
# 在这之后，将有多个进程执行
fire_event(:startup, reverse: false, reraise: true)

launch(self_read) # 继续下一步

end

def launch(self_read)
  # ..

  begin
    launcher.run 

    # 进程接收到的信号处理以及退出处理
    while (readable_io = IO.select([self_read])) 
      signal = readable_io.first[0].gets.strip
      handle_signal(signalsignal)
    end
  rescue Interrupt
    logger.info "Shutting down"
    launcher.stop
    logger.info "Bye!"
    # ..
    exit(0)
  end
end

又到了骚代码环节


def self.❨╯°□°❩╯︵┻━┻
  puts "Calm down, yo."
end