#9 楼 @lithium4010 因为读取单个缓存对象用 read 方法，读取多个用 read_multi 方法。

#7 楼 @jimrokliu 你可以试试 identity_cache identity_cache 有一个 fetch_multi 方法，可以一次获取多个 id 对应的 ActiveRecord 对象， ActiveRecord 的关联对象可以通过 cache_has_many 设置，它还提供 embed 选项把关联对象全部放置一起，貌似能解决你的问题。

#4 楼 @hooopo SLC 很酷！比较好的解决这个问题。

#3 楼 @victor “Russian Doll Caching”主要是为了避免嵌套缓存版本更新问题，因为 top-level 有一次整体的缓存读写，性能还是比较好的。我认为 http://guides.rubyonrails.org/caching_with_rails.html#fragment-caching 里介绍的例子有误导嫌疑，按上面的做法通常只能让性能更差。

#36 楼 @lips 因为公司重心已经转到移动 app 上，资源向 app 倾斜，而网站论坛运营特别耗精力，所以就停了。

#37 楼 @alex_marmot 欢迎啊，期待你的来信。

#34 楼 @lips 这不是 bug，网站上的论坛已经关闭了，网站本身已经很久没有更新了，现在重心都在移动 app 上。

#32 楼 @lips 多谢反馈，我们赶紧查一下。

#30 楼 @wskongdesheng 等着你的腹肌照，哈哈

#20 楼 @shangrenzhidao 嘿嘿，招聘不让上美女图片了，说是逼格不高，:(

感谢分享！非常棒！

#14 楼 @huobazi 来薄荷吧，包你能减，我给你找最好的减重顾问，哈哈。

#7 楼 @wskongdesheng 哇！瘦了这么多，可以上成功故事了。

#6 楼 @shangrenzhidao 欢迎来坐一坐啊。

#3 楼 @yujing_z 现在不给上美女照片了，今天我拍些公司办公室的照片放上去吧。

#1 楼 @lgn21st #2 楼 @lidashuang 感谢支持！

#104 楼 @hegwin 有没有兴趣来薄荷啊，不知道怎么联系你

#9 楼 @sleepless 七牛整理了一份文稿 http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=206678805&idx=1&sn=9927a61f037a3d57127cb933ff47e6d5&scene=2&from=timeline&isappinstalled=0#rd

#1 楼 @mimosa 好吧，放到百度云盘了，这是链接 http://pan.baidu.com/s/1qWqiuuS

#37 楼 @xiaoronglv #21 楼 @gene_wu ppt 放上去了 ruby 服务间通信模式 https://speakerdeck.com/xiewenwei/ruby-fu-wu-jian-tong-xin-mo-shi

#37 楼 @xiaoronglv 好，我今天稍微整理一下，再补充一些内容发出来，因为原来的 ppt 只适合讲演，作为独立文档还需要补充一些内容。

:plus1: proc 和 lambda 中 return 的不同是很容易让人迷惑的。

楼主应该是对 rails 爱恨交加吧，对第一条：rails 没有架构，个人持保留意见。

偶也是从 java 转到 ruby 的，相比于 java 很多架构起步就到引入庞大组件的做法，rails 是化架构于无形，让人可以十分简便高效的建立产品原型，完成早期项目开发。如果项目不能成长起来，早死早超生，这种做法最经济不过。如果项目能够成长起来（理性的看，这是凤毛麟角），为了处理各种复杂性，再引入各种处理复杂问题的方法不迟，比如剥离 service 层，比如微服务化等等。

不过还是觉得文章很赞，让人深入思考 rails 的一些利弊，里面提到很多东西也让人眼界大开，/强

#111 楼 @shangrenzhidao redis 使用比较广泛，首先用来异步任务队列的容器，比如 sidekiq 和 resque，然后是做一些性能高度相关的储存，比如计数器和最新排行什么的，最后是用来做缓存（取代 memcached）.

上面的方法不够好，用来设置 readonly 没有问题，但是想临时禁用 readonly，可以用下面的方法，直接上代码吧。

module ModelReadonly
  extend ActiveSupport::Concern

  included do
    enable_readonly
    before_destroy :can_not_destroy
  end

  def readonly?
    self.class.model_readonly?
  end

  def can_not_destroy
    if self.class.model_readonly?
      raise ActiveRecord::ReadOnlyRecord, 'data is readonly.'
    end
  end

  module ClassMethods 
    def enable_readonly
      @readonly = true
    end

    def disable_readonly
      @readonly = false
    end

    def model_readonly?
      @readonly
    end

    def without_readonly 
       old_value = @readonly
       @readonly = false
       begin
         yield
       ensure
         @readonly = old_value
       end 
    end
  end
end

class MyModel < ActiveRecord::Base
    include ModelReadonly
 end

 MyModel.without_readonly do
    # do something writing my_models table 
 end

ActvieRecord 里可以把 model 设置成 readonly 的，参考代码：

# Make model readonly

module ModelReadonly
  extend ActiveSupport::Concern

  included do
    before_destroy :can_not_destroy
  end

  def readonly?
    true
  end

  def can_not_destroy
    raise ActiveRecord::ReadOnlyRecord, 'data is readonly.'
  end  
end

class MyModel < ActiveRecord::Base
   include ModelReadonly
end

需要 打开写的时候，建立一个新的 model，写操作用这个新 WriteModel

class WriteModel < MyModel
    self.table_name = "my_models"
    def readonly?
      false
    end

    def can_not_destroy
    end
end

#4 楼 @jayliud 可以用 header 传 token，也可以用普通参数传 token，通常客户端登录成功后就一直保存这个 token（同时保存过期时间），每次请求的时候都带上 token。

大概是这样做，token 就相当于会话的 id，不过你提到的 token 生成机制貌似有缺陷，通过加密方式生成的话难以让 token 失效（过期），不如维护一个 token（user_id, token, expired_at）表，在登录的时候为会员生成 token，把会员 id 和 token 关联起来，另外存一个过期时间，通过时间控制 token 有效性。

#10 楼 @kgen 我们还没有尝试过，：）

没有这样用过，不过从 innodb 存储特性看，这种做法非常不可取，如果数据量很大，可能导致严重的性能问题，主要原因有：

1. innodb 的非主键索引都将存一个主键，uuid 相比整数 id，索引大小增加很多；
2. uuid 主键比较肯定比 整数慢，另外非主键索引查找最终还要引用一次主键查找；
3. innodb 主键索引和数据存储位置相关（簇类索引），uuid 主键可能会引起数据位置频繁变动，严重影响性能。