你现在的位置： >
> 淘宝天猫搜索引擎昨日任性瘫痪
淘宝天猫搜索引擎昨日任性瘫痪
来源：中国鞋网/半岛晨报
中国鞋网 xz.cn/
| 浏览（3978）
&&&【中国鞋网-电商频道】昨日上午11点左右，微博上多名网友发现淘宝天猫搜索引擎忽然任性起来，瘫痪半小时有余，这是继前日微信坏掉之后，又一电商渠道中招，不知道赖以生存的电商服企们是否心有疑虑，但是任性在这时间就是金钱的时代，恐怕有些商家要头疼了。11点15分，搜索引擎服务恢复正常，截至记者发稿时，对于此次服务异常一事淘宝官方并未给出回复。
　　昨日上午10点50分左右，有网友致电本报，淘宝、天猫搜索功能均陷入崩溃，无论是pc端还是手机端都无法正常显示搜索结果，除了买家外，卖家店铺产品的列表也无法显示。记者尝试登录淘宝和天猫网站，随机搜索商品时，均出现“商品加载失败”“没找到相关产品”等字样。截至11点15分，搜索引擎服务恢复正常。记者推算，此次搜索引擎瘫痪时间至少在半小时。对此，有网友猜测，或许只是小范围出现的搜索瘫痪。也有网友猜测由于与12306合作导致了网站服务器运载超时。
　　随后，记者拨打了淘宝的官方热线，一位客服人员表示，这种情况很有可能是访问的会员太多，引发系统故障造成。据记者了解，日，天猫的搜索页面曾突然出现异常情况，向搜索对话框内输入任何商品名称，均显示“没有找到”，导致不少网友抢购失败。不过，目前并非“双11”或“双12”购物高峰，那么为何出现网站崩溃问题，截至记者发稿时，淘宝官方尚未对此事做出声明。
　　相关链接
　　1月17日，阿里首次承认确实在和铁道部订票网站12306开展云合作。据了解，12306与淘宝、天猫的后台是两种系统，所以对接12306的业务复杂度更高。
　　据此前数据显示：海量的火车票查询，正是影响12306性能的重要原因之一，大概占了90%以上的访问流量。由于波峰和波谷间的车票查询差异，让后台系统无法在成本和并发能力上找到一个平衡，所以才会出现12306被买到“瘫痪”的状态。（中国鞋网-最权威最专业的鞋业资讯中心。合作媒体：&）
欢迎品牌、企业及个人投稿，投稿请Email至：
相关报道：
| 浏览（3978）
你好，请你先登录或者注册!!!
文明上网理性发言，评论仅供其表达个人看法，并不表明中国鞋网立场。
热门鞋业专区淘宝搜索技术总监鬼脚七搜索引擎原理
一、搜索排序相关因素
（16:04:21）：
宝贝搜索上，有两种主要的排序方式，人气排序和所有宝贝排序。目前主要是默认所有宝贝排序。所有排序中还有按照价格从低到高、从高到低排序、销量排序、信用从高到低排序的选项，这些排序的原则也很明确，基本上是按照选项来的。
（16:04:53）：
接下来主要讲下所有宝贝排序、人气排序的影响因素。
（16:06:19）：
所有宝贝排序，与之相关的因素主要有：相关性（标题相关性、类目相关性）、卖家服务质量（退款率、纠纷退款率、是否做作弊卖家）、橱窗推荐、下架时间
（16:07:35）：
相关性是基础
，每个排序维度都会有这个因素，并且权重较大；相关性包含了你的标题与用户搜索的关键词是否相关，你宝贝放的类目与用户搜索的意图是否相关。&
（16:08:51）：
例如：搜索"篮球",
最相关的应该就是"篮球"的商品，其次才会是篮球鞋、篮球服等商品。
（16:10:05）：
所以大家一定要重视标题。标题如何描述一方面会影响相关性，另一方面也会影响用户体验。有些卖家为了让宝贝被找到，标题堆砌一堆不相关的品牌或其他关键词，其实这是会被降权的。
（16:13:12）：
人气排序，不是大家理解的销量越高就越排前。
（16:14:28）：
实际上也有很多因素在影响：相关性（标题相关性、类目相关性）、交易量、转化率、收藏量、回头客等。
交易量是其中一个因素，并且并不是说一个销量几千的宝贝就一定要把销量几百的宝贝好很多，如果其他方面做的不好，那也可能是要排后面的。
（16:16:43）：
不是只有大卖家才能有较高的人气分。
（16:17:56）：
人气分的计算：店铺信誉的权重很低，目前人气排序结果里，不少排序靠前的也是中小卖家的宝贝。只是大卖家累计客户多，比中小卖家更容易培养出来人气宝贝。
现在搜索结果页里有个规则限制，每页最多显示同一卖家的两款宝贝，如果同一卖家有更多优秀宝贝，会显示到下一页开始。
二、搜索违规规则解读
主讲：资深小二（扬溢）
（16:21:08）：
几种作弊的处理方式：
搜索降权--所有宝贝、人气排序下排名靠后、单一维度不展示；
2. 搜索屏蔽--所有维度不展示；
单一维度搜索过滤--不影响所有宝贝、人气排序，只在某个单一维度下不展示（比如价格排序过滤只影响价格排序）。
（16:21:34）：
这是几个基本的概念一定要搞清楚，这和你后续如何处理非常相关。
下面说一下宝贝被降权后的处理办法。
（16:22:35）：
最好不要通过作弊类型去判断自己被降权的商品是应该进行一定的整改还是选择直接删除。
首先宝贝被降权只会影响宝贝在搜索的排名，对宝贝其他的状态不会产生影响，所以要结合宝贝和店铺的具体情况决定等待降权结束还是删
其次有一部分降权是整改后就可以在3到5个工作日内自动恢复的，这部分降权往往是一些修改后就不会对搜索体验产生持续性影响
的，比如标题滥用、类目错放、价格作弊等，改过来了就是改过来了。
（16:23:55）：
PS:这个是否产生持续性影响非常关键
有些降权就算再怎么改也是无法在短时间内自动恢复的，因为有
些行为是无论你怎么修改都会在一定的时间内（比如30天）对线上的搜索体验带来持续性的影响的，比如虚假交易、换宝贝等，这些降权就
更建议进行删除了。
（16:25:15）：
抓住这一点进行判断保证没错，因为有时候就算是同样的作弊类型不同的情况相应的处理方式会有不同。比如SKU作弊。
（16:26:14）：
宝贝是一个手机 但是卖家在设置SKU时，放了一个充电器上去
,并且以充电器的价格作为一口价发布，这是一种SKU价格作弊。
但是，如果这个充电器产生过销量的话，这个宝贝就不适合进行修改了。
（16:27:19）：
因为充电器的销量累积在了这个手机的销量中，也就是这个手机的销量是不准确的，这就是产生了持续性的影响了。
但是如果充电器没有产生过销量
那把充电器的SKU去掉，以手机的价格作为商品一口价，过两天就会自动恢复。
（16:28:58）：&
OK,因为时间有限
最后说一下目前虚假交易处理方法和力度：
①一般搜索的处理还是还是以宝贝维度的搜索降权为主；
②对于一些非常恶劣的卖家（长期、多次、大量）我们会进行全店降权30天的处理，同时会将这部分卖家转交到其他的相关部门，根据情节
严重程度进行处罚，最严重的会进行48分的炒信处罚，这也是在帮派里看到的TOP200、TOP500这些；
③对于一些在刷钻网站炒作的卖家，我们会定期进行一些专项的打击，处理方式也是全店降权；
④部分被判定为虚假交易的宝贝可能会失去直通车资格。
三、申诉的具体操作
主讲：资深客服小二无寒
（16:31:39）：&
今天为大家讲下申诉的具体操作，
在接听电话的过程当中，经常会员发现会员在进行虚假交易申诉的过程中因申诉凭证不齐全的问题而多次来电，多多少少会影响到会员的商品申诉时间。这次对于申诉的流程做一个整理，希望能帮助到大家更快的去做申诉。
（16:32:45）：&
首先商品ID，每个商品都有自己唯一的编码，这个编码就在链接上：商品链接网址后的11位ID数字。这个数字大有用处，只要是涉及到单个商品的问题，只要把商品ID告诉到我们的客服工作人员我们就可以帮助核实相应的原因。
（16:33:40）：&
其次举证编号的提取：打开和买家的对话框后按键盘上的F8,会出来消息管理器！
按照截图上的显示来提取到，
这样我们的工作人员就能核实买卖双方的聊天信息。
（16:34:48）：&
但是要注意哦卖家昵称是要聊天的人是谁，子账户也是可以的。
（16:36:00）：&
同时继续添加的按钮是很重要的，
这个东东可以出来5个的，以为一个ID只能申诉一次的，所以一定一定要点它…
如果买家比较多的那可以在接下去的申诉理由中写入相应的信息了，这个就是一个完整的表单页面了。
（16:37:06）：&
在上传凭证的入口也是一样的，一共可以出10个入口。要是物流底单比较多的，那尝试下把物流底单放排起来，拍成一张尝试。但是凭证的齐全对于申诉是很重要的哦！
（16:39:41）：&
所有的凭证都添加完成了，那咱们就可以点击提交了，很多会员会担心说自己没有提交成功而来电，其实有地方可以查哦！
不用担心的，在"卖家中心-客户服务-咨询回复"中我们可以查看到我们提交的凭证，和工作人员的处理进度。
（16:41:15）：&
一般建议您关注7个工作日，当然，目前的速度还是比较客观的，还很不错的，嘿嘿！
当然申诉后大家可以关注下站内信、邮件和旺旺提醒的最后结果的。
（16:42:33）：&
最后提醒到大家的是每次大家从客服工作人员获取的申诉路径的有效时间是24小时，若24小时内未有及时申诉的，是需要再次来电获取申诉路径的。
如果不小心把系统信息关闭的，那一定可以通过站内信找到相应的信息的。
（16:43:25）：&
淘宝网登录的状态下，左上角，会员名后就有"站内信"了哦！
好了，时间也差不多了，先到这吧。
四、卖家经验分享
主讲：喜悦
喜悦运动专营店
（16:46:58）：&
很高兴能跟大家讨论下服务理念的问题，这是我们一直努力在做的，但是也有很多不足，我们也正在改进。
喜悦运动专营店
（16:48:16）：&
服务体系现在已经关系到我们的店铺排名和流量搜索，这是为什么我们要在群里交流这个问题的原因。
喜悦运动专营店
（16:49:19）：&
我们就简单从我们现在做的方面先跟大家讨论下：
第一，我们要打造我们的特色服务
喜悦运动专营店
（16:51:53）：
我们客服中心的特色，如貂蝉，我们就可以对任何一个过来的客户称呼一声施需要什么东西
这样的话给顾客一种独特的购物体验；
我们在打包发货的时候，我们在每一个包裹都会精心的包装，让客户感觉到我们的用心，每一个客户我们都会送上一份惊喜；
第二、售后回访，我们会定期去随机抽选一些客户进行回访，了解客户的需求，看下客户对我们的产品和服务的意见
这样既能留住一些客户，还能增加客户的购物体验从而更好的去服务客户；
我们淘宝不像实体店铺，可以跟客户面对面的交流，所以我们要跟客户之间建立一种关系，就是诚心和信任。
喜悦运动专营店
（16:56:26）：&
我们为客服规定了旺旺响应时间和旺旺响应率。
我们会对我们的客服定期的进行考核，包括专业知识和服务态度。
第六 如果客户收到商品有任何问题 我们都会通过电话去联系客户
去沟通 ，这样能增加我们跟客户之间的信任。售后问题及时处理，让客户满意，就能帮我们增加很多回头客 我们要让客户听到我们的声音
感觉到我们的诚意。
喜悦运动专营店
（17:00:16）：&
谢谢大家 以后有什么更好的提升服务的理念
大家多多交流
五、重量级神秘嘉宾部门负责人（鬼脚七）鬼老师出场
（17:01:31）：
谢谢大家。很惭愧好久没有到这个群里来跟大家分享了，不过我经常在这里看大家聊天的…
（17:02:33）：&
年底了，给大家汇报一下搜索的工作：
搜索今年的流量增长大约有50%左右，大家可以参考一下自己店铺的比例，
（17:05:23）：&
以前有个数据，在我微博上发过淘宝不同类目的搜索流量占比，大家可以对照一下。
另外一个说明：在量子统计中有个来源：类目。
以前这部分是list的流量，这个比例和搜索比例应该是1:3左右。去年是1:2.
（17:06:59）：&
在产品上，搜索今年在垂直化、个性化上都做了很多尝试，明年会大做。
会根据不同的人，出现不同的结果，大家优化的难度会更大一些。但是有个捷径来优化，就是维护好你现有的客户，因为我们算法中会根据兴趣、偏好、历史来做个性化，如果你现有客户维护的好，会对你很有利。
关于一淘，大家可以开始做一些关注了。
（17:09:06）：
现在流量增长比较快，在收录规则上，也已经公布了。不同行业不一样。
（17:10:25）：&
总体来说：除了那些有作弊的卖家，商城的大部分商品会收录；集市的优质商品会收录。
这里回答一些之前管理员收集的问题：
搜索排名是否会出现异常！比如系统监管等！
搜索排名一般不会有剧烈的变化，但例如打假、知识产权、一些外部报道某些商品不合格，会做过滤。当然偶尔会有系统bug,但这种情况我们控制在0.01%以下。
影响排名异常的问题有哪些方面？同时建议买家应怎样避免排名异常的现象？
有些排名异常是有可能的，可能的原因：
现在每周在线上都有几套算法在测试，例如：排序优化、类目垂直化优化、个性化优化等。如果你自己的落在了某个比例中，那么和之前会有不同。
有可能是被识别你的服务质量或者作弊嫌疑比较严重。
对于第一种，关系不大，只要整体的流量没有大的变化就可以了。对于第二种，绝大部分你通过诊断助手是可以看出来的。尽量保证你自己的交易和商品，都是正常的。不要出现太多的特殊情况，搞得跟作弊很像。
例如（一款宝贝原先销量与排名都很好，间隔一天的时间、现在搜索的排名就基于原先（第一页前十）的排名，现一直出现在搜索排名第二页的位置（销量，人气，收藏）一直都很好！请问是什么原因呢？这种情况是否为排名异常的现象、是否属于正常现象、要怎样解决这种现象？
这种排名出现一页两页的，都是正常的。如果是搜索降权，肯定会下降很多的。时间因素，其他商品的因素，季节因素都会有影响。
大家经常会问我一些优化的问题，说以前在第一页，后来到第4页了，怎么才能回去？
这类问题我真的没法回答……而且我们是裁判，不能做教练。
鬼脚七的微博说，这个月主图也列为搜索时考核的内容了，请问首图有什么具体的要求吗，打有促销文字的会降权吗？相床上用品的全图是图片内容的怎么来考核呢？首图背景一定要为
白色吗？可以用图案背景吗？可以打促销标签吗？
这个月在一淘的一些类目已经上线，在淘宝的一些类目也在线上测试。正式上线之前，会做大面积宣告的。 -
要求就是，主图最好干净一点，什么背景无所谓，别写促销文字和促销信息。
问题5:.当店铺转行后，全店的经营类目发生变化，会地全店降权吗？我现有一4钻的店转行，类目全变了。一天只有30多个PV.
类目发生变化，不会全店降权。&
但是现在的店铺服务质量，是已经按照类目来计算的，会考虑你的主营行业。所以你跟那个开始转型的时候，你在这个行业的质量分还没有积累起来，排序自然就会比别人做得很久的低一些。
问题6:标题30个字，内容相似度降权的标准是多少？&
关键看你有没有堆积关键词、品牌词等等。而且标题是有中心词识别的，就像遥遥先提到的相关性。如果不是中心词，写再多也是白搭…
问题7:.用主图5张的第2.3.4.5任何一张换位第一张图片，会降权吗？
- 从我目前了解来看，不会降权。
问题8:如何运用淘宝搜索所采用的中文分词方法，对宝贝标题进行优化？（请以"单肩包"这个关键词搜索到的人气排序Top1的这款产品举例：id=）
这是个好问题，如果细心的卖家，应该已经发现，现在淘宝搜索已经把中文分词的因素考虑进去了。
我没来得及看这个id啊，但告诉大家的是，如果你想让别人通过"童鞋"找到你的宝贝，最好能把这两个字连在一起。
问题9:虚拟转实物卖家，虚拟占比影响搜索排名问题
这个问题和类目转换差不多，现状都是按照主营类目来算，任何变化都有一定成本，相对公平一点。
今天讲的内容可以好好消化，我们也非常欢迎希望通过这个平台跟其他卖家分享的比较有经验的卖家朋友，其实这些经验才是干货。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。　　多年以来，主搜索的集群架构和排序算法相对比较单一，一定程度上制约了搜索业务的发展。本文主要介绍主搜索最新采用的索引分层技术。这种分层技术把主搜索集群架构从二维扩展到了三维。基于这种三维的新架构，主搜索可以根据不同的应用场景，选择不同的检索和排序算法，从而更好的提升主搜索的检索性能与检索效果。实践表明，这种分层技术能提升主搜索120%的检索性能和6%的搜索GMV。
主搜索多年以来一直采用二维集群架构来提供淘宝网商品的检索服务，其结构如图 1所示。主要的检索流程如下：
step 1. SP向QRS提交查询请求，QRS根据查询内容和Searcher的状态信息动态选择出一行searcher机器，把查询转发到这些searcher机器上进行检索。每个searcher只包含部分商品的索引，而被选择出的一行searcher则包含一个完整商品的索引。
step 2. Searcher机器根据查询，在索引的商品中检索符合查询串的商品,并对这些商品进行排序后返回top-k结果给QRS。Searcher机器之间查询是并行的处理，各searcher使用的检索与排序算法都一样。
step 3. QRS根据一定的规则对searcher返回的结果进行合并和排序，然后返回top-k’结果给SP。
图1. 主搜索集群二维结构示意图
　　这种二维结构的集群架构和在这基础上的检索流程主要有以下几个问题：
集群需要的机器多。目前主搜索需索引的商品数量近10亿。在一定的查询响应时间下，单机的索引量非常有限。例如单机索引4000万商品，那就需要25台机器才能索引完整的商品数据。为了达到一定的服务规模，需要的行数也会特别多。如果单行的服务能力为1000QPS，那么在10万QPS的压力下，需要100行，共2500台searcher机器。
查询范围大，检索效率相对较低。QRS挑出的一行searcher索引了完整的商品数据。在这完整的商品中，与查询相关的商品可能有上百万个，而QRS最终只返回几十条最相关的结果给用户。因此绝大部分的商品是对查询结果没有用的，而对这些相关性小的商品的检索降低了检索的效率。主搜索中存在大量的冷门商品，它们与绝大部分的查询都不相关，索引和检索这些冷门商品都会浪费一定的资源。
支持索引结构单一，可使用检索优化方法较少。因为各个searcher中索引的结构是一致的，一旦采用了一种全局序索引优化就难再使用其它的全局序优化。 单一的全局序优化虽然能提升针对这种按全局序排序的查询性能,但对其它类型的排序就会有损害。在未做分层优化之前，主搜索的索引一直采用按商品下架时间（END_TIME）全局排序后进行索引。它对按END_TIME排序的查询能提升不少性能，但对按人气或销量排序的查询就非常低效。
对检索和排序的多样性支持并不友好。例如最终查询结果可能需要包含部分销量高的商品，部分相关性好的商品还需要照顾展示商品的多样性。基于这种结构需要多次完整查询才能得到结果，从而制约了相关性选择算法的问题空间。
显然，上述的问题对主搜索引擎都是致命的，它从一定程度上限制了主搜索的规模以及与搜索相关的业务发展，急需要一种新的方法来解决或缓解上述的问题。
2. 相关知识
在介绍主搜索具体的分层优化方法之前，我们先简单介绍一下搜索引擎中常用优化技术—索引剪枝（又称索引截断）。因为主搜索中使用三维集群架构，以及在些架构上采用的检索方法都是这些基础索引截断技术的演化版。通常索引截断可分为静态索引截断和动态索引截断：在静态索引截断中，以下三种方法比较常用：
根据文档静态质量分把文档划分成多个类别。例如在全网搜索中根据网页质量可把网页划分成正常网页和垃圾网页，同样主搜索中根据商品销量等可把商品划分成热门商品和冷门商品。这样我们就可以针对不同类别文档应用不同的索引结构和检索策略以便更高效的进行大规模的文档索引与检索。
根据每个索引词出现的文档按特定的特征对这些文档进行筛选。这个特征可以是文档的全局特征，也可以是term-doc的特征。例如在全网搜索中可以根据BM25分数挑出与索引词相关性程度较高的文档单独建成一个倒排链。在主搜索中可以根据商品的质量挑出与这个索引词最相关的高质量商品单独建倒排链。在搜索时，我们可以优先使用这个截断链快迅的找到与这个词最相关或最热门的文档。
根据文档中每个词的特性挑选出最能代表文档内容的词来代替全文内容，以减少索引量。例如，主搜索中的每个商品只挑选商品标题和SKU中的词进入索引，以减少倒排索引的大小或减少引入不相关的内容。
动态索引剪枝的技术比较多，但其剪枝算法通常与排序模型相关。多阶段的检索与排序是目前比较常用的方法。这种方法把文档的查询与排序划分成多个阶段，越靠前的阶段计算单个文档相关性所需的时间越少，但找出的文档越多；越后的阶段计算单个文档相关性所需要的时间越多，找到的文档越少。 主搜索一直使用二阶段排序模型来优化检索的性能。第一阶段商品的海选，先前主搜索默认按商品的下架时间海选出数万个最近会下架的商品。这主要是为了照顾快下架的商品有更多的展示机会。这些选出的商品不区分质量，只匹配查询词。第二阶段商品的精选阶段，对海选出的商品利用相关性等各种特征计算最匹配几十条商品返回给用户。二阶段的排序模型给主搜索带来的很大的性能提升，但由于后面阶段的输入依赖于前面阶段的输出。例如第一阶段输出的商品质量不高，则直接影响第二阶段的排序效果。所以主搜索为了保证二阶段的商品输入的质量，从一阶段中挑选了数千个文档给二阶段排序，但这些输入的文档绝大部分最终没有返回。
3. 分层优化
3.1 辅链优化
主搜索先前采用的二维结构比较直观，也容易理解，但它很难满足检索性能与排序多样性的需求。主搜索的流量组成非常多样化，有来自网页、无线和各种应用的请求。在这些请求中，包含各种各样的商品排序需要，其中按人气排序和按END_TIME在主搜索查询流量中占比最大，它们分别是无线搜索与网页搜索的默认排序方式。 为了更快的支持END_TIME排序的查询处理速度，主搜索的索引一直按END_TIME全局序排序。当索引全局按END_TIME有序，就能通过二分查找快速的定位到满足查询条件商品的开始位置，可以略过很多相关但不符END_TIME的商品。但因为第一阶段的排序不包含其它信息，所以找出的文档质量参差不齐，因此需要找较多的文档给第二阶段的排序才能挑选出合适的商品给用户。
按人气排序的查询显然不能利用END_TIME排序的索引优化，所以它只能从前到后找人气高的并符合查询条件的商品。这种按人气排序的查询在一阶段选出的商品人气分很高，通常人手高的商品质量也比较好，所以二阶段只需要对少量的商品进行重排序即可找到非常相关的文档。但由于索引的商品按END_TIME排序，人气高的相关商品就会随机的出现索引的不同位置，所以在第一阶段需要查找的文档数量会比较多。 针对这个问题，主搜索目前使用人气辅链（截断链）来加速查询。人气辅链构建过程如下：&
流量是互联网变现的基石，而流量的资源是有限的，如何实现资源的最大化利用（买家-商品的最高效的匹配）是此次双11搜索技术深度切入的使命，也是第一次在双11通过实时把握资源流动的脉搏来控制资源的收和放。
天猫的业务团队同学，通过针对去年双11细致认真的数据分析，发现了去年双11暴露的一些问题。 预热期
小部分商品预热过度，预热期吸引的加购量远超出商品库存能支撑的量，大部分用户虽然加了购物车但当天也抢不到，购物车转化率低；而大部分商品预热不足，没有充分曝光；
活动期间商品的加购行为和历史行为差别巨大，离线（ T-1）天的数据无法真实反映商品的实时受欢迎程度；
即将售罄的热销商品仍然获得了大量流量，剩余库存无法支撑短时间内的大用户量；主售款（热销 sku）卖完的商品获得了流量，用户无法买到商品热销的 sku，转换率低;
和预热期一样，活动期间，商品离线（ T-1）天的数据无法真实反映商品的实时的受欢迎程度;
二、问题解决
问题是很明显了，那么如何来解决呢？总体来看，无论是预热期还是双11当天，就是要降低资源（流量）浪费和提升资源（流量）利用率。
降低流量浪费层面，首先来看预热期，就是如何避免一个商品由于过度曝光（pv），使得加购总量所能带来的潜在成交笔数超出其库存，导致大量交消费者即使加购，当天也无法下单； 那我们就要建立一个合理调控商品展示的机制来实现。我们根据一个商品的长期，实时的加购历史，预测出它在双11当天能够拿到的成交量，当成交笔数超出该商品的库存承受能力时，降权分将会在商品排序中发挥作用，来减少该商品的曝光机会，通过有效的流量引导来减缓该商品的加购，从而减少无效加购的总量，提高双11当天购物车的转化率。
接着来看看双11当天，理性和非理性消费者的购物欲望都在这一天得以释放，流量暴增， 如果一个商品即将销售一空却仍然获取大量的曝光和点击，带来的体验必然是很多消费者铩羽而归，同时浪费了宝贵的流量资源。如何来避免呢？同预热期一样，我们要建立一个合理的商品展示调控机制，我们根据商品的成交记录，预测出商品销售速度，这样根据商品的剩余库存除以销售速度，就能预判出该商品从当前时刻起还有多少时间就会售罄； 系统可以根据即将售罄的时间长短建立不同粒度的降权分，从而有效的调节即将售罄商品的曝光机会。 除了降权逻辑，我们也需要给那些表现突出的商品给与更多的曝光机会，提升流量转化效率。
接下来我们就从系统技术架构方面来加以阐述；算法方面具体细节不便透露
五角星的部分都是此次实时流量调控的重要核心模块：
PORA：PORA是搜索离线团队针对实时个性化业务场景打造的一套离线实时计算系统。它能实时同步海量用户日志，对每一条日志关联相关数据并驱动执行相关算法业务模块，产出数据自动更新下游在线服务。整个过程通常在秒级别完成，这样用户实时行为可以在几秒内就对搜索排序等线上服务产生影响。为灵活支持业务需要，PORA针对不同个性化场景提供了业务层的平台抽象，解决了所有算法不需要关心的工程问题，并通过接口和插件机制集成所有的算法模块。这样算法只需要遵循接口，专注于实现从输入用户数据到输出下游数据的算法逻辑本身，而无须关注数据同步、提取、存储、查询、更新等复杂的前后工程逻辑，也无须担心海量实时数据对系统的冲击，从而最大程度降低了算法开发成本。
具体到本次双11实时流量调控需求，PORA需要实时接入预热期和双11当天全网用户的所有点击、加购、成交行为日志，按商品维度累计相关行为数量，并实时关联查询商品库存信息，提供流量调控算法插件进行实时售罄率和实时转化率的计算分析，并将插件计算出的字段更新实时同步给主搜、商城、店铺内搜索引擎，天猫推荐平台，流量直播间等下游业务。其中，双11当天的用户访问压力是平常和预热期所难以想象的，业务方对此评估后给出了50w/s的预测峰值QPS，PORA需要确保在这样的高压力下仍然保持端到端秒级实时更新。
UPS：UPS是搜索技术部门提供个性化服务存储计算的在线系统，承担了包括搜索个性化在内的众多业务线上全量实时KV/KKV数据的低延迟的存储、查询和计算服务。在本次双11实时流量调控中，UPS在提供用户个性化数据等原有服务的基础上还存储了PORA实时更新的流量调控数据，供下游天猫双11直播间使用。
Isearch5: ISearch5是搜索最新一代引擎平台，服务于淘宝、天猫、B2B等各个搜索业务线，支持秒级实时索引、辅表等众多新特性。在本次双11实时流量调控中，PORA产出的实时售罄率和转化率字段正是通过Swift消息实时更新的索引字段。ISearch5引擎中还包含一个战马框架可以支持嵌入算法的排序模块，算法在对应的流量调控排序模块中可以获取到PORA实时更新至引擎的售罄率和转化率字段值，从而实时影响排序结果，达到调控流量的目的。
SP ：SP是搜索面向前端应用的统一服务接口，根据用户指定的查询条件制定查询计划，查询包括QP/UPS，ISearch5引擎在内的各个搜索后端系统，得到最终结果返回个前端。SP通过将业务逻辑从前端往后端下沉，简化了搜索调用逻辑，提升了前端系统性能。
BTS 服务：BTS是搜索的分桶测试管理服务，搜索的一次服务首先从BTS中获得自己所属的测试，BTS确保一个用户的前后多次访问获取到的始终是相同结果，测试信息作为一个查询条件通过SP传给后端各个系统，后端据此可以进行分桶测试。具体到本次双11的实时流量调控需求，引擎的战马框架中配置的算法排序模块会根据传入测试信息不同进行不同权重的流量调控排序，从而帮助算法对比和优化模型。
下面从系统层面讲一下这几个环节如何默契的配合来实现实时的流量调控的。 用户无论是通过PC还是无线每次点击/加购/成交一个商品，都会产生一条对应的行为日志，这个行为日志通过集团的日志实时传输系统TT（TimeTunnel）实时进入PORA系统，PORA取到这条日志的同时会实时关联获得包括商品实时库存在内的相关商品数据，并以商品为单位累积对应的点击/加购/成交数据，提供算法插件进行实时售罄率和转化率的计算更新，得到的数据更新自动同步给下游的ISearch5引擎、UPS和天猫推荐接口。整个过程在几秒内自动完成，当新的用户再发起搜索请求时，先从BTS获得自己的测试信息，由SP将搜索请求连带测试信息传输至ISearch5引擎，引擎内部的战马框架根据测试信息选择对应的算法模型，算法模型在对引擎查询返回的商品列表进行排序时，可以获取列表中所有商品经过PORA更新过的最新售罄率和转化率数据，对即将售罄的商品进行降权，对转化率高的商品进行加权，从而完成实时流量调控的目的。其中不同测试可能对应不同的算法模型，不同模型的降权和加权力度可能各不相同，因此各个分桶测试下算法的流量调控效果也各不相同。BTS服务的高效便捷性可以允许算法同学当天根据实时报表来切换排序策略。此次实时流量调控不仅仅服务于搜索业务本身，也同时通过UPS和相关接口输出实时武器给兄弟团队（天猫推荐， 直播间， 店铺内搜），来共同优化业务效率。
三、双11流量调控效果
在进入效果数据review之前，需要明确指出一点，下面给出的数据都是基于AB-test机制得到实际效果，基准桶与测试桶除了在实时流量调控环节有差异外，所有其他的环节都保持一致，因此实际的效果对比数据都是能够反映算法调控的真实效果。
很久很久以前，有一个PE叫川小生，有一个开发叫子小嘉。双11前，他们按照业务的要求给天猫准备了14倍余量，给主 搜准备了1倍余量。结果11号上午流量涨势喜人啊，嗖嗖往上涨。川小生和子小嘉说不对啊，怎么主搜涨这么厉害天猫只涨4倍呢，川小生掐指一 算，干，到 晚上主搜就挂了啊。俩人怂了，把天猫机器迁一点给主搜吧。于是改clustermap下机器，发binary，发依赖数据，发全量，追增量，起进程，改 clustermap加机器，一通折腾一个半小时过去，总算有惊无险。满心期待到了晚上，主搜流量却木有来，有木有，木有来啊。。。
　　上面是一个发生某年双11的一个真实的关于搬机器的故事， 好像每年的双11总会发生点超出我们预期的事情，而每次系统变动又总是让人胆战心惊。2014年的双11我们内心变得很平静，这些事情再也不需要咱自己去干了，因为咱有了自动化的解决方案——来自引擎调度系统小组的Hippo。
一、来自一线的诉求
PE／App Ops 同学的诉求
业务安全－健壮的系统－不要随便回收应用的机器－及时完整系统反馈／监控
系统利用率低－资源管理／复用－快速方便的调整应用资源（负载高时扩容、负载低时减机器）
捣腾机器太麻烦、大促搬机器累死的呢－集群资源统一管理
太复杂了－简单易理解，系统解耦（避免牵一发而动全身）－系统可视化
熬夜上线可不可以没有－系统级别支持灰度／平滑上线－支持方便快捷的部署／发布系统
上线麻烦，要解决太多依赖－自动部署解依赖
业务／系统开发同学的诉求
上线不求人，不要排期－更加高效的上线流程－系统解耦，不要相互约束－流程（自动化）友好
不要搭环境，不要搞机器－屏蔽运维操作、提供自动运维服务
方便debug－可重入／可复现的系统环境
简单应用不要开发－提供默认的调度、支持非侵入式接入、轻量级
复杂应用支持自定义调度－支持多层调度
随时可用的测试环境－共享测试集群
快速测试反馈－集成测试自动流程
熟悉的开发语言
这些诉求是我们与相关同学长时间深入沟通拿到的（真是很难感觉到幸福啊），转换到对我们的调度系统的需求：集群集中管理、资源调度、应用托管、高效自动部署/变更、应用安全、应用隔离。
二、为什么造轮子
Borg、Omega（Google）
Autopilot （Microsoft）
ARK/IDLE/Matrix（Baidu）
TBorg、Torca （Typhoon.Tencent）
有规模应用开源系统
Yarn （Hadoop）
战争从来都是拼后勤拼平台支撑的，天猫双十一这一天对于我们搜索事业部来说，就是一场高强度的数字化战争。为了这一天，各兄弟业务线的战友们已经摩拳擦掌，纷纷亮出各种新式武器，而我们原有的离线系统平台却渐渐显出疲态，慢慢被来自各业务线的不断提升的压力需求搞得捉襟见肘了。个性化搜索实时数据处理平台(Pora)在双十一将正式亮相，当时我们预计会有数以十亿计的新增HBase读写请求，如果不进行升级优化，原有的离线集群预计将无法承受这一前所未有的压力；天猫业务线的增量在双十一更是重中之重，届时预计会有数倍甚至十多倍的增长，不断流，不延迟对于原有的离线集群来说也是巨大的考验；主搜、国际站等业务线也都对底层平台提出了越来越高的要求，凌晨全量的时间极其有限，不能出现任何闪失。如何有效应对以上这些复杂且艰巨的挑战就成为我们离线系统团队最紧迫最核心的课题。HBase-0.98版本就是我们就对挑战的新型“核动力航母”，在这个平台上，我们有效地支撑各相关业务的发展，最终有惊无险地度过了双十一，顺利通过了考验。
Hadoop/HBase技术被引入阿里的搜索体系是在2010年夏天，初始版本号是hadoop-0.20.2和hbase-0.20.5。当时的导购搜索项目急需寻找一种高可靠高性能的分布式存储系统，用于存储导购相关的网页、价格和图片等信息，同时需要进行大量的随机读写和批量扫描、数据挖掘等工作。2011年，我们的HBase升级到0.90版本；2012年初，HBase再次升级至0.92版本；再后来，2013年初，主搜和Etao的离线集群都进入了Hadoop-2.0和HBase-0.94时代。从那以后，我们有一年半的时间没有对集群进行过大的版本升级，直到2014年8月初，etao离线集群率先升级至HBase-0.98版本，紧接着，主搜cm8集群也在10月初步入HBase-0.98时代。计算模型方面，我们基于hadoop全新的YARN框架开发出了iStream实时流计算模型，从而形成了全量、增量加实时的分布式计算+存储一体化的解决方案。在主搜cm8集群中，全量、增量及实时计算的资源(CPU和内存)占比分别是50%，13%和37%；而Etao离线集群三项的占比分别是39%，3%和58%。集群的机器数量也从2010年最初的单一集群40台节点，一步一步进化到现在，形成了一个主搜cm8近700台，etao近500台，整体上近1200台节点的搜索离线集群。
HBase-0.98版本的前期技术调研始于2014年初，当时的调研结果是非常令人满意的，以下几个大的变化让我们充满期待：
具有更好的读性能。在开发集群使用YCSB压测结果显示，相对于HBase-0.94版本，HBase-0.98的Get操作的latency下降60%，Scan的latency下降40%；
MTTR(Mean Time To Recovery)机制让RegionServer的Failover恢复更快，实测显示，写操作可以在秒级恢复，读操作可以在十秒级恢复；
StripeCompaction策略优化了Compaction的IO使用，对于在搜索业务中广泛使用的HQueue时间序列式的表来说，优化会很明显；
全新的启发式LoadBalancer，比原有HBase-0.94默认按region个数进行balance的策略更加有效提升系统的稳定性及性能，减少出现Region热点的概率；
ProtocolBuffer通信协议，让以后的跨大版本Rolling升级成为可能，避免了不必要的停服务操作。
除了技术调研和基本的性能评测以外，我们还要将自己在HBase-0.94中增加的各种patch移植到新版本中去，例如：
HTable的autoFlush批量写操作优化，减少rpc次数，提高写吞吐能力；
ThriftServer支持HQueue读写，并自动清理未关闭的Scanner，节约内存；
网页端Table级别的数据查询工具
Metrics优化，由于0.98改用了HadoopMetrics2版本，相应的配置及metrics指标与以前完全不同了，为了对比的需要，我们重新把一些指标补充进来(例如HFile的read和pread的latency等)，并更新ganglia配置，以适应新的指标
RegionServer的Rolling升级工具，让日常小版本升级对应用更加平滑透明
Region Split/Merge策略和工具
还有一些Client端接口的向前兼容等
另外，我们还发现了社区版本中的一些小bug，及时地提交patch并被接受。
HBase-0.98版本的前景很令人期待，但升级的过程还是比较坎坷的。Etao离线集群作为主搜cm8集群的backup集群，首先来承担了HBase-0.98的升级演练及功能、性能验证工作。这个过程我们踩了不少的“坑”，例如：我们的集群中使用了Phoenix项目（集群资源统计系统HStats以及新版的HistoryServer都依赖于它），相关的一些表中就使用了Phoenix定制的Coprocessor，而这些Coprocessor在HBase升级时，会保留一些旧版本的java package类名，这些类却不在新版本phoenix的jar中，导致hbase启动后加载这些带有phoenix定制coprocessor的表时出现失败，集群无法启动。最终我们是通过改hbase源代码加逻辑绕过这些表才恢复的。接下来，由于升级前后那段时间，公司对生产网机器都增加采用了长域名访问机制(以”tbsite.net”结尾)，而之前我们集群中各种相关配置都是短域名，造成了HBase集群运维过程中的一些不一致现象，后来我们是通过统一采用长域名来解决的。还有一点，为了给集群版本升级降低压力，我们在升级前24小时(具体时间是根据集群实际规模及数据量来确定的)，对HBase集群所有的表进行一次major_compaction，最大限度地减少体积，从而间接减少HBase启、停时间；另外，升级前24小时也要通知业务方清理HDFS上面的所有无用目录及文件，为hdfs减轻启、停压力。
在etao离线集群升级HBase-0.98完成后，我们立即就开始进行各主要功能点的验证工作，为主搜cm8集群的升级铺平道路。
最给力的指标莫过于读性能的提升，由于etao集群上面的各业务对于HBase的读（随机Get+顺序Scan）要求比较高，因此效果很明显，凌晨全量的scan密集型的job普遍快了10~20%，而白天增量时段，集群的get的latency也下降30%左右，且更加平稳。
由于采用了新的异步写WAL的机制，集群中由Put写操作产生的IO压力相比以前也变得更加稳定。
PrefixTree与DIFF方式的ENCODING相比，对于随机读(GET)操作来说，降低了约5%左右的latency。后来由于社区曝出在scan时有漏数据的问题，因此紧急下掉，等社区后面修复稳定后再考虑上线。
StripeCompaction在试用时发现，在Size比较大的HQueue上效果基本符合预期，但对于Size比较小的HQueue来说，再次分“Stripe”会导致小文件过多，因此这个功能也安排在双十一之后逐步上线。
启发式的LoadBalancer比较让人失望，它的算法理论上是追求动态均衡的，考虑到了很多的因素（包括region个数，move次数，read/write请求数，storeSize，locality等），但在实际运行中常常造成集群中大量region的迁移，影响到上层应用的访问，而且，在计算locality因素时，常常会给hdfs很大的访问压力，因此这项功能最终被我们放弃了，还是恢复到0.94时的按region个数进行balance的策略。
这段时期，最让人头痛的问题还是稳定性。稳定性是分布式存储平台的基础，是最最最基本的要求，但升级0.98后我们发现，常常有RegionServer会莫名其妙地写HDFS卡住，无法响应外部请求，直接严重影响了上层的应用，连续导致我们出现了3次P4和1次P3事故，尝尝收到来自淘点点业务的投诉，弄得我们焦头烂额。为此，我们一方面专门开发了一套HBase集群可用性监控及自动处理系统，能在几分钟内，尽快发现并解决掉已经卡住无法对外响应的RS；另一方面，我们投入多名工程师一起攻坚，最终解决了HBase写HDFS卡住的问题。原因主要分为两方面，一是集群机器操作系统配置中的net.core.somaxconn为默认值，之前在云梯集群发现过类似问题，调大此值到4000，应用后然后重启DN，情况大大改善；另一方面是hadoop-2.4 HDFS Client重构后未对socket设置超时时间，默认永不超时，导致卡住，后来我们fix了这个bug，HBase集群稳定性因此得以恢复。
在经历了一番波折解决了前面的问题后，我们本以为可以高枕无忧了，因此，今年10月初，就急切地把主搜cm8集群也升级到HBase-0.98版本。大大出乎我们的意料的是，升级后的主搜离线集群性能及稳定性居然还不如升级之前！双十一日益临近，没有回头路的我们开始了新一轮的调优和改进。
连续挂RS的问题
关于cm8集群的稳定性问题，其实最重要的就是一点：每天上午总会连续挂掉数十台RS。去查它们的HBase日志，基本上都是GC太忙，OutOfMemory挂掉的。但由于都是直接进程消失，没有其他痕迹，导致我们无从查起，只能根据发生的时间来判断应该与上午的某个job的读写有关。幸运地是，我们在逐台“验尸”时，发现一台机器保留了hprof文件，把当时RS的内存完整保留了下来。经过profiling分析发现，原来是在cm8集群hbase中，有一张odin_stat的统计用的表，它里面中存放了不合理的数据，一次scan操作时，扫出的某单条数据row的size超过1G，另外还有几条size达到数百M的row，导致RS无法短时间内消化掉，最终OOM了。在我们停掉了这张表对应的扫表job后，连续挂RS的情况再也没有出现。后续我们推动业务方改用OpenTSDB这种系统来存储时间序列日志。
LoadBlancer的“坑”&
说起load balance，一般比较容易想到的是大型服务在多个replica之间的load balance、和kernal的load balance。前者一般只是在流量入口做一下流量分配，逻辑相对简单；而后者则比较复杂，需要不断发现正在运行的各个进程之间的imbalance，然后通过将进程在CPU之间进行迁移，使得各个CPU都被充分利用起来。
而本文想要讨论的load balance有别于以上两种，它是多线程（多进程）server程序内部，各个worker线程（进程）之间的load balance。
考虑一种常用的server模型：一个receiver线程负责接收请求，后面有一个线程池装了一堆worker线程，收到的请求被分派给这些worker进行处理。receiver与worker之间通过pthread_cond+request_queue来进行通信。一般的做法是：receiver将收到的请求放入queue，然后signal一下cond，就OK了。具体哪个worker会被唤醒，那是kernel的事情（实际上kernel会遵循先来后到原则，唤醒先进入等待的进程，参阅《》）。通常情况下这样做就足够了，receiver唤醒worker不需要涉及load balance的逻辑。但是有时候我们还是可以做一些load balance的工作，来提高server的性能。
kernel load balance概述
由于这里的load balance跟kernel的load balance息息相关，所以我们有必要先看看kernel的load balance都做了些什么。详细的内容请参阅《》，这里只做一些简要的概括。
说白了，kernel的load balance就做一件事情： 让系统中RUNNING状态的进程尽可能的被分摊，在每一个调度域上看都是balance的 。怎么理解呢？现在CPU的结构一般有：物理CPU、core、超线程、这么几个层次。”在每一个调度域上看都balance”可以理解为在每一个层次上都balance：每个物理CPU上的总load相当、每个core上的总load相当、每个超线程上的load也相当。
我们在系统中看到的”CPU”都是最底层的超线程这个层次，我们可能会直观的认为把RUNNING状态的进程分摊到每一个”CPU”上就行了，但是实际上kernel的load balance还有更高的要求。假设我们的机器有2个物理CPU、每个物理CPU有2个core、每个core有2个超线程，共8个”CPU”。如果现在有8个RUNNING状态的进程（假设优先级都相同），每个”CPU”各分摊一个进程，那么自然就是balance的。但是如果现在只有4个RUNNING状态的进程（假设优先级都相同），真正的balance并不仅仅是每个进程各自落到一个”CPU”上就行了，而是进一步要求每个物理CPU上跑两个进程、每个core上跑一个进程。
为什么要有这样的强约束呢？因为尽管各个”CPU”逻辑上是独立的（不存在主从关系之类），但它们并非孤立存在。相同物理CPU下的”CPU”会共享cache、相同core下的”CPU”会共享计算资源（所谓的超线程也就是一套流水线跑两个线程）。而共享也就意味着争抢。所以，在RUNNING状态的进程并非正好均摊给每一个”CPU”的情况下，需要考虑更高层次的CPU是否被均摊，以避免cache和CPU流水线的争抢（当然，除了性能，这也体现了kernel的公平性）。
最后再多提一点，kernel的load balance是异步的。为避免占用过多资源，kernel肯定不可能实时监控各个”CPU”的情况，然后面对变化实时的做出反应（当然，实时进程除外，但这不在我们讨论范围内）。
server的load balance考虑
有了kernel的load balance作为铺垫，看看我们server上的receiver线程能做些什么吧。
首先是worker线程的数量问题。如果worker数量过多会发生什么情况？还是假设我们的机器有上述的8个”CPU”，假设我们开了80个worker，再假设这80个线程被平均分派到每一个”CPU”上，等待处理任务。当一堆请求陆续到来的时候，由于我们的receiver没有任何load balance的策略，被唤醒的worker出现在哪个”CPU”上可以说是随机的。你想想，”同时”到来的8个请求正好落到8个不同”CPU”上的概率是多少？是：(70*60*50*40*30*20*10)/(79*78*77*76*75*74*73)=0.34%。也就是说几乎肯定会出现某些”CPU”要处理多个请求、某些”CPU”却闲着没事干的情况，系统的性能可想而知。而等到后知后觉的kernel load balance将这些请求balance到每一个”CPU”上时，可能请求已经处理得差不多了，等到下一批请求到来时，load又还是凌乱的。因为刚刚已经balance好的那些worker线程又被放回到了cond等待队列的尾部，而优先响应新请求的则是那些位于队列头部的未曾被balance过的worker。
那么会不会经历几轮请求之后就能达到balance了呢？如果请求真的是一轮一轮的过来，并且每个请求的处理时间完全相同，那么有可能会达到balance，但是实际情况肯定相差甚远。
前些天，五福老大的文章《》介绍了搜索双11的5件新式武器，其中就包括天猫SKU搜索。本文就对此做一些更详细的介绍：
SKU，Stock Keeping Unit，库存单元，是商品库存的最小单位。通俗的讲，一种商品可能有各种规格的货，每一种货就是一个SKU。比如，iphone6有白色16G、金色16G、白色64G、金色64G、等多种SKU；再比如商家售卖的某款T恤有白色S码、黑色S码、白色M码、黑色S码、等等SKU。
SKU的概念在tmall这个平台上其实已经存在很久了。在tmall上，当我们进入一个商品详情页时，会看到SKU相关的选项。比如进入某商家售卖的iphone6手机的商品详情页，你可以选择具体规格的iphone6手机：颜色是白色、金色、还是黑色？内存大小是16G、64G、还是128G？如果某种规格的手机没货，比如金色64G无货，那么页面会禁止你同时选中”金色”和”64G”，或者在你选中这样的组合之后提示你无货。当你选定了一种规格，如果有货，页面会显示对应规则的售价（不同规则售价很可能是不一样的哦），这时你才能对此商品下单。而此时，其实你是选中的就是一个确定的SKU。
不过很遗憾，一直以来，你只有进入商品详情页才能看到这些关于SKU的选项，才知道什么样的SKU是有货的，具体售价是多少。而在商品搜索页面展示的结果只有商品维度的信息。
SKU搜索能带来什么
如果你对于精细化的搜索没什么需求，只是想随便逛逛，那么原先的搜索体验对你来说应该问题不大。否则，你可能会遇到一些不方便，比如：
你想买64G的iphone6，想找一个价位合适一些的商家。但是搜索结果没法给你展现64G的iphone6卖什么价钱（一般为了吸引眼球展现的都是最便宜的16G的价格，或者直接展示一个总的价格区间），你只能在茫茫多的搜索结果中逐个点击进入商品详情页，然后再逐个比较。甚至不少商家可能暂没有64G的货，却也堂而皇之的出现在搜索结果中；
跟上一个场景比较类似，可能你看到茫茫多的搜索结果被吓坏了，打算做一下价格过滤，只搜索售价低于5000块的64G iphone6。但是结果再一次让你失望了，既然搜索结果没法将64G iphone6准确的价格区间展现给你，那么价格过滤必定也不是你所期望的结果；
类似的，选择按价格排序的搜索结果也肯定让你直摇头；
时间倒退半年，2014巴西世界杯要开打了，你想买一件西班牙队的球衣以表支持。Tmall上的西班牙球衣或者相关T恤简直五花八门，让你挑花了眼。于是你打算加一些筛选条件：红色、M号（可能你几次点击进入商品详情后已经发现有些商品并没有合适你穿的M号）。可惜搜索又再一次令你失望了，很多商品并没有红色M号却也混进了搜索结果中。这是BUG么？其实不是，细心的你也发现虽然那些商品并没有你想要的红色M号，却有红色S号和白色M号，或者红色L号和黑色M号，诸如此类，反正红色是有的，M号也是有的，就是未必能凑在一起；
这些问题的的根源在于，搜索引擎是以商品作为检索单位，没法提供更细粒度（SKU粒度）的检索功能。于是，为了提升用户的搜索体验，为了把搜索做得更好，搜索引擎需要支持SKU粒度的检索。
有了SKU粒度的搜索引擎，不仅能解决上面提到的这些关于精准搜索的问题，也给搜索结果的组织和排序提供了更多的玩法与可能性。比如：
SKU信息披露：搜索结果依然按商品来展示，但是满足搜索条件的SKU可以以小图的形式展现在商品下面，在搜索结果页面点击这些小图就能看到对应SKU的价格；有些类目下面，SKU小图可以做成两个维度的。比如鞋子，小图展现的是不同颜色的各个版本，点击小图之后会展现该颜色对应有货的各种尺码信息。选中颜色和尺码再展现对应的价格区间。另一方面，这些小图也可以按其对应的SKU受欢迎程度等逻辑来进行排序；
搜索结果组织：普通的query按商品粒度展示、命中标类（SPU）的query按标类聚合展示，这都是原来就有的组织方式。有了SKU引擎，当query更为具体（满足条件的商品很少）时，可以以更细粒度来展示搜索结果，比如按子标类（CSPU）聚合展示、或直接按SKU展示；（关于子标类，举一个简单的例子，iphone6是一个标类，白色64G iphone6就是一个子标类。当用户搜索”手机”时，搜索结果可以按标类聚合展示；当用户搜索”iphone6″时，如果依然按标类来聚合，那么搜索结果就只有iphone6自己孤零零的一个了，这时候更好的做法是按子标类聚合展示。）
精准排序：现在既然引擎已经能认识到商品的某些SKU是不满足搜索条件的，那么提供给算法用来计算排序分的信息就应该只包含满足条件的那些SKU的信息，而不应该是整个商品的信息。这样可以做到更精准的排序；
有了SKU引擎，有了精准搜索，一个叫”尺码个性化”的需求就信心满满地登上了台面。用户可以在tmall上设置自己以及家人朋友的各种尺码，在搜索服饰类商品的时候可以方便的进行尺码筛选。可以想象，在没有精准搜索之前，尺码个性化这样的功能简直就是自曝其短（搜索结果不准确、价格展现也差强人意，用户肯定骂声一片）。
SKU引擎和尺码个性化功能上线之后，取得了不错的成绩。经过数据分析，CSPU聚合场景下IPVUV/UV增长率为2.16%、整个沙发类目平均ipvuv价值增长率为8.50%、文胸类目平均ipvuv价值增长率为3.23%、男鞋类目平均ipvuv价值增长率为1.26%、女鞋类目平均ipvuv价值增长率为1.20%、等等。
目前SKU引擎才刚刚上线，大幕才刚刚拉开，在此基础上，后续必定会有更多的feature让我们的搜索变得更好用，大家可以拭目以待。
SKU搜索的实现
讲了这么多SKU引擎的好处，为什么不早点把这个东西搞起来呢？其实实现SKU引擎的道路充满了波折……
第一个时期，可以称为改良期。其实这个时侯并没有什么SKU引擎，但是为了实现个别场景下的精准搜索，我们利用搜索引擎插件来做了一些处理。最典型的就是价格展现，并不是直接展现商品的最小SKU价格或是所有SKU的价格区间，而是通过插件来判断哪些SKU是满足搜索条件的，从而决定应该展现什么样的价格区间。
插件实现的精准搜索主要存在两方面的问题：
没有统一的方案，各个改良点分散在不同的角落，难以维护；
效率不尽如人意，一般需要在检索过程之后额外增加一个SKU的判断逻辑。特别是当SKU维度的搜索条件比较复杂时，插件判断起来会很费劲。比如用户搜索：64G、白色或金色的iphone6，搜索条件是一个比较复杂的表达式，而不仅仅是一堆AND关系的条件叠加；
第二个时期，是全面SKU化，将引擎数据由商品粒度改为SKU粒度。这是非常简单易行的SKU方案，并且能够很好的实现SKU引擎的各种需求。唯一，并且是致命，的问题是浪费太大。毕竟用于检索的数据，绝大部分还是在商品这个维度上的。将检索粒度直接改为SKU粒度，这意味着商品维度上的数据需要冗余到其对应的每一个SKU上。数据的冗余，造成了引擎索引量增大、造成了离线数据处理开销增大、造成了各种在线归并和聚合逻辑的开销增大。细算下来，tmall引擎需要增加5倍以上的机器才能支撑网站的全部流量，离线处理的机器资源也需要相应的增加，这实在是不可接受。
所以这个时期的SKU引擎只存在于bts，它的功绩是验证了SKU引擎的功能和效果，更坚定了我们要做SKU引擎的决心。
第三个时期，才是目前的SKU引擎。既要支持SKU的检索粒度，又要避免数据冗余，那么引擎就必须要支持两个维度的数据共存。
为此，作为搜索引擎内核的isearch5引擎引入了”子表”的概念。”主表”和”子表”都拥有完整的检索能力，并且建立强一致的对应关系。商品作为主表、SKU作为子表，检索结果就表现为”一主带多子”的结构。这些子表记录都一定是满足检索条件的，并且当一个主表记录对应0个子表记录时，说明这个主表记录不满足检索条件（回想之前”红色M号”的例子）。后续的RANK、字段展现、等等都在这样的一主带多子的数据结构上工作，每个环节都明确知道哪些SKU是满足检索条件的。
“子表”这个概念跟引擎里面早已存在的”辅表”似乎有些相似。一般来说，我们可以将商家信息作为辅表来提供检索，目的也是避免数据冗余。但是”子表”与”辅表”还是有本质的不同：辅表并不提供查询功能，我们只能实现查询商品，然后从辅表中读取商品对应的商家信息，而不能查商家（比如说，我们不能查询店铺名称含有”夕阳红”的商家所售卖的标题含有”保暖内衣”的商品）。基于这一点，主表与辅表虽然是两个表，但是引擎的处理逻辑还是一维的（主表维度），并不存在一主带多辅的概念（一般来说一个主表记录只能对应到一个辅表记录，就算数据结构是一对多，在进行取值的时候也只能保留一个而舍弃其他）。
而”子表”则是真正的两维概念，两个表可以同时查询（比如说，可以查询标题含有”iphone6″的商品，且这些商品需要拥有包含”白色”和”16G”两个属性的SKU），并且检索结果在引擎中表现为一主带多子的两维结构。这一点对isearch引擎来说冲击是非常大的，整个查询流程需要从一维数据结构变为两维结构。具体来说主要有以下几点：
查询过程支持主表与子表的混合查询。了解isearch的同学都应该知道，引擎的查询过程是由语法树来描述的。比如查询64G、白色或金色的iphone6，写成查询语法大概是这样子：query=主表:iphone6 AND
在搜索我经历过全部的双11，12年和13年这2次大促，GN是开发总指挥，我是在礼台上看各种新武器实弹表演。过去6年里，我们的引擎体系每年做到100%的性能提升，以淘系搜索为例，从最初3000台机器翻倍到现在区区6000台，但搜索服务却从6千qps增长了40倍到现在的32万qps，同时还填补了算法欲壑（算法数据占用内存从最初的10%到了现在的50%），转化率持续攀升，目前大搜索GMV已经是全网的主体了。搜索工程师的双11历来是实弹各种新武器的大机遇，而常规的技术保障已经成为踩在脚下的底线。实施任何一种降级预案都被我们视为耻辱，因为预案都是以伤害用户体验为代价的。在技术保障部双11总指挥群里此起彼伏的降级通告里面，从来没有过搜索的身影！
14年双11大促总指挥是YF，搜索焦点集中在要检阅的5件新武器上：
天猫售罄率预估，商品加购和交易后及时预测它的售罄时间，通过降权或者加权提升搜索结果页每一个位置的价值，搜索GMV可提升10%。
天猫SKU搜索，颜色尺码等sku属性参与检索。引擎平台实现了子文档检索功能，将原来集群拓展五倍规模才能做到的天猫SKU在原有基础上增加60%即可实现。
Hippo引擎在线管理系统，机群变为可灵活流动的三维架构，第一维度是根据商品质量或类目划分子机群，下面才是传统的二维行列架构，这带来的好处是查询性能的巨幅优化。
离线集群HBase升级0.98，近700台机器的离线集群上各业务线分头开发累积导致集群效率底下，支持售罄率预估也要求我们把调优经验更厚实的0.98版本升级上去。
搜索分层优化GMV，借助Hippo系统主搜根据商品质量划分子机群然后在业务服务层聚合，搜索GMV可提升6%，整体性能大幅提升80%。
10/17，离双11还有段日子，下午我常规心血来潮找XD了解Hippo的进展，结果却触动了我的神经，我们都希望看到Hippo在双11上线主搜和天猫实战检验，但GD坚持把统一到A8机器的运维工作一并完成（稍显保守），因为这需要补充近300台A8的机器，而机器已经拖延几个星期了，本该9月底完成上线的Hippo到了10/17看来机会渺茫，引擎体系奔向世界级的路上焉能贻误战机！更有甚者，售罄率预估与天猫SKU搜索这两个业务项目都依赖Hippo，业务项目要是延误可是要掉脑袋的，念及此处我没有心情观礼了。要知道，主搜天猫加上这些A8升级后，还要退出来低配机器给其它搜索服务扩容，上下游一系列连锁依赖都嗷嗷待哺需要时间呀。紧急状态，不得不对搜索工程各相关团队发起动员了。Hippo必须不能够等待A8的到来尽快上线检验，要打破常规的水平分工来一场混战了。我直接请YL担任紧急状态下引擎端的负责人，飞行时更换引擎是我们起步时代的杀手锏，今天必须成为我们的底线。
10/27日，紧急状态的第10天，ZY和GD在各应用集群间辗转腾挪，终于完成了Hippo上线和天猫SKU搜索上线；插件小组完成了售罄率预估上线，把主搜性能提升了30%；LT和XY在QA小组的陪伴下解决了各组件的core与慢，CS也分批交付了A8机器。淘宝搜索、天猫搜索、店铺内搜索、店铺搜索共四个核心应用的淘系搜索达到了40万qps服务能力。这火热的十天，恰好也是CS和GD的陪产假。
现在我是不是可以高枕无忧重上观礼台了呢？此次要实弹的新武器只有Hippo和天猫SKU搜索踏实了，而售罄率预估所需离线集群HBase升级后鲜有指标超越升级以前，全链路压测未能成功。更为甚者，TM根据10月份无线端流量情况，把对搜索的要求从10万qps提升到了15万qps，也就是说现有的40万qps整体能力必须提升到45万qps！而多出来的5万qps要求又只能实打实落在最大的主搜索集群上，目前的优化手段已经用尽，降级是容易的也是耻辱的，怎么办？崩溃前奏，我冷汗直冒，尽管现在是YF担任总指挥。
搜索分层优化GMV成了救命稻草，尽管已经在无线全量上线并拿到了大部分性能成果，已经体在现有40万qps的服务能力里。但在PC端上线却因为对广告的负面影响而步伐迟缓，这里还有100台机器可以省下来。此外协同搜索是主搜的辅助引擎，这有200台机器不得已可以下线。分层优化GMV和协同检索一上一下恰好可以抵消GMV损失，同时又能节省300多台机器。紧急关头，老板给我们亮了黄灯，暂时下掉代表搜索体系技术一大进步的协同关系搜索是我此次最大的遗憾。
11/7日，紧急状态的第20天，大促准备的战场收尾之后，全淘系搜索在线服务规模达到了2500台机器，搜索服务能力推高到至45万qps，此外还有推荐服务能力到了12万qps，以及4万qps的AE引擎服务能力。已成为集团基础设施的opensearch在那个周末还有个插曲，HT应淘点点要求紧急把集群扩容到4万qps。至此万事俱备，欢度周末之后我准备上观礼台了。
11/10日21点到11日晚12点共27个小时，5种新武器实弹表演渐入佳境，事后回顾流量高峰在最初的4小时就已经到来了，尽管11日白天来势汹汹比前一天高出一倍不止，但到了晚上涨幅回落基本和10日持平了。观礼过程最为惊险的在11号上午8点到12点这段期间，对IC销量字段的更新度预估不足，导致天猫引擎有约半小时的延迟，售罄率预估也无法开启；无线推荐因为上游降级而流量大损峰值只有4万qps（上限12万qps）。在这27个小时里，搜索峰值是32万qps（上限45万qps），其中最大的份额来自手淘搜索峰值10万qps（上限15万qps）。手淘UV只到了理想目标的60%，真要是满负荷过来的话，手淘搜索峰值会突破上限15万qps而达到16.7万，那么等待我们的唯有耻辱降级一途！售罄率预估当天开启12个小时，对成交转化提升达到了10个百分点。Opensearch的服务大大低于预期只跑到了7千qps。最后AE的大促意外交出了完美的业务答卷，同时引擎后台服务真的一度达到了3.2万qps（上限4万qps）。
迄今为止的每一次大促搜索在线服务都没有任何形式的降级，无论是天猫还是淘宝还是SC/AE还是1688，这一次游走在天堂和地狱之间，我们更清醒的认识到，技术进步永无止境！&
在这一篇中，将对4store中涉及的查询结果处理的内容进行解析。查询结果处理主要包括triple的结果合并操作以及triple之上的block结果合并操作等。此外，关于4store实现的一些SPARQL关键字的处理逻辑，也会在这一篇中进行简单的说明。
查询结果的合并
triple查询结果的合并
这里讨论的是一个block之内的多条triple查询结果的合并问题。一个block之内的多条triple之间的关系有两种：
没有关系。比如，?x P0 O0和S1 P1 ?y.这两条triple之间是毫无关系的，因为他们之间没有变量的交集。
有关系。比如，?x P0 O0和?x P1 ?y.这两条triple就通过x变量连接起来了。
在4store中，结果合并操作在每执行完一条triple后就要执行一次。具体来说，合并主要的执行内容是将之前已有记录合并到新获取到的记录中。它是通过下面这个步骤进行的：
当前的block节点若有父节点，则从父节点中复制一份变量值，作为当前block的初始结果；若当前节点没有父节点，则block的初始结果是一个空集合；不妨设这个集合为R。
假如我们用集合N来存储一条triple执行返回的结果，N中只包含triple涉及的变量值。
接下来执行R和N的合并，4store中是将R的结果向N进行合并，完成合并后又进行如下集合操作R=U, U={}。
在合并时，会根据N和R中是否有变量交集来决定合并的策略。N和R中都要至少一个变量是有值，表示N和R是有交集的。
若N和R集合没有变量交集，则直接将R中所有的变量值添加到N后面，即可完成结果的合并。
若两者有交集，则将R和N分别按照两者有交集部分的变量值进行排序，我们在这里称这些变量为排序变量。然后，按行比较R和N中排序变量的值，剔除N中排序变量值与R不同的那些行。对于N与R中排序变量相同的行，则将R中除排序变量外的其他变量的值复制N中。需要注意的是，R中可能有多行的排序变量值是一样的，如果这些行都与N中的某行相同，那么N需要复制多行来跟这些重复行匹配。
PREFIX rdf: &http://www.w3.org/-rdf-syntax-ns#&
PREFIX foaf: &/foaf/0.1/&
在之前的两篇4store源码解析系列文章中，我们已经对单条triple的查询流程和细节处理进行了说明。在这一篇中，我们将对如何处理有嵌套关系的多条triple查询问题展开讨论，并进一步分析4store对这个问题的处理优化。
graph pattern解析和优化
如中所述，4store并不直接参与sparql语句的解析，而只对Rasqal库解析了后的graph结构进行分析。
要了解4store如何二次解析Rasqal对sparql查询语句的解析结果，我们首先需要了解Rasqa解析结果的具体形式。在Rasqal中，主要使用了graph pattern的概念，来组合解析结果中各个分支。我们可以将其理解成语法树中的一个节点，但这里的节点有很多类型，包括：Graph、Optional、Filter、Basic以及Union等。
Basic类型节点只包含若干条triple，每个triple的返回结果之间做交（即MERGE）。
Filter类型节点只包含一个表达式，表达式只使用其兄弟节点中涉及的变量值来计算。表达式是可以嵌套的，如?x & 10 && ?y != 0。最外层的表达式必要能返回BOOL类型的结果；返回TRUE表示符合表达式的条件，FALSE表示不符合；只有符合表达式条件的结果会被其父节点接受。
GRAPH类型节点只包含若干个子节点，每个节点返回的结果间做交（即INNER_JOIN，同MERGE，仅在名称上有所区分）操作。
Union类型的节点也只包含若干个子节点，但是每个子节点返回的结果间做并（即UNION）操作。
Optional类型的节点，也只包含若干个子节点。其结果与其兄弟节点之间做半交（即LEFT_JOIN）操作，Optional节点下涉及的变量值对于其父节点而言是可选的。
其他类型，如MINUS类型、LET类型等暂不展开介绍。
可以看到，中graph pattern是非常简单的，只有一个Basic类型的节点。
下面，我们将引入了一个相对复杂的sparql查询语句来作为例子，针对分析有嵌套关系的多条triple查询问题。
测试数据依旧是&
在上一篇中，我们对4store查询的基本流程进行了梳理。在这一篇中，我们将对查询在客户端和服务端的一些处理细节展开讨论。
客户端的triple查询处理
关于triple查询的最底层实现，我们在源码解析中已经具体介绍了，我们这里要讨论的是在底层查询接口之上的一些优化和处理。
一般来说，在单条query查询语句中虽然可能涉及多条triple查询，但这些triple查询请求很少会重复。但是，我们在使用4store进行多次query查询时，则很有可能会出现重复的triple查询了。我们这一节中所说的缓存处理，就是针对重复的triple查询而设计的。
首先，我们来回顾一下一条triple查询语句有哪些元素。在上一篇中，我们提到的flag域、[M, S, P, O]的rids，决定了这次查询的主要内容。细心的同学会发现，在那篇文章的示例图中，还有limit和offset这两个域，它们也是triple查询的一个组成部分。limit和offset主要用在LIMIT和OFFSET这两个关键字上，关于它们的使用说明，可以详见。除此之外，query是否需要向所有的segment发送，也是一个隐式的属性。
4store在处理triple查询的缓存时，并不是所有triple查询结果都缓存的。它仅缓存[M, S, P, O]中每项查询条件，不包含多个rid的情况。而且，查询结果中包含过多结果时（大于10000条），也不进行缓存。缓存使用一个数组指针来保存，在查询和插入缓存时我们就需要一个cache_key作为这个数组的下标。我们使用flags、limit、offset、以及all（即是否向所有segment发送的属性）以及[M, S, P, O]的rid值，进行了一些异或等数值处理，来得到这个cache_key。
完整的triple查询逻辑：
判定当前query是否适用于加入缓存，若不适用则直接向服务器查询结果；
若适用，则计算cache_key，并判定cache_key指向的缓存中是否有记录；
若缓存命中，则返回缓存的结果；
若缓存没有命中，则继续向服务器查询结果；
检查服务器返回结果，若结果集不大，则将其插入到cache_key指向的缓存位置。
4store中提供了非常简单的权限管理功能。其实现机制如下：
向服务器端发起一次特殊的triple查询请求，查询服务器端记录的权限管理记录
根据查询结果中的配置，来建立具体哪些graph是哪些用户可以访问的映射
A quality product by}