Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

关于定制化数据

  当一个产品的数据积累足够时就会考虑使用现有的数据做一些奇怪的事情。比如根据用户操作记录给猜用户喜欢什么,甚至针对每个用户显示转化率最高的内容。我觉得这种做法会是将来的趋势,然而也存在另一个问题。如何处理定制数据的缓存命中率?
  在一些餐厅吃饭时,招牌菜上的非常快,而一些冷门的菜则需要等很久。因为招牌菜总是可以卖完,所以厨房可能无视掉订单,持续不断地做着这道菜。而其它菜如果一个客人点了之后没要,被其它客人点中的概率就很低,那么就可能浪费掉。于是可以理解为,招牌菜的访问量大,缓存命中率高,所以上菜才快。
  这种招牌菜的模式是比较传统的。然而现代人讲究的是体验,是独立无二的服务,这是传统行业很难做到的。如今技术这么发达的时代,我们其实完全可以让程序智能地根据用户以往消费历史来定制用户最喜欢的菜单。但从另外的角度看,缓存确实会因此被削弱甚至彻底失效,服务器的负载会变得非常大,这正是我担心的点。
  由于这种定制化的数据是非常零碎的,我们就应该把传输粒度缩小到和业务需求相符的程度。比如搜索服务提供的数据粒度到某一张表的行级别,我们的传输就可以以这个行的粒度为单位。有了粒度规则之后要做的就是在各个端对这些数据粒子做适当缓存。其实就是这么简单的一个概念,但要真正实现好是很不容易的。
  下面是我的一套思路。在 Web 服务器端提供两个接口,一个是数据查询接口,一个是搜索接口。查询接口只负责查询数据库,不做其它复杂的业务处理;搜索接口只做搜索算法并返回结果的 ID 组,不占用多余的带宽。客户端首先会调用一次搜索接口,拿到 ID 组后再调用查询接口。虽然有点绕,但是这么做可以尽可能地在客户端避免冗余传输,可以粒子级地将数据缓存下来。
  然而这套思路有几个问题,首先是前端要同步地调用两次接口才可以拿到所需的数据,这会让首次访问变慢。当然也可以采取一些奇怪的手法来优化掉它,还算是个可以解决的问题。另一个大问题则是排序与分页,这也不算是这套方案的问题,而是「定制数据」这个概念的问题。搜索是个非幂等的接口,因为搜索这个行为可能被记录作为下一次搜索的参考。以同样的参数调用两次搜索接口是可能得到不同的结果的,所以这是个棘手的问题。最后如果再考虑筛选与排序的话,分页这个坑估计就没法搞了。
  前面这一坨东西也只是我一拍脑子想到的。也许有更好的实现方式,只是我还没来得及认真去思考吧。反正我觉得定制化数据会是将来的趋势,该解决的问题迟早都是要解决的。
网名:
54.211.148.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^