背景现在移动网络越来越发达，移动生活越来越丰富。安装一个APP的时间也会逐渐缩短。如果用户在APP中只浏览几分钟甚至几十秒，我们将难以为用户提供更有价值的服务和信息。应用的闪屏或者首焦点，对于闲鱼这样拥有丰富商业生态的应用来说，显然是不够的。那么如何在用户短暂的停留时间内为用户提供更多有价值的信息呢？闲鱼根据用户的访问路径，为用户提供更丰富的优质信息和服务。例如，如果用户发布了产品，我们将推荐当前的免费送货活动。如果用户没有购买到想要的商品，我们会及时向用户推荐相同的商品。为了实现这样的信息提供模式，闲鱼搭建了流量控制系统。什么是交通管制系统？分为云端事件处理和设备端事件处理。云端事件处理可以集中处理所有可以收集的事件。今天介绍负责端侧事件实时处理的框架。端侧框架只运行在单个手机APP上，可以分担云端资源压力，进一步提高实时效率。闲鱼实时交通控制系统的客户端版本是一个合作项目，我们称之为BehaviR。BehaviR框架涵盖用户行为实时处理、高质量数据供给、强实时数据传输、垂直流程实时计算。、决策和用户接入，在广度上，可以支持用户在应用中的全场景，同时也会有针对典型场景的定制化支持。本文介绍的实时处理框架是其中的一部分，负责闭环实时计算。让我们看一下BehaviR的全貌：为了完成闭环实时计算，实时处理框架需要具备以下能力：在实时处理框架中，它负责rules计算部分是设备端的计算引擎。与云端计算引擎一样，设备端计算引擎的目的是对获取的数据进行有状态的实时流计算，没有最终状态。但是，由于计算发生在终端侧，在输入源相对有限、计算资源相对有限、版本受限的计算环境中，为了达到上述目的，需要解决以下问题：如何保证终端侧无终端状态如何在终端侧进行有状态的实时计算，持续提供数据如何有效输出实时计算结果终端侧数据，数据提供流程如图：数据供给能力由BehaviR的数据模块完成，业务方集成在APPBehaviR中，然后将页面操作数据、网络请求数据、存储操作数据等有序的注入到BehaviR中，BehaviR持久化根据计算配置，按需提供需要计算的数据。例如在终端指定如下配置：{"actionTypeIn":["leave"],"sceneIn":["https://market.m.taobao.com/app/idleFish-F2e/idlefish-renting/home","https://market.wapa.taobao.com/app/idleFish-F2e/idlefish-renting/home"],"taskArray":[{"taskType":"py_backtrace","pythonName":"test_cep_rent_rule2","filter":[{"alias":"e1","actionType":"leave"},{"alias":"e2","actionType":"pv"}]}]}我们将配置“actionType”触发器，即当“actionType”为“leave”的事件发生时，BehaviR会将拥有的数据提供给计算引擎。在计算发生之前，计算所需的数据类型是可以预测的，因此BehaviR会根据“filter”中的配置对数据进行过滤，并传输给计算引擎。在APP中运行计算任务之前，每个计算任务都会有自己的配置来指定需要的计算数据类型。在BehaviR中，可以根据端侧所有计算任务的数据需求，对持久化进行优化，尽可能少占用磁盘空间和内存空间。计算云端实时计算能力成为业界先行者。Flink、Siddhi、Spark等不多见，但是设备端的计算框架还没有先例。我们需要在设备端做的是深入了解云端引擎，然后针对设备端环境。轻巧且可定制。结合我们承接业务的经验，我们将计算框架从功能层面划分如下，并与云端进行对比：实时计算窗口可以对数据进行一定的预处理，比如每N秒处理一次到时间间隔，并根据数量处理每N个事件等。最后，由于每个行为都有典型的特征，大多数场景对这些特征都有明确的期望，所以最后以Trigger的形式处理事件，它描述了我们需要开始计算的事件。它是有属性的，当事件属性匹配到Trigger属性时，开始计算。（不确定性有限）状态机和共享缓冲区是计算处理的核心。共享缓冲区是状态计算中状态与事件对应关系的存储优化。我们还在第一个版本中实现了它的必要组件。在并发规划和事件时序控制上，端暂时使用单端事件的有序进入来保证大部分事件的时序，并发的优化不是第一版的瓶颈，所以我们直接放弃并发控制。在单线程上计算。总之，我们去掉了多流处理的设计，弱化了容错机制中的处理，但保留了核心计算能力，同时融入了实时流处理的概念，更贴近我们的应用场景。关于计算部分的具体实现，后面会有更详细的介绍。实现方案选择当框架的概念和功能确定后，我们需要考虑用什么方法来实现它。因此，我们从动态性、执行效率、开发效率等方面对准备好的实施方案进行了比较：由于是第一次尝试实施整个端侧处理框架的研发，希望尽快验证可行性，于是项目上线运行。将存在高度不确定性和稳定性风险。综合以上因素，恰好集团可以有一个高效稳定的Python运行时框架Walle，所以我们选择了Python运行时框架下的Walle，并使用Python进行研发。描述与编译在开始计算之前，我们会有一套基于Python的应用程序编程接口来描述计算逻辑。使用该接口编写后，会在运行时编译构建计算图实例，然后进行计算。该编程接口的表达式以“访问详情并离开”为例，我们可以将其描述为：Pattern('e1')\.where(KVCondition('actionType','pv'))\.and(KVCondition('scene','item_detail'))\.followby('e2')\.where(KVCondition('actionType','leave'))\.and(KVCondition('scene','item_detail'))以获得一致的体验云端与终端之间此外，我们还将支持从控制系统的标准DSL（这个DSL已经成为Blink支持的标准）到Python描述的转换。上面的代码是用DSL描述的，即：EVENT:e1->e2WHEREe1.extra_info.actionType='pv'ANDe1.extra_info.scene='item_detail'ANDe2.extra_info.actionType='leave'ANDe2.extra_info。scene='item_detail'output当计算完成后，我们会输出计算结果，在端侧输出主要分为三个方面，一是业务权限的获取，二是算法模型的输入，第三个是另一个计算输入。由于不同的应用在业务权益方面有自己的展示形式和实现方式，我们只保留通用的通信协议来格式化和输出计算结果。在闲鱼这边，我们会介入协议的响应者，接入闲鱼的决策分发模块进行统一管控。决策分配模块将控制单个策略的到达效果，同时控制同一用户的所有策略。闲鱼APP中注入了丰富的联系方式，供决策模块选择。端侧算法模型在运行时，往往需要特定的行为作为模型运行的触发因素。然后当计算结果作为算法模型输入时，由于端侧算法模型在集团内有统一的运行平台，我们需要将计算输出与统一模型运行框架对接，支持特定计算结果自动唤醒上运行相应的模型，然后将计算结果经过选择性筛选后输出给算法模型。如果需要通过多种计算策略进行级联计算后输出结果，我们会在级联计算前提前约定数据规格。当另一个计算进程需要使用当前的计算结果作为输入时，我们将计算结果模拟为一旦约定的特殊类型的行为数据流入数据模块，然后将对该类型数据的监控添加到另一个计算配置中，它可以顺利执行。流程回顾在我们了解了端侧复杂事件实时处理框架的各个部分之后，我们可以通过下图来回顾整个运行过程：我们会在应用启动时同步本次启动所需的计算任务配置，而数据模块会开始实时处理数据，当处理后的数据匹配任务配置后，就会开始向计算框架提供数据，然后进行实时计算。计算完成后，将调用决策分配模块，由决策模块决定计算结果的输出方向。如果决定要到达用户，它将使用相关的到达配置和表单到达。展望未来，我们目前正在在线闲鱼APP上稳定运行第一版实时处理框架。在云端处理需要5秒左右，现在整个过程毫秒级完成，服务器资源零消耗。但是在计算细节方面，我们还有很多工作要做，比如最后进程退出导致的计算中断，少量事件的乱序问题，需要聚合计算，可以承担更复杂的场景。因此，我们会为更高效的计算和更稳定的服务而努力。更详细的计算详情敬请期待！本文作者：闲鱼科技-星钱阅读原文文字为阿里云内容，未经允许不得转载。
