30Wqps+闲鱼优惠中台，如何架构的？

小咪咪 2024-03-22 17:41 42阅读 0赞

### 说在前面 ###

在尼恩的（50+）读者社群中，经常遇到一个 非常、非常高频的一个面试题，但是很不好回答，类似如下：

>  *  千万级数据，如何做系统架构？
>  *  亿级数据，如何做做系统架构？
>  *  千万级流量，如何做系统架构？
>  *  亿级流量，如何做做系统架构？
>  *  高并发系统，如何架构？

**最近，这段时间，好几个小伙伴都和尼恩来反馈：在面试过程中，遇到了这样的真题。**

其实，答案不是一成不变的。

高并发、高性能、高扩展的案例，千千万万，尼恩一直结合行业案例，梳理一个最为全面、最为系统化的答案，

这里有一个新的行业案例《兼顾可扩展、高并发与数据一致性：闲鱼鱼优惠系统设计实践》，尼恩从 面试维度，对这个方案，进行二次重构和梳理，现在把其做为参考答案，收入咱们的《[尼恩Java面试宝典 PDF][Java_ PDF]》 V65版本

供后面的小伙伴参考，大家一定好好看看这个生产级别的答案。

> 注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请到文末公众号 【技术自由圈】获取

本文原文：《兼顾可扩展、高并发与数据一致性：咸鱼优惠系统设计实践》 原始方案的作者是闲鱼的资深开发工程师泊垚 ，原文来自于 公众号，闲鱼技术（ID：XYtech\_Alibaba）。

下面的内容，是尼恩是结合自己的3高架构笔记，以及尼恩的3高架构知识体系（3高架构宇宙），在原文的基础上，做的二次架构分析和创作。

### 优惠券业务的场景分析 ###

优惠券业务，在大量的场景中，会有使用。

在我们日常生活中，常常会遇到下面这样的场景：优惠券业务是一种促销方式，通常由商家向消费者提供的折扣或者特价优惠，在推广和销售产品时具有重要的作用。

#### 优惠券业务主要使用场景分析 ####

**场景1：电商平台**

在电商平台上，商家可以通过发布优惠券来吸引更多用户购买商品，从而提高销售额。比如，在双十一或者618等大促销活动中，商家会发布各种优惠券，包括满减券、折扣券、免邮券等等，以达到促销的目的。

**场景2：实体店铺**

实体店铺也可以通过发放优惠券来吸引更多顾客到店消费。

比如，在超市或者餐厅中，可以提供满减券、折扣券、赠品券等等，让消费者享受到更多的实惠，从而增加消费频次和消费金额。

**场景3：O2O平台**

在O2O平台中，商家可以通过发放优惠券来吸引用户使用其服务。

比如，在外卖平台上，商家可以发布满减券、新用户专属券等等，以吸引更多的用户尝试其服务；在打车平台上，也可以发布优惠券来吸引用户使用其服务。

**场景4：品牌推广**

品牌推广也是优惠券业务的一个重要场景。

比如，在新品上市或者品牌促销活动中，可以通过发放折扣券或者礼品券等等，来吸引更多用户尝试品牌产品或者服务，提高品牌知名度和美誉度。

总之，优惠券业务在各个行业中都有广泛的应用，可以帮助商家提高销售额、增加用户粘性和忠诚度，同时也能为消费者提供更多的实惠和福利。

#### 优惠券场景的业务迭代 ####

如何提升优惠券的引流能力。 答案是： 设计一个个性化的优惠券系统，为不同的粉丝群体，设置不同的优惠券价格。

为了设计一个个性化的优惠券系统，闲鱼团队需要考虑以下几个方面：

**粉丝群体分类**

首先，需要将粉丝群体进行分类，比如按照年龄、性别、地域、消费习惯等等进行分类。这样可以更好地理解不同群体的需求和行为特征，有针对性地推出不同的优惠券。

**优惠券类型**

其次，需要确定不同的优惠券类型，比如满减券、折扣券、免单券等等。根据不同的群体需求，设置不同的优惠力度和使用条件，例如对于高消费群体，可以设置更高额度的满减券或者更高折扣力度的折扣券。

**优惠券价格**

最后，需要考虑不同粉丝群体的经济实力和消费能力，合理设置优惠券价格。

例如，对于大学生群体，可以设置较低的价格，以吸引他们尝试新产品或服务；而对于高收入群体，则可以设置更高的价格，以提升产品或服务的价值感。

##### 优惠券的迭代分析： #####

除此之外，可以通过数据分析的方式，不断优化和调整优惠券系统，以达到更好的促销效果和用户满意度。

同时，还需要注意保障优惠券系统的安全性和有效性，例如设置使用期限、使用限制等措施，避免滥用和恶意操作。

#### 闲鱼的个性化优惠场景 ####

闲鱼是一款二手交易平台APP，主要面向年轻用户群体。以下是闲鱼APP的用户分析：

**年龄分布**

闲鱼APP的主要用户群体年龄在18-35岁之间，其中以25-30岁的用户占比最高。这个年龄段的用户更注重物品的性价比和实用性，同时也更善于使用互联网和移动设备进行购物。

**性别分布**

相比于其他二手交易平台APP，闲鱼APP的用户男女比例较为接近，女性用户占比略高。这也反映出闲鱼APP对女性用户的吸引力较大，可能与其简单易用、社区氛围浓厚等特点有关。

**地域分布**

闲鱼APP的用户主要集中在一二线城市，尤以杭州、上海、北京等城市为主。这些城市的用户更注重生活品质和消费体验，对于二手商品的需求也更为广泛和多样化。

**用户行为特征**

闲鱼APP的用户通常具有以下几个行为特征：爱好交友、追求个性化、注重环保节能等等。他们不仅使用闲鱼APP进行二手交易，还会通过闲鱼社区分享生活经验、交流兴趣爱好等，形成了一种类似于社交媒体的共享氛围。

**用户需求和偏好**

闲鱼APP的用户需求和偏好主要集中在以下几个方面：时尚潮流、个性化定制、品质保障等。他们通常会在闲鱼APP上寻找一些独特而实用的物品，包括衣物、配饰、家居用品等等，同时也关注卖家的信誉度和商品质量。

总闲鱼APP的用户具有年轻、多样化、社交化等特点，商家可以根据这些特点进行针对性的营销策略和产品服务优化，提高用户满意度和购买转化率。

在闲鱼上，针对闲鱼交易中的 粉丝群体，提供了 专门的 优惠策略，针对 粉丝购买和粉丝回购的优惠促销场景，提供了一种定向的/个性化的优惠价：

![a0403d286c1a4e57a86429f02f453496.png][]

*  卖家可以按商品分别面向全部粉丝、老粉、已购粉设置不同的优惠价格。
 *  买家在导购、下单等场景可以实时看到自己能够享受的最低优惠价格。

虽然闲鱼没有使用优惠券的概念，使用的优惠价格。 但是和 个性化的优惠券，本质是一样的。

所以，闲鱼的优惠中台的架构，对大家做 个性化的优惠券中台的架构，具有巨大的借鉴的架构。

*尼恩提示：技术自由圈3高社群的宗旨：聚焦研究 3高架构，研究成熟案例，研究生产案例， 为大家做架构提供方案支撑。*

### 海量用户场景问题与挑战 ###

闲鱼APP的DAU，注册用户数2.5个亿，日活跃用户数（DAU）为2900万左右。

按照尼恩的3高架构理论，吞吐量峰值至少在30Wqps+。

这么大的 海量用户场景， 在 优惠券计算、优惠券展示的过程中，存在巨大的技术难题:

*  难题1： 如何描述、存储和计算优惠，提供较好的业务可扩展性?
 *  难题2： **如何保障大流量下，优惠实时计算的性能?**
 *  难题3：为优惠查询加速做的数据同步，如何实现一致性?

### 闲鱼的个性化优惠中台的技术演进 ###

闲鱼的个性化优中台的技术演进, 分为三个阶段来实现：

*  阶段1：分解优惠的基本要素，实现优惠的基本表达和计算；
 *  阶段2：对优惠对象的判定过程进行抽象和加速  
    为了保障大流量下的优惠查询下性能和业务的可扩展性，对优惠对象的判定过程进行抽象和加速；
 *  阶段3：在优惠对象制备的过程中，通过离线+实时的方式同步数据，保障数据一致性。

### 阶段1：分解优惠的基本要素，实现优惠的基本表达和计算 ###

#### 分解优惠的基本要素 ####

一个优惠主要描述了“谁对哪个商品享受什么优惠”，拆解为三个要素就是：

【优惠对象】+【优惠商品】+【优惠价格】。

![18a917aca69845d0a82c004f95c4f8c2.png][]

在粉丝优惠的场景下，优惠对象是指卖家的粉丝、卖家的已购粉丝等，

优惠对象 如何存储呢？

一个卖家的粉丝，可以被描述为“卖家ID\_all\_fans”的符号

一个卖家的已购用户，可以被描述为“卖家ID\_buy\_fans” 的符号 。

这样闲鱼团队可以得到一个优惠规则的描述大致如下：

**【卖家A\_all\_fans】+【商品1234】+【18.88元】，**

对应的业务语义是：

**卖家A的所有粉丝，对于（卖家A的）商品1234，可以以18.88元的优惠价格。**

#### 实现优惠的基本表达和计算的三个步骤 ####

以这条优惠为例，当买家B访问商品1234时，闲鱼团队会执行这样的一个过程：

**第一步： 根据商品，查询优惠规则**

查询商品1234上的优惠规则，发现一条【卖家A\_all\_fans】+【商品1234】+【18.88元】的规则；

**第二步：分析 优惠对象的语义**

分析【卖家A\_all\_fans】表达的含义，表示的是卖家A的全部粉丝可以享受优惠；

**第三步：根据规则的语义，计算当前用户的优惠价格**

确定买家B是否是卖家A的粉丝，如果是，则以18.88元的价格展示优惠或者成交。

#### 闲鱼的优惠中台的架构1.0版本 ####

为了实现了优惠设置和计算的能力，闲鱼的优惠中台的架构1.0版本,大致如下：

![3c33ed984a2f4007bb432ffe7094dff3.png][]

### 阶段2：对优惠对象的判定过程进行抽象和加速 ###

#### 闲鱼的优惠中台的架构1.0版本存在两个问题： ####

*  问题1：优惠对象语义分析，可扩展性差

优惠计算过程需要解析【优惠对象】这个符号背后所包含的业务语义，再由系统进行判断买家是否符合条件，随着业务规则的升级，系统的会变的非常复杂，可扩展性差。

*  问题2：太多的RPC调用，性能差

每一次优惠查询，都需要访问用户的关注关系、购买关系，这整个查询过程非常长，性能低下，当面对大流量时，系统会陷入瘫痪。

#### 对优惠对象的计算进行抽取和解耦 ####

为了解决这两个问题，闲鱼希望优惠计算过程不再需要理解【优惠对象】的语义，判定过程中也不要再去查询各个业务系统。

闲鱼团队发现，优惠对象的判定过程都是在回答“用户是否属于某个群体”，于是，可以将这个关系进行抽象，提前制备并存储起来。

常见的技术手段中，表达一个用户是否属于某个群体有两种实现：

*  在用户对象上打上一个标记。
 *  创建一个“人群”对象，将用户关联到人群。

一般情况下，第一种方式使用于群体较少可枚举的情况，第二种方案适用于群体较多的情况。在闲鱼的实现中，使用了第二种方案。

具体的措施是， 抽取出一个新的 实体：人群 ，并且提前进行 异步计算。

闲鱼将用于描述优惠对象的符号（例如“卖家A\_all\_fans”）作为人群的名称去定义一个人群。按照这个规则，平台为每个卖家的不同分组各定义这样一个人群。

闲鱼定义了人群的概念，并提供了一种实现人群的技术方案，这个架构中，人群在同时充当了“协议”和“缓存”的作用。

人群和用户的关系，如何存储呢？

方案一：可以通过redis string 实现，设计一个类似： `${user_A}` `${crowd_B}` 的key写入redis。

在查询时，查询 `${user_A}` `${crowd_B}` 这个key是否存在，就可以判定user\_A是否属于crowd\_B。

方案二：可以通过redis set 实现，设计一个类似 `${crowd_B}` 的key写入redis, 然后把 `${user_A}` 的用户加入到set 。

在查询时，查询 `${crowd_B}`，是否在 `${user_A}` 的集合中，就可以判定`user_A`是否属于`crowd_B`。

当然，上面仅仅是参考的案例，闲鱼设计中需要根据数据特性进行优化。

如果读者有更好的方案，也可以来高并发社群，技术自由圈（原疯狂创客圈） 中交流。

#### 闲鱼的优惠中台的架构2.0版本 ####

这时闲鱼的得到的整体架构是这样的：

![97a8e9d6ae77480a8fa197e3159eb1d8.png][]

在上面的架构中，顺带缓存了一下优惠数据

事实上，在闲鱼基于中台的解决方案中，从一开始面临的就是这样的架构（实际中台的架构比这个会更复杂一些）。

如果尝试从头演进了这个系统，也得到这样的一个方案。

**从一定程度来说，这也是架构的必然性.**

具体来说，当我们从业务的可扩展性、系统的性能角度从头进行推演的时候，我们发现最终会回到类似的架构上来。

可以说，在特定的业务规模下，架构的演进有它历史的必然性。

### 阶段3：在优惠对象制备的过程中，通过离线+实时的方式同步数据，保障数据一致性 ###

#### 闲鱼的优惠中台的架构2.0版本的问题 ####

在实际落地的过程中，如何将业务系统中的关注和购买关系同步到人群中，并保证数据的一致性。

人群的同步整体上分为两个主要部分：

*  将离线业务数据通过T+1的方式，同步到人群服务中。
 *  通过实时同步的方式，将当天实时产生的关注、取消关注等行为产生的变动，同步的更新到人群服务中。

![d596dd053851459dabc1f50ad16aac4e.png][]

这种结合的方式具有以下优点：

*  实时消费消息进行同步，保障了数据的实时性。
 *  离线T+1的全量同步，保证实时同步过程中产生的数据不一致会被及时的纠正，保障了数据的最终一致。
 *  离线同步解决了数据初始化过程中的全量同步问题。

但上述的两个过程中，会出现两类问题：

*  离线数据因为其数据存储的特征，只会记录存在的关注关系，如果是被删除的关注关系（取消关注），则不会出现在离线数据中。因此实时同步中，因未同步取消关注事件产生了不一致，数据无法被全量同步纠正。
 *  离线同步和实时同步在实际实施过程中，会产生一种常见的数据冲突：用户A今天原本关注了用户B，某天较早的时候取消关注了，如果这个时候的离线数据还没同步完成，全量同步会再次将A对B的关注关系写入到人群中，出现了与实际数据的不一致。

![a40eb7714327493bba594152b388cc78.png][]

#### 闲鱼的优惠中台的架构3.0版本 ####

针对上述的两个问题，分别给出了以下两个解决方案：

*  针对取关数据误差无法通过全量同步纠正的问题，同步过程中，写入人群的时候会添加一个过期时间，这个过期时间略长于离线全量同步的间隔，这样的好处是一旦在实时同步过程中，出现了取关但未同步到人群的情况，这条记录会自动过期，从而避免了不一致的数据在系统中积累。
 *  针对同步过程中发生数据冲突的问题，通过在实时同步的过程中，取关的事件在redis写入一条临时记录，表示该数据近期发生过取关；在全量同步过程中，去比对redis中是否有取关记录，避免发生冲突。

通过上述两个解决方案，闲鱼实现了人群同步的最终一致性，最终实现的方式如图：

![814d72a27a32445d936ac12e38d485eb.png][]

#### 闲鱼数据一致性方案的普适性 ####

这样的同步方案，对于搜索、推荐等大流量的导购场景，提供了充分的数据一致性保障。

绝大多数情况下，数据实时一致，对于小概率出现数据实时同步不一致，通过全量同步保障数据最终一致，满足导购场景的一致性要求。

此外，针对交易这样的要求强一致性但访问规模较小的场景，闲鱼团队通过下单前对人群同步的数据进行核对，保障数据的实时完全一致。

### 闲鱼团队结语 ###

本文从三个部分介绍了优惠的实现：

*  通过对优惠要素的拆解和人群的定义，我们在描述、存储和计算优惠的同时，提供较好的业务可扩展性。
 *  通过提前制备人群数据，我们保障了大流量下的优惠查询下性能，系统能够支持几十万QPS下的毫秒级响应。
 *  在人群同步的过程中，通过离线+实时的方式同步数据，保障了数据的最终一致性。

在优惠的实现过程中，直接面临了一个迭代了多年的优惠中台，需要闲鱼团队通过同步人群数据的方式进行接入。可能一开始会疑惑为什么需要执行一个复杂、高成本且会引入数据一致性风险的同步过程。

但当闲鱼团队从业务的可扩展性、系统的性能角度从头进行推演的时候，闲鱼团队发现最终会回到类似的架构上来。

可以说，在特定的业务规模下，架构的演进有它历史的必然性。

当然，也不是说这样的架构是适用于所有情况的，架构选型还是需要结合实际情况出发量身定制。

### 结合 闲鱼的方案，回顾前面的面试题： ###

*  千万级数据，如何做系统架构？
 *  亿级数据，如何做做系统架构？
 *  千万级流量，如何做系统架构？
 *  亿级流量，如何做做系统架构？
 *  高并发系统，如何架构？

以上的方案，可以作为大家的一个参考答案。 后续尼恩会给大家结合行业案例，分析出更多，更加劲爆的答案。

当然，如果大家遇到这类高并发的面试难题，可以找来尼恩的 社群交流。

### 技术自由的实现路径 PDF： ###

##### 实现你的 架构自由： #####

《[吃透8图1模板，人人可以做架构][8_1]》

《[10Wqps评论中台，如何架构？B站是这么做的！！！][10Wqps_B]》

《[阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了][Link 1]》

《[峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？][21WQps_DAU]》

《[100亿级订单怎么调度，来一个大厂的极品方案][100]》

《[2个大厂 100亿级 超大流量 红包 架构方案][2_ 100_ _ _]》

*… 更多架构文章，正在添加中*

##### 实现你的 响应式 自由： #####

《[响应式圣经：10W字，实现Spring响应式编程自由][10W_Spring]》

这是老版本 《[Flux、Mono、Reactor 实战（史上最全）][Flux_Mono_Reactor]》

##### 实现你的 spring cloud 自由： #####

《[Spring cloud Alibaba 学习圣经][Spring cloud Alibaba]》

《[分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）][Sharding-JDBC]》

《[一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）][SpringBoot_SLF4j_Log4j_Logback_Netty]》

##### 实现你的 linux 自由： #####

《[Linux命令大全：2W多字，一次实现Linux自由][Linux_2W_Linux]》

##### 实现你的 网络 自由： #####

《[TCP协议详解 (史上最全)][TCP_]》

《[网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！][ARP_ MAC_]》

##### 实现你的 分布式锁 自由： #####

《[Redis分布式锁（图解 - 秒懂 - 史上最全）][Redis_ - _ -]》

《[Zookeeper 分布式锁 - 图解 - 秒懂][Zookeeper _ - _ -]》

##### 实现你的 王者组件 自由： #####

《[队列之王： Disruptor 原理、架构、源码 一文穿透][Disruptor _]》

《[缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）][Caffeine _10W_]》

《[缓存之王：Caffeine 的使用（史上最全）][Caffeine]》

《[Java Agent 探针、字节码增强 ByteBuddy（史上最全）][Java Agent _ ByteBuddy]》

##### 实现你的 面试题 自由： #####

[4000页《尼恩Java面试宝典 》 40个专题][Java_ PDF]

以上尼恩 架构笔记、面试题 的PDF文件更新，请到下面《技术自由圈》公号取↓↓↓

[Java_ PDF]: https://blog.csdn.net/crazymakercircle/article/details/124790425
[a0403d286c1a4e57a86429f02f453496.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/01c50a4686ee40d184daaebb6b605a0c.png
[18a917aca69845d0a82c004f95c4f8c2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/21fd8112cd994e70b375408c77e4c422.png
[3c33ed984a2f4007bb432ffe7094dff3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/95b4af2008a74e9f9713c2f4c9e57b1f.png
[97a8e9d6ae77480a8fa197e3159eb1d8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/22e0d85d025f49af800f9ab8c2904ecd.png
[d596dd053851459dabc1f50ad16aac4e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/3a629bb7e36f4cd68b436a5cd9b64fad.png
[a40eb7714327493bba594152b388cc78.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/463b9b56de31431f9ebf60c00af67a7f.png
[814d72a27a32445d936ac12e38d485eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/22b85341b0b94fc797098db7998bb7ac.png
[8_1]: https://blog.csdn.net/crazymakercircle/article/details/129204455
[10Wqps_B]: https://blog.csdn.net/crazymakercircle/article/details/129410795
[Link 1]: https://blog.csdn.net/crazymakercircle/article/details/128848309
[21WQps_DAU]: https://blog.csdn.net/crazymakercircle/article/details/128725701
[100]: https://blog.csdn.net/crazymakercircle/article/details/129145200
[2_ 100_ _ _]: https://blog.csdn.net/crazymakercircle/article/details/128697096
[10W_Spring]: https://blog.csdn.net/crazymakercircle/article/details/129022714
[Flux_Mono_Reactor]: https://blog.csdn.net/crazymakercircle/article/details/124120506
[Spring cloud Alibaba]: https://blog.csdn.net/crazymakercircle/article/details/129559428
[Sharding-JDBC]: https://blog.csdn.net/crazymakercircle/article/details/123420859
[SpringBoot_SLF4j_Log4j_Logback_Netty]: https://blog.csdn.net/crazymakercircle/article/details/125135726
[Linux_2W_Linux]: https://blog.csdn.net/crazymakercircle/article/details/128932396
[TCP_]: https://blog.csdn.net/crazymakercircle/article/details/114527369
[ARP_ MAC_]: https://blog.csdn.net/crazymakercircle/article/details/129334254
[Redis_ - _ -]: https://blog.csdn.net/crazymakercircle/article/details/116425814
[Zookeeper _ - _ -]: https://blog.csdn.net/crazymakercircle/article/details/85956246
[Disruptor _]: https://blog.csdn.net/crazymakercircle/article/details/128264803
[Caffeine _10W_]: https://blog.csdn.net/crazymakercircle/article/details/128123114
[Caffeine]: https://blog.csdn.net/crazymakercircle/article/details/113751575
[Java Agent _ ByteBuddy]: https://blog.csdn.net/crazymakercircle/article/details/126579528