1. 背景
转转作为国内领先的二手电商平台,商品品类横跨数码3C、家电家居乃至奢品、汽车,用户群体与需求呈现显著差异化。例如,学生群体侧重性价比,白领阶层偏好品质服务。为了实现商品与用户的精准匹配,就需要精细化的运营策略,然而,精细化的运营却面临以下难题:
1.1 精细化运营面临四大难题
- 二手商品数据复杂性高:二手商品除了商品本身的标品属性外,还存在成色、机况、质检报告等大量的非标属性。这些属性描述方式多样,缺乏统一标准,信息分散在商品描述、图片、质检报告等不同地方,导致商品数据结构复杂,难以标准化管理。
- 商品管理和筛选效率低下:传统电商的标准化SPU维度无法有效处理二手商品丰富的非标属性,平台难以基于这些关键属性对商品进行精细化管理和筛选。
- 用户体验受影响:由于缺乏对非标属性的有效利用,导致用户在搜索商品时难以精准定位到符合需求的商品,例如,用户想要搜索“成色好”的二手手机,传统筛选系统可能无法有效支持这种基于非标属性的搜索。
- 运营效率难以提升:由于数据复杂且难以有效管理,平台难以基于数据进行深入分析,无法精准了解商品销售情况、用户偏好等,从而难以制定有效的数据驱动运营策略,限制了运营效率的提升。
1.2 商品标签平台旨在解决上述痛点
- 结构化非标属性数据:将分散、非结构化的非标属性信息转化为结构化的标签,实现数据标准化管理。
- 提高商品管理和筛选效率:基于标签系统,平台可以高效地筛选和管理商品,提升运营效率。
- 提升用户体验:通过基于标签系统的精准搜索和推荐,帮助用户快速找到心仪的商品,提升购物体验。
- 实现数据驱动运营:利用标签数据进行深入分析,为平台运营决策提供数据支持,提升运营效率和竞争力。
2. 系统总览
整个商品标签平台大致上可分为三层:
系统架构图
应用层:应用层作为系统的入口,负责提供用户操作界面(后台配置中心、标签后台组件)和RPC 接口,是用户和外部系统与标签平台进行交互的通道。
服务层:服务层是系统的核心业务处理层,负责执行关键的商品标签匹配、标签生命周期管理、离线数据管理、商品管理和数据互联互通等核心业务逻辑。
数据层:数据层为服务层提供多样化的数据存储能力,包括关系型数据库(MySQL)、搜索引擎(ES)、本地缓存(Local Cache)和分布式缓存(Redis),以满足不同类型数据的存储和高效访问需求。
3. 系统核心设计之如何保证标签的实时性
3.1 背景
作为电商平台,商品的更新和用户的行为都会时刻发生,商品标签的实时性会直接影响到用户的体验和整体的运营效率。那么在标签平台中,是如何设计来保证实时性呢?
实时性设计示意图
解释:增量(给变动的商品重新匹配标签);存量(给符合标签规则的商品进行标签绑定)
3.2 核心设计
- 流量分离:上图中,虽然执行的都是商品和标签的匹配操作,但明确区分了实时性要求高的增量打标和非实时性的存量打标。为什么这么做呢?
流量分离示意图
- 提升实时打标响应速度:增量打标专注于处理商品变更、价格变更等实时事件,通过消息队列驱动,可以做到事件发生时立即触发打标流程,大幅降低打标延迟,保证实时性。
- 降低存量打标对实时性的影响:存量打标通常存在不确定性,标签圈选的商品数量级未知,将存量与增量打标分离,可以避免存量打标任务对实时打标链路造成性能冲击,保证实时打标的稳定性和低延迟。
- 资源隔离,提升系统稳定性:将不同类型的打标任务隔离处理,可以更好地进行资源调配和管理,避免资源争抢,提升系统的整体稳定性。
- 事件驱动:通过对商品进行监听,让系统对商品数据的变更事件立即做出反应,而不是被动等待或轮询。当商品数据发生变化(例如商品创建、更新、价格变动、属性变更等)时,系统能够立即捕获这些事件,并触发后续的打标流程。
事件驱动示意图
- 引入去重 MQ (Deduplication MQ) 机制:在实践中发现,一个商品的某一块数据发生了变化,那么其他数据会产生一种联动效应,一起发生变化,所以在增量通道中新增"ES处理去重MQ"和"增量标签匹配去重MQ"两种去重消息队列,减少因消息重复导致的商品与标签的重复匹配,提升标签数据的准确性和可靠性,降低不必要的资源消耗。
MQ去重示意图
4. 系统核心设计之如何保证数据的一致性
4.1 背景
针对存量打标,是对平台所有存量商品进行标签匹配的操作。涉及大量数据的批量处理,数据量巨大,处理时间长,处理环节多,任何环节出现异常都有可能导致数据不一致的发生。为了避免这种情况的发生,平台建立了一套完整的机制,用于保证数据的一致性。
数据一致性设计流程图
4.2 机制拆解
- 全局统一入口:定义打标任务统一入口,确保每次打标任务都能够按照预设的流程执行下去,最终形成任务流的闭环。
- 全局互斥锁:每个存量打标任务圈选的商品数量是不可预测的,可能存在前一个任务还未执行完成,后一个任务已经启动的情况,所以采用全局互斥锁的操作,来保证同一时刻,只有一个任务在执行打标任务,避免多任务并发执行导致任务流执行紊乱。
- 全局异常捕获:任务即使做了统一入口的操作,但在任务执行过程中,也会出现因为任务内部异常导致执行流中断的情况,所以就引入全局异常捕获机制,并记录异常任务的执行进度,为后续任务恢复提供数据保证。
- 异常任务恢复:每次新任务开始执行之前,默认校验上次任务是否存在异常,如果存在异常,就根据异常任务的执行进度,开展异常任务断点续传的操作,进一步避免由于任务异常中断而导致数据遗漏问题。
- 数据异步处理:利用MQ的异步化处理能力,提升系统效率的同时,并结合MQ的持久化和消息可靠投递机制,保障任务的顺利向下游执行,降低数据丢失的风险。
为了保证数据的一致性,在任务执行的过程中每个步骤环环相扣,严密协作。从任务级别的全局互斥锁,到流程内部的断点续传机制,再到消息队列的可靠传输,以及全局异常监控,每一个步骤都指向了同一个目标:确保存量商品标签数据更新的完整性、准确性和可靠性,最终实现系统数据的一致性。
5. 系统核心设计之如何消除数据读取瓶颈
5.1 背景
在整个系统中,特别是进行规则匹配时,往往需要频繁地根据规则去查找、读取大量的标签基础数据。如果每次都直接从MySQL读取,在高并发、大数据量的情况下,MySQL很容易成为性能瓶颈,严重影响打标整体效率。为了避免这种现象的发生,设计了一套健全的多级缓存结构。
多级缓存设计示意图
5.2 核心理念
- 多级缓存的数据维护
- 始终以MySQL为权威源,所有上层缓存都遵循随MySQL数据变而变的基本原则
- 特殊场景主动清理,在“存量打标任务”启动时,优先主动清理本地缓存和Redis缓存,确保任务基于最新数据进行
- 数据按需加载,缓存数据通常在首次访问时,从更权威的数据源 (Redis 或 MySQL) 按需加载并缓存
- 多级缓存的数据读取
性能高度依赖缓存,多级缓存是保证打标效率的重要组件之一,所以在整个标签系统的匹配流程中,始终遵循缓存优先原则
容错降级能力设计:在整个缓存数据使用中,即使部分缓存层失效,系统仍能退回到下层缓存或数据库,以短暂的性能损失来保证整个标签数据的可用性
多级缓存架构在整个打标系统中至关重要。维护上,以MySQL为权威,缓存失效策略为主,辅以特殊场景清理;读取上,缓存是性能核心,数据获取分层依赖,并具备容错能力。并且这种设计在性能、一致性和可靠性之间取得了平衡,从而支撑起高效稳定的打标流程。
6. 未来构想
标签平台作为转转运营系统中的重要组成部分之一,未来还有很大的效率提升空间,后续也将从以下几部分入手,进一步提升效率:
- 商品维度:支撑商品打标数量级由百万级至千万级
- 标签维度:标签数据的结构化,如对标签数据树形化处理,利用树的特点,提升匹配效率等
7. 总结
转转商品标签平台的成功实践,充分证明了结构化非标数据对于二手电商平台精细化运营的重要性。平台提供了一种技术驱动的解决方案,巧妙地结合了分层架构、事件驱动、消息队列、多级缓存、和数据一致性保障机制等技术手段,有效解决了精细化运营的痛点,并提供强大的技术支持。