办公技巧索引是什么(推荐引擎-索引系统介绍)

提供了海量的视频供用户欣赏，运营人员和算法团队精挑细选的视频资源由CMS（Content Management System）系统进行管理。推荐系统负责将这些缤纷多彩的资源推荐给用户。运营人员不断的调整内容的配置，推荐系统需要快速感知并更新推荐内容。因此，在承接巨大用户流量的同时，还需要让用户及时获取最新内容，以保证良好的用户体验。推荐系统引擎索引系统（以下简称建库）孕育而生，本文将简要介绍该系统架构及相关周边设施的建设。

索引系统架构图

如图所示，建库系统部分主要分为三部分，建库服务，实时监控以及Falcon监控平台，Recommend Build Index DataBase采用Redis作为数据存储层，以下称RBIDB。

第一部分--建库模块

这是整个系统的主要部分，分为以下三个模块：批量建库（Batch Build），增量建库（使用AWS Lambda服务实现），HTTP Interface。

批量建库于每天凌晨，推荐服务流量低谷期间触发，批量将配置完成的数据以与线上相同逻辑从CMS Elasticsearch（下称ES）中组织到RBIDB中，供线上服务使用，由于省去了召回、解析数据的计算开销，提高了性能并降低了线上机器资源，另外也解决了高并发下ES不够稳定的问题。后面会详细介绍。增量建库为在批量建库的基础上，将运营人员在CMS上对数据的调整实时更新到RBIDB中。Http interface为建库服务的日常运维暴露的一个HTTP接口，方便人为干预建库过程。目前支持两类操作，一类是针对于单个资源的索引重建，一类是针对单个类型的批量建库。

第二部分--实时监控模块

实时监控主要负责监控推荐服务从RBIDB取出的数据与线上从ES实时计算得来的数据是否存在差异，确保数据一致性。实时监控部分由延迟队列收集消息，Celery调度消费消息，推荐系统模拟客户端三部分组成。运营人员对CMS数据进行调整后，会同步发送一条SNS消息，订阅了SNS消息的SQS就可以收集到该操作，并在一定时间后使其可见。Celery将调度Worker，调用推荐系统模拟客户端，分别发送两条请求，并在请求中标明本次请求需要推荐系统推荐的数据来源（RBIDB or CMS ES），获取两次响应结果后，对Result列表进行比较。如果存在差异，实时监控系统会调用相关的HTTP接口触发自动重建，并且将本条SQS消息扔回队列中，待后续再次检查。出现diff的数据会被记录diff次数，一旦到达阈值，将把该条数据从建库支持列表中删除，发出警报（邮件 钉钉通知）的同时记录为问题数据，推荐系统对该条数据的推荐将不再使用建库数据， 转而请求CMS ES，确保业务逻辑正常。整个流程完全自动化运行，无需人工干预。整个流程稍后将会被详细介绍。

第三部分--Falcon监控模块

此部分区别于实时监控模块，该模块用于监控增量建库（Lambda）部分是否正常运作。定期运行，对来自于CMS的数据和来自RBIDB的数据进行全量对比，如果发现差异，进行邮件报警，并自动触发重建过程。

索引存储结构图

上图为RBIDB的结构图，作为推荐系统建库服务的核心存储，RBIDB中主要包含四部分内容，用来保障建库服务的正常运行，而RBIDB本身为分布式高可用架构，因此系统稳定性得到保障。

第一部分Current key map提供了数据指针。维护正副索引切换，每个类型的数据索引均采用双buffer切换，确保建库过程中全程无损。

第二部分Key one和Key two提供了索引存储服务，存储每种类型数据索，具体由Current key map中保存的数据指针进行调度。

第三部分Support resource提供了RBIDB支持的数据列表，管理实时监控下的全部正常数据，问题数据将自动从中移出，从而保证线上服务的正确性。

第四部分保存了建库服务运行中的参数保存，以及监控，重试次数等一些参数的存储。

建库核心流程图

上图为推荐系统建库服务的核心部分，全量建库（Batch）和增量建库（Lambda）的结构。全量建库每天定时触发，数据来源为CMS ES，增量建库为全天候运行，数据来源为CMS操作触发的SNS消息。全量建库保证基础性，增量建库保证实时性。全量、增量互为补充，可以在保证实时性的同时，尽可能保证了鲁棒性和强一致性。

建库流程时序

上图为推荐系统建库服务时序图，描述了推荐服务建库系统的核心建库流程。大致流程如下：

每天定时触发全量建库任务，首先将状态置为运行中，并获取当前线上正在使用的索引数据版本。从CMS ES读取数据，交由建库服务进行解析，导入到副索引中。检查SQS消息队列中是否有在建库过程中CMS的数据更改（概率较低，建库一般在深夜流量低谷进行，此处主要为严格保持数据一致性与为后续手动同步数据接口做出保证），如果有数据则将SQS中数据改动交由建库模块处理，并导入副索引中。解析CMS数据逻辑与线上逻辑一致，此处不再赘述。Lambda服务实时获取消息并进行处理（增量建库为全天候任务，当CMS中数据有改动时首先会更新到ES，并且发送一条消息到SNS中），逻辑与全量建库一致。增量过程需要获取当前正在使用的索引数据版本和全量建库运行状态，如果全量建库为非运行状态，增量服务只需要将更改同步到当前正在使用的索引数据即可；否则增量服务除了更新当前版本索引，还需要将更改的信息投送至SQS消息队列。批量建库过程结束后，消化SQS中积压的消息。（由于增量过程会将更新追加到当前索引，并把消息发送至SQS中，所以即使在批量建库过程中遇到数据更新，也可以保证数据严格同步）。切换数据指针。整个批量建库过程完成。触发通知机制，报告建库状态及详情信息。

实时监控时序图

上图为实时监控时序图，描述了实时监控模块在建库服务中进行自动化运维，纠错以及提示报警的主要流程。该模块用于保证推荐系统从建库获取数据与从ES获取的数据的一致性：

CMS中数据被更新并成功触发SNS消息，监控系统获取这条更新操作。Celery调度Worker进行该数据的一致性验证。验证过程为调用推荐系统模拟客户端模块，向推荐系统发送两条Request，并指定一次从建库获取数据，另一次从ES在线计算获取数据。对比两次的Response，如果产生差异，监控模块会调用建库服务的HTTP interface进行数据同步，并将本次消息放回SQS队列，等候下一次验证。记录每条数据的失败次数，一旦超过阈值，监控模块将把本条改动数据从RBIDB的Support resource中删除，并调用报警模块对开发人员进行提醒，目前报警模块植入Email报警通知和钉钉办公软件报警通知。

总结

以上是目前MX Player推荐系统建库服务整个架构和工作流程，建库服务使推荐系统与数据层面解耦，双方数据设计更为灵活。由于对复杂的召回过程、数据解析不在进行在线计算，节约了在线系统开销。

此外，在提升系统稳定性，保证用户体验上面也起到了显著的作用。使用建库数据时推荐系统性能指标及直接使用CMS ES数据时推荐系统性能指标对比见下图（1-2）。使用建库数据时，整个服务更加稳定，不易波动，而直接使用CMS ES数据时，受到ES稳定性的影响（即使在线部分已经加入了相应的熔断机制 ）明显。

图 1. 直接从ES请求数据

图 2. 经过建库后从新索引请求数据

另外， 由于ES的性能在流量增加之后性能恶化，为了服务稳定运行，在线服务的本地缓存时间必须做得很长（分钟级），从而影响了用户及时获得内容更新的体验；而使用建库数据，缓存时间可以大幅缩短（秒级），即使考虑到建库所需的全部链路带来的额外耗时，从数据更新到用户感知的时延也会控制在几秒钟之内。