breeze (breeze🐑)

关于数据库部份表做中英版本的探讨

breeze — Sun, 22 Apr 2018 22:10:35 +0800

欢迎大家来指出不好的地方

产品需求分析

用户账号体系不分中英文版本：在中文版本下注册的用户，在英文版本中也可以登录。
资讯类的数据做中英文两个版本：在中文版本中只有中文资讯，英文版本下只有英文资讯。

解决思路

一个数据库，用户表不分中英两张表。资讯类的表分中英两张表。
部署两个 rails 服务 (中英各一个)，在 initialization 中使 model table_name 映射到相应版本的表名。
通过 Nginx 根据自定义的 http 头识别中英版本的请求，转发到相应的 rails 服务。

具体代码

例如创建两个版本的帖子表：cn_topics 与 en_topics
创建一个名为 Topic 的 Model
在 config/initializers 中创建 map_multiversion_models.rb

MULTIVERSION_MODELS = %w(Topic).freeze

if ENV['CURRENT_LANG'] === 'CN'
  current_lang_prefix = 'cn'
else
  current_lang_prefix = 'en'
end

MULTIVERSION_MODELS.each do |t|
  t.safe_constantize.table_name = "#{current_lang_prefix}#{t.underscore.pluralize}"
end

nginx 的转发配置

upstream cn_production {
  server 192.168.1.11:3000;
}

upstream en_production {
  server 192.168.1.12:3000;
}

server {
  location / {
    if ($http_x_current_lang = 'cn') {
      proxy_pass http://cn_production;
      break;
    }

    if ($http_x_current_lang != 'cn') {
      proxy_pass http://en_production;
      break;
    }
  }
}

方案分析

数据隔离上通常有三种做法：数据库隔离、表隔离、元数据隔离。
- 数据库实例隔离不符合业务需求
- 元数据隔离方案会对正常业务代码造成污染，增加 lang 的字段来区别。
采用表隔离的方式，并用上面的解决方案
- 可以按正常的逻辑去写业务代码，避免了因为中英文版本问题对代码做兼容处理。
- 只需在环境变量中指定当前语言版本，即可同一套测试代码测试指定语言版本的业务代码

Puma 的线程数量与数据库连接池的关系

breeze — Wed, 07 Mar 2018 23:29:00 +0800

puma 是 rails5 的标配可是你知道 puma 的线程数与数据库连接池的关系吗？

当我们配置 rails 的时候应注意 puma 的线程数与数据库连接池数一致。

否则会出来一些奇怪的现象：

例如在并发大，但是在内存，cpu,mysql 压力不大的情况下，ruby 耗时特别的长。使用 Newrelic 与 ab 工具尝试了解项目的性能

例如得到一个错误：ActiveRecord::ConnectionTimeoutError (could not obtain a connection from the pool within 5.000 seconds (waited 5.002 seconds); all pooled connections were in use)

下面我们通过 connection_pool 的源码来了解一下

这里有着一个缓存，缓存着一个 conn, 这个 conn，在此次的请求中可以被使用任意次数。缓存不存在时，将从连接池中获取相应的 conn

#/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb#363
def connection
  @thread_cached_conns[connection_cache_key(Thread.current)] ||= checkout
end

#/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb#389

# If all connections are leased and the pool is at capacity (meaning the
# number of currently leased connections is greater than or equal to 
# size limit set), an ActiveRecord::ConnectionTimeoutError exception will be raised.
def checkout(checkout_timeout = @checkout_timeout)
  checkout_and_verify(acquire_connection(checkout_timeout))
end

获取 conn 的方式有以下三种，第一种是直接返回可用的 conn, 我们现在先关注第二种，尝试创建 conn，并控制着进程中所有的线程创建的连接数。

#/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb#706

# Acquire a connection by one of 1) immediately removing one
# from the queue of available connections, 2) creating a new
# connection if the pool is not at capacity, 3) waiting on the
# queue for a connection to become available.
def acquire_connection(checkout_timeout)
  if conn = @available.poll || try_to_checkout_new_connection
    conn
  else
    reap
    @available.poll(checkout_timeout)
  end
end

#/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb#739

# If the pool is not at a +@size+ limit, establish new connection. Connecting
# to the DB is done outside main synchronized section.
def try_to_checkout_new_connection
  # first in synchronized section check if establishing new conns is allowed
  # and increment @now_connecting, to prevent overstepping this pool's @size
  # constraint
  do_checkout = synchronize do
    if @threads_blocking_new_connections.zero? && (@connections.size + @now_connecting) < @size
      @now_connecting += 1
    end
  end
  if do_checkout
    begin
      conn = checkout_new_connection
    ensure
      synchronize do
        if conn
          adopt_connection(conn)
          # returned conn needs to be already leased
          conn.lease
        end
        @now_connecting -= 1
      end
    end
  end
end

当没有可用的 conns，并且也已经达到创建 conn 的上限时，该怎么办呢？这时就会等待使用中的 conns 的释放，等待超时了就会报错

#/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb#147
def poll(timeout = nil)
  synchronize { internal_poll(timeout) }
end

def internal_poll(timeout)
  no_wait_poll || (timeout && wait_poll(timeout))
end

def wait_poll(timeout)
  @num_waiting += 1

  t0 = Time.now
  elapsed = 0
  loop do
    @cond.wait(timeout - elapsed)

    return remove if any?

    elapsed = Time.now - t0
    if elapsed >= timeout
      msg = 'could not obtain a connection from the pool within %0.3f seconds (waited %0.3f seconds); all pooled connections were in use' %
        [timeout, elapsed]
      raise ConnectionTimeoutError, msg
    end
  end
ensure
  @num_waiting -= 1
end
end

总结

当使用多线程的 rails 服务器时，应当注意：连接池的数量与线程数量相同。
当连接池数小于线程数并且高负载时，某些线程会等待 conn 的释放，而影响访问速度与性能。具体情况可以查看该帖子：使用 Newrelic 与 ab 工具尝试了解项目的性能
当偶尔发生 ActiveRecord::ConnectionTimeoutError 错误时，请检查连接池数
puma 配置中默认线程是 0-16，数据库连接池默认是 5。可能大多人在并发高的时候都需要增加连接池。

使用 Newrelic 与 ab 工具尝试了解项目的性能

breeze — Thu, 13 Jul 2017 12:44:06 +0800

压测 1

服务器为 8 核 16g，使用 puma 开启 15 个 wokers
每秒 200 请求压测重度使用 mysql 的 api 接口

总结：

平均每个请求的时间都要 1.6s 以上，apdex 得分非常的低
ruby 占用时间为 60% 左右，mysql 占了将近 40%。
尝试通过提升服务器的配置性能到 12 核，puma 开多几个实例。效率还是很低，并没有与提升的配置成正比。

压测 2

在上一个压测中，ruby 占用的时间实在太多了，又没有解决思路，决定转变下压测条件。
使用 nginx 做负载均衡，性能好的服务器 weight 为 2，另一个 weight 为 1。
每一台服务器为 4 核 8g，使用 puma 开启 8 个 wokers
第二台服务器为 2 核 4g，使用 puma 开启 5 个 wokers
每秒 200 请求压测重度使用 mysql 的 api 接口

总结：

效率明显上升，apdex 得分看起来不错了
虽然效率上升了，但是 ruby 占用时间还是很高 (这个需要继续探索)
在服务器的配置比压测 1 的服务器配置差的情况下，既然效率会更高。这是负载均衡的功劳了，成功让对单台服务器的并发降了下来。
并发越高，服务器性能越差 (参考下面第二张图)。 * * *

压测 3

分析代码后，代码并没有可疑之处。可是为什么 ruby 占用时间那么高呢？
怀疑是在什么地方排队等候，花了时间。
在等 mysql？redis?
rails 中 mysql 默认连接池为 5，尝试压测不同数据的连接池。
为减少影响，使用单台服务器服务器为 4 核 8g，使用 puma 开启 8 个 wokers

总结：

5pool 的条件下：ruby 花费了 60% 的时间。
提升了 pool 之后：ruby 花费的时间降下来了，花了 20% 左右。
原来 ruby 花费了大部分的时间，是在等待 mysql 的连接池啊。
现在是 mysql 占用大部分的时间了，可以专心的优化 sql 之类的了

追加

之后尝试使用 gem 'connection_pool' 为 redis_store 增加了连接池，增加后没有什么变化。

求解 singleton_class, singleton_methods 的深入问题

breeze — Tue, 29 Nov 2016 17:51:45 +0800

环境：ruby2.3.2

问题：

为什么下面两者的 ancestors 差这么多，A 与 A.singleton_class 有哪些关联与不同？
与 A.ancestors 相比 A.singleton_class.ancestors 中 #<Class:A>, #<Class:Object>类似这些东西是什么？

class A
end

A.ancestors
# => [A, Object, Kernel, BasicObject]

A.singleton_class.ancestors
# => [#<Class:A>, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

问题：

为什么不是一个 singleton_class 也可以定义 singleton_method ?
现在可以推出，A 与 A.singleton_class 是完全不同的东西，那么 A.singleton_class 存在的意义是什么？

class A
  def self.say
    p 'say'
  end
end

A.singleton_methods
# => [:say]

A.singleton_class.singleton_methods
# => [:constants, :nesting]   方法中没有:say,这个可以理解，因为它的ancestors中没有A。

A.singleton_class?
#  => false

A.singleton_class.singleton_class?
#  => true

问题：

如果说 A.say 是一个 singleton_method，也是一个类方法，那么 a1.run 是一个 singleton_method，也是一个类方法？
类方法与 singleton_method 有什么关系与不同？

class A
  def self.say
    p 'say'
  end
end

A.singleton_methods
# => [:say]

a1 = A.new

def a1.run
  p 'run'
end

a1.singleton_methods
# => [:run]

问题：

#<Class:#<A:0x000000010ac200>> 这是什么东西？实例变量也是一个类？

class A
  def self.say
    p 'say'
  end
end

a1 = A.new
#  => #<A:0x000000010ac200>

a1.singleton_class.ancestors
#=> [#<Class:#<A:0x000000010ac200>>, A, Object, Kernel, BasicObject]

a1.singleton_class.singleton_methods
#  => [:say]  # 因为ancestor中有 A, 所以继承了:say方法

傻瓜是这么理解 has_one 与 belongs_to 的 primary_key, foreign_key

breeze — Fri, 30 Sep 2016 22:15:51 +0800

有人一直弄不清楚，has_one 与 belongs_to 的 primary_key 与 foreign_key 要如何设置。于是我就这么解释了！！！

首先讲 raIls 默认的规则：

class User < ApplicationRecord
  # 当user是主人时, dog是主人的附属品时,应这样设置
  has_one :dog
  has_one :dog, primary_key: :id, foreign_key: :user_id
  # 当我们没有定义任何的primary_key与 foreign_key时
  # rails会默认拿user的主键id 与 dog的外键user_id进行关联,即 primary_key: :id, foreign_key: :user_id
  # 为什么是拿dog的user_id进行关联,因为rails默认外键的规则是: 表名_主键
  # 所以以上两种定义是等价的
end

class Dog < ApplicationRecord

  # 以下两种定义也是等价的
  belongs_to :user
  belongs_to :user, primary_key: :id, foreign_key: :user_id 

  # 这时候,新人就会有疑问了,怎么两个model中的primary_key与foreign_key是一样的
  # 为什么不是默认设置成:
  belongs_to :user, primary_key: :id, foreign_key: :dog_id
end

因为规则是：谁是主人，primary_key 就是默认主人的主键，foreign_key 就是默认附属品的外键，所以不管是 has_one 还是 belongs_to 他们的主人都是 user。

当默认的 foreign_key 不存在时

class User < ApplicationRecord
=begin     表结构
+-----------+----------------------+------+-----+---------+----------------+
| Field     | Type                 | Null | Key | Default | Extra          |
+-----------+----------------------+------+-----+---------+----------------+
| id        | int(11) unsigned     | NO   | PRI | NULL    | auto_increment |
| name      | varchar(21)          | NO   | UNI |         |                |
+-----------+----------------------+------+-----+---------+----------------+
=end

  has_one :dog
  # 当遇到dog这张表中没有 user_id时
  # 如果使用以上关联,则会报错,因为dog表中没有rails默认外键 user_id

  # 此时,如果要成功建立关联,则需要手动指定外键
  # 当dog表中的外键字段是master_id,则需要这样设置:
  has_one :dog, foreign_key: :master_id

end

class Dog < ApplicationRecord
=begin    表结构
+-----------+----------------------+------+-----+---------+----------------+
| Field     | Type                 | Null | Key | Default | Extra          |
+-----------+----------------------+------+-----+---------+----------------+
| id        | int(11) unsigned     | NO   | PRI | NULL    | auto_increment |
| master_id | int(11) unsigned     | NO   | UNI |         |                |
+-----------+----------------------+------+-----+---------+----------------+
=end

  #同样的也需要指明foreign_key,否则通过默认规则会报错
  belongs_to :user, foreign_key: :master_id
end

Rails 5.0 API 模式中，如何在收到参数之前，就统一进行 xss 过滤？

breeze — Mon, 25 Jul 2016 21:04:31 +0800

如题。希望像 permit(健壮参数) 一样，不需要在后续的实际业务中关心参数过滤的问题