商品卖不动?闲鱼Tellus任务系统来帮你

简介:复杂事件采集+任务系统+实时触达

作者:闲鱼技术-占先

一、业务背景

闲鱼作为一款C2X的app,与淘宝、天猫等B2C的业务模式存在天然不同。个人卖家也是普通的消费者,很多个人卖家相比专业卖家,并不清楚如何卖出自己的商品,问题主要表现在以下两个方面:
1、商品信息不足。闲鱼采用轻发布模式,用户只需要上传几张照片,简单描述一下商品信息,即可在一分钟之内完成发布流程。轻发布模式迎合了用户快速发布的体验,但也导致了商品信息不足的问题。
2、商品定价不合理。有些卖家用户误判了自己商品的市场行情,导致定价和买家预期存在偏差,降低了买家的购买意愿。
所以问题来了,如何在既保证轻发布的同时,提升商品的有效信息量,增加商品宝贝的吸引力,促进成交呢?

二、解决思路

在上述问题背景下,我们想到了做任务的方式引导用户。具体做法是:在轻发布的前提下,通过做任务的方式引导卖家补全商品信息或引导商品降价,从而促进成交。
一方面,商品关键属性的信息补全了,价格变得合理了,就有更多的买家愿意浏览商品并成交。
另一方面,也帮助我们技术小二更好的理解商品的特征,从而更精准地推荐给需要的买家。

三、技术实现与系统沉淀

       在这个解决思路下,我们创造了Tellus-基于用户&商品的任务系统。
有些同学可能问了:“公司内部难道没有类似的系统吗?任务系统应该比较常见吧?”经过调研,发现已有的内部系统大部分是基于用户的任务系统,而闲鱼的任务系统是基于用户&商品维度的,这样的特点导致我们无法复用现有的任务系统,只能通过自研。
 
整体系统结构图
图片 1.png
 
任务的生命周期分为创建任务、展示任务和完成任务。
 
任务创建模块:
创建任务的难点在于之前提到的数据来源复杂的问题,因为任务创建的来源较多,为了降低接入成本,Tellus的任务创建模块使用消息队列来做事件解耦。Tellus使用MetaQ作为消息队列。MetaQ是一款阿里自研分布式、队列模型的消息中间件(RocketMQ)。基于发布订阅模式,有Push和Pull两种消费方式,支持严格的消息顺序,亿级别的堆积能力,支持消息回溯和多个维度的消息查询。通过消息定制,所有的数据源统一发送创建任务的消息,Tellus系统监听此类消息并且根据业务逻辑创建对应的任务,很好地解决了复杂消息源的问题。
 
任务展示模块:
当任务创建后,如何展示任务呢?展示流程如下:
 
 
图片 2.png
我们通过AB实验进行了全方位的探索,Tellus系统支持了丰富的任务类型, 我们尝试了单个任务和组合任务:
 
单个任务展示
图片 3.png
 
组合任务展示
图片 4.png
还支持基于用户维度(例如连续擦亮任务)的和基于商品维度(例如选商品成色)的任务。Tellus系统同时也实现了任务频次的定制,任务可以一次性完成,也可以重复做,可以按照特定顺序完成组合任务,也可以乱序完成,给业务提供了灵活的可配置型。
 
 
任务完成模块
    任务的完成模块分为主动完成逻辑和被动完成逻辑,主动完成可分为任务成功和任务失败,被动完成属于用户的某些app行为触发了完成任务的逻辑,从而在不知情的情况下完成了任务,比如在重新编辑商品的时候添加了商品成色,那么添加成色的任务就自动完成了。不同任务还可以实现个性化的激励步骤,Tellus通过策略模式的设计,将接口开放给业务方开发,每个任务的完成,用户都可以获取到一定的激励,这些激励根据业务的不同而不同,通过接口开放,业务方开发只需要遵守接口的协议,便可以实现定制化开发,完成不同的任务激励机制。
图片 5.png
 
在整个任务的生命周期过程中,还有一个始终都绕不开的难题,就是数据该如何存储,任务数据主要分为两类:一类为任务的详细数据;另一类为任务的元数据。
       针对任务的详细数据,首先要考虑的是关系型数据库还是非关系型数据库,关系型数据库支持事务,可以进行复杂的联表查询,这些对于任务系统并非必须和必要的,任务系统对数据的关联性要求不高(任务数据之间几乎是相互独立的),但是对于数据的存储量级要求较高(百亿级别)。支持海量数据存储的Table store进入了我们的视野。
表格存储(Table Store)是阿里云自研的NoSQL多模型数据库,提供海量结构化数据存储以及快速的查询和分析服务。表格存储的分布式存储和强大的索引引擎能够支持PB级存储、千万TPS以及毫秒级延迟的服务能力。除此之外,Table Store还兼具以下优点:
1、Table Store还是一种全托管的数据库。使用表格存储只需专注于业务研发,无需担心软硬件预置、配置、故障、集群扩展、安全等问题,在保证高服务可用性的同时,极大地减少了管理及运维成本,这样可以使我们把精力全部放在业务的开发上。
2、查询能力强。除了支持主键查询,表格存储还支持多元索引、全局二级索引。
3、高可用。表格存储将数据的多个备份存储在不同机架的不同机器上,并会在备份失效时进行快速恢复,提供99.99999999%(10个9)的可靠性。
4、数据强一致。表格存储保证数据写入强一致,并保证数据 3 副本均写入磁盘,且所有数据保持一致。写操作一旦返回成功,应用程序就能立即读到最新的数据。
基于上述优点,Table Store比较好的满足了我们数据存储的需求。
针对任务的元数据,考虑到使用频率,我们也创建了缓存进行读写,对于任务系统的元数据,我们选取了guava cache作为缓存。原因是guava cache请求快速且简单易用。任务元数据数据量较小,即使每个节点都存储一份缓存,开销也不大,这种情形使用分布式缓存比较重,意义不大。
 

四、业务效果

Tellus由于其功能支持的多样性,可拓展性,以及可配置性的多种特点,在短时间内可以支持大量不同业务场景的上线,这里我们以超级曝光和存量诊断也为为例,具体说明一下。
超级曝光针对新发商品在商品发布时弹出一个弹窗,引导用户进入组合任务页面完成任务,完成后用户可获得超级曝光特权。存量诊断针对存量商品,在宝贝下方透出第一个任务信息,引导用户进入组合任务页面,完成组合任务。上线后,组合任务大幅提高了任务完成率。
图片 6.png

五、开发效率提升

对于Tellus来说,比较大的一个挑战是新增任务数量较多,较短时间内需要支持数百个任务,这几乎是不可完成的工作。为了支持业务的快速试错,并且降低开发成本,Tellus主要做了两个方面的优化,一个是任务模版化,另一个是支持任务的可配置化。
先说说任务的模版化:我们发现任务从表现形式上可以抽象为单选类、多选类、确认类、跳转类等等。将每类任务定制为一个模版,视觉同学针对模板进行视觉抽象,固定展示样式,服务端根据展示样式抽象模板类型,前端完全基于服务端数据驱动,前后端的协议格式举例如下:
图片 7.png
新增任务时,只需要套模版即可,减少了很多重复开发的工作量。
再说下任务的可配置化:在任务模版化的基础上,我们发现对于某些任务,任务的逻辑基本一致,只是对应的任务文案不同。Tellus针对这些简单任务,支持了任务可配置化的开发,目前1.0已经开发完成,原本需要改代码才可以新增一个任务,如今只需要改配置文案即可。后续2.0版本将做运营页面的开发,运营同学只需要在页面上配置即可,不再需要开发人员介入,从而大幅提高开发运营效率。
图片 8.png

六、展望

Tellus后续计划与Omega和Hermes平台对接。Omega是闲鱼一个实时事件采集系统,通过日志采集用户行为事件,通过规则计算,对符合条件的用户调用Hermes精准触达。Hermes是闲鱼的触达系统,之前的公众号文章也有介绍。举个例子:用户发布商品,可以通过omega实时采集这一事件,然后实时生成该商品对应的某些任务,这样相较于消息的方式设计更合理,后期可拓展性更高;和Hermes的联动,更多地体现在通过push等方式去促使用户完成任务,增加任务的曝光。
    Tellus还计划增加一系列激励措施,鼓励用户做任务,最近我们在和闲鱼币的同学进行对接,对于完成某类任务的用户,通过给与一定量的闲鱼币,从而激励用户更多地完成任务。

原文链接:https://developer.aliyun.com/article/769999?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

猜你喜欢

转载自blog.csdn.net/alitech2017/article/details/107939509