说在前面
在尼恩的（50+）读者社群中，经常遇到一个 非常、非常高频的一个面试题，但是很不好回答，类似如下：
- 千万级数据，如何做系统架构？
- 亿级数据，如何做做系统架构？
- 千万级流量，如何做系统架构？
- 亿级流量，如何做做系统架构？
- 高并发系统，如何架构？
最近，这段时间，好几个小伙伴都和尼恩来反馈：在面试过程中，遇到了这样的真题。
其实，答案不是一成不变的。
高并发、高性能、高扩展的案例，千千万万，尼恩一直结合行业案例，梳理一个最为全面、最为系统化的答案，
这里有一个新的行业案例《兼顾可扩展、高并发与数据一致性：闲鱼鱼优惠系统设计实践》，尼恩从 面试维度，对这个方案，进行二次重构和梳理，现在把其做为参考答案，收入咱们的《尼恩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的用户具有年轻、多样化、社交化等特点，商家可以根据这些特点进行针对性的营销策略和产品服务优化，提高用户满意度和购买转化率。
在闲鱼上，针对闲鱼交易中的 粉丝群体，提供了 专门的 优惠策略，针对 粉丝购买和粉丝回购的优惠促销场景，提供了一种定向的/个性化的优惠价：
- 卖家可以按商品分别面向全部粉丝、老粉、已购粉设置不同的优惠价格。
- 买家在导购、下单等场景可以实时看到自己能够享受的最低优惠价格。
虽然闲鱼没有使用优惠券的概念，使用的优惠价格。 但是和 个性化的优惠券，本质是一样的。
所以，闲鱼的优惠中台的架构，对大家做 个性化的优惠券中台的架构，具有巨大的借鉴的架构。
尼恩提示：技术自由圈3高社群的宗旨：聚焦研究 3高架构，研究成熟案例，研究生产案例， 为大家做架构提供方案支撑。
海量用户场景问题与挑战
闲鱼APP的DAU，注册用户数2.5个亿，日活跃用户数（DAU）为2900万左右。
按照尼恩的3高架构理论，吞吐量峰值至少在30Wqps+。
这么大的 海量用户场景， 在 优惠券计算、优惠券展示的过程中，存在巨大的技术难题:
- 难题1： 如何描述、存储和计算优惠，提供较好的业务可扩展性?
- 难题2： 如何保障大流量下，优惠实时计算的性能?
- 难题3：为优惠查询加速做的数据同步，如何实现一致性?
闲鱼的个性化优惠中台的技术演进
闲鱼的个性化优中台的技术演进, 分为三个阶段来实现：
- 阶段1：分解优惠的基本要素，实现优惠的基本表达和计算；
- 阶段2：对优惠对象的判定过程进行抽象和加速
为了保障大流量下的优惠查询下性能和业务的可扩展性，对优惠对象的判定过程进行抽象和加速； - 阶段3：在优惠对象制备的过程中，通过离线+实时的方式同步数据，保障数据一致性。
阶段1：分解优惠的基本要素，实现优惠的基本表达和计算
分解优惠的基本要素
一个优惠主要描述了“谁对哪个商品享受什么优惠”，拆解为三个要素就是：
【优惠对象】+【优惠商品】+【优惠价格】。
在粉丝优惠的场景下，优惠对象是指卖家的粉丝、卖家的已购粉丝等，
优惠对象 如何存储呢？
一个卖家的粉丝，可以被描述为“卖家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版本,大致如下：
阶段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版本
这时闲鱼的得到的整体架构是这样的：
在上面的架构中，顺带缓存了一下优惠数据
事实上，在闲鱼基于中台的解决方案中，从一开始面临的就是这样的架构（实际中台的架构比这个会更复杂一些）。
如果尝试从头演进了这个系统，也得到这样的一个方案。
从一定程度来说，这也是架构的必然性.
具体来说，当我们从业务的可扩展性、系统的性能角度从头进行推演的时候，我们发现最终会回到类似的架构上来。
可以说，在特定的业务规模下，架构的演进有它历史的必然性。
阶段3：在优惠对象制备的过程中，通过离线+实时的方式同步数据，保障数据一致性
闲鱼的优惠中台的架构2.0版本的问题
在实际落地的过程中，如何将业务系统中的关注和购买关系同步到人群中，并保证数据的一致性。
人群的同步整体上分为两个主要部分：
- 将离线业务数据通过T+1的方式，同步到人群服务中。
- 通过实时同步的方式，将当天实时产生的关注、取消关注等行为产生的变动，同步的更新到人群服务中。
这种结合的方式具有以下优点：
- 实时消费消息进行同步，保障了数据的实时性。
- 离线T+1的全量同步，保证实时同步过程中产生的数据不一致会被及时的纠正，保障了数据的最终一致。
- 离线同步解决了数据初始化过程中的全量同步问题。
但上述的两个过程中，会出现两类问题：
- 离线数据因为其数据存储的特征，只会记录存在的关注关系，如果是被删除的关注关系（取消关注），则不会出现在离线数据中。因此实时同步中，因未同步取消关注事件产生了不一致，数据无法被全量同步纠正。
- 离线同步和实时同步在实际实施过程中，会产生一种常见的数据冲突：用户A今天原本关注了用户B，某天较早的时候取消关注了，如果这个时候的离线数据还没同步完成，全量同步会再次将A对B的关注关系写入到人群中，出现了与实际数据的不一致。
闲鱼的优惠中台的架构3.0版本
针对上述的两个问题，分别给出了以下两个解决方案：
- 针对取关数据误差无法通过全量同步纠正的问题，同步过程中，写入人群的时候会添加一个过期时间，这个过期时间略长于离线全量同步的间隔，这样的好处是一旦在实时同步过程中，出现了取关但未同步到人群的情况，这条记录会自动过期，从而避免了不一致的数据在系统中积累。
- 针对同步过程中发生数据冲突的问题，通过在实时同步的过程中，取关的事件在redis写入一条临时记录，表示该数据近期发生过取关；在全量同步过程中，去比对redis中是否有取关记录，避免发生冲突。
通过上述两个解决方案，闲鱼实现了人群同步的最终一致性，最终实现的方式如图：
闲鱼数据一致性方案的普适性
这样的同步方案，对于搜索、推荐等大流量的导购场景，提供了充分的数据一致性保障。
绝大多数情况下，数据实时一致，对于小概率出现数据实时同步不一致，通过全量同步保障数据最终一致，满足导购场景的一致性要求。
此外，针对交易这样的要求强一致性但访问规模较小的场景，闲鱼团队通过下单前对人群同步的数据进行核对，保障数据的实时完全一致。
闲鱼团队结语
本文从三个部分介绍了优惠的实现：
- 通过对优惠要素的拆解和人群的定义，我们在描述、存储和计算优惠的同时，提供较好的业务可扩展性。
- 通过提前制备人群数据，我们保障了大流量下的优惠查询下性能，系统能够支持几十万QPS下的毫秒级响应。
- 在人群同步的过程中，通过离线+实时的方式同步数据，保障了数据的最终一致性。
在优惠的实现过程中，直接面临了一个迭代了多年的优惠中台，需要闲鱼团队通过同步人群数据的方式进行接入。可能一开始会疑惑为什么需要执行一个复杂、高成本且会引入数据一致性风险的同步过程。
但当闲鱼团队从业务的可扩展性、系统的性能角度从头进行推演的时候，闲鱼团队发现最终会回到类似的架构上来。
可以说，在特定的业务规模下，架构的演进有它历史的必然性。
当然，也不是说这样的架构是适用于所有情况的，架构选型还是需要结合实际情况出发量身定制。
结合 闲鱼的方案，回顾前面的面试题：
- 千万级数据，如何做系统架构？
- 亿级数据，如何做做系统架构？
- 千万级流量，如何做系统架构？
- 亿级流量，如何做做系统架构？
- 高并发系统，如何架构？
以上的方案，可以作为大家的一个参考答案。 后续尼恩会给大家结合行业案例，分析出更多，更加劲爆的答案。
当然，如果大家遇到这类高并发的面试难题，可以找来尼恩的 社群交流。
技术自由的实现路径 PDF：
实现你的 架构自由：
《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》
《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》
… 更多架构文章，正在添加中
实现你的 响应式 自由：
这是老版本 《Flux、Mono、Reactor 实战（史上最全）》
实现你的 spring cloud 自由：
《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》
《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》
实现你的 linux 自由：
实现你的 网络 自由：
《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》
实现你的 分布式锁 自由：
实现你的 王者组件 自由：
《队列之王： Disruptor 原理、架构、源码 一文穿透》
《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》
《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》
实现你的 面试题 自由：
以上尼恩 架构笔记、面试题 的PDF文件更新，请到下面《技术自由圈》公号取↓↓↓