vivo商城促销系统架构设计与实践-概览篇（vivo促销策略）

25-02-10 25

如果您想了解vivo商城促销系统架构设计与实践-概览篇的相关知识，那么本文是一篇不可错过的文章，我们将对vivo促销策略进行全面详尽的解释，并且为您提供关于5G融合计费系统架构设计与实现(一)、Blo

如果您想了解vivo商城促销系统架构设计与实践-概览篇的相关知识，那么本文是一篇不可错过的文章，我们将对vivo促销策略进行全面详尽的解释，并且为您提供关于5G 融合计费系统架构设计与实现 (一)、Blog.6 分布式会话跟踪系统架构设计与实践、B站千万级长连接实时消息系统的架构设计与实践、Java生鲜电商平台-促销系统的架构设计与源码解析的有价值的信息。

本文目录一览：

vivo商城促销系统架构设计与实践-概览篇（vivo促销策略）
5G 融合计费系统架构设计与实现 (一)
Blog.6 分布式会话跟踪系统架构设计与实践
B站千万级长连接实时消息系统的架构设计与实践
Java生鲜电商平台-促销系统的架构设计与源码解析

vivo商城促销系统架构设计与实践-概览篇（vivo促销策略）

一、前言

随着商城业务渠道不断扩展，促销玩法不断增多，原商城v2.0架构已经无法满足不断增加的活动玩法，需要进行促销系统的独立建设，与商城解耦，提供纯粹的商城营销活动玩法支撑能力。

我们将分系列来介绍vivo商城促销系统建设的过程中遇到的问题和解决方案，分享架构设计经验。

二、系统框架

2.1 业务梳理

在介绍业务架构前我们先简单了解下vivo商城促销系统业务能力建设历程，对现促销能力进行梳理回顾。在商城v2.0中促销功能存在以下问题：

1. 促销模型不够抽象，维护混乱，没有独立的活动库存；

2. 混乱的活动共融互斥关系管理，缺乏统一的促销计价能力。

商城核心交易链路中商详页、购物车、下单这三块关于计价逻辑是分开独立维护的，没有统一，如下图所示。显然随着促销优惠的增加或者玩法的变动，商城侧业务重复开发量会显著加大。

（图2-1. 促销计价统一前）

3. 促销性能无法满足活动量级，往往会影响商城主站的性能。

因与商城系统耦合，无法提供针对性的性能优化，造成系统无法支撑越来越频繁的大流量场景下大促活动。

基于这些痛点问题，我们一期完成促销系统的独立，与商城解耦，搭建出促销系统核心能力：

优惠活动管理

对所有优惠活动抽象出统一的优惠模型和配置管理界面，提供活动编辑、修改、查询及数据统计等功能。并独立出统一的活动库存管理，便于活动资源的统一把控。

促销计价

基于高度灵活、抽象化的计价引擎能力，通过定义分层计价的促销计价模型，制定统一的优惠叠加规则与计价流程，实现vivo商城促销计价能力的建设。推动完成vivo商城所有核心链路接入促销计价，实现全链路优惠价格计算的统一，如下图：

（图2-2. 促销计价统一后）

随着一期促销系统核心能力的完成，极大的满足了业务需要，各类优惠玩法随之增多。但伴随而来的就是各种运营痛点：

维护的促销活动无法提前点检，检查活动效果是否符合预期；
随着优惠玩法的增多，一个商品所能享受的优惠越来越多，配置也越来越复杂，极易配置错误造成线上事故；

为此我们开始促销系统二期的能力建设，着重解决以上运营痛点：

提供时光穿越功能，实现用户能够“穿越”至未来某个时间点，从而实现促销活动的提前点检；
提供价格监控功能，结合「商城营销价格能力矩阵」规划的能力，通过事前/事中/事后多维度监控措施，来“降低出错概率，出错能及时止损”。

2.2 促销与优惠券

促销的主要目的就是向用户传递商品的各种优惠信息，提供优惠利益，吸引用户购买，从而起到促活拉新、提高销量的目的。从这种角度来看，优惠券也属于促销的一部分。

但因一些原因vivo商城促销系统独立过程中，并没有与促销系统放一块：

首先，优惠券系统在商城v2.0时就已独立，已经对接很多上游业务，已经是成熟的中台系统；
再者，就是优惠券也有相较与其它促销优惠的业务特殊性，如有发券、领券能力。

在考虑设计改造成本就未将优惠券包括在促销系统能力范畴，但优惠券毕竟也是商品价格优惠的一部分，因此促销计价需要依赖优惠券系统提供券优惠的能力。

2.3 业务架构&流程

至此我们也就梳理出整个促销系统的大概能力矩阵，整体架构设计如下：

（图2-3. 促销系统架构）

而随着促销系统独立，整个商城购物流程与促销系统的关系如下：

（图2-4. 最新商城购物流程）

三、技术挑战

作为中台能力系统，促销系统面临的技术挑战包括以下几方面：

面对复杂多变的促销玩法、优惠叠加规则，如何让系统具备可扩展性，满足日益多变的优惠需求，提升开发与运营效率。
面对新品发布、双11大为客户等大流量场景，如何满足高并发场景下的高性能要求。
面对来自上游业务方的不可信调用，以及下游依赖方的不可靠服务等复杂系统环境，如何提升系统整体的稳定性，保障系统的高可用。

我们结合自身业务特点，梳理出一些技术解决方案。

3.1 可扩展性

扩展性提升主要体现在两块：

优惠模型的定义，对所有优惠活动抽象出统一的优惠模型和配置管理界面；
促销计价引擎的建立，计价模型的统一。

相关的详细设计内容，会有后续文章进行说明。

3.2 高并发/高性能

缓存

缓存几乎就是解决性能问题的“银弹”，在促销系统中也大量使用缓存进行性能提升，包括使用redis缓存与本地缓存。而使用缓存就需要关注数据一致性问题，redis缓存还好解决，但本地缓存不就好处理了。因此本地缓存的使用要看业务场景，尽量是数据不经常变更且业务上能接受一定不一致的场景。

批量化

促销系统的业务场景属于典型的读多写少场景，而读的过程中对性能影响最大的就是IO操作，包括db、redis以及第三方远程调用。而对这些IO操作进行批量化改造，以空间换时间，减少IO交互次数也是性能优化的一大方案。

精简化/异步化

简化功能实现，将非核心任务进行异步化改造。如活动编辑后的缓存处理、资源预占后的消息同步、拼团状态流转的消息通知等等。

冷热分离

对于读多写少场景对性能影响最大的除了IO操作，还有就是数据量，在促销系统中也存在一些用户态数据，如优惠资源预占记录、用户拼团信息等。这些数据都具备时间属性，存在热尾效应，大部分情况下需要的都是最近的数据。针对这类场景对数据进行冷热分离是最佳选择。

3.3 系统稳定性

限流降级

基于公司的限流组件，对非核心的服务功能进行流量限制与服务降级，高并发场景下全力保障整体系统的核心服务

幂等性

所有接口均具备幂等性，避免业务方的网络超时重试造成的系统异常

熔断

使用Hystrix组件对外部系统的调用添加熔断保护，防止外部系统的故障造成整个促销系统的服务崩溃

监控和告警

通过配置日志平台的错误日志报警、调用链的服务分析告警，再加上公司各中间件和基础组件的监控告警功能，让我们能够第一时间发现系统异常

四、踩过的坑

4.1 Redis SCAN命令使用

在Redis缓存数据清除的处理过程中，存在部分缓存key是通过模糊匹配的方式进行查找并清除操作，底层依赖Redis SCAN命令。

SCAN命令是一个基于游标的迭代器，每次被调用之后都会向用户返回一个新的游标，用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数，以此来延续之前的迭代过程。

对于使用KEYS命令，SCAN命令并不是一次性返回所有匹配结果，减少命令操作对Redis系统的阻塞风险。但并不是说SCAN命令就可以随便用，其实在大数据量场景下SCAN存在与KEYS命令一样的风险问题，极易造成Redis负载升高，响应变慢，进而影响整个系统的稳定性。

（图4-1 Redis负载升高）

(图4-2 Redis响应出现尖刺)

而解决方案就是：

优化Redis key设计，减少不必要的缓存key；
移除SCAN命令使用，通过精确匹配查找进行清除操作。

4.2 热点key问题

在促销系统中普遍使用redis缓存进行性能提升，缓存数据很多都是SKU商品维度。在新品发布、特定类型手机大促等业务场景下极容易产生热点Key问题。

热点Key具有聚集效应，会导致Redis集群内节点负载出现不均衡，进而造成整个系统不稳定。该问题是普通的机器扩容无法解决的。如下图某次线上摸排压测时redis负载情况：

常用的解决方案有两种：

散列方案：对Redis Key进行散列，平均分散到RedisCluster Nodes中，解决热点Key的聚集效应。
多级缓存方案：对热点Key增加使用本地缓存，最大限度加速访问性能，降低Redis节点负载。

我们是采用多级缓存方案，参照优秀的开源热点缓存框架，定制化扩展出一整套热点解决方案，支持热点探测、本地缓存、集群广播以及热点预热功能，做到准实时热点探测并将热点Key通知实例集群进行本地缓存，极大限度避免大量重复调用冲击分布式缓存，提升系统运行效率。

五、总结

本篇属于vivo商城促销系统概览介绍篇，简单回顾了vivo商城促销系统业务能力建设历程及系统架构，并分享遇到的技术问题与解决方案。后续我们会对促销系统的核心功能模块（优惠活动管理、促销计价、价格监控和时光穿越）的设计实践进行逐个分享，敬请期待。

5G 融合计费系统架构设计与实现 (一)

　　随着 5G 商用临近，5G 的各个子系统也在加紧研发调试，本人有兴全程参与 5G 中的融合计费系统 (CCS) 的设计、开发、联调工作。接下来将用几篇文章介绍我们在 CCS 实现过程遇到的挑战与架构设计的考量。相信这些宝贵的经验可以适用于更广的软件系统，免于重复地陷入软件开发的焦油坑。

　　5G 系统由 3Gpp 定制统一的架构和协议规范，这也是电信行业一直以来通行的作法。不同的是，5G 以前的规范 3Gpp 总是喜欢独树一帜，比如最出名的 DCC (Diameter Credit Control) 协议。虽然二进制的格式封装可以带来极佳的性能，但这个协议应用的范围也十分有限，仅限于电信行业。

　　5G 规范从一开始，3Gpp 就一改以往的风格，极力与目前主流的技术进行匹配，甚至不惜重构整个通信系统。接下来我们会听到很多熟悉的词汇，包括：微服务、注册与发现、Http2、JSON、RESTFul、容器化、微服务编排等等。没错，新 5G 系统在尽一切可能拥抱最新的技术潮流。正由于这个原因，在设计新的 5G CCS 时，我们发现以前的技术储备全都用上了。这对于一个新系统来说极大地降低了原始开发的风险，在真正动手写代码之前，我们就已经知道项目一定会成功。这点对于新系统的研发至关重要！

　　一切从微服务架构说起…… 在微服务架构兴起前，大部分应用软件系统都采用单体应用架构。如下图所示，单体应用有他的优势 —— 简单。但也有他的缺点，下面这段引自 Introduction to Microservices，作者 Chris Richardson。

" 迈向单体应用的地狱，不幸的是，这个简单的方法有巨大的限制。成功的应用会随着时间推进，变得越来越大。在每次需求更改或者功能增加时，你的开发团队会实现更多的业务功能，这意味要增加很多行代码。在几年后，你的简单的应用将会成长为一个巨大的单体应用。为了提供一个极其简单的例子，我（指作者）最近和一个开发者进行了交流，这个开发者正在写一个工具来分析他们的应用使用的 JAR 彼此之间的依赖，但是这个应用竟然有数以百万行的代码，我确信一定很多的开发者经过很多年的辛苦努力才创造出来了这样的巨无霸。

一旦你的应用成为一个巨大的、复杂的单体应用，你的开发团队一定会陷入痛苦的泥淖不能自拔，任何对于敏捷开发和交付的尝试最终都会陷入挣扎之中。一个主要的问题是这个应用过于复杂了。它太大以至于对于任何一个开发者都无法完全理解。结果就是，修复 bug 和正确地实现新功能变得非常困难，并且会消耗大量的时间。更重要的是，这将会趋向于一个向下的螺旋。如果代码库理解起来很困难，那么也就不会给出恰当的改善方案。你最终会得到一个巨大的、难以理解的 big ball of mud."

　　单体应用给我带来更直观的感受是当系统规模达到一定程度时，维护这个系统不断更新、接受新需求是一个恶梦。首先系统的稳定性会受到挑战：一个微不足道的错误，就可能导致整个系统瘫痪，对此可能一点办法没有。其次，系统的可扩展性不够：对于一个应用系统，不断接受千奇百怪的新需求是这个系统具有生命力的向征，但对于一个庞大的旧系统而言，这点又是每个程序员的恶梦。你不知道在一个几十万行代码的系统里面改几行的后果会是什么，也许什么事也没有，也许错误从此埋下，等发现的时候已经造成不可挽回的损失。想像一下因为你改的几行代码，给电信带来几百上千万的费用计算错误，并且不可回退。

　　解决之道就是微服务架构，同样引用上面同一篇文章的观点：

“微服务架构有很多重要的优点。首先，它解决了复杂性的问题。它将一个本会成为巨大的单体应用分解成一系列服务。在保证整体的功能没有改变的前提下，应用被分成很多的模块或者服务。每个服务都有明确的边界，这种边界是通过远程调用（RPC）或者消息驱动的 API 来确定的。微服务架构模式强制实行模块化，这种在单体应用中是很难去实现的。结果就是，单个服务开发起来更快、也更容易理解和维护。

第二，这个架构使得每个服务可以被独立地开发。开发者可以自由地选择合适的技术，只要这个服务满足 API 交互规范。当然，大多数组织想通过限制技术选项来避免过于无拘无束。然而，这种自由意味着开发者没必要在开始新工程时继续使用过时的技术。当开发一个新的服务时，他们可以选择使用当前的技术。另外，因为服务相对来说很小，那么使用当前的技术重写旧的服务会更加可行。

第三，微服务架构模式使得每个微服务可以被独立部署。当本地的服务发生变化时，开发者不再需要协调这种变化引起的部署问题。只要被测试通过，这些变化就可以被部署。UI 团队可以执行 AB 测试，并且可以快速地迭代 UI 的变化。微服务架构模式使得持续部署成为可能。

最后，微服务架构模式使得每个服务可以被独立地扩展。为了满足吞吐量和可用性，你可以对每个服务部署任意的实例数量。另外，你可以使用最能满足服务资源要求的硬件。例如，你可以部署 CPU 密集型图像处理服务到 EC2 Compute Optimized instances，部署内存数据库到 EC2 Memory-optimized instances。”

　　总结下微服务架构几点要素：注册与发现、API Gateway、服务间通讯……

　　3Gpp 制定的 5G 架构规范也是采用微服务的模式。下图是 5G 系统的总体架构图。5G 系统被拆分为许多个 F (Function)，你问为啥不叫 Service，哈哈，3Gpp 还是要保持自己的个性的吧，我猜。其中 NRF (Network Resource Function) 负责各个服务的注册与发现。标红的是我们要实现的服务 CHF (Charging Function)，与我们打交道的是 SMF。各个服务通过定好的协议进行交互，如：NRF 的接口协议就叫 Nnrf，CHF 的接口协议就叫 Nchf。

　　不止于 5G 的整体架构是微服务架构，每个子服务的内部也都是按微服务的架构重新设计实现的。容器化、微服务架构、服务编排是这两年我们系统的改造重点。相信也是其它子服务的改造重点。5G 核心网未来要满足网络切片的要求，NFV 和微服务化，服务编排都是实现这一切的基础。

原文出处：https://www.cnblogs.com/cdap/p/11077270.html

Blog.6 分布式会话跟踪系统架构设计与实践

调用链trace系统可以帮助技术人员快速的定位问题，查看整个请求的调用链路，及各个链路的耗时情况。方便技术人员针对性的对服务进行性能优化。

概念

参考调用链trace的设计分析的介绍，trace系统的要素包括：traceId、spanId、annotation。

traceId：贯穿整个调用链路，通过traceId来关联链路的所有相关日志
spanId：标识单次请求调用
annotation：记录请求调用的附加信息

简化`trace`日志设计

在调用链trace的设计分析文章中，系统log设计相对复杂，先从最简单的入手开始了解。

微服务A、B、C之间存在相互调用关系，我们为每次请求记录一条log。通过log中的parnetID来确定调用的层级关系，通过spanID来唯标识一个独立请求，通过traceID来收敛所有相关日志。最终就可以确定请求的调用层级结构。

图片描述

从SERVER-C可以看出，日志记录在C服务的总处理时间。在结合SERVER-B的发起请求时间，可以初略得出span2的网络耗时。

特别注意一下span的变化。当向下游服务发起请求时，需要生成一个新的span，并将该span的父节点设置成上一步生成的span。SERVER-B请求SERVER-C描述的就是这个过程。

而当服务收到一个请求时，只有当请求没有关联新的span时，才需要生成一个span。SERVER-C收到SERVER-B的请求，描述的是这种情况。

`Other`日志设计

调用链trace的设计分析文章又是如何实现的呢？文章给出的调用关系如下：

图片描述

两者的区别在于：确定层级的方式不同。这里通过span值的创建规则来确定调用的层级。而前者是通过借助parentID来确定层级。

图片描述

`Annotation`

通过基于Zipkin的Thrift服务RPC调用链跟踪文章了解到，存储span信息可以通过Annotation和BinaryAnnotation来实现。

Annotation用于记录某个时间点发生的event，对event的触发时间、类型有明确规定。而BinaryAnnotation则用来记录用户自定义的信息。也就是说：前者是公用的，后者是个人用的。

因为反向代理路径重写的原因，客户端请求的path和服务端提供服务的path可能不相同，如果你想在系统中定位这种情况，那么你就可以将http.url追加到BinaryAnnotaion属性中。

了解一下BinaryAnnotation日志存储的数据内容：

{
    "app": "app", //所属应用
    "ip": "ip", //ip地址,冗余信息
    "key": "key", //key, 可以设为存储用户session的key, 如果是用来传递用户session信息的, 可以统一约定为: session_id
    "mname": "mname",  //方法名
    "pid": "10000", //进程id,冗余信息
    "sid": "sid", //spanId
    "sname": "sname", //服务名
    "tid": "tid", //traceId
    "timestamp": 1449038780194, //产生的时间戳, 长整型, 精确到毫秒
    "type": "type", //类型,用来区分是记录异常的还是业务流程的等等, 默认是''common''即可
    "value": "value" //如果是传递用户session信息 ,可以直接写在该字段中.
}

参考地址：

调用链trace的设计分析
分布式会话跟踪系统架构设计与实践
基于Zipkin的Thrift服务RPC调用链跟踪

B站千万级长连接实时消息系统的架构设计与实践

本文由哔哩哔哩资深开发工程师黄山成分享，原题“千万长连消息系统”，本文进行了排版和内容优化等。

1、引言

在当今数字娱乐时代，弹幕已经成为直播平台上不可或缺的互动元素之一。

用户通过发送弹幕、送礼等，可以实时在直播画面上展现自己的想法、评论和互动内容，从而丰富了用户观看体验。在这个过程中，实时向终端推送互动信息，就需要用到长连接。长连接，顾名思义，是应用存活期间和服务端一直保持的网络数据通道，能够支持全双工上下行数据传输。其和请求响应模式的短连接服务最大的差异，在于它可以提供服务端主动给用户实时推送数据的能力。
本文将介绍B站基于golang实现的千万级长连接实时消息系统的架构设计与实践，包括长连接服务的框架设计，以及针对稳定性与高吞吐做的相关优化。

技术交流：

移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步发布于：http://www.52im.net/thread-4647-1-1.html）

2、关联文章

《B站基于微服务的API网关从0到1的演进之路》
《石墨文档单机50万WebSocket长连接架构实践》
《百度统一socket长连接组件从0到1的技术实践》
《探探的IM长连接技术实践：技术选型、架构设计、性能优化》
《爱奇艺WebSocket实时推送网关技术实践》
《LinkedIn的Web端即时通讯实践：实现单机几十万条长连接》
《一个基于长连接的安全可扩展的订阅/推送服务实现思路》
《魅族2500万长连接的实时消息推送架构的技术实践分享》
《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》

3、架构设计

3.1概述

长连接服务是多业务方共同使用一条长连接。因为在设计时，需要考虑到不同业务方、不同业务场景对长连接服务的诉求，同时也要考虑长连接服务的边界，避免介入业务逻辑，影响后续长连接服务的迭代和发展。
长连接服务主要分为三个方面：
1）长连接建立、维护、管理；
2）下行数据推送；
3）上行数据转发（目前只有心跳，还没实际业务场景需求）。

3.2整体架构

长连接服务整体构架如上图所示，整体服务包含以下几个部分。
1）控制层：建连的前置调用，主要做接入合法性校验、身份校验和路由管控。主要职责：
1）用户身份鉴权；
2）加密组装数据，生成合法token；
3）动态调度分配接入节点。
2）接入层：长连接核心服务，主要做卸载证书、协议对接和长连接维护。主要职责：
1）卸载证书和协议；
2）负责和客户端建立并维护连接，管理连接id和roomid的映射关系；3）处理上下行消息。
3）逻辑层：简化接入层，主要做长连的业务功能。主要职责：
1）在线人数上报记录；
2）记录连接ID各属性和各节点的映射关系。
4）消息分发层：消息推送到接入层。主要职责：
1）消息封装、压缩和聚合推送给相应的边缘节点；
5）服务层：业务服务对接层，提供下行消息推送入口。主要职责：
1）管控业务推送权限；
2）消息检测和重组装；
3）消息按一定策略限流，保护自身系统。

3.3核心流程

长连接主要是3个核心流程：
1）建立连接：由客户端发起，先通过控制层，获取该设备合法的token和接入点配置；
2）维持连接：主要是客户端定时发起心跳，来保证长连接活跃；
3）下行推送：下行推送由业务Server发起，经由服务层根据相关标识确定连接标识和接入节点，经过消息分发层，把推送到对应的接入层，写入到指定连接上，然后下发到客户端。

3.4功能列表

结合B站业务场景，下行数据推送，提供如下通用功能：
1）用户级消息：指定推送给某些用户（比如给某个主播发送邀请pk消息）；
2）设备级消息：制定推送给某些设备（比如针对未登陆的设备，推送客户端日志上报指令）；
3）房间级消息：给某房间内的连接推送消息（比如给直播间的所有在线用户推送弹幕消息）；
4）分区消息：给某分区的房间推送消息（比如给某个分区下，所有开播的房间，推送某个营收活动）；
5）全区消息：给全平台用户推送消息（比如给全部在线用户推送活动通知）。

4、高吞吐技术设计

随着业务发展壮大，在线用户越来越多，长连系统的压力越来越大，尤其是热门赛事直播，比如s赛期间，全平台在线人数快达到千万，消息吞吐量有上亿，长连系统消息分发平均延迟耗时在1s左右，消息到达率达到99%，下面具体分析下长连做了哪些措施。

4.1网络协议

选择合适的网络协议对于长连接系统的性能至关重要：
1）TCP协议：可以提供可靠的连接和数据传输，适用于对数据可靠性要求较高的场景；
2）UDP协议：是一个不可靠的协议，但是传输效率高，适用于对数据可靠性要求不高的场景；
3）WebSocket协议：也是实现双向通信而不增加太多的开销，更多的用于web端。
接入层拆分成协议模块和连接模块：
1）协议模块：和具体的通讯层协议交互，封装不同通讯协议的接口和逻辑差异。
2）连接模块：维护长连接业务连接状态，支持请求上行、下行等业务逻辑，维护连接各属性，以及和房间id的绑定关系。
针对以上第 1）点，协议模块同时给连接模块提供统一的数据接口，包括连接建立、数据读取、写入等。后续增加新协议，只要在协议模块做适配，不影响其他模块的长连业务逻辑。
优势在于：
1）业务逻辑和通讯协议做了隔离，方便迭代增加通讯协议，简化兼容多通讯协议的实现难度；
2）控制层可以根据客户端的实际情况，下发更优的通讯协议。

4.2负载均衡

采用负载均衡技术可以将请求分发到不同的服务器节点上处理，避免了单一节点的负载过高，提高了系统的扩展性和稳定性。长连增加控制层，做负载均衡。控制层提供http短连接口，基于客户端和各边缘节点实际情况，根据就近原则，动态选择合适的接入节点。接入层支持水平扩展，控制层可以实时增加、减少分配节点。在S赛期间，在线人数快到达千万时，平衡调度各接入节点，保障了各节点的CPU和内存都在稳定的范围内。

4.3消息队列

消息推送链路是：业务发送推送，经过服务层推到边缘节点，然后下发给客户端。服务层实时分发到各边缘节点，如果是房间类型消息，需要推到多个边缘节点，服务层同时还要处理业务逻辑，很影响消息的吞吐量。所以增加消息队列和消息分发层，消息分发层维护各边缘节点信息和推送消息，提高了系统的并发处理能力和稳定性，避免了因消息推送阻塞而导致的性能问题。

4.4消息聚合

当有热门赛事时，同时在线可能达到千万级别，一条弹幕消息就要扩散到千万个终端，假如在线的每个人每秒发一条，需要发送消息量就是1kw*1kw，消息量非常大，此时消息分发层和接入层，压力都会很大。

分析发现：这些消息都是同一个房间的，属于热点房间，比如s赛房间，观众数量是无法减少的，那只能在消息数上做文章。业务消息推送不能减少，又要减少扩散的消息数，就想到了消息聚合。针对房间消息，按照一定的规则进行消息聚合，批量推送：

消息聚合上线后，消息分发层对接入层调用QPS下降60%左右，极大的降低了接入层和消息分发层的压力。

4.5压缩算法

消息聚合后，降低了消息的数量，但是增加了消息体的大小，影响了写入IO，需要减少消息体大小，就想到了消息压缩。压缩算法，选了市面上比较常用的两个：zlib和brotli，进行比较。抓取了线上业务推送的数据，选择最高等级的压缩等级，进过压缩验证：

由此可见，brotli相比zlib有很大的优势，最后选择了brotli压缩算法。选择在消息分发层进行消息压缩，避免在各接入节点多次重复压缩，浪费性能。上线后提升吞吐量的同时，也降低的宽带使用成本。

5、服务保障技术设计

现在有些业务是强依赖长连推送消息，消息丢失，轻则影响用户体验，重则阻塞业务后续流程，进而影响业务流水。针对长连服务消息保障，做了如下工作。

5.1多活部署

多活部署，通过在不同地理位置部署相同的系统架构和服务，实现了系统在单一地域故障时的快速故障转移，从而提高了系统的稳定性和可用性。

长连服务部署，主要做了以下几点：
1）长连接在国内华东、华南、华北地域均部署了接入点，支持三大运营商；华南和华中自建机房也部署了接入点；为支持海外用户，增加了新加坡机房独立接入点；
2）针对业务场景不同，在云上节点和自建节点之间，实时切换，因为云上节点和自建机房的成本是不一样的，在保证服务质量的前提下，尽可能的控制成本。目前线上运行过程中，偶尔会遇到单节点或机房的网络抖动，通过控制层，对有问题的节点，进行秒级摘流，大大减少了对业务的影响。

5.2高低消息通道

多业务消息接入长连接，但不同消息之间的重要性是不一样的，比如弹幕消息和邀请pk消息，丢失几条弹幕对用户体验不会影响很大，但如果邀请pk消息丢失，则会导致pk业务无法进行后续的流程。针对不同等级的消息，采用了高低优消息通道。重要消息走高优通道，普通消息走低优通道。这样重要和普通消息进行了物理隔离，消息分发优先保证重要消息。

针对高优通道，做了双投递的保障，在接入层做幂等去重。首先重要消息是针对用户级别的，量不会很大，所以对接入层的压力不会增加很大。另外双投递的job是部署在多机房的，这也就降低单机房网络抖动造成的影响。高低优通道上线后，遇到过内网出网抖动，当时内网部属的job节点推送消息异常，而云上高优job节点可正常推送，很好的保障了高优消息的到达，进而保障了高优业务不受影响。

5.3高达功能

高低优通道解决的是job到接入层的这一个环节，但消息推送联路涉及到多个环节，比如服务层到job、接入层到客户端。针对整个链路，通过实现必达机制来确保终端的到达率，简称高达功能。

功能实现：
1）每条消息引入msgID，客户端收到消息后进行幂等去重和ack回执；2）服务端针对msgid进行ack检测，针对未ack的，有效期内再次重试下发。最终到达率 = (1-(1-r)^(n+1))，其中：r为广播单次到达率，n为最大重试次数。例如：r = 97%、n=2，那么最终到达率可以达到(1-(1-0.97)^(2+1)) = 99.9973%

6、进出”房“消息的送达保证设计

有些业务场景，需要用到用户进出房消息，比如用户A进入直播间，页面会显示欢迎用户A进入房间，或者是加入在线榜单。
1）进房消息会存在丢失，需要有补偿机制。想到可以通过连接心跳来补偿进房消息，但心跳是持续不断的，连接在线期间，业务希望只收到一次进房消息，所以进房消息需要有幂等机制。
2）出房消息也会存在丢失，如果丢失了，业务无法从在线榜单剔除用户，此时也需要有补偿机制。此时就需要增加连接的状态机，通过心跳维护状态机，当心跳丢失时，认为连接断开，用户退房。

7、未来规划

统一长连接服务经历数次迭代后，目前基本功能已经趋于稳定，后续对长连接服务进行改善和优化。
主要集中在以下几个方向：
1）数据化：进一步完善长连接全链路网络质量数据统计和高价值消息全链路追踪的能力；
2）智能化：端上建联、接入点选择等能够根据实际环境进行自动化调整；
3）性能优化：接入层的连接模块中，处理上下行消息的携程进行共享，减少接入层的携程数，进一步提升单机性能和连接数；
4）功能扩展：新增离线消息功能等。

8、参考资料

[1] 手把手教你写基于TCP的Socket长连接
[2] 正确理解IM长连接、心跳及重连机制，并动手实现
[3] 万字长文：手把手教你实现一套高效的IM长连接自适应心跳保活机制
[4] 用JWT技术解决IM系统Socket长连接的身份认证痛点
[5] TCP/IP详解 - 第11章·UDP：用户数据报协议
[6] TCP/IP详解 - 第17章·TCP：传输控制协议
[7] WebSocket从入门到精通，半小时就够！
[8] 快速理解TCP协议一篇就够
[9] 快速理解TCP和UDP的差异
[10] 一泡尿的时间，快速搞懂TCP和UDP的区别
[11] 到底什么是Socket？一文即懂！
[12] 我们在读写Socket时，究竟在读写什么？
[13] 假如你来设计TCP协议，会怎么做？
[14] 深入操作系统，一文搞懂Socket到底是什么
[15] 通俗易懂，高性能服务器到底是如何实现的
[16] 12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)

（本文已同步发布于：http://www.52im.net/thread-4647-1-1.html）

Java生鲜电商平台-促销系统的架构设计与源码解析

Java生鲜电商平台-促销系统的架构设计与源码解析

说明：本文重点讲解现在流行的促销方案以及源码解析,让大家对促销，纳新有一个深入的了解与学习过程.

促销系统是电商系统另外一个比较大，也是比较复杂的系统，作为一个卖货的，当我们准备好了店铺、商品，那么剩下的就是卖货了。

但是，卖的好不好，有时候并不取决与你的商品质量，而是会不会营销，会不会做活动，甚至说即便你的商品质量不好。但是如果营销活动做得好，那也是可以卖的比别人挣钱的，所以促销活动很重要。它需要分析市场结合自身条件合理的创建促销活动，我们理解的促销活动可能是优惠券，满X减Y，和一些专题活动。

下面对促销活动进行一个系统的总结：广义上来说，一切为了扩大商家销售和用户优势的行为都属于促销活动。

鉴于软件行业和电商系统的特征，电商的促销系统设计应该是分为这几个大的分类：促销活动、CMS系统、优惠券、拼团。

优惠券：这大家可能很熟悉，设置优惠券的规则，然后进行发放，用户可以在购买商品的时候使用优惠券；
拼团：这大家也很熟悉，比如：拼多多大家可能都用过，简单来说需要设置拼团的人数，价格，当拼团人数达到时，拼团成功，然后进行发货。
促销活动：促销活动一般是与CMS系统一起用的，促销活动模块用于设置活动的规则，而CMS系统用户推广活动。其实来说CMS系统对技术的要求是很高的，一些小的电商是不支持CMS的，那么促销活动就会通过广告位进行推广，或者不推广。

先促销活动，再说优惠券，再说拼团，下面详细说说。

一、促销活动

促销活动是什么呢？

接触电商系统设计的产品经理肯定明白，促销活动与优惠券类似，都是在购买商品时如果满足促销条件或者优惠券的条件就会对用户的购买进行优惠。

不同点在于：优惠券是具体的东西，他与商品是分离的，优惠券更加灵活，而促销活动一般来说会与商品绑定，并且这种活动的制定可能还会与节日有关——清明节了，我要搞个促销活动，促销活动的目的性更强，既然是“活动”那么也就注定了推广的重要性。

这也就是为什么促销活动要与CMS系统连用，可以达到更好的宣传效果，下面我从几个方面说说促销活动：

促销活动都有哪些形式，每种形式的规则是什么？
促销活动具体的创建规则与业务流程？
促销活动在订单中的问题。
对促销活动的管理。
促销活动在产品中的具体设计方法。

1. 促销活动的各种形式

满减促销：

满减促销是最常见的一种促销活动，当订单满足一定金额优惠一定金额，一般会产与多个订单，比如：满200减20。这样，为了能够获得优惠可能就会多买几件，满减促销分为两种形式：每满减和阶梯满减，在创建活动的时候只能选择一种形式。

什么每满减呢？

——每满X元减Y元，比如每满100元减10元，如果订单满足一个100元优惠10元，如果订单满足两个100元，优惠20元，以此类推。

什么是阶梯满减呢？

——满X1元减Y1元，满X2元减Y2元，满Xn元减Yn元，比如满100减10元，满200减300元，满300减50元。

显而易见阶梯满减是消费越多优惠比例越大，设置多个阶梯，如果设置了每满减同时设置阶梯满减肯定会有冲突的，因为订单金额相同时优惠金额可能不一样，也就是说，不能共用。

单品促销：

单品促销就很简单喽，就是一件商品打折。

这里说明一下哈，不仅仅是这里，所有的，你没看错，我是说所有的打折都支持两种选择，百分比打折和金额打折，在设置打折规则的时候进行单选百分比或者固定金额。

那么，百分比打折和固定金额打折不同点在于哪呢？

差异化的造成主要体现在价格的变动上，当价格变动对折扣打折是没有影响的。因为是按比例计算，而对于固定金额打折就会有影响，无论价格的过高或者过低，都会造成优惠金额的不合理。但是，固定金额打折的优势是易于消费者理解，优惠价格可控，对于资金的掌控更加稳定。

在进行百分比打折的时候，前端同时显示折扣比例和折扣金额。

套装促销：

套装促销就是多件商品捆绑销售，设置套餐价格，但是在设置的时候其他促销形式有所不同。不同点主要体现在前端的展示上，其他的促销获得是依附在某个商品之上的，当我们进入商品详情页就会看到促销活动的介绍。然后选择规格当，数量等信息，当选择满足条件后就会实现优惠。

而套装促销是多商品，下面的赠品促销，满赠促销也是一样，这种多商品的促销在展现形式上有所不同。

首先来说，我们在设置套装的时候肯定选择多个商品，而每一个商品肯定会有多个SKU信息，那么说我们在选择商品的时候应该精确到商品的SKU，也就是把规格选出来。

为什么要这样选呢？因为我们最终要设置套餐价格，那么这个套餐价格肯定基于某个确定的原价的，也就是每个套装商品的SUK价格。

其次，我们要考虑到前端的展示问题。

既然是促销活动，我们现在还原一个场景：

小张没有鞋穿了，要去商场买鞋，而鞋子肯定有很多规格，小张要买43码红色的鞋子100元，如果选择43码黑色的鞋子可能就是200元了。

这个时候服务员告诉他：我们现在搞套装活动，红色的鞋子加红色的袜子一共110元，红色的鞋子加红色的袜子一共120元，黑色的鞋子加红色的袜子一共210元，黑色的鞋子加黑色的袜子一共220元，红色袜子单独购买20元，黑色袜子单独购买40元。

那么，在这种场景下，小张的选择是多样化的，他可以选择任意的组合，然后给钱就行了。但是，如果把这种场景还原到产品设计中就会产生很多问题。

原因很简单：我们在线下购买商品，当我们提交订单之前，我们面向的是所有的商品。而在网上购物的时候，我们要进入某一个具体的商品才能看到促销活动——我们在网上看到一双鞋，然后活动是加上某个袜子110元，难道我们要返回首页在去寻找那个袜子吗，显然是不行的。

也就是说，套装的选择要在鞋子这个商品的详情页面完成，可是鞋子的商品详情页只能展示鞋子的，比如：尺码，颜色；是无法选择袜子的规格信息的。

所以，一般来说有两种处理方式：

直接把套装做成商品。
在商品详情页面增加套装选项。

直接把套装做成商品：

这个跟商品的编辑流程是一样的，我们在定义商品标题的时候，直接把它写成某个套餐，比如：化妆品套餐，然后利用规格设置不同的套餐价格。

比方说：套餐一牙刷+牙膏10元，套餐二牙刷+牙膏+杯子12元，套餐三单个牙刷5元，以此类推。但是，这种也可以实现套装促销的效果，但是这种方式却偏了促销系统的设计规则。其实根本没有促销规则，商品本身的设定就是套装也就没有规则可言。

在商品详情页面增加套装选项：

这种方式就是设置完套装后，在相关商品的详情页面在选择规格的时候增加套装选项。当选择某个套装后显示套装信息，套装信息是某个具体的SKU信息，套装和主商只能二选一，选择商品就不能购买套餐，选择套装就不能在选择商品信息了。

下面举一个例子：

有A B C D E 五个SKU信息，要进行不同的套装组合，AB AC AD AE BC BD DE ，这是7个套装。

那么，在我们进入A商品的详情页面时，套装信息就会显示所有的，因为跟它都有关。当我们进入B商品的详情页面时，显示AB BC 两种套餐，因为B只有这两种套装。同理，当我们进入E时，显示AE DA ,也就是说只显示跟当前商品有关的套装信息。这是这种设置方式，其实来说产品的设计形式没有固定的，我们也总在寻求更好的解决方案。

赠品促销：

赠品促销也是多商品，当我们在购买主商品满足赠品条件后，就会获得赠品，有两种方式：

只要购买主商品就会获得赠品。
购买一定数量才能获取赠品。

而赠送的形式也有两种：全部赠送，赠送一件或者N件。

在设置的时候我们首先要选择主商品、满赠条件——购买即赠还是制定购买数量赠送。

然后选择赠品——可以选择多个，是全部赠送还是部分赠送，对于赠品只需要在专题页面说明就可以了，然后在详情页面介绍赠品信息。

加价优惠：

加价优惠是当我们满足了一定金额，如果在多付一定的金额就会优惠多少，或者免费赠送什么。

比如：我们一共花了120元想去结账，然后系统提示你，当订单金额达到150元就是享受-20优惠，或者赠送某某商品。对于加价优惠要选择商品，然后设置当满X元，在加Y元时，优惠N元或者免费送F商品，这样设置。

多买优惠促销：

多买优惠促销就是买的越多，优惠越大，可以设置一定金额随便买几件，或者当几件的时候极则，规则的核心是商品的件数——也就是多买。

这个地方既然是多买，那么在设置活动的时候肯定要设置活动的商品池——可以逐个拉去，也可以按分类拉去，多买优惠只有在这些商品上才能生效，其他商品不生效，在设置规则的时候可以设置。

订单满X件N折
订单金额X元内任意购

根据具体情况设定。

定金促销：

定金促销一般会出现在商品预售的时候，当商品进行预售时，设置定金促销，用户提前付定金可以抵扣一定金额。

比如：定金30抵扣50，相当于优惠50元，当商品进行发售的时候付尾款即可完成订单。

2. 促销活动的创建规则与业务流程

促销活动的创建分为三个步骤：

设置活动基本信息：比如活动的标题，活动时间？
设置活动的规则：满赠促销还是单品促销，规则是什么？
设置活动商品：参与活动的商品是什么？

创建完成。

2.1 设置活动的基本信息

活动标题：设置活动的标题，可以设置多个标题，不同标题的作用不同，根据需求看你需要几个标题，然后每个标题展示在哪里。

活动编码：活动的唯一编码，创建活动是自动生成，这种编码很常见，不仅仅是这里，比如订单的编码，账单的编码，这些编码的规则，一般与时间，用户，商品等联系进行组合设置。

活动时间：设置活动的时间，只有在时间范围内活动才生效，如果活动时间未到但是活动开启了，需要在前端进行倒计时提升。

推广渠道：商城一般会有很多用户端，选择活动在哪里投放：H5，公众号，微信小程序，支付宝小程序，APP，PC端商城。

限购数量：商品的限购数量，从这几个方面来考虑，每项都是默认不限购，之所以进行限购主要是考虑到库存的原因：

每个商品的限购数量：当此商品卖出X件不在参与活动。
商品的总数量：参与活动所有的商品一共多少？
每个用户的限购数量：每个用户最多可以购买多少件，达到上限不可继续参与活动，

用户范围：活动的用户范围，当用户在范围内才能参与活动，否则无法参与活动，默认不限制用户范围。

选择指定用户：从用户列表进行获取多个用户。
用户会员等级：选择那个等级的会员才可以参与活动。
用户分组：那个用户组才可以参与活动。

对于用户范围的限定，主要看后台是如何对用户进行分类的，根据这些分类记性限购，如果用户有标签；也可以根据标签进行限购——如果分新用户，老用户，也可以根据此限购，主要取决于系统的设置。

是否与优惠券通用：一般来说促销活动是不与优惠券通用的，现在市面上的电商促销活动又不会与优惠券通用，所以这个地方可以再后台写死，只要是参与促销活动的商品都不与优惠券通用。

推广链接：创建活动时会自动生成活动链接和活动二维码用户推广使用。

2.2 设置活动的规则

在上面已经介绍了活动的形式以及它们不同的规则，但我们设置完活动的基本信息后就要设置活动的规则分类两步：

选择活动类型：满减，单品，套装，赠品，加价，多买，定金。
不同的活动其规则肯定是不同的，然后设置活动的规则。

满减：

选择满减类型：阶梯满减、每满减

设置满减规则：

阶梯满减：满X1减Y1、满X2减Y2、满Xn减Yn……
每满减：订单每满X元减Y元

单品：

选择打折形式：百分比、指定金额

设置打折程度:

百分比：X%
指定金额：X元

套装：设置套装价格——X元

赠品：

设置赠送条件：买即赠、买X件即赠
选择赠送数量：全部赠送，部分赠送（赠送几件）

加价：

设置当满X元时加Y元时生效
设置奖励形式：减N员或者送F商品

多买优惠：设置多买形式——M件N折或者X元任意购

定金：设置定金金额X抵扣金额Y

2.3 设置活动商品

当我们设置完促销规则的时候就要选择活动商品了，不管是什么类型的活动都要选择活动商品。只是不同的活动选择商品的规则不一样，我们来看下：不同促销活动他们选择活动商品时，有什么不同？

满减：选择全部商品或者部分商品，部分商品可以根据分类，品牌进行筛选，可以手动制定某些商品。
单品：选择某一个商品。
套装：选择多个商品组合，每个组合代表一个套装，这里注意，套装商品的选择需要精确到SKU。
赠品：选择主商品，然后选择赠品，赠品可多选可单选，赠品要精确到SKU。
多买优惠：这个选择商品的形式有所不同，要选择商品池，构建一个商品的水池，水池里的商品即为活动商品的范围，用户参与活动必须到水池里选择商品。
加价：设置商品范围，如果奖励形式是赠品，需要设置赠品。
定金：选择定金商品。

2.4 活动创建完成

KO，到现在为止促销活动的创建已经完成，我们总结一些：

首先，定义活动的基本规则，这些基本规则肯定是通用的，它不影响活动规则。

然后，设置活动规则，不同的活动有不同的形式，而不同的形式有不同的设置规则。

最后，根据不同的活动规则选择参与活动的商品。

这样活动就创建完成了，这是促销活动的创建方式与流程。不管什么样的促销活动都可以这样来设置，要把基本设置，活动规则，参与商品相互分开，这样有利于我们理解。下面，最后说说促销活动在订单流程中的问题。

3. 促销活动在订单流程中的问题

当用户进行下单的时候，首先要判断：商品是否参与促销活动？参与哪个促销活动？

然后，判断：是否满足促销规则？满足哪个促狭规则？

最后，计算满足情况下，优惠的金额是多少？在用户订单付款页面要告诉用户优惠金额是多少？

if(活动商品){哪个活动}
if（规则1）{优惠金额计算}
else if（规则2）{优惠金额计算}
erse if（不是活动商品）（不计算优惠）

当用户下单完成后，多个商品可以放在一个订单下统一发货，不能统一发货需要进行拆单，订单的详细问题现在先不说，以后会专门讲订单。

4. 对促销活动的管理

促销活动的管理是管理已经创建出来的活动列表，主要管理的是活动的状态和编辑活动，删除活动。

编辑活动：当活动创建完成后可能因为一些原因需要修改，这个时候需要去编辑。

删除：删除活动后，活动将直接终止。

活动状态管理：未开始，活动中，以结束，是否投放。

未开始：活动时间未到。
活动中：处在活动时间内。
已结束：活动时间已过。

是否投放：当投放之后活动才会生效，投放状态与活动时间状态（其他三个状态）相互独立，互不影响，无论是否投放都有可能处在其他三个状态中的一个，时间状态是无法操作的，可以操作投放状态。

删除：直接删除活动，如果活动正在活动中，那么活动将直接终止。

5. 促销活动在产品中的具体设计方法

5.1促销活动的前端展示

促销活动在用户端的展示主要体现在详情页面和列表页面，当满足促销活动是要在商品的列表页面加上标签。

比如：

“满减”：在商品的详情页面要加上促销栏目。
“促销：满100件10元”，让用户可以看到，如果是套装商品和赠品，需要展示每个商品的SKU信息、商品图片、价格、规格等。

5.2 促销活动的后台设计

促销活动属于促销系统的一部分，对于后台的设计，活动管理和创建活动两个部分。

创建活动：一个创建活动的菜单，点击进去就是创建页面、填各种表单、最后保存，表单的内容上面已经说了，就是促销活动的创建流程。

活动管理：一个活动管理菜单栏，点击进去是活动列表，管理活动状态、投放状态、删除。

二、优惠券

优惠券与促销活动的不同点是：优惠券突出的是商品。

当我们要买哪个商品时，我们会考虑用哪个优惠券，而从设计上来说，专题活动要比优惠券难度高。

1. 优惠券的各种类型

现金券：优惠券直接抵扣现金，不设置使用门槛，比如：50元现金券，现金券之所以称之为现金券，就是因为它可以当做现金直接使用，相当于你自己的钱，没有订单金额的限制。

满减券：与促销活动的满减类似，当订单满足一定金额才可以使用优惠券，比如：满200减20元。

折扣券：在购买某些商品是可以进行打折，比如8折，那么100块钱的东西就是80元。

单品券：单品券是针对特定的商品才可以使用，指定特定商品后可以设置满减或者折扣或者现金券。

分类券：分类券是针对特定分类的商品才可以使用，指定分类后设置满减或者折扣或者现金券。

品牌券：品类券是针对特定品牌的商品才可以使用，指定品牌后设置满减或者折扣或者现金券。

平台券：平台券适用于所有的店铺的优惠券，无论在哪个商家，哪个店铺，都可以使用，优惠金额由平台承担。

店铺券：店铺券是入驻平台的商家自己发布的优惠券，只在本店铺有效，优惠金额由店铺承担。

2. 优惠券的设计规则

优惠券的设计规则分为三步：

创建优惠券
领取优惠券
优惠券核销

2.1 创建优惠券

在创建优惠券的时候需要填写相关的信息，以及选择一些信息。

优惠券名称：给优惠券起一个名称。

选择优惠券类型：现金券，折扣券，满减券。

优惠券面值和使用条件：现金券（X元）、折扣券（满X元Y折）、满减券（满X元减Y元）。

推广渠道：优惠券的发放渠道：公众号、小程序、app、PC端商城。

有效时间：优惠券的有效时间，这里有两种时间的设置方式，相对时间和绝对时间；相对时间（用户领取后X天内有效）、绝对时间（开始时间——结束时间内有效），时间的设置应该应该精确到某年某月某时某分。

使用范围：设置优惠券的使用范围，全部商品可用，还是部分商品可用，如果是部分商品可用可以通过分类品牌进行筛选，最后可以选择指定商品不可用；也可以直接指定某些商品可用。

返还规则：返还规则主要考虑到退款退货的情况，从订单的流程上来说分为正向流程和逆向流程。

正向流程是指：用户正常下单最后收获，没有退款退货操作。计算订单金额时需要减去优惠券的金额，告诉用户优惠金额是多少
逆向流程是指：用户付款之后发生退款，退货操作

逆向流程主要考虑到优惠券的返还问题——怎么返还？

因为可能有很多个商品才同时满足优惠，用户如果仅仅退某款商品该怎么办，退款的细节以后讲订单的时候再说还涉及到一些结账分佣的问题，那么现在在这个地方优惠券的返还规则。

统一不返还：优惠券用了就不能退了，不管你退货还是退款。
优惠分摊：当多个商品满足优惠券使用条件但是用户退款某个商品时，以优惠券的形式返还给用户改商品分摊的优惠金额。优惠券的使用条件不变，比如用户用了一张满200减60的优惠券，订单有两个商品——一个60元，一个120元，根据权重，这减的60元属于60元商品20元，属于120元商品40元，用户退120元商品的就返还给用户一张满200减40的优惠券，那个也一样。

2.2 领取优惠券

优惠券的领取方式有两种：主动领取和被动领取。

主动领取：用户需要在我的优惠券界面主动领取才可以使用优惠券。

被动领取：直接发送给用户，默认领取。

2.3 优惠券核销

当用户下单时需要判断提示用户使用哪种优惠券，逻辑上分为以下几个步骤：

从用户的优惠券列表中筛选可用的优惠券，是否是有效时间，是否在商品范围之内，这里用户未领取的优惠券一同计算。
如果有多种优惠券满足使用条件默认给用户使用优惠金额最高的。
如果金额相同默认为用户选择使用快过期的优惠券。

3. 优惠券的管理

优惠券的管理，主要是：统计优惠券的使用情况。

优惠券发放了多少？用户领取了多少？核销了多少？剩余多少？这些操作对应的时间是什么时候？

4. 优惠券的产品设计方法

4.1 优惠券的前端展示问题

我们主要考虑：优惠券在什么地方展示？展示的形式是什么？

——展示的位置主要有商品详情页面，个人优惠券中心页面。

商品详情页面需要展示用户领取的和未领取的包含在商品下的优惠券，只要是属于商品下的优惠券都需要展示出来。

个人优惠券中心展示用户所有的优惠券，已用的、没有用户，提供领取入口，用户进入可以领取优惠券。

4.2 优惠券管理的后台设计方法

优惠券的后台设计，分为两个菜单：创建优惠券，优惠券管理

创建优惠券：点击创建优惠券菜单进入编辑页面，须填写先关信息，选择相关信息，表单内容为 2.2.1创建优惠券的各种信息可以去上面看；创建完成点击保存优惠券创建成功，在优惠券管理菜单里显示
优惠券管理：主要以列表的形式展示优惠券。

优惠券的管理，主要是对优惠券的统计作用列表信息为下：

优惠券信息：优惠券名称，优惠券金额，使用条件
推广信息：展示推广的渠道
发放量、领取量、核销量。

如果是没有发放完成的优惠券可以执行停止发放或者继续发放操作，还可以执行删除操作，删除后前端的领券中心将没有优惠券，同时从后台的优惠券管理中删除。

关于vivo商城促销系统架构设计与实践-概览篇和vivo促销策略的介绍现已完结，谢谢您的耐心阅读，如果想了解更多关于5G 融合计费系统架构设计与实现 (一)、Blog.6 分布式会话跟踪系统架构设计与实践、B站千万级长连接实时消息系统的架构设计与实践、Java生鲜电商平台-促销系统的架构设计与源码解析的相关知识，请在本站寻找。

本文标签：