该文章来自阿里巴巴技术协会（ata）精选集
随着2015双促落下帷幕，igraph在线图存储和查询服务也在全力支撑各项业务的过程中经历了近乎疯狂的成长。随着大家逐渐从 关系的视角来审视我们的数据和业务，igraph服务所提供的 基于关系的查询服务也开始被大家大量应用到业务逻辑中。igraph团队也很兴奋地看到igraph服务中所承载的业务呈现出了爆发式的增长，其中不乏集团的核心业务，比如搜索业务和推荐业务。在这里，我们igraph团队向所有信任我们的用户，表示最衷心的感谢，是你们的信任和优异的成绩彰显了igraph团队工作的价值。这一篇文章首先向大家整体介绍igraph服务目前的发展状况，然后向大家介绍我们在支撑双十一大促业务过程中所做的相关工作。希望这些介绍能够让大家进一步了解igraph，并能够给我们提出宝贵的意见。
虽然igraph服务上目前承载了众多业务，但是对igraph服务造成巨大压力的还是集团两大核心业务—— 搜索和 推荐。这两项业务平时的体量已经足够大，双十一他们的流量更是难以预估。尤其是推荐业务，由于今年是个性化推荐元年，业务呈现出爆发式增长，更是让整个容量评估过程难上加难。
其实对于igraph服务来讲，不但访问压力大，实时更新压力也非常巨大。因为，用户实时行为（比如点击行为、购买行为、加购行为、收藏行为等）反馈对算法效果至关重要，这些实时行为反馈通过pora实时流计算平台实时更新到igraph服务中。由于双十一当天用户行为数激增，所以实时行为反馈对igraph服务造成了巨大的更新压力。
很幸运，在各团队的通力合作下，igraph在双十一大促过程中平稳地支撑了这两条重要的业务，也迎来了igraph各项系统指标的峰值。
系统核心指标（出于安全考虑，请原谅我们不能给出精确绝对值）：
1. proxy流量接入层峰值qps达到几百万的，searcher集群峰值qps超过千万。
2. proxy接入层在qps达到几百万峰值qps时，服务响应保持在3ms以内。
3. 实时更新消息峰值达到几百万qps每秒，双十一当天更新消息总量更是超过五百亿条。
目前，igraph服务在上海、杭州以及深圳三个机房进行了单元化部署，为近千份关系数据提供在线服务，数据规模约250t。日常访问igraph服务接入层峰值qps在 110w左右。
由于大家对于igraph团队的信任，igraph服务的客户也在不断增长，包括（排名不分先后）：
1. 个性化推荐业务
2. 淘系商品个性化搜索业务
3. 1688搜索业务
4. 虾米音乐推荐业务
5. 集团安全用户指纹业务
7. 拍立淘业务
8. 航旅业务
9. b2b icbu推荐业务
10. 蚂蚁金服天罗地网业务
11. ...
igraph团队主要从两个方向来备战2015双十一。首先，需要让igraph支撑更多的业务，这就需要我们不断丰富igraph的功能，并且提升业务团队使用igraph服务的效率；其次，需要不断提升我们自身的运转效率，这就需要我们提升igraph服务的性能同时降低维护igraph服务的运维成本。于是我们主要做了一下几件事情：
对于个性化搜索和个性化推荐来讲，都离不开用户的行为数据，通常这些数据都要求比较高的实时性（通常是秒级）。因为igraph服务能够支持高并发低延迟的访问，并且支持大量消息实时更新，于是我们联合pora实时流式处理平台以及igraph服务打造了用户基础数据服务（如下图所示）。这个服务既可以提供最近一段时间内用户的历史行为数据也可以提供实时的用户行为。基础数据服务为集团各条业务的实时个性化提供支撑。基础服务提供的实时数据包括：
1. 用户点击行为
2. 用户购买行为
3. 用户收藏行为
4. 用户收藏商品行为
5. 用户收藏店铺行为
6. 用户加购行为
7. 用户profile（购买力、偏好等）。
基础数据服务为业务方在双十一提供 126w峰值qps，双十二 170w 峰值qps的用户实时行为访问，给业务指标带来了巨大的提升。搜索离线团队提供的pora 实时流式计算平台在处理用户实时日志方面也非常给力。
为了能够让业务进行快速迭代，我们igraph团队提供了一个igraph服务自助接入web服务。用户只需在web页面上（如下图所示）简单填写相关信息，igraph服务就可以自动托管整个数据的回流，并且用户可以在自助服务页面上查看到数据回流具体状态。只要自助服务页面上显示数据回流成功，那么用户就可以通过igraph client或者igraph http服务查询自己的数据。
随着igraph服务承接的业务不停增长，igraph集群的规模不停增长，集群的在线部署和异常处理占用了我们大量时间。为了能够自动化地进行在线集群部署以及智能的异常处理，我们给igraph在线集群添加了一个自动化调度角色，我们称之为igraph admin。
有了igraph admin角色之后，使我们应对igraph集群部署和异常处理变得轻松自如。集群部署只需要保证有足够的空闲机器资源，igraph admin可以自动申请机器资源并部署上igraph服务，整个过程不需要人工干预；对于集群中经常出现的机器异常，igraph admin会自动把对应的igraph服务迁移到正常的机器上。
为了能够让igraph服务支撑更高的访问量，我们将原先igraph proxy的线程模型进行了异步化改造。之前proxy采用同步访问模型，使得proxy服务的单机服务能力在1w qps左右就上不去了，因为这时候同步服务模型所带来的线程切换代价太高，导致cpu system非常高，而此时整体cpu利用率仅仅在40%左右。为了解决这个问题，我们把proxy的服务模型进行异步化改造，让proxy的整体服务能力提升了2.5倍，proxy极限cpu可以压到90%以上。如果查询返回结果稍大，这时千兆网络带宽会成为制约单机proxy服务能力的瓶颈。
因为igraph中所有数据都存放在ssd上，热点数据会被cache在内存中。这样如果某一张表进行数据全量切换时，会造成内存中所有cache的数据都失效。这时候所有对该表的访问都会落在ssd上，如果访问量比较大，会把ssd的iops打满，这时候会对整体服务的稳定性造成巨大的影响。为了降低这种影响，我们在数据切换时采用渐进式引流的数据切换方式，这样可以减轻ssd的iops压力，同时能够让该表的热点数据逐渐cache到内存中，最终我们可以在数据切换过程中实现在线服务的稳定性。
其实在igraph服务性能优化方面，我们做了非常多优化，这些优化琐碎但是非常有收益，比如提供batch访问接口、优化网络中断平衡、调整内核内存回收参数等等，由于篇幅所限，我们不能一一深入说明，还请谅解。
这篇文章给大家简单介绍了igraph在准备2015双十一大促过程中所做的一些工作以及igraph在大促过程中的相关数据表现。由于篇幅有限，无法深入阐述每一项工作的细节。最后，感谢大家一直以来对igraph团队的信任，我们会更加努力地将igraph打造成更加高效、易用的关系查询服务。