#4 楼 @huacnlee 感谢指教。

学习了一下 second_level_cache, data service 的确做了一些和 second_level_cache 类似的事情，场景的区别主要因为我们前后端项目分离后，Write-Through 在 ruby, Read-Through 需要在 node 端发起. 在单体 ruby 项目中 SecondLevelCache 是个非常不错的选择！

不过有些场景还是不能容忍数据在缓存中 miss 后再去触发生成，这个节点容易造成 5XX, data service 主要就是加强缓存异步刷新，在 redis 数据没有 expire 之前去刷新数据。

#5 楼 @i5ting 感谢指教. 这里和直接 RPC 还是有点区别，在文中的最后一张图「周内 TP 变化情况」, 该页面是在 22 号之前很多数据是走的 http/thrift RPC, 22 号之前的很多不可用 (超时/5XX) 都是因为 RPC 调用偶尔的失败导致，而 22 后接入了 data service 后，基本保证所有数据在 redis 中都有，基本不会发生 miss 的情况，页面很稳定。

对比 RPC 封装缓存和 data service 采用的异步更新，忘了哪里看来的比喻还挺形象的：

1. 发现缓存过期时，线程都去获取并更新缓存，容易引发雪崩，5XX 的原因：

   5 个工人（线程）去港口取同样 Key 的货（get），发现货已经过期被扔掉了，这时 5 个工人各自分别去对岸取新货，然后返回

2. 异步更新数据：

   5 个工人（线程）去港口取同样 Key 的货（get）, 货一直存在，即使货过期了也不会扔掉 (很长的有效期). 但港口的货物还是比较新鲜，因为对岸有个家伙在不时更新着货物，这个家伙在 data service 中就是 ruby 端的 after_commit 或者定时 rake

#1 楼 @huacnlee 看了代码，目前的确是用的after_commit 感谢提醒~ 稍后更新文档。

1) 数据更新有 2 种途径：

对于需要实时更新的数据，使用after_commit+sidekiq , 只是稍微进行了封装，调用方式形如：Monitor.watch(Product, SomeSidekiqWorker, :title, :price) 会给 Product 加上after_commit, after_commit中判断如果 title 或 price 有变化，会扔到 sidekiq 中更新. 对于旧数据有一定容忍度的业务，采用 rake 定时更新。

2) 缓存存储前面需要有一个应用服务，两者都可能成为瓶颈，Redis 自然高效，应用服务使用 node 的好处之一在于异步 IO:

let data = yield {
  '商品':  dataService.fetch(...),
  '广告':  dataService.fetch(...),
  '友情链接': dataService.fetch(...),
}

dataService.fetch返回的是 promise, 3 次 IO 的时间为：max(查商品时间，查广告时间，查友链时间)

如果采用阻塞 IO 的实现，时间将是：查商品时间 + 查广告时间 + 查友链时间

3) 缓存时间是各模型必须设置的，是在 redis cluster 中的缓存时间，我们有用 varnish 作为反向代理，主要用于页面缓存。

Data Service 的目的在于管理那些可缓存的数据，Data Service 提供的数据，前端在 Node 中还可能进行加工再展示，这也是之前引入 node 的一个原因--前端希望管理 view 层。

另外不同页面的 Data Service 数据可以在 node 端方便的组合，比如很多页面都需要「友情链接」的数据，在 Data Service 中只需要存一份。

采用 redis 的另一个原因是可以比较容易的进行分布式扩展，可选哨兵 + 主从或者 cluster.

#16 楼 @killernova 2 个 puts 之间其实有 200 多行代码，篇幅原因，在文章中省略掉了中间代码。当时是希望通过 singleton_methods 去判断类方法是否加上了，意外发现了第二个 puts 没有输出。

信渊格格，得永生