为了帮助卖家成交，闲鱼工程师做了些什么？

能帮助卖家提高其成交效率。

可以快速的接入新的场景。

在线状态。当前用户在线状态以及距离上一次在线时长。

询单回复统计。用户在过去半小时的询单回复情况。

买家基于商品和卖家创建对话。

买家基于对话给卖家发送消息。

卖家基于对话回复买家消息。

活动关联若干任务，对卖家进行引导。

任务用于规范卖家行为。

数据用于卖家行为识别。

模块间互相解耦。实现过程中依赖了很多外部系统，明确彼此的边界，做到最小耦合。

模块内单一职责。整个系统的核心是数据流。越简单越稳定，3我们希望降低维护成本，减少风险。

活动元数据管理。

对上层提供查询服务。

从底层数据同步通道同步活动信息。

容灾计算。虽然同步通道会将任务同步至活动，但是当底层通道出现异常时需要有机制保证可以同步从任务粒度实时计算出活动数据，容灾计算启动时系统整体性能降低。

元数据管理。包括任务定义及其任务完成之后的回调。

任务初始化。数据均产自若干三方系统，主要来源于三部分：1）算法模型产出。2）数据分析。3）买家反馈。

三方系统。用一套标准的交互协议实现解耦。

数据一致性。任务模块涉及到多方的读写，需要保证数据的最终一致性。

增量：实时同步任务数据。任务初始化/卖家完成任务。

全量：全量一般在新增活动/活动规则变更时触发。需要解决

分布式任务分发。分布式完成全量任务。

操作幂等。操作可以重复，但不影响最终结果。

全量增量彼此隔离，不影响在线服务。

实时流计算。简单事件(聚合/关联等统计数据)匹配使用实时流计算来完成。资源消耗低，但缺乏灵活性，一些复杂事件虽然也能完成，但是代码复杂度高，不利于维护。

CEP引擎。复杂事件采用CEP引擎做跨事件的模式匹配。功能灵活，可读性强，但是资源消耗高。

持久化。带状态的数据需要持久化，用于接下来的匹配计算。

收益感知。为了加强卖家利益点的感知，在外围添加了收益感知模块，从三方在线系统回流数据作为活动效果的展示，刺激卖家行为，我们认为这有助于卖家心智的培养与增强。

人群圈选。用于活动信息触达卖家。

服务层。规范和端上的协议，提供渲染模版，活动查询，action配置等功能。

卖家理解离不开行为数据的支撑。我们需要更完善的用户行为数据及特征向量作为底层的基础设施。

有了完善的用户行为特征库，如何挖掘出对卖家更有价值的行为点加以引导，这些价值往往充满了差异性，需要结合个性化。

目前的收益反馈机制还较为简单，增加卖家对行为利益点的感知，有助于培养成熟稳定的卖家心智。