快手作品买赞:闲鱼怎么粉丝多

背景

在日常业务开发中，您是否遇到这样的问题：新的需求显示某些业务数据，数据源跨越多个不相关的业务系统，时间跨度较长，需要及时反映实时数据。 数据变化，数据查询的QPS高，所需的rt小。

遇到这样的问题应该如何处理呢？ 下面以闲鱼粉丝系统标签的实现为例，给大家分享一个实用的解决方案。

面临的挑战

粉丝系统标签是闲鱼为Pro用户提供的管理粉丝的基础功能。 “我的粉丝”页面上有多个粉丝系统标签组，包括新粉丝、老粉丝和购买粉丝。 其中，购买粉丝是指有成功交易记录的粉丝，购买粉丝列表中显示历史购买总数，按最新购买时间排序。

对于系统标签，有以下要求：

• 必须包括所有历史数据。 例如，如果购买了粉丝，则必须统计历史交易总数。

• 多场景透明，如IM聊天场景，也要求标签透明，QPS较高。

目标：

• 数据实时更新，反映最新的粉丝购买趋势。

• 查询性能好，QPS 较大，RT 要求高。

• 数据准确且完整。

系统标签面临的问题和挑战与文章开头提到的基本相同。 一句话，当面临多系统业务数据聚合展示的需求时，如何在保证数据准确性的同时，还兼顾实时性和查询性能。

下面讨论此类问题的解决方案。

总体思路及方案选择

为了解决上述问题，常见的解决方案有如下几种，其各自的优缺点列举如下：

以上三种方案各有优缺点。 我们可以考虑结合上面的解决思路来满足文章开头提到的需求。

首先采用第二种方法，每天早上导出不同系统的业务数据，进行离线关联计算。 然后将计算结果转换为schema，作为业务数据的离线数据源。 该方法能够满足覆盖多个业务系统全量历史数据的要求，并保证数据的准确性。 为了在此基础上反映实时数据的变化，可以采用方案3的思想对离线数据进行实时补偿。

可以根据消费业务变更消息进行实时数据补偿。 例如，在系统标签场景中，可以消费follow/unfollow消息和交易消息来生成实时补偿数据。 查询业务数据时，将离线和实时的薪酬数据进行聚合，如下图所示。

最后，要保证查询的高吞吐量和低延迟。 这里有两个方面需要考虑。 首先，在技术选型方面，需要考虑选择高性能的存储系统。 这里可以使用KV存储（例如LevelDB）来保证低延迟。 其次，可以根据查询到的数据视图生成数据存储模式，以尽可能降低数据查询的频率和数据后处理的复杂度。

离线数据和实时数据如何聚合才能保证数据的准确性？ 离线和实时数据准备链路是如何实现的？ 我们以采购的粉体系统标签为例，介绍一下具体的解决方案实现。

开发实用的数据结构和聚合逻辑

系统标签数据存储采用kv存储。 kv存储中的数据主要分为一对一的交易数据和一对多的购买粉丝列表数据。 从离线和实时来看，两种不同类型有各自的离线和实时数据。

之所以有一对一的交易数据，是为了对交易笔数进行正向和反向查询。 添加关注者后，还可以实时查询两个人的历史购买数据。

查询交易笔数时闲鱼怎么粉丝多，第一步是读取一对一的离线交易数据，获取历史交易笔数。 第二步，读取一对一实时补偿交易数据，查询交易时间大于离线数据更新时间的交易订单数，将两者相加得到当前总交易数。

查询购买的粉丝列表时，会将一对多的实时交易数据和一对多的离线数据进行合并，按照最新的购买时间重新排序，然后查询购买的数据服务，获取交易数量并显示给用户。

系统标签数据准备链接

离线数据的准备就是根据订单数据和关注关系的业务系统存储数据，离线生成离线数据表，然后聚合导入到离线kv存储中。

实时数据的准备主要是通过消费交易成功的消息来更新一对一交易的实时数据。 如果是后续关系变更消息，则购买的粉丝列表会实时更新补偿数据。

还有一种情况需要处理。 如果有新粉丝，需要查询该粉丝的历史购买数据，并将其添加到已购买粉丝列表数据中。 新关注的新闻会在特定的更新环节被消费，然后通过查询离线和实时的一对一交易数据获取最新的交易时间，并更新为购买粉丝的实时补偿数据列表。

计划结果

上述方案不仅可以展示完整的历史购买粉丝数据，还可以满足及时响应数据实时变化的要求。 在保证数据准确性的同时，可承载近万QPS，查询rt可控制在几毫秒以内。

总结与展望

本文以闲鱼系统标签系统为例，介绍解决多业务系统中数据实时聚合和展示问题的总体思路。 这种思路可以高效、快速地满足一些业务需求，但也有一定的局限性。 比如热点数据会导致实时补偿数据激增，需要进一步优化。 另外闲鱼怎么粉丝多，在选择数据存储时，还可以考虑使用分析型数据库，例如AnalyticDB。

如果您还有其他解决类似问题的想法，欢迎留言讨论。 谢谢。