pathbox (tequila)

Rails App 之间的三种"通讯"方式实践

pathbox — Sat, 06 Jan 2018 16:35:20 +0800

三种方式

API 接口通讯
Sidekiq
gRPC

Rails 环境

Rails 5.1.4
Ruby 2.3.3
redis

Two Rails App:

jerry_app

listen: 127.0.0.1:9001

tom_app

listen: 127.0.0.1:9002

定义一个请求方向：tom_app -> 发起请求 -> jerry_app

文章 Rails App 完整的代码在：完整代码 repo

API 接口通讯

简单、稳定的方式，没有"第三方的依赖"。

在jerry_app定义一个对外接口，get请求，url 是 http://127.0.0.1/product，controller 的代码：

# products_controller.rb
class ProductsController < ApplicationController
  before_action :do_validation, only: :index

  def index
    render json: {code: 200, message: "Success"}
  end

  private

  def do_validation
    timestamp = params[:timestamp].to_i
    token = params[:token]

    if timestamp.blank? || token.blank?
      return render json: {code: 400, message: "timestamp or token can't be blank"}, status: 400
    end

    time_now = Time.now.to_i
    if time_now - timestamp > 300 || time_now < 0
      return render json: {code: 400, message: "Timestamp is expired"}, status: 400
    end

    str = APP_ID + timestamp.to_s
    hex_token = OpenSSL::HMAC.hexdigest("SHA1", APP_KEY, str)

    if token != hex_token
      return render json: {code: 401, message: "token is wrong"}, status: 401
    end

  end
end

在tom_app定义一个方法，请求jerry_app开放的接口：

# tom_app/app/services/product_service.rb
class ProductService

  class << self
    def get_products
      timestamp = Time.now.to_i
      str = APP_ID + timestamp.to_s
      token = OpenSSL::HMAC.hexdigest("SHA1", APP_KEY, str)

      params = "token=#{token}&timestamp=#{timestamp}"
      url = "127.0.0.1:9001/products?#{params}" # jerry_app listens 9001

      resp = Typhoeus.get(url, timeout: 3)
      body = resp.body
      puts "Products result: #{body}"
    end
  end
end

接口进行了参数验证和 token 方式的权限认证，保证一定的安全性。实际生产环境使用 https 会更好。

鉴权的算法是：

str = APP_ID + timestamp.to_s
token = OpenSSL::HMAC.hexdigest("SHA1", APP_KEY, str)

然后对 token 进行了过期验证：

time_now = Time.now.to_i
if time_now - timestamp > 300 || time_now < 0
  return render json: {code: 400, message: "Timestamp is expired"}, status: 400
end

你还可以用 IP 白名单的方式，让接口只允许白名单的 IP 访问。

使用 Sidekiq "通讯"

其实这是一种使用消息队列，进行异步调用的方式。并不是只有Sidekiq能做到，一般的消息队列框架都可以实现，简单的使用 redis 也可以实现。

在 Rails(Ruby) 环境，顺其自然的，就选择了Sidekiq。分别在两个 Rails App 进行 Sidekiq 操作，代码示例：

# tom_app/config/initializers/tom.rb

jerry_redis_config = {
  host: '127.0.0.1',
  port: 6379,
  db: 0
}

jerry_redis = Redis.new(jerry_redis_config)

jerry_sidekiq_redis = Redis::Namespace.new(:jerry_app, redis: jerry_redis)

JERRY_REDIS_POOL = ConnectionPool.new(timeout: 1) {jerry_sidekiq_redis}

上面我们定义了一个全局的 ConnectionPool实例对象JERRY_REDIS_POOL。使用到的 redis 配置是我们要调用的jerry_app的 redis 配置：jerry_redis_config。也就是JERRY_REDIS_POOL是jerry_app的ConnectionPool实例对象。

然后我们定义一个 Sidekiq Worker：

# tom_app/app/workers/update_product_worker.rb

class UpdateProductWorker
  include Sidekiq::Worker
  sidekiq_options :queue => :default, :pool => JERRY_REDIS_POOL
end

在 sidekiq_options 中配置 pool 的值为 JERRY_REDIS_POOL。在这里不需要定义perform方式。

在你想要向jerry_app发起调用时，调用UpdateProductWorker就行。

# tom_app/app/services/product_service.rb
class ProductService

  class << self
    # ......

    def update_product_worker
      UpdateProductWorker.perform_async(1)
    end
  end
end

接下来在jerry_app也定义相同名称的UpdateProductWorker

# jerry_app/app/services/product_service.rb
class UpdateProductWorker
  include Sidekiq::Worker
  sidekiq_options :queue => :default

  def perform(product_id)
    # do something for example:
    # product = Product.find(product_id)
    # product.update!(amount: 0)
    Sidekiq.logger.info "++++++product_id: #{product_id}"
    Sidekiq.logger.info "UpdateProductWorker Success"
  end
end

在tom_app中打开rails c:

ProductService.update_product_worker

在jerry_app中，tailf sidekiq.log -n 20得到了：

2018-01-05T05:55:07.681Z 28855 TID-hooyg UpdateProductWorker JID-2714364eff0c2d6714d38221 INFO: start
2018-01-05T05:55:07.683Z 28855 TID-hooyg UpdateProductWorker JID-2714364eff0c2d6714d38221 INFO: ++++++product_id: 1
2018-01-05T05:55:07.683Z 28855 TID-hooyg UpdateProductWorker JID-2714364eff0c2d6714d38221 INFO: UpdateProductWorker Success
2018-01-05T05:55:07.683Z 28855 TID-hooyg UpdateProductWorker JID-2714364eff0c2d6714d38221 INFO: done: 0.002 sec

原理：tom_app 是"消费者"，jerry_app 是"生产者"。借助 Sidekiq，"消费者"得到参数并执行具体的逻辑。显然，这是一种异步请求调用。如果你需要同步的请求调用，这种方式就不合适了。

gRPC in Ruby on Rails

如果不了解 gRPC，可以阅读这里gRPC 官网，是一种 rpc 的方式。我在之前 Go 的微服务项目中，服务之间使用了 gRPC 进行通讯。 gRPC 对 ruby 也有支持，gRPC ruby example。阅读了它的例子和文档，觉得实现方式和 Rails 并没有融合的很好。然后在 github 上搜了一下，找到了这个 gem: gruf。它是将 gRPC ruby 进行了一定的封装。于是我就选择了使用它。不过我发现，gruf的README 在一些细节上不够完整，有些坑，我按照 README 的操作，没有成功。直到把他们的 demo 的代码看完，和 demo 中 rake 测试命令的代码看完，才明白了所有细节。我修改了 README，并给他们提了 push。如果你在本地没法跑通例子，也许你需要安装 gRPC 和 protocol buffers。

看具体的代码例子，主要的代码逻辑在app/rpc目录下：

tom_app中

# tom_app/config/initializers/gruf.rb

require 'gruf'
require 'app/proto/helloworld_services_pb'

Gruf.configure do |c|
  c.default_client_host = '127.0.0.1:9003' # 在这里默认配置了host，如果不配置，则需要在每次调用的时候传host值
end

# 在 tom_app/app/rpc/app/ 执行 grpc_tools_ruby_protoc -Iproto --ruby_out=proto --grpc_out=proto proto/helloworld.proto 会生成　helloworld_pb.rb和helloworld_services_pb.rb文件。这样有一个问题，就是helloworld_pb 文件的加载问题，应该和加载路径有关。我就手动修改了 helloworld_services_pb.rb文件

require 'app/proto/helloworld_pb' # 这样就正确加载了helloworld_pb.rb了

# 这里不列出来了，具体的client端和server端，就是使用helloworld_pb.rb和helloworld_services_pb.rb文件中的类和方法

# tom_app/app/rpc/greeter_client.rb
class GreeterClient

  def self.say_hello(name)
    puts "say_hello: #{name}"

    options = {
      # hostname: '127.0.0.1:9003',
      username: 'admin',
      password: 'admin'
    }

    begin
      client = ::Gruf::Client.new(service: ::Helloworld::Helloworld, options: options)

      response = client.call(:SayHello, name: name)
      puts "+"*30
      puts response.message.message # Helloworld::HelloReply instance
    rescue Gruf::Client::Error => e
      puts e.error.inspect
    end
  end
end

tom_app中

# tom_app/config/initializers/gruf.rb
require 'gruf'
require 'app/proto/helloworld_services_pb'

Gruf.configure do |c|
  c.server_binding_url = '127.0.0.1:9003'
  c.interceptors.use(Gruf::Interceptors::Instrumentation::RequestLogging::Interceptor, formatter: :logstash)
  # basic auth
  c.interceptors.use(
    Gruf::Interceptors::Authentication::Basic,
    credentials: [{
      username: 'admin',
      password: 'admin',
    },{
      username: 'another-username',
      password: 'another-password',
    },{
      password: 'a-password-only'
    }]
  )
end

# helloworld.proto
# helloworld_pb.rb
# helloworld_services_pb.rb
# 这三个文件和　tom_app一样

# jerry_app/app/rpc/greeter_controller.rb
class GreeterController < Gruf::Controllers::Base
  bind ::Helloworld::Helloworld::Service

  def say_hello
    name = request.message.name
    result = "+++ Hello #{name}+++"
    puts result
    Helloworld::HelloReply.new(message: result)
  end
end

在jerry_app根目录执行bundle exec gruf,你可以看到

[2018-01-05T15:31:46.719862 #31505]  INFO -- : handling /helloworld.Greeter/SayHello with #<Method: Helloworld::Hello::Service#say_hello>

在tom_app rails c 中执行

2.3.3 :001 > GreeterClient.say_hello("Tom")
say_hello: Tom
D, [2018-01-05T15:34:15.095475 #32363] DEBUG -- : calling 127.0.0.1:9003:/helloworld.Greeter/SayHello
++++++++++++++++++++++++++++++
+++ Hello Tom+++
 => nil

在jerry_app　gruf 服务，你可以看到这样的日志：


+++ Hello Tom+++
I, [2018-01-05T15:35:49.945836 #31505]  INFO -- : {"message":"[GRPC::Ok] (helloworld.hello.say_hello)","status":0,"service":"helloworld.hello","method":"say_hello","action":"say_hello","grpc_status":"GRPC::Ok","duration":0.74,"thread_id":40308860,"time":"2018-01-05 15:35:49 +0800","host":"20161125","format":"json"}

整个过程：将 gRPC client 端实现为一个类，定义调度的类方法或实例方法，使用了账号密码的 basic auth；在 gRPC server 端具体实现要调度的方法代码逻辑。你可以查阅更多gruf的内容，它实现了其他一些中间件 (interceptor),让你更好的使用 gRPC。你可以选择用foreman来控制gruf服务的启动。

其他

我用 go-grpc 的作为 client，调用jerry_app的gruf服务，结果报了错。

W, [2018-01-05T15:59:22.046980 #31505]  WARN -- : UNIMPLEMENTED: #<struct Struct::NewServerRpc method="/proto.Hello/SayHello", host="127.0.0.1:9003", deadline=1970-01-01 07:59:59 +0800, metadata={"user-agent"=>"grpc-go/1.8.0-dev"}, call=#<GRPC::Core::Call:0x000000045a7e50>>

关于跨语言的 rpc 调用，我还未尝试。thrift应该会是一个不错的选择。

Raft 算法动画演示

pathbox — Thu, 14 Dec 2017 17:54:39 +0800

今天发现了有人做了这个 Raft 算法演示。做的挺好的，动画简洁，台词通俗易懂。对分布式算法感兴趣的同学可以了解

演示地址

简记 Rails 中的 logger 实用技巧

pathbox — Sat, 02 Dec 2017 15:26:12 +0800

Gem lograge

lograge is awesome for formating log.


# Gemfile
gem "lograge"

# config/initializers/lograge.rb
# OR
# config/environments/production.rb

Rails.application.configure do
  ...
# Logger
  config.lograge.enabled = true
  config.lograge.ignore_actions = ['home#welcome']
  config.lograge.custom_options = lambda do |event|
    params = event.payload[:params].reject do |k|
      ['controller', 'action'].include? k
    end
    options = {
      params: params,    # add params to lograge
      time:   event.time # add time to lograge
    }
    options
  end
  ...
end

lograge 能帮你格式化日志输出，定义日志输出的格式和内容。去掉了 view 层渲染的日志内容。如果你不需要日志具体打印 view 层的渲染内容，用lograge是极好的，如果你需要，lograge 就不适合你。一般应用不关心 view 层渲染的具体日志内容。

例子：

环境：Rails 5.1.4

lograge还提供了不同的 formatters。

Lograge::Formatters::Lines.new
Lograge::Formatters::Cee.new
Lograge::Formatters::Graylog2.new
Lograge::Formatters::KeyValue.new  # default lograge format
Lograge::Formatters::Json.new
Lograge::Formatters::Logstash.new
Lograge::Formatters::LTSV.new
Lograge::Formatters::Raw.new       # Returns a ruby hash object

默认的日志格式是 key=value 的格式：

[2017-12-01 22:43:00] [INFO] [] [localhost] [127.0.0.1] [1593754b-bc95-42] method=GET path=/ format=*/* controller=HomeController action=welcome status=200 duration=472.00 view=0.00 params={} time=2017-12-01 11:49:09 +0800

比如，配置 Lograge::Formatters::Json.new

config.lograge.formatter = Lograge::Formatters::Json.new

得到的日志结果是这样的：

[2017-12-01 22:43:34] [INFO] [] [localhost] [127.0.0.1] [74cc1bef-2155-42] {"method":"GET","path":"/","format":"*/*","controller":"HomeController","action":"welcome","status":200,"duration":3.09,"view":0.0,"params":{"home":{}},"time":"2017-12-01 22:43:34 +0800"}

config.lograge.formatter = Lograge::Formatters::Graylog2.new

得到的日志结果是这样的：

[2017-12-01 22:47:46] [INFO] [] [localhost] [127.0.0.1] [18654bb8-01ec-48] {:_method=>"GET", :_path=>"/", :_format=>"*/*", :_controller=>"HomeController", :_action=>"welcome", :_status=>200, :_duration=>368.34, :_view=>0.0, :_params=>{"home"=>{}}, :_time=>2017-12-01 22:47:46 +0800, :short_message=>"[200] GET / (HomeController#welcome)"}

如果想使用

config.lograge.formatter = Lograge::Formatters::Logstash.new

需要配合安装 logstash-event

gem "logstash-event"

这样很方便的能够得到你想要的日志内容结构，并且被各种日志监控系统兼容。这是lograge简单的功能，更多配置查看文档

自定义生成 log 文件

有时候，我们想要将日志存储到一个新的 log 文件中，和主日志文件区分开来。

定义一个类方法或全局的方法：

def create_my_logger(file_name)
  logger = Logger.new("#{Rails.root}/log/#{file_name}")  # 根据file_name，创建一个logger实例。会在Rails.root/log目录下生成file_name文件，用来记录日志
  logger.level = Logger::DEBUG  # 设置日志的level
  logger.formatter = proc do |severity, datetime, progname, message| # 设置日志的formatter
    "[#{datetime.to_s(:db)}] [#{severity}] #{message}\n"
  end

  logger
end

在想要使用该日志实例的代码中：

log = create_my_logger("third_api_service.log")

... # do something
result = do_third_api_service
if result
  log.info("Third api service success")
else
  log.error("Third api service fail: #{result}")
end

个人认为这种方法适用于调用一些关键服务或操作，想要快速了解该服务的正确性，当有错误的时候，可以快速查阅日志，了解服务信息。也便于调试和快速排查问题

还可以给 logger 实例扩展一些方法：

module MyLogger
  def log_json
    info = {}
    title = []

    yield msg, info

    timestamp  = Time.now.strftime('%Y%m%d_%H%M%S_%L')
    msg      = [timestamp, msg].flatten.compact
    title = title.join('-')

    data = {}
    data[:msg] = msg
    data.merge! info

    self.debug data.to_json # 打印json日志内容
  end
end

def create_my_logger(file_name)
  logger = Logger.new("#{Rails.root}/log/#{file_name}")  # 根据file_name，创建一个logger实例。会在Rails.root/log目录下生成file_name文件，用来记录日志
  logger.level = Logger::DEBUG  # 设置日志的level
  logger.formatter = proc do |severity, datetime, progname, message| # 设置日志的formatter
    "[#{datetime.to_s(:db)}] [#{severity}] #{message}\n"
  end
  logger.extend MyLogger

  logger
end

使用示例：

SYNC_LOGGER = create_my_logger('sync.log')

SYNC_LOGGER.log_json do |msg, info|
  msg << 'user_id:1'
  info[:action] = 'sync success'
end

生成 sync.log 文件会打印以下信息：

[2017-12-01 22:45:20] [DEBUG] {"title":"20171202_141419_311-user_id:1","action":"sync success"}

为调用外部服务增加必要日志

当系统中有需要 http client 形式调用外部服务时，比如：微信开发的微信接口，推送接口，第三方开放 API，我会这么做：

使用示例：

API_LOGGER = create_my_logger('xxx_api.log')

API_LOGGER.log_json do |msg, info|
  begin
    msg << 'xxx:api:user_id:1'
    info[:resquest] = request_params
    start = Time.now
    res = httpclient.do(url, request_params)
    duration = Time.now - start
    info[:response] = res
    info[:duration] = duration
    info[:error] = nil
  rescue => e
    info[:res] = nil
    info[:error] = "#{e.inspect}"
  end
end

将请求参数、返回响应、报错信息都记录下来，查看日志时一目了然。出问题时，能帮助你很快的定位出是系统中的 bug 还是外部服务的 bug。

证明"代码的清白"，就靠他们了。

一个好的日志设计和使用习惯，是一个系统稳定、健壮和可控的重要保证。

本文简单小结了在 Rails 项目中日志的使用。

为 Rails 项目升级使用 ElasticSearch 5.x 版本

pathbox — Wed, 01 Nov 2017 15:47:50 +0800

最近为项目系统中使用的 Elasticsearch 进行了升级。从原来 1.4 版本的 Elasticsearch 升级到 5.x 版本。

由于 5.x 版本的 Elasticsearch 不再支持 1.4 版本中的很多查询语法，所以不可避免的进行了查询层的重构。每次 Elasticsearch 有重大版本升级的时候，会在官方文档中列出相应的改变，你需要认真阅读的Breaking changes内容。

最重要的事情是，终于可以利用这次机会，为 Elasticsearch 加入了索引别名机制

安装

Elasticsearch-5.x server 版本的安装可以参考之前的博文。我是安装在 Ubuntu16.04 上，Ubuntu14.04 也是可以的。

在Gemfile中增加

gem "elasticsearch"
gem "elasticsearch-model"
gem "elasticsearch-rails"

使用最新的 elasticsearch gem 包，至少大于 5.0 版本

加入索引别名机制

为什么说别名机制是最重要的事情呢？我们知道 Elasticsearch 的索引，当你配置并建立好之后，是无法进行更新修改的。想要进行更新修改，需要删除原来的整个索引，然后再根据新的配置，重建索引，包括索引的文档数据。这就不可避免了该索引在重建过程中有一段时间是不可用的。

举个简单的例子：Elasticsearch 有一个 orders 索引，大概有 1000w 条记录数据。你的客户会经常使用查询 orders 的功能，这个功能查的就是 orders 索引。现在你要修改 orders 索引的分词器。这时你需要重建 orders 索引 (删除再新建)，假设这个过程，让 orders 索引完全恢复到可用状态需要 10 分钟。那么，你的客户就会有 10 分钟没法使用 orders 的搜索功能。当然，你可以在凌晨 3 点进行这个操作。这里只是举个例子。Elasticsearch 索引别名机制可以帮助你进行索引无缝的升级或更新。

别名机制的过程及原理

关键的操作是：取别名。现在我要重构 orders 这个索引，我会先创建一个叫做 orders_v1 的索引，为其配置名称为 orders 的别名。这样，在查询代码层，你就可以使用类似Order.__elasticsearch__.search()这样的查询了。其实，也就是在代码层面上，不知道有 orders_v1 这个索引额存在，一切对 Elasticsearch 的操作，都通过别名 orders 操作。

现在，我们需要修改 orders_v1 索引，只要简单的三步：

1. 用新的索引配置新建一个叫 orders_v2 的索引，将文档数据也建立好
2. 进行切换别名的操作，将 orders 别名由原来 order_v1 指向 orders_v2
3. 看你的需要，再进行增量变更数据的更新

切换别名的操作非常快，并且你的代码层的修改会变得很轻松。几乎不会对用户的使用造成影响。

简单的图表示：

在项目中，实现别名机制不难。详见官方文档的例子

新建索引别名

POST /_aliases
{
    "actions" : [
        { "add" : { "index" : "order_v1", "alias" : "orders" } }
    ]
}

切换索引别名

POST /_aliases
{
    "actions" : [
        { "remove" : { "index" : "order_v1", "alias" : "orders" } },
        { "add" : { "index" : "order_v2", "alias" : "orders" } }
    ]
}

在 rails 项目中，我通过 rake 脚本实现，下面是我写的一个 rake 脚本，在新建或重建索引的时候使用，仅供参考。

#coding: utf-8
client = Elasticsearch::Client.new(
  host: elasticsearch_url,
  retry_on_failure: 0,
  log: true,
  transport_options: { request: { timeout: 10 } }
  )

# ++++++++++++++++++++++++++++++++++使用方式++++++++++++++++++++++++++++++++++++++

#1 创建索引 　　 # bundle exec rake es_action:create_index table=Order index_name=orders_v1
#2 索引别名配置　#　bundle exec rake es_action:update_index_alias alias=orders new_index=orders_v1 old_index=orders_v2(可选，交换索引的时候使用)
namespace :es_action do

  desc "重建es索引,根据传入的参数指定重置的索引"
  task create_index: :environment do
    table = ENV['table']
    index_name = ENV['index_name']
    puts "++++++ start remapping index #{table}"
    if table.blank? || index_name.blank?
      puts "table 和 index_name 参数不能为空"
      return
    end

    model = table.camelize.constantize

    model.__elasticsearch__.create_index! index: index_name, force: true  # ++++++创建索引
    model.__elasticsearch__.refresh_index! index: index_name
  end

  desc "新建或交换es的别名（将别名由旧的索引指向新的索引）"
  task update_index_alias: :environment do
    old_index = ENV['old_index']
    new_index = ENV['new_index']
    alias_name = ENV['alias']

    puts "++++++ start update_index_alias #{alias_name}"
    if alias_name.blank? || new_index.blank?
      puts "++++++ alias new_index 参数不能为空"
      return
    end

    body = {actions: []}
    body[:actions] << {remove: {index: old_index, alias: alias_name}} if old_index.present? # old_index存在，表示是进行别名切换
    body[:actions] << {add: {index: new_index, alias: alias_name}}

    client.indices.update_aliases body: body

    puts "++++++ update_index_alias success"
  end

end

mapping 的配置

app/models/order.rb

1.4 版本中的 mapping 配置

indexes :subject, type: 'multi_field' do
  indexes :raw, type: :string, index: :not_analyzed
  indexes :tokenized, analyzer: :ik_smart
end
indexes uuid, type: :string
indexes amount, type: :integer
indexes price, type: :long
indexes :created_at, type: :date
indexes :updated_at, type: :date
indexes :users do
  indexes :id, type: :integer
  indexes :name, type: :string, index: :not_analyzed
end

5.x 版本中的 mapping 配置

indexes :subject, type: :keyword do
  indexes :raw, type: :keyword
  indexes :tokenized, analyzer: :ik_smart
end
indexes uuid, type: :text
indexes amount, type: :integer
indexes price, type: :long
indexes :created_at, type: :date
indexes :updated_at, type: :date
indexes :users do
  indexes :id, type: :integer
  indexes :name, type: :keyword
end

5.x 版本没有了 string 类型，拆分成了 keyword 和 text。如果你指定了 analyzer，则是 text 类型；如果指定了 text 类型但是没有指定 analyzer，则会使用默认的 analyzer
不再有 type: 'multi_field'，这个好像是 2.x 版本就废弃了
5.x 的 IK 也分成了两种配置。 ik_smart和ik_max_word， ik_max_word拥有更细的分词粒度。

查询语句的重构

官方文档的 query changes

修改例子：

不再使用 filtered

{filtered: {
  filter: {
    bool: {
      must: [{or: [{terms: {user_id: user_id}}]},
      {term: {order_id: order_id}}
     ],
    }
   }
 }
}

# 重构为：
{bool: {
  filter: {
    {bool: {
       must:[
         {term: {order_id: order_id}},
       ],
       should: [
         {terms: {user_id: user_id}}
       ]
     }
    }
  }
 }
}

不再使用 or

filters[:must] << {
  or: [
    {term: {order_id: order_id}},
    {term: {user_id: user_id}}
  ]
}

#重构为:
filters[:must] << {
  bool: {
    should: [
      {term: {order_id: order_id}},
      {term: {user_id: user_id}}
    ]
  }
}

不再使用 missing

{missing: {field: field_name}}

#重构为：
{"bool": {
   "must_not": [
      {
        "exists":{
           "field": field_name
        }
      }
   ]
  }
}

execution: 'and'不再使用

{terms: {field_name => value, execution: "and"}}

#重构为：
terms_array = value.map {|v| {term: {field_name => v}}}
{bool: {must: terms_array}}

Elasticsearch 的功能还是很强大的，这次 Elasticsearch 升级没有使用自定义的 Routing 的机制，一个是任务时间考虑，另一个是现在的服务负载还能撑一段时间，并不急迫需求这样的优化。现在有了索引别名，以后就可以放心的考虑优化进程了～

注意使用 inject 和 reduce

pathbox — Thu, 24 Aug 2017 14:43:35 +0800

最近在使用 inject 的时候遇到了一个问题。我的代码例子是：

[1,2,3,4,5,6].inject([]) do |sum, i|
  if i > 1
    sum << i
  end
end

结果报错：

NoMethodError: undefined method `<<' for nil:NilClass

一开始很奇怪，在 inject([]) 的时候，我给 sum 赋值初始值为数组了，报错信息怎么会报 sum 是一个 nil:NilClass 呢？

打断点

def test_inject
  [1,2,3,4,5,6].inject([]) do |sum, i|
    if i > 1
      binding.pry
      sum << i
    end
  end
end

发现确实 sum 是 nil。想到了可能是 if i > 1 这个条件判断的影响。修改一下测试代码

def test_inject_0
  [1,2,3,4,5,6].inject([]) do |sum, i|
    if i > 0
      sum << i
    end
  end
end

def test_inject_3
  [4,5,6,1,2,3].inject([]) do |sum, i|
    binding.pry
    if i > 3
      sum << i
    end
  end
end

test_inject_0  # [1, 2, 3, 4, 5, 6]

test_inject_3  
sum
# []
# [4]
# [4,5]
# [4,5,6]
# NoMethodError: undefined method `<<' for nil:NilClass

根据 test_inject_3，当 i 的值不满足 if i > 3 的条件的时候，sum 的值就被置为 nil 了。

如果你需要在 inject 的 block 中进行对操作元素的条件过滤操作，你会将 sum 变为 nil。

所以建议不在 inject 的 block 中进行条件过滤操作，而是在 inject 方法之前过滤好。

同理 reduce 方法。

Ruby 版本：ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]

升级 Elasticsearch 集群数量实战记录

pathbox — Mon, 31 Jul 2017 15:47:34 +0800

现在线上有一个 elasticsearch 集群搜索服务有三台 elasticsearch 实例（es1、es2、es3），打算将其升级为 5 台（增加 es4、es5）。这篇文章主要是对整个操作的过程记录，以及出现的问题总结，包括移动数据量所需要的时间。因为，一开始由于不知道线上数据量全部分配完需要多少时间，如果从凌晨开始操作，到早上 8 点都还没有同步完，这样会影响到白天线上业务的正常使用。

准备阶段

线上 es 集群使用的是阿里云服务器，copy 其中一个镜像。然后更改其 elasticsearch.yml 配置文件，检查 IK 插件是否安装成功。按照这个流程，准备两台新的服务器放入阿里云的隔离组，并安装好 elasticsearch，测试 elasticsearch 实例可以正确启动。也做了将这两台服务器构建一个集群的测试。开始升级操作前 30 分钟，再次检查 elasticsearch.yml 配置。主要的修改是：

discovery.zen.minimum_master_nodes:3
discovery.zen.ping.unicast.hosts: ["es1_ip", "es2_ip","es3_ip","es4_ip","es5_ip"]

升级操作

关闭 es 集群 shard 分配功能。对 es1 执行：

curl -XPUT es1_ip:9200/_cluster/settings -d '{
  "transient": {
   "cluster.routing.allocation.enable": "none"
   }
}'

然后检查：

curl es1_ip:9200/_cluster/settings
curl es2_ip:9200/_cluster/settings
curl es3_ip:9200/_cluster/settings

得到的结果是：

{"transient":{"cluster":{"routing":{"allocation":{"enable":"none"}}}}}

说明 es 集群已经关闭 shard 分配功能

关闭 es1、es2、es3 上的 monit

sudo service monit stop

手动控制 elasticsearch 进程的启动，避免 monit 自动拉起 elasticsearch 进程导致意外问题

这时，新的两台服务器 es4、es5 还在隔离组。把隔离取消，然后启动这两台服务器的 elasticsearch 实例

使用目录下面写好的启动脚本，这个脚本可以在启动时，为 elasticsearch 获取所设定的内存 (控制分配给 es 进程的最大内存、最小内存)，JVM 的设置等

./elasticsearch.sh start

执行

curl es1_ip:9200/_cat/nodes
curl es1_ip:9200/_cat/shards
curl es1_ip:9200/_cat/health
curl es1_ip:9200/_cat/indices

验证 nodes 节点信息是否变为五个，以及 shard 现在的分布情况，应该只分布在 es1、es2、es3 上。es4 和 es5 还没有 shard

然后记录下当前的 indices 信息

例子：

health status index    pri rep docs.count docs.deleted store.size pri.store.size
green  open   users     5   1   15036978      4262221     13.2gb          6.6gb
green  open   posts     5   1   15036978      4262221     13.2gb          6.6gb

我们可以看到索引的健康度、状态、文档数量、数据大小和主分片数量、副分片的倍数设置。记录下这些信息，在最后升级完的时候进行比对，看是否有偏差。如果一切正常，这些信息是不会变的。

启动 es 集群 shard 分配功能

这是集群操作，所以只要对其中一台 es 实例操作即可

curl -XPUT es1_ip:9200/_cluster/settings -d '{
  "transient": {
   "cluster.routing.allocation.enable": "all"
   }
}'

shard 分配开始

执行：

curl es1_ip:9200/_cat/shards

curl es1_ip:9200/_cat/health

curl es1_ip:9200/_cat/indices

curl es1_ip:9200/_cat/recovery

观察 shards 分布情况，是否向 es4 和 es5 分配 shards。以及分配的百分比进度
监控 es4 和 es5 服务器的 elasticsearch 的 log
登入 es4 和 es5，查看挂载的 SSD 数据盘数据量是否在增长
测试进行 es 搜索的测试，快速搜索，工单筛选，客户筛选，观察对线上业务的影响

这段时间，主要使用：

curl es1_ip:9200/_cat/shards

curl es1_ip:9200/_cat/health

curl es1_ip:9200/_cat/recovery

观测 shard 分配进度和情况，以及线上系统健康度。

curl es1_ip:9200/_cat/shards 可以看见具体哪个索引的，哪个 es 服务器在移动 shard 到另一台 es 服务器

正在shard移动时的状态
posts r RELOCATING  3628884   5.4gb es_ip1   elasticsearch1 -> es_ip5 elasticsearch5

可以看到哪个索引，哪个 shard 分片，从哪台服务器上移到另一台服务器上

这个过程发现，elasticsearch 会选择将 reproduction shard(副本分片) 移到新的 elasticsearch 服务器上，而避免移到主分片。

这样可以避免移到主分片时候发生数据丢失的情况，而移动副本分配不用担心这个问题，并且线上的 health 一直是 green。尽可能不影响线上正常搜索业务。

移动 shard 默认是两个并发操作。一开始误解了，以为每个 es 实例会进行两个并发的 shard 移动，会有 6 个 shard 在并发移动，实际情况是，整个集群只有 2 个 shard 在并发移动。下次可以将这个值调大一些，加快 shard 的移动速度，幸好 shard 数据移动的速度比想象的要快。

通过 htop 观察服务器的负载，在进行 shard 分配的服务器，CPU 使用率一般在 20%-40% 之间。服务器是 16 核，也就是一个 elasticsearch 进程 shard 的移动，一个核心都没有跑满，服务器负载在 0.2。可见 elasticsearch 的分片移动还是很保守的，对服务器几乎没有很大的压力。并且观察发现，elasticsearch 不会一次把某个索引该分配的 shard 都分配完再选择下一个索引，而是轮询的分配索引的 shard。A 索引分配了一个 shard，就分配 B 索引的 shard，一圈之后，又回到 A 索引继续分配 shard。直到最后所有索引 shard 数量在集群中平衡。

收尾操作

大约一个小时时间，shard 分配结束。一共将 88G 左右的数据分配到了两台新的服务器上。这是在默认 shard 并发分配数 2 的情况下的时间记录。大家以后可以根据这个记录，预估自己的 elasticsearch shard 分配会需要多少时间。

动态修改 master 选举数量。根据 elasticsearch 文档推荐的公式： (N(master)+1)/2

curl -XPUT es1_ip:9200/_cluster/settings -d '{
      "persistent" : {
          "discovery.zen.minimum_master_nodes" : 3
      }
    }'

检查配置：

{"persistent":{"discovery":{"zen":{"minimum_master_nodes":"3"}}},"transient":{"cluster":{"routing":{"allocation":{"enable":"all"}}}}}

再检测 API 命令

curl es1_ip:9200/_cat/health

curl es1_ip:9200/_cat/indices

curl es1_ip:9200/_cat/shards

这时候，观察到 shard 分配的结果是，每个索引有 10 个 shard，每个 es 服务器拥有一个索引的两个 shard。新加入的 es4、es5 上都是副本 shard，原有集群中的 es1、es2、es3 拥有主 shard 和副本 shard。

例子：

index              shard   prirep   state     docs     store  ip    node
posts               2       r       STARTED   993718   3.5gb es1_ip es1
posts               2       p       STARTED   993718   3.5gb es1_ip es1
posts               0       p       STARTED   993428   3.7gb es2_ip es2
posts               0       p       STARTED   993428   3.7gb es2_ip es2
posts               3       p       STARTED   993653   3.6gb es3_ip es3
posts               3       p       STARTED   993653   3.6gb es3_ip es3
posts               1       r       STARTED   994063   3.5gb es4_ip es4
posts               1       r       STARTED   994063   3.5gb es4_ip es4
posts               4       r       STARTED   993938   3.5gb es5_ip es5
posts               4       r       STARTED   993938   3.5gb es5_ip es5

posts 索引的十个 shard 分片在每台 elasticsearch 服务器上有两个分片。perfect!(实际结果是乱序的)

后悔的操作选择

我们修改了 es1 的配置文件，想要重启 es1 elasticsearch 实例。重启后，发生了意想不到的事情，索引的 shard 又开始分配移动，等了快 40 分钟分配移动结束，但是，这时候不是每个 es 服务器平均拥有一个索引的两个 shard，而是有的 es 服务器有该索引的三个 shard。

posts               2 r STARTED   993718   3.5gb es4_ip es4
posts               2 p STARTED   993718   3.5gb es2_ip es2
posts               0 p STARTED   993428   3.7gb es4_ip es4
posts               0 r STARTED   993428   3.7gb es1_ip es1
posts               3 r STARTED   993653   3.6gb es1_ip es1
posts               3 p STARTED   993653   3.6gb es2_ip es2
posts               1 r STARTED   994063   3.5gb es5_ip es5
posts               1 p STARTED   994063   3.5gb es1_ip es1
posts               4 r STARTED   993938   3.5gb es5_ip es5
posts               4 p STARTED   993938   3.5gb es3_ip es3

posts 在 elasticsearch1 上出现了三个 shard

实际上，原本集群中的三台服务器是不用重启的，你可以修改他们 elasticsearch.yml 配置中的单拨数组设置：discovery.zen.ping.unicast.hosts。加上新加的两台服务器的 ip，和 discovery.zen.minimum_master_nodes:3。下次重启的时候，就会读取这个新的配置，而不需要马上重新。因为，k 可以通过调用 API 的方式，动态配置 discovery.zen.minimum_master_nodes，而 discovery.zen.ping.unicast.hosts 的配置，在新的 elasticsearch 服务器上配置五台服务器的 ip 地址就可以了。

打开所有 es 服务器的 monit，测试线上 elasticsearch 搜索功能

修改项目代码，加上新加的两台 elasticsearch 服务器 IP

如何更可控、稳定地写 Rails 脚本操作线上数据库的记录

pathbox — Thu, 11 May 2017 18:46:09 +0800

在公司，有各种 Ruby 老司机。我们都喜欢用 Ruby 来解决各种问题。比如：操作线上的数据库记录，修改 ElasticSearch 等。

描述：某个功能需要为数据库增加相关数据。大概逻辑是：根据表 Company，根据某些条件往 Department 和 DepartmentsUser 表中插入数据。然后将 User 表中满足筛选条件的 status 字段进行更改。

结果：需要超过一个小时才将整个脚本跑完，也就是这一小时都在影响线上数据库

反思：可以更可控、稳定地写 Ruby 脚本操作线上数据库的表吗？

一、思考脚本是否可以在项目升级前运行

如果脚本可以在项目升级前运行，则可以在一定程度上更早的发现问题，以做出对正式升级时的预防。比如，操作新的表，或新的字段。这种情况是完全可以提早运行脚本的。有的脚本是必须要升级之前运行的，由于线上代码逻辑依赖于这个脚本的数据。所以，需要在升级之前跑一下，升级之后再跑一下。这样的脚本需要写成可重复执行。但是有的脚本是只能升级后跑的，则千万别在升级前跑

二、是否有长时间 commit 操作

警惕长时间 commit 的操作。举个例子：比如用 update_all 或批量插入在一定程度上可以更快的运行 sql，但是，这些操作的 commit 的时间可能会很长 (如果你用的是 MySQL)。这时候用户可以进行 select 或 insert 操作，但是对 update 操作就会阻塞了。如果时间过长则很有可能超时。这样会让用户感知到系统的延迟或崩溃。所以，不使用这种批量操作，排除 commit 长时间的操作，使用粒度小的 create，update，destroy 操作或者每次小批量的 commit 操作。如果一个 commit 很大，中间异常断了，则前面跑的 sql 语句就废弃了。而粒度小的操作则可以避免这样。虽然，总的执行时间会更长，但是，这样就不会长时间占用数据库的某个表而影响用户的一些使用。如果真的无法避免长时间的操作，就需要在后半夜大家睡觉的时候跑脚本或者进行数据库操作了 (比如新增字段，新增索引等)。

三、捕获异常错误

使用异常，捕获异常错误，将异常打印出来。或者可以在全局新建一个数组，然后将某次异常的操作中相关记录的 id 存入数组中，最后打印出来，就可以知道在执行过程中哪个记录是有问题的，可以很方便的追踪错误，后续就可以很方便的进行验证和纠错了。

四、让脚本可以重复运行

尽量让脚本可以重复运行。即使加入额外的 find 或者 find_or_create_by 查询。或者捕获异常，而不是让异常中断操作。不要使用清空数据库的方式，因为这样需要从 0 条记录开始跑，所需要的时间更长。脚本重复运行要注意的是，避免每次的重复运行增加脏数据。只有 update 操作的脚本可以重复运行，如果是 create 的操作，可以在操作前先判断一下是否存在，不存在则创建。 find_or_create_by 方法可以使用 block 方法，更方便的使用。

五、使用 find_each 或 find_in_batches

使用 find_each 或 find_in_batches 分批次的进行查询循环操作。注意，find_in_batches 得到的是对象数组集合。

六、使用 gem 'ruby-progressbar' 愉快的展示执行进度

在 Gemfile 中假如 gem 'ruby-progressbar', require: false。然后在脚本文件中 require 'ruby-progressbar' 进行使用。可以很方便的展示脚本执行的百分比和进度。

七、统计脚本结果信息，对比正确的信息以确定脚本运行无误。

八、踩过的坑。。。。。

在 rails c(用的是 pry 环境) 不要跑脚本，因为脚本代码中如果有 next 方法，会使用到的是 pry 的 next 方法而不是 ruby 的 next 方法，然后你就掉坑里了这对 rails 4.0 的版本有这个问题，4.2 以上的版本修复了这个问题
代码中不要定义和数据库字段相同名称的方法，如果有重名的方法，请先确认是需要该方法还是需要的是数据库的字段。是数据库的字段请使用 read_attributes
让每个脚本只执行一个循环模块，进行一种数据的更改。尽量保持独立。如果有互相依赖的循环逻辑，再写在一个脚本中。

九、对执行脚本后，线上数据的分析和校验。我觉得这也是最难的一步了，这一步根据不同项目而不同。我觉得应该在执行脚本之前，将验证数据的方案也准备好，

而不是脚本执行完就过了，而不知道线上数据到底正确不正确。所以，执行脚本其实应该分两部分。一部分是正常的更改逻辑，另一部分是验证线上数据正确与否的方案。

也许会因此会有成倍的代码量，但是，如果给线上数据带来隐患，给用户造成损失或不便，这才是更大的问题。

代码示例分析：

require 'ruby-progressbar'
progressbar = ProgressBar.create :total => Company.count, format: "%p%% [%B] %c/%C %E"
progressbar.log "= 开始初始化 ="
Company.find_each do |company|
  begin
    department = Department.create!(company_id: company.id, name: company.subdomain, parent_id: 0, is_default: true)
    company.agents.each do |agent|
      begin
        DepartmentsUser.create!(user_id: agent.id, department_id: department.id)
      rescue => e
        puts e
        next
      end
    end
  rescue => e
    puts e
    next
  end
  progressbar.increment
end

progressbar.log "=== 初始化完毕 ==="
User.where(p: ['A','UG']).update_all(status: true)

代码示例小结：

脚本是为新的数据库补充对应数据，所以可以在项目升级前运行
脚本使用了 find_each
脚本进行了异常捕获
脚本使用了 ruby-progressbar

可以改进的地方：

脚本不能重复跑，如果重复跑的话，对于 create 操作会产生脏数据；将 create! 改为 find_or_create_by!
没有收集异常错误的记录
没有统计脚本结果信息，对比正确的信息
建议将 progressbar.increment 放到循环的最开始
使用了 update_all 这种可能长时间锁表的操作

代码示例改进：

require 'ruby-progressbar'
progressbar = ProgressBar.create :total => Company.count, format: "%p%% [%B] %c/%C %E"
progressbar.log "= 开始初始化 ="
error_user = []
error_company = []
update_user_error = []
Company.find_each do |company|
  progressbar.increment
  begin
    department = Department.find_or_create_by!(company_id: company.id, name: company.subdomain, parent_id: 0, is_default: true)
    company.users.each do |user|
      begin
        DepartmentsUser.find_or_create_by!(user_id: user.id, department_id: department.id)
      rescue => e
        puts e
        error_user << user.id
        next
      end
    end
  rescue => e
    puts e
    error_company << company.id
    next
  end
end

User.where(p: ['A','UG']).find_each do |user|
  begin
    user.update!(status: true)
  rescue => e
    puts e
    update_user_error << user.id
  end
end

progressbar.log "Company count: #{Company.count} -- Department count: #{Department.count} -- DepartmentsUser count: #{DepartmentsUser.count} User count: #{User.count}"

progressbar.log "error: error_user: #{error_user}; error_company: #{error_company}"

progressbar.log "=== 初始化完毕 ==="

执行： bundle exec rails runner -e development init_department.rb

= 开始初始化 =                                                                                                                                                                        
100% [======================================================================================================================================================================] xxx/xxx Time: 00:00:00

Company count: xxx -- Department count: xxx -- DepartmentsUser count: xxx User count: xxx         

error: error_user: []; error_company: []                     

=== 初始化完毕 ===

本文提供的几个思路其实都不难，只是往往我们都忽略了。

无论是写 rails 脚本，rake 脚本，复杂的 migration 或者其他语言的脚本操作线上的数据库，都应该思考如何对线上的数据库影响最小，对用户的使用影响最小，以及最终的结果是否正确也许在本地或测试环境你的脚本运行的没有问题，但是，线上的数据数量往往是本地和测试环境的 n 倍，并且已经有很多隐藏的脏数据，各种奇妙的事情都有可能发生。即使是在半夜运行脚本，能够预先做更多的准备对应出现的异常情况，也能更快的找到问题的所在。

阅读 GitHub 仓库中项目源码的好帮手

pathbox — Fri, 05 May 2017 11:58:15 +0800

今天在 Github 上查看源码的时候，作者有个推荐查看文档的连接，点进去后来到了 https://sourcegraph.com。

这是一个有点仿照 Visual stadio code 的在线阅读源码的查看器，为什么说是查看器，因为我没有发现可以编辑。也许是我没有注册账户。界面的主题是 Dracula 吧。

这个界面是这样的：

Logo 的右边是一个搜索框，可以搜索 Github 上的项目仓库名称。我这里搜索出了 ruby-china/homeland 项目。之后，右边就会列出项目的所有代码，选择某个文件后就能看见源码。左边的搜索图标点击后，可以在项目中进行搜索。有点像是全局搜索。在代码中，按 ctrl+f 可以进行本文件的搜索。还可以显示多个选项框。暂时只发现这几个功能。

对于想方便的阅读 Github 代码，但是并不想把代码下载到本地的时候，用这个在线查看器还是很舒服的。不过，好像搜到的应该是 master 分支。暂不清楚是否可以选择分支。当然，如果要跳到 Github 上，右上角也可以很方便的跳转到 Github，不过可能会被谷歌浏览器拦截为弹出窗口。主页下面还有 Kelsey Hightower 为其做广告。如果你感兴趣，可以试一试。

在 Rails 项目中管理、自定义配置你的 ElasticSearch indexes

pathbox — Fri, 03 Mar 2017 10:56:18 +0800

这周对 Rails 项目中的 ElasticSearch 进行了总结并写成了文档，觉得有一些内容值得记录和分享。原文连接：超链接这篇文章主要是在 Rails 项目中对索引，mapping 的设置、管理操作的总结，不涉及搜索方面的内容。源数据是存在 MySQL 中，ES 的数据是 MySQL 写操作的时候进行了回调同步到 ES 中，这个应该和很多人的使用同步策略一样。

1.Model#mapping

在 model 文件中，使用 mapping 的声明方式。

class Article < ActiveRecord::Base
  include Elasticsearch::Model
  include Elasticsearch::Model::Callbacks
  index_name self.table_name  # 这里可以自定义Article的ES索引名称

  mapping do
    indexes :subject, type: 'multi_field' do
      indexes :raw, index: :not_analyzed
      indexes :tokenized, analyzer: 'ik'
    end
    indexes :content, type: :string, analyzer: 'ik'
  end
end

indexes :subject, type: 'multi_field' do
  indexes :original, index: :not_analyzed
  indexes :tokenized, analyzer: 'ik'
end

使用了 multi_field 定义了两个 indexes，这样在 ES 中会产生下面的 mapping 结构

"subject": {
   "type": "string",
   "index": "no",
   "fields": {
      "original": {
         "type": "string",
         "index": "not_analyzed"
      },
      "tokenized": {
         "type": "string",
         "analyzer": "ik"
      }
   }
}

对于 MySQL articles 表的 subject 数据，在 ES 的 articles 索引中用了两个 field 来存储 subject.original 和 subject.tokenized。他们存储的数据是一样的，不同的是 subject.original 没有被分词，subject.tokenized 使用了ik进行了分词。这样做的效果是当想要对 subject 进行全文搜索时，就可以使用 subject.tokenized，想要对 subject 进行条件过滤的时候，就可以使用 subject.original 了。

Tip: ik 是一个优秀的中文分析器 github 地址

我们知道 include Elasticsearch::Model::Callbacks 这个模块帮我们做了：

def self.included(base)
  base.class_eval do
    after_commit lambda { __elasticsearch__.index_document  },  on: :create
    after_commit lambda { __elasticsearch__.update_document },  on: :update
    after_commit lambda { __elasticsearch__.delete_document },  on: :destroy
  end
end

就是写操作的模块。

我们也可以这样做：

after_commit :create_es_index, on: :create

def create_es_index
  begin
    __elasticsearch__.index_document
  rescue => e
    hash = {}
    hash['article_id'] = self.id
    hash['time'] = Time.now
    hash['error'] = {}
    hash['error']['message']   = e.message
    hash['error']['backtrace'] = e.app_backtrace
    ErrorESMailer.send_error_email(hash).deliver  # send a error email
  end
end

这样，如果有回调的同步 ES 的操作有异常，则会捕获这个异常并且发送 error 的相关信息邮件给开发人员，开发人员可以及时的处理异常。同理 update 和 destroy 操作。

2. Model.import force:true

Article.import force:true

ES 会根据 Article 中 setting 和 mapping 的配置，在 ES 中构建 articles 的索引 (清空新建索引 + 导入数据)，对应的 type 为 article。

下面的三个操作，同样可以创建索引并导入数据

1. Article.__elasticsearch__.create_index! force: true  # 根据mapping和setting 创建articles索引，该索引没有任何数据
2. Article.__elasticsearch__.refresh_index!  # refresh 操作
3. Article.find_in_batches do |articles|   # 批量同步导入MySQL articles的数据
    Article.__elasticsearch__.client.bulk({
      index: 'articles',
      type: 'article',
      body: articles.map do |article|
        {index: {_id: article.id, data: article.as_indexed_json }}
      end
    })
   end

假设，你需要往 ES articles 索引中同步一批数据，这批数据已经被导入到了 MySQL 中，如果数据量不大，使用 import: true 的方法快速导入完。如果数据量比较大，导入耗时很多。还使用 import 的方式导入的话，会导致在 ES articles 被清空后，如果线上有用户在对 articles 的数据进行 ES 的搜索，很有可能会导致没有搜索结果。这时候，你可以使用上面的第三个操作，不需要重建整个 articles 索引。而是往 articles 索引中添加索引数据。

3. as_indexed_json

as_indexed_json 是一个很重要的方法。如果你明白了它，你就能知道 ES 索引中存的 documents 数据是怎样的。我们知道 ES 不是关系型数据库，ES 中的 documents 数据和 MongoDB 的 documents 类似，每个 document 是一个 json。所以，知道索引中 documents 数据存了哪些 fields，你才能更好地结合灵活多变的搜索条件和方式，构造多种多样的搜索情况。

下面我们看as_indexed_json 的源码：

# File 'lib/elasticsearch/model/serializing.rb', line 26
def as_indexed_json(options={})
  # TODO: Play with the `MyModel.indexes` method -- reject non-mapped attributes, `:as` options, etc
  self.as_json(options.merge root: false)
end

这里的 self 其实是 model 的一个 instance。我们可以在 model 中 monkey patch 这个方法。

# article.rb
class Article < ActiveRecord::Base
  include Elasticsearch::Model
  include Elasticsearch::Model::Callbacks
  index_name self.table_name  # 这里可以自定义Article的ES索引名称

  has_many :comments
  has_many :followers

  mapping do
    indexes :subject, type: 'multi_field' do
      indexes :raw, index: :not_analyzed
      indexes :tokenized, analyzer: 'ik'
    end
    indexes :content, type: :string, analyzer: 'ik'
    indexes :created_at, type: :date
  end 

  def as_indexed_json(options={})
    hash = as_json(
      except: [:update_at], 
      methods: [:parse_content],
      include: {
        comments: {only: [:id, :content]},
        followers: {only: [:id]}
      }
    )
    hash.merge!(other_hash)
    hash
  end

  def other_hash
    {title: "My title", owner: "My owner"}
  end

  def parse_content
    "Article: "+ self.content
  end
end

我们重写的as_indexed_json 方法构造了一个 hash 然后返回。except 表示排除某个字段，这个字段不会出现在 hash 的 key 中，methods 表示将某个方法作为 hash 的 key，对应的 value 就是该方法的返回值。include 表示会找相关联的表，并取定义的字段作为 hash 的 key，value 则为该字段的值。

这样，最后得到的 hash 大概是这样的，比如 Article.first.as_indexed_json:

{
  'id'=> 1,
  'subject' => '这是第一篇文章的主题',
  'content' => '这是第一篇文章的内容',
  'title' => 'My title',
  'owner' => 'My owner',
  'created_at' => 'Tue, 02 Aug 2016 20:40:08 CST +08:00'
  'parse_content' => 'Article: 这是第一篇文章的内容',
  'comments' => [{'id'=> 1, 'content'=> '点赞'},{'id'=> 2, 'content'=> 'good'}],
  'followers' => [{'id'=> 1},{'id'=> 2}]
}

通过这个事例，你应该能明白as_indexed_json 中可以如何构造想要的 hash 数据了。

在什么时候用到 as_indexed_json方法呢？

在 index_document 方法的源码中：

# File 'lib/elasticsearch/model/indexing.rb', line 333
def index_document(options={})
  document = self.as_indexed_json # Hi! I'm here!

  client.index(
    { index: index_name,
      type:  document_type,
      id:    self.id,
      body:  document }.merge(options)
  )
end

这样就明白了，当一个 model instance(一条记录) 从 MySQL 同步到 ES 的时候，将这条记录转为 hash 结构。其实，as_indexed_json 返回的这个 hash 就是 ES 对应的一条 document。这个过程就是：

MySQL one record => as_indexed_json => ES one document

现在我们明白了as_indexed_json，就可以根据自己的需要，往 ES 索引中存储 documents 数据了。并不是 ES 索引的 mapping field 只能和数据库对应表的字段一样，如果你什么都不做，ES 会用默认的配置帮你做这些事情。如果你想要存储更多的数据字段到 ES 的 document 中进行索引分词，你就需要自己动手做更多的自定义的配置。合理的 documents 数据是 ES 进行高效搜索功能的保证。

4. ES 的 mapping 只能增加

ES 的 mapping 一旦创建，只能增加字段，而不能修改已经 mapping 的字段。

client = Elasticsearch::Model.client
client.indices.put_mapping index: "articles", type: "article", body: {
  article: {
    properties: {
      organization: {
        properties: {
          id:   { type: :integer },
          name: { type: :string, index: :not_analyzed }
        }
      }
    }
  }
}

得到的 mappin 是：

"organization": {
  "properties": {
    "id": {
      "type": "integer"
      },
    "name": {
      "type": "string",
      "analyzer": "not_analyzed"
      }
    }
  }

上面的方法代码可以写成 rails 脚本，使用 rails runner 执行。也可以写成 rake 命令。然后，建议把新增的 mapping field 写在 Article 的 mapping 定义中。让 mapping 定义在代码层面保持显示最完整的定义结构。

5. 设置自定义的 analysis

什么是 analysis、analyzer、tokenizer 和 filter，如果不知道或者有遗忘了，请看ElasticSearch 的官方文档。官方文档描述的简单清晰，例子也易懂。

在上面的 Article 例子中，我们没有对 analysis 进行设置，这样，ES 会使用默认的 analysis 设置。但是，也许默认的设置并不是我们真正想要的 analysis。我们现在开始自定义 analysis。

# article.rb
class Article < ActiveRecord::Base
  include Elasticsearch::Model
  include Elasticsearch::Model::Callbacks
  index_name self.table_name  # 这里可以自定义Article的ES索引名称

  has_many :comments
  has_many :followers

  settings analysis:{
    analyzer: {
      my_custom_analyzer:{ type: 'custom', tokenizer: 'ngram_tokenizer'}
    },
    tokenizer: {
      ngram_tokenizer: { type: 'nGram', min_gram: 2, max_gram: 3, token_chars: ['lettler, 'digit', 'punctuation']}
    }
} do
    mapping do
      indexes :subject, type: 'multi_field' do
        indexes :raw, index: :not_analyzed
        indexes :tokenized, analyzer: 'ik'
      end
      indexes :content, type: :string, analyzer: 'ik'
      indexes :created_at, type: :date
    end 
  end

  def as_indexed_json(options={})
    hash = as_json(
      except: [:update_at], 
      methods: [:parse_content],
      include: {
        comments: {only: [:id, :content]},
        followers: {only: [:id]}
      }
    )
    hash.merge!(other_hash)
    hash
  end

  def other_hash
    {title: "My title", owner: "My owner"}
  end

  def parse_content
    "Article: "+ self.content
  end
end

自定义的主要代码是这部分：

settings analysis:{
    analyzer: {
      my_custom_analyzer:{ type: 'custom', tokenizer: 'ngram_tokenizer'}
    },
    tokenizer: {
      ngram_tokenizer: { type: 'nGram', min_gram: 2, max_gram: 3, token_chars: ['lettler, 'digit', 'punctuation']}
    }
}

这里你可能需要倒回来看，我们自定义定义了一个 tokenizer，取名为 ngram_tokenizer ，type 表示使用的 tokenizer。我们使用的是 ES built-in 的 nGram tokenizer ，具体配置参数请看它的文档。ES built-in 了不同的 tokenizer，开发人员可以自由选择使用。

我们还定义了一个 analyzer，取名为 my_custom_analyzer。type custom 表示这个 analyzer 是自定义的。使用了 ngram_tokenizer 这个 tokenizer。这时你应该发现了，我们使用的就是这里我们自定义的 ngram_tokenizer 。这里我们没有对 filter 进行自定义，看过 ES 文档的朋友，应该知道 filter 也是可以自定义的。

官方的示例：

PUT /my_index
{
    "settings": {
        "analysis": {
            "char_filter": { ... custom character filters ... },
            "tokenizer":   { ...    custom tokenizers     ... },
            "filter":      { ...   custom token filters   ... },
            "analyzer":    { ...    custom analyzers      ... }
        }
    }
}

ElasticSearch 确实是一个优秀的全文搜索引擎。了解和实践更多的 ElasticSearch 的设置和搜索，能够体会到 ElasticSearch 更多的功能。即使看过 ElasticSearch 入门教程的朋友，我觉得 ElasticSearch 的官方文档也是非常值得阅读的。

2017年不同的和 Ruby 和 Rails 有关的 conference

pathbox — Mon, 16 Jan 2017 16:30:22 +0800

这个网站 (友情链接) 列出了 2017 年已定的不同的和 Ruby 和 Rails 有关的 conference。去不了的，只好等 YouTube 视频了。。。

What Rails 5 has in store for you

pathbox — Mon, 09 May 2016 17:51:42 +0800

Take a look at what Rails 5 has in store for you. We go through all the new features and improvements across development, testing, caching and much more. So let's dive in.

YouTube超级链接

Resque vs. Sidekiq

pathbox — Thu, 25 Feb 2016 15:28:20 +0800

工作中 Resque 和 Sidekiq 都有用过，这几天突然想他们的优缺点是什么？然后 Google。发现了一个叫 Jeremy Green 的 coder 的比较全面的测试总结。连接在此 :超级链接。仅供参考

请教关于 find_each 的优化使用

pathbox — Mon, 22 Feb 2016 14:59:30 +0800

有一个需求，需要把表中 200w 左右的数据进行一次过滤。比如：过滤的方法是

def check
  xxx
end

每一条记录都需要调用一次过滤方法 check 不想一次把 200w 条记录取出来，预测对内存来说会是一个灾难。所以打算使用 find_each。由于过滤操作不是后台异步操作，所以在使用 find_each 时希望能快一些处理完然后在前台将满足条件的记录马上展示出来。

我先用了一个有 200w 左右数据的表在 rails console 中进行测试。

Benchmark.bm do |b|
   b.report("show") {TestOrder.find_each(batch_size: 1000).count}
end

#         user         system       total          real      单位是：秒
#  show   28.340000   1.200000    29.540000    ( 33.036628)

然后我增加了 batch_size 到 5000

#         user         system       total          real      单位是：秒
#  show   26.870000   0.840000    27.710000    ( 29.737033)

两次使用的时间差不多。batch_size 为 10000 时也是差不多。换成打印测试： batch_size 分别为 1000 和 10000

Benchmark.bm do |b|
   b.report("show") do  
       TestOrder.find_each(batch_size: 1000).each do |p|    
          puts p.id 
        end
    end
end

两次结果大约需要 50s。不能让用户等 20s 的时间，所以想请教是否有优化的方法，使 find_each 的效率更高呢？或者有其他更好的方法（除了异步的操作方法外）

在微信里看见的一个故事: 23 岁时这个女生从经济学转做程序媛

pathbox — Sun, 17 Jan 2016 12:35:14 +0800

这是在微信里看见的一个 23 岁时这个女生从经济学转做程序媛，感慨好深啊。搜了下 Spitfire Athlete，是一个女性健身和举重相关的内容项目，主页网站和 iOS 软件都已经不错了。文中作者从几乎 0 基础开始学编程，她的经历也许可以给好多新手 (包括我自己) 很多启示。请点击这里：文章内容链接

GitHub 秘籍

pathbox — Mon, 11 Jan 2016 11:47:11 +0800

Git 和 Github 秘籍，灵感来自于 Zach Holman 在 2012 年 Aloha Ruby Conference 和 2013 年 WDCNZ 上所做的演讲：Git and GitHub Secrets(slides) 和 More Git and GitHub Secrets(slides)。突然在 GitHub 上发现了这个。内容包括了:GitHub 的使用和 git 的使用，分享给大家。请点击链接：https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.zh-cn.md

谷歌浏览器 RailsPanel 插件

pathbox — Wed, 29 Jul 2015 11:50:23 +0800

看了 railscast 上的 better_error 的视频，里面介绍了 Rails_Panel 插件。对于请求的分析一目了然。觉得挺适合接触 rails 时间不长的开发人员或 rails 的前端开发人员。

better_error 视频链接

scan 和 split 的区别记录

pathbox — Wed, 22 Jul 2015 17:11:44 +0800

最近项目里出现了大量的 scan 方法。查看了下资料，明白了它的意思。 scan 是将满足条件（如正则表达式过滤后）的字符串返回到数组，split 是将满足条件的内容为分割点，将分割点左右两边的字符串返回到数组中。不知道这样理解是否有偏差 The output of String#split doesn't include the delimiter. Rather, everything except the delimiter would be returned in the output array, while the output of String#scan would only include what is matched by the delimiter.

A delimited string split on | returns everything surrounding the | delimiters

"a|delimited|string".split("|")

Prints: ["a", "delimited", "string"]

The same string scanninng for | only returns the matched |

"a|delimited|string".scan("|")

Prints: ["|", "|"]

Both of the above would also accept a regular expression in place of the simple string "|".

Split on everything between and including two t's

"a|delimited|string".split(/t.+t/)

Prints: ["a|delimi", "ring"]

Search for everything between and including two t's

"a|delimited|string".scan(/t.+t/)

Prints: ["ted|st"]

没法科学上网的时候如何使用 Google 搜索引擎

pathbox — Tue, 07 Jul 2015 16:57:07 +0800

我们都知道科学上网对于 ruby on rails 程序员来说是何等重要。我想大家都做好了科学上网的各种配置，但是也许会有无法科学上网的时候发生，虽然几率很小。最近朋友和我说了一种不能科学上网的时候使用 Google 的方法。在这里分享给大家。

首先打开这个网站 www.aol.com 对，这就是大名鼎鼎的美国在线（感兴趣可以搜索了解一下）。然后直接在网站的搜索栏上输入想要搜索的内容，美国在线使用的是 Google 的搜索引擎，也就是说，你也在使用 Google 搜索内容了。哈哈，美国在线没有被墙。不愧是美国最大的互联网提供商之一

关于 rails_admin 的看法。

pathbox — Fri, 12 Jun 2015 17:40:20 +0800

已经对 rails_admin 无力吐槽了。。。竟然出现了在本地 development 和 production 都正常的情况下，线上出现一句 select 查询语句不执行的情况。决定再也不碰 rails_admin 了。。。。。。（之前用这 rails_admin 的家伙离职了。。。）

关于 carrierwave 如何获取 original_filename 值感想

pathbox — Wed, 27 May 2015 15:29:33 +0800

近工作使用 carrierwave 做上传文件的功能。只是上传文件，比如 word 文件，txt 文件。然后需要有一个列表页面，需要显示上传的文件的名称。比如：上传了一个 goodrails.txt 的文件，需要在列表的第二列显示文件名称，即 goodrails.txt 要显示出来，让使用者日后查看时，知道上传了什么文件。在 carrierwave 中显示的上传文件名称会存储到 original_filename 中，所以思路就是拿到 original_filename 的值就行了。

carrierwave 中有一个

#def filename
#  "something.jpg" if original_filename
# end  方法，大家应该不陌生。就是自定义存入upload文件夹中的文件名称。比如在上传图片时，这样写
     (参考大神的文章 http://huacnlee.com/blog/carrierwave-upload-store-file-name-config/)
    def filename
        if original_filename
      @name ||= Digest::MD5.hexdigest(current_path)
      "#{@name}.#{file.extension}"
    end

通过查看后台传的参数，如 Processing by UpdateFilesController#create as HTML Parameters: {"utf8"=>"✓", "authenticity_token"=>"hGKDQsOQPBhpEyKDuLhOIOTNDGJ+VlZoNrLblcVNEl1cIXcTh+ePmy46G7ZdfUZlaUZJqsHcIG/ny4WTEo3MRw==", "update_file"=>{"name"=>"", "file_url"=>#, @original_filename="welcome.html.bak.erb", @content_type="application/octet-stream", @headers="Content-Disposition: form-data; name=\"update_file[file_url]\"; filename=\"welcome.html.bak.erb\"\r\nContent-Type: application/octet-stream\r\n">, "file_url_cache"=>""}, "commit"=>"提交"}

然后在 modle 写了一个 after_create 回调代码是这样的：

 class UpdateFile < ActiveRecord::Base
   mount_uploader :file_url, UpdatefileUploader
   after_create :save_filename

  def save_filename
     self.filename = self.file_url.get_original_filename
         self.save
  end
end

直接得到 original_filename，存到数据库表里，但是这样报了一个错误，private method `original_filename' called for #UpdatefileUploader:0x007fdbaddbfc00. original_filename 是私有方法。外部不能调用。好吧，和同事讨论后。决定在 updatefile-uploader。rb 文件中，写一个 public 的方法，去得到私有的 original-filename 这样

def get_original_filename
  return original_filename
end

然后在修改 model 中 after_create 的方法为

def save_filename
  self.filename = self.file_url.get_original_filename
  self.save
end

ok 顺利通过。从这个问题也学习到了，如果一个方法或变量是私有的，可以在那个类里面写一个 public 的方法来获得这个方法的返回值或变量供给外部调用。第一次发帖，经验不足，请大家指正。