短视频热门教程在前面说
在Nion（50+）的读者群中，我经常遇到一个非常非常频繁的采访问题，但很难回答，类似于以下内容：
最近，在这段时间里，有几位朋友向念恩汇报：在面试过程中，他们遇到了这样的真实问题。
实际上，答案并不是一成不变的。
高并发、高性能、高扩展的案例上百个，念恩一直在结合行业案例，梳理出最全面、最系统的答案
这里是一个新的行业案例“可扩展、高并发和数据一致性：咸宇宇优先系统设计实践”，念恩从访谈维度出发，对这个方案进行了二次重构和梳理，现在作为参考答案，收录在我们的V67版本中
对于后来的合作伙伴来说，大家一定要好好看看这个生产层次的答案。
注：本文以PDF格式持续更新，关注本公众号【科技自由圈】即可获取到倜恩架构笔记和面试题的最新PDF文件，代码：接收电子书。
本文原文：《兼顾可扩展性、高并发性和数据一致性：咸鱼优惠制度的设计实践》 原方案作者为咸宇高级开发工程师博瑶，原文来自公众号鲜宇科技（ID：XYtech_Alibaba）。
以下内容是倪恩在原文基础上，根据自己的3个高层次建筑笔记和倪的3个高层次建筑知识体系（3个高层次建筑宇宙）所做的二次架构分析和创作。
本文目录
- 在前面说
- 优惠券业务场景分析
- 优惠券业务主要使用场景分析
- 优惠券场景下的业务迭代
- 优惠券的迭代分析：
- 咸鱼个性化报价场景
- 大量用户场景中的问题和挑战
- 咸宇个性化报价平台的技术演变
- 第一阶段：分解报价的基本要素，实现报价的基本表达和计算
- 分解报价的要点
- 实现报价基本表达和计算的三个步骤
- 仙宇优先中间平台架构1.0版本
- 第 2 阶段：抽象并加快确定要约目标的过程
- 咸鱼折扣中间平台1.0版本的架构存在两个问题：
- 优惠对象计算的提取和解耦
- 仙宇折扣中间平台架构2.0版
- 第三阶段：在准备优先对象的过程中，通过离线+实时模式同步数据，保证数据一致性
- Idle Fish's Discount Middle Office 2.0 版本的架构问题
- 仙宇折扣中间平台架构3.0版
- 咸宇数据一致性方案的普遍性
- 鲜宇团队总结
- 结合仙宇的计划，复习一下之前的面试问题：
- 技术实施路径的自由
- 免费获取 11 本科技圣经的 PDF
优惠券业务场景分析
优惠券业务，在大量场景下，都会被使用。
在我们的日常生活中，我们经常会遇到以下几种情况：优惠券业务是一种促销，通常由商家为消费者提供折扣或特价优惠，在促销和销售产品方面具有重要作用。
优惠券业务主要用于情景分析
场景一：电商平台
在电商平台上，商家可以通过发放优惠券来增加销售额，吸引更多用户购买商品。例如，在双11、618等重大促销活动中，商家会发放各种优惠券，包括全额折扣券、折扣券、免费券等，以达到促销的目的。
场景 2：实体店
实体店还可以发行优惠券，以吸引更多顾客到店。
例如，在超市或餐厅，可以提供全额折扣券、折扣券、礼券等，让消费者享受到更多的福利，从而增加消费的频率和数量。
场景三：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万。
根据 Nien 的 3-high 架构理论，吞吐量峰值至少为 30Wqps+。
在如此庞大的用户场景中，优惠券计算和优惠券展示过程中存在巨大的技术问题
咸鱼个性化报价平台的技术演变
咸宇个性化优秀平台的技术演进分为三个阶段
第1阶段：分解偏好的基本元素，实现偏好的基本表达，计算分解偏好的基本元素
折扣主要描述“谁在哪种产品上享受什么折扣”，它分为三个要素：
【优惠对象】+【优惠商品】+【优惠价格】。
在粉丝打折场景中，优惠对象是指卖家的粉丝、卖家购买的粉丝等
如何储存？可以说是
“卖家ID_all_fans的象征的卖家的粉丝
“。
卖方的购买用户可以被描述为“卖方ID_buy_fans”的象征。
这样一来，仙鱼团队就可以得到一个优惠规则的描述，大致如下：
【卖家A_all_fans】+【商品1234】+【18.88元】
相应的业务语义为：
卖家A的所有粉丝都可以获得商品18.88元的折扣价1234（卖家A）。
三个步骤实现报价的基本表达和计算
以这个报价为例，当买家 B 访问产品 1234 时，咸鱼团队将执行这样的流程：
第 1 步：根据产品，查看折扣规则
查询商品1234优惠规则，找到【卖家A_all_fans】+【商品1234】+【18.88元】的规则;
步骤 2：分析选件对象的语义
分析【卖家A_all_fans】所表达的意思，表示卖家A的所有粉丝都可以享受折扣;
步骤三：根据规则语义计算当前用户的优惠价格
确定买家 B 是否是卖家 A 的粉丝，如果是，则显示折扣或以 18.88 元的价格完成交易。
仙宇优先中间平台架构1.0版本
为了实现折扣的设置和计算能力，咸宇的优先中间平台1.0版本的架构大致如下：
第二阶段：对优先对象的判断过程进行抽象和加速 咸宇的优先中间平台1.0版本的架构存在两个问题：
优先计算过程需要分析“优先客体”符号背后的业务语义，然后系统会判断买方是否符合条件。
每次查询折扣时，都需要访问用户的注意力关系和购买关系，这是一个很长的查询过程，性能低下，当面对大流量时，系统会瘫痪。
优先对象计算的提取与解耦
为了解决这两个问题，仙宇希望优先计算过程不再需要理解【优先对象】的语义，在判断过程中也不需要查询各种业务系统。
仙宇团队发现，确定优先对象的过程是回答“用户是否属于某个群体”，因此这种关系可以提前抽象、准备和存储。
在常见的技术手段中，有两种实现方式来表达用户是否属于某个群体：
通常，第一种方法用于要枚举的组较少的情况，而第二种方法适用于具有较大组的情况。在咸宇的实施中，使用了第二种方案。
具体来说，预先提取并异步计算一个新实体，即人群。
羡鱼使用用于描述要约对象的符号（例如，“卖方A_all_fans”）作为人群的名称来定义人群。根据这条规则，平台为不同的卖家群体定义了这样一群人。
先宇定义了人群的概念，并提供了实现人群的技术方案，在这个架构中，人群既是“协议”又是“缓存”。
人群和用户之间的关系是如何存储的？
解决方案 1：您可以使用 Redis String 设计一个类似于 ${user_A} ${crowd_B} 的键来写入 Redis。
查询时，检查键${user_A} ${crowd_B}是否存在，以确定user_A是否属于crowd_B。
解决方案 2：您可以使用 Redis 集设计一个类似 ${crowd_B} 的键并将其写入 Redis，然后将 ${user_A} 的用户添加到该集。
查询时，可以判断${crowd_B}是否在${user_A}的集合中，以确定user_A是否属于crowd_B。
当然，以上只是一个参考案例，仙宇的设计需要根据数据的特点进行优化。
如果读者有更好的计划，也可以来高并发社区，Technology Freedom Circle（原Crazy Maker Circle）进行交流。
仙宇优先中间平台架构2.0版本
此时，鲜宇的整体结构是这样的：
在上面的架构中，产品/服务数据按以下方式缓存
事实上，在咸鱼基于中台的解决方案中，从一开始就面临着这样的架构（实际的中端架构会比这更复杂）。
如果你尝试从头开始发展这个系统，你会得到这样的解决方案。
在某种程度上，这也是建筑的必然性
具体来说，当我们从业务可扩展性和系统性能的角度从头开始推导时，我们发现我们最终会回到类似的架构。
可以说，建筑的演进在特定的商业规模下有其历史的必然性。
第三阶段：在准备优先对象的过程中，以离线+实时的方式同步数据，保证数据的一致性 先宇优先中间平台2.0版本的架构是问题所在
在实际的实施过程中，如何将业务系统中的关注和购买关系同步到人群中，保证数据的一致性。
人群作为一个整体的同步分为两个主要部分：
这种组合具有以下优点：
但在上述两个过程中，会出现两类问题：
咸宇优先中间平台架构3.0版本
针对上述两个问题，现给出以下两种解决方法：
通过以上两种方案，先宇实现了人群同步的极致一致性闲鱼怎么增加粉丝，最终实现的方式如下：
咸鱼数据一致性方案的通用性
这样的同步方案为搜索、推荐等大流量导购场景提供了充分的数据一致性保障。
大多数情况下，数据是实时一致的，对于实时数据同步不一致的概率较小，数据最终通过全同步实现一致，满足导购场景的一致性要求。
此外，对于交易等需要强一致性但访问规模较小的场景，先宇团队在下单前会检查人群同步的数据，确保数据实时完全一致。
仙宇团队总结
本文分三个部分介绍产品/服务的实现：
在实现折扣的过程中，直接面对一个迭代多年的优惠中间平台，咸鱼团队需要通过同步人群数据来接入。起初，您可能想知道为什么需要执行一个复杂、昂贵且数据一致的同步过程，这会带来数据一致性风险。
然而，当宪鱼团队从业务可扩展性和系统性能的角度从头开始推导时，鲜宇团队发现，它最终会回到类似的架构。
可以说，建筑的演进在特定的商业规模下有其历史的必然性。
当然，这并不意味着这样的架构适合所有情况，架构选择还是需要根据实际情况量身定做。
结合仙宇的计划，复习一下之前的面试问题：
以上方案可以作为大家的参考答案。未来，念恩会根据行业案例，给大家带来越来越精彩的答案。
当然，如果遇到这种高并发面试问题，可以联系念的社区进行交流。
通往技术自由之路
念N硬核架构文章，帮你实现架构自由：
《》
《》
《》
《》
《》
《》
.......更多架构文章，正在添加中
实现响应自由：
《》
这是“Flux、Mono、Reactor Combat（历史上最完整）”的旧版本。
实现 Spring Cloud 自由：
《》 PDF格式
“Sharding-JDBC基础原则和核心实践（史上最完整）”。
“一篇文章：SpringBoot、SLF4j、Log4j、Logback 和 Netty 之间的混淆关系（历史上最完整的）”。
实现您的 Linux 自由：
《》
实现您的网络自由：
“TCP协议详细解释（历史上最完整）”。
《》
免费实现分布式锁：
Redis 分布式锁（插图 - 秒理解 - 史上最完整）》
“Zookeeper 分布式锁 - 图表 - 第二次理解”。
免费实现您的 King's Component：
《》
《》
缓存之王：最完整的咖啡因使用（有史以来最完整的）。
Java 代理探针、字节码增强 ByteBuddy（有史以来最完整的）。
免费实施您的面试问题：
获取 11 本技术圣经的免费 PDF
发表评论