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. 总结
转转商品标签平台的成功实践，充分证明了结构化非标数据对于二手电商平台精细化运营的重要性。平台提供了一种技术驱动的解决方案，巧妙地结合了分层架构、事件驱动、消息队列、多级缓存、和数据一致性保障机制等技术手段，有效解决了精细化运营的痛点，并提供强大的技术支持。
