注意 update 回调有坑

我 monkey_patch 了一下 as_index_json, 省得重复写两遍。

class Elasticsearch::Model::Indexing::Mappings
  def to_hash
    { @type.to_sym => @options.merge( properties: @mapping.as_json(except: :as) ) }
  end
end

module Elasticsearch::Model::Serializing::InstanceMethods

  def as_indexed_json(options={})
    build_indexed_json(
      target.class.mappings.instance_variable_get(:@mapping),
      target,
      {id: target.id.to_s}
    ).as_json(options.merge root: false)
  end

private

  def build_indexed_json(mappings, model, json)
    return json unless model.respond_to? :[]

    if model.kind_of? Array
      build_array_json(mappings, model, json)
    else
      build_hash_json(mappings, model, json)
    end

    json
  end

  def build_array_json(mappings, model, json)
    return json unless model.respond_to?(:[]) && json.kind_of?(Array)

    model.each do |elem|
      elem_json = if elem.kind_of? Array then [] else {} end
      json << elem_json
      build_indexed_json(mappings, elem, elem_json)
    end
  end

  def build_hash_json(mappings, model, json)
    return json unless model.respond_to?(:[]) && json.kind_of?(Hash)

    mappings.each_pair do |field, option|

      # Custom transformer
      if option.has_key?(:as) && option[:as].kind_of?(Proc)
        json[field] = target.instance_exec(get_field(model, field), &option[:as])

      # A nested field
      elsif option.has_key?(:properties)
        json[field] = if get_field(model, field).kind_of? Array then [] else {} end
        build_indexed_json(option[:properties], get_field(model, field), json[field])

      # Normal case
      else
        json[field] = get_field(model, field)
      end
    end
  end

  def get_field(model, field_name)
    model.try(:[], field_name) || model.try(field_name)
  end
end

666

md5 这种应该叫摘要不能叫加密吧

liker liked article 必须关联上

测试环境数据库没有 id 为 1 的 liker 和 liked_article

滋呲

诶为什么是自由枪骑兵？ 为什么不是自由枪兵？

但是手机的话用气来不方便，不能直接长按呼出扫码

Casterly Rock

#30 楼 @menghuanwd 不如你想一下？估算不是猜测，麻烦不要来抬杠。前提已经说了单个任务最多耗时 t，麻烦读一下。

#28 楼 @menghuanwd 按最大的估算

#26 楼 @darkbaby123 说的有道理，我这里给出的只是一个很粗糙的思路。对于具体的场景可以考虑的更精细。这里的本质应该是发现只需要猜测单一前置任务的执行时间，而不是所有前置任务的执行时间。

• 队列拥挤的情况应该不存在。
• Sidekiq 挂掉重启不会影响。

这个思路有趣！

#23 楼 @angelfan 具体情况具体分析。可以设置 timeout，对于出错的任务进行记录。像我遇到的上传图片的场景，只要大部分的图片上传成功，就可以执行后续任务。对于出错的图片，可以根据错误记录下次执行。

#20 楼 @wpzero 对于发生错误的情况，需要保证 A 任务不重试，而是记录错误。sidekiq 使用 lpush 插入任务，brpop 弹出任务，所以一个队列中的任务是相对顺序执行的。当任务数远大于并发数是可以看做是顺序执行。 https://github.com/mperham/sidekiq/blob/master/lib/sidekiq/client.rb#L199

#19 楼 @gihnius 😂

#15 楼 @gihnius 我不明白为什么讨论技术问题你给人一种高高在上的感觉。好像钦点的你就是对的一样。估计你是个老板吧。而且你几乎没有正面回答过我的问题。

#14 楼 @wpzero 就是并发数远小于任务总数。sidekiq 是利用 redis 来做队列的。考虑并发数为 2，顺序插入 a1, a2, a3, b 这四个任务。第一轮拉出 a1, a2，第二轮 拉出 a3, b。b 任务只需要等待 a3 一个任务完成后执行即可。

#12 楼 @gihnius 你的这个方案适合 n 的数量不远大于 q，而且整体 n 个任务完成耗时很短，不会出现进程被杀或服务器故障的情况。假如 n 个任务在数小时后才能全部完成，中间拔一次 sidekiq 机器的电源，就无法恢复了。

#12 楼 @gihnius 请加上启动 n 个 A 任务 和 一个 B 任务的部分。主楼方案在任务中只需要添加一行代码。

# at beginning of task B

sleep 1.minute # depends on time of task A

#8 楼 @wpzero 不要感觉，说说具体为什么不靠谱。

#9 楼 @gihnius 我说的是相对复杂，不是绝对复杂。你能说说 7 楼和你的方法相比复杂在哪里吗？主楼的方法相比你的方法确实更简单。

#4 楼 @gihnius sidekiq 有 api 可以查队列中的任务是否已完成。

#4 楼 @gihnius 但是相比来说确实是更复杂

#3 楼 @gihnius 估算。比如上传一张 4M 以下图片到 CDN 的任务 A, 耗时大概 数秒。要求上传完 1w 张后触发任务 B，则 B 启动前 睡 1 分钟 即可。

#1 楼 @gihnius 这样实现起来相对复杂，需要很多额外的操作。而且随时启动，等到 n 执行这个需要 启动了的 B 任务长时间待机。设想待机时进程被杀或者服务器故障。

#1 楼 @adamshen 0.3% 有可能是因为把不涉黄的判黄了

👏

metabase +1. 记得用 docker.

喂，不要拖更啊。。。