（最早接触双11的年份？）
起于2009年，刚开始的双十一还并不出名，电商开展促销月都是以各自的店庆月作为基础的。国美在线是4月份，京东6月份，易购8月份，而淘宝商城选择了双十一作为促销月。促销的初衷是光棍节(11月11日)大家没事干，就该买点啥东西去当礼物送人。于是乎，双11就这样诞生了。
了解双11背景下电商公司的应对措施，有助于提升高访问量背景下的系统架构知识。
从组织架构到技术架构，当前各大电商系统基本趋于中台化。中台在2015由阿里提出，其实是一种企业架构而不是单纯的技术层面，目前几乎各大电商都进行着中台化的建设。
中台没有什么神秘的，说到底，中台就是对 ”共享“ 理念系统化的归纳和总结。
即大中台，小前台的前台，电商中直面用户的B2B,B2C等各个业务线。
业务中台基于公共服务的沉淀，需要收敛一些基础的业务服务，如商品、订单、会员、库存、财务、结算等等。
数据中台不是一个平台，也不是一个系统。数据仓库、数据平台和数据中台是有区别的。简单的举例：数据平台可以理解为数据库，数据仓库类比为报表，而数据中台更贴近上层业务，带着业务属性。
与业务无关的基础沉淀，中间件，系统框架，监控，日志，集成部署等等
不一定存在，系统运维相关的内容，硬件，机房，包括企业云平台的建设等可以划分为单独的运维中台
（根据项目情况有所偏重，例如分布式与一致性是一对矛盾）
该小节从中台的各个团队角度，介绍双11期间的一些应对措施和遇到的问题。
（异步化的目的是什么？大家使用过的mq？遇到的问题？）
场景：
大促期间新增许多需要获取订单状态的服务，比如应对双11而临时增加的数据中台订单大屏展示等
解决：
异步化，并对消息队列调优，多队列分流
问题：
注意异步化引发的乱序问题，一是传输阶段，二是消费阶段
局部有序与绝对有序
图解：
rabbitmq传输：队列级别顺序保障，单消费者消费一个队列可以严格保障顺序性，需要扩充队列数提升性能
kafka传输：分区级别顺序保障，只能保障投放和传输阶段的顺序性
消费阶段：1对1消费存在性能问题，接收消息后对key做二次分发，放入多个内存队列，开启多线程消费
（场景及思考，如果让你做架构设计有什么方案？这些方案有什么优缺点）
双11抢单是最常见的场景，抢单不支付会占据大批量资源，如商品库存。如何取消过期订单是架构师必须面对的问题。主要有以下几种方案：
扫表实现
原理：
通过定时任务轮询扫描订单表，超时的批量修改状态
优点：
缺点:
java延迟队列实现
原理：
通过DelayQueue，每下一单，放入一个订单元素并实现getDelay()方法，方法返回该元素距离失效还剩余的时间，当<=0时元素就失效，就可以从队列中获取到。启用线程池对数据监听，一旦捕获失效订单，取出之后，调用取消逻辑进行处理。（多线程课题案例）
优点:
缺点:
消息队列实现
原理：
设置两个队列，每下一单放一条进延迟队列，设定过期时间。消息一旦过期，获取并放入工作队列，由consumer获取，唤起超时处理逻辑
如果采用的是RabbitMQ，其本身没有直接支持延迟队列功能，可以针对Queue和Message设置 x-message-ttl，用消息的生存时间，和死信队列来实现，具体有两种手段， A: 通过队列属性设置，队列中所有消息都有相同的过期时间，粗粒度，编码简单 B: 对消息进行单独设置，每条消息TTL可以不同，细粒度，但编码稍微复杂。
优点：
缺点：
redis实现
原理：
利用redis的notify-keyspace-events，该选项默认为空，改为Ex开启过期事件，配置消息监听。每下一单在redis中放置一个key（如订单id），并设置过期时间。
优点:
缺点:
被动取消
原理：
在每次用户查询订单的时候，判断订单时间，超时则同时完成订单取消业务。
优点：
缺点：
支付交互流程，支付系统设计偏重，关于做过的那些支付系统2014与2018的架构变化，政策的变动经历。
（2018重复支付事故）
原因：
在第一步发起的时候，用户进入支付方式选择页。选第一个支付方式并支付完后因为通知延迟，以为支付失败。在支付又选了第二种，再次支付。
应对方案：
程序屏蔽，前端js触发按钮置灰或者遮罩提示（支付成功？遇到问题？），或者在支付方式选择页直接跳转。
后端处理，发现不同通道下的支付成功回调，抛消息队列或记录日志。
数据修复：
首先查支付日志，确认针对同一笔订单收到了不同支付渠道的回调。
其次，在支付平台管理后端可以查到入账记录，人工介入。
最后对账阶段会发现对方多帐，我方补单时出现重复订单。
问题处理：
调取退款接口或者在支付渠道的管理后台操作退款（一定要多次确认无误）。
支付但未开单
场景：
用户明明支付成功，但未开通订单
问题分析：
一般支付渠道会间隔性多次回调开单链接，如果支付未开单，银行未回调的可能性比较小，着重排查开单接口是否可用。如果可用追查日志是否出现异常记录。
应对措施：
未支付但已开单
场景：
用户未支付，或者财务中心未收到这笔款项，订单状态已开通。这种就问题比较严重了
应对措施：
首先排除人为操作因素。其次排查系统是否存在漏洞或者级联开单的情况（支付中心测试环境数据回调造成线上意外开单经历）
场景：
用户是期望支付完成的同时立马看到结果。但是中间多层远程的调用，可能发生订单状态更新延迟问题。
解决：
主动查询。在用户查看订单的时候，如果是类似“支付中”的中间态时，触发远程订单状态查询接口。（大家看到的点击“支付完成”跳转的过程，触发远程支付结果查询）
（你所看到的收银台图标内情...）
背景：
保障支付可用性及支付分流，支付中心对接多家渠道
方案：
大促和活动不分家，一般营销中心所面对的主要是促销策略、优惠方式等业务上的架构问题。
从促销活动的范围来看，分为单品促销活动、套装促销活动、店铺促销活动，平台促销活动。
从促销类型来看，分为满减、折扣、赠品等。
业务复杂度高，一般遵循 “同类营销仅可选其一，不同类营销可叠加” 的规则。同类叠加意义不大且会造成系统复杂度上升，引发用户困惑。
用户体验上的设计，比如购物车里商品的排序，按商铺分门别类。优惠总价格及时调整。这些依赖于前端的ui设计和交互体验。
(SPU , SKU 基础概念，如何设计表结构？京东怎么做的)
赠品有两种设计方案，一种是不做单独的SKU，只有一个空的描述，设计简单，缺点是没有商品详情页，无法给用户直观的查看和估值。
另一种是单独做SKU，赠品也会作为一个商品存在，与主商品关联，下单的时候将会自动加到商品列表，价格降为0。这种更为常见。整个商品有完善的详情页，用户可以直接看到价格甚至单独下单购买。
检查同类别促销，将最大优惠力度的规则应用到订单，并且满足排他性，同类只享受其一。比如满10减3，满20减5，那么用户购买大于20时，只减5即可。
不同类别不做排斥，如购物车整体满减后，不影响单个商品的折扣。在记录数据时，优惠要细化到每个单独的订单明细上。退款也做到明细级别的单独退。
（有没有遇到精度问题？价格字段如何设计？）
满减或平台券等优惠，在多个商品下单时，涉及到金额的分摊。即 优惠总额度/购物车总额 ，得到比例后再按比例均分到每个商品。只有分摊才能在发生部分退款时退回真实金额。
但是这会涉及到一个精度问题。举例如下：满99减9活动，假设用户购买了 30+40+50=120，3件商品应付111元。按比例折算的话，9/99取4位小数是0.9090，那么分摊后为 30x0.9090+40x0.9090+50x0.9090=109.08与实际支付金额出现偏差。这会造成财务无法平账。
解决方案：记账时在订单明细记录，将误差 111-109.08=1.92计入金额最大的明细，也就是50元商品上。那么最终记账为：30x0.9090 + 40x0.9090 +（50*0.909+1.92）= 111
退单后要同时恢复用户的权益，比如优惠券的再次使用，限购次数等。确保用户体验。
这个和超时订单设计方案类似，前面已经提到不再赘述。
普通商品可以直接借助数据库锁实现，一般分乐观锁和悲观锁两种方案，如果采用悲观锁（如select语句带forupdate），会带来很大的性能阻塞，所以更多的采用乐观锁设计。（幂等性课题的锁机制有详细讲解）
乐观锁就是在最后执行库存扣减操作时，将事务开始前获取的库存数量带入到SQL语句中作为更新的where条件，如果数量相等，则该条更新库存的语句成功执行返回update条数为1；如果不相等，则表示该商品的库存信息已经被其他事务修改，需要放弃该条update的执行，采用重试处理。
库存秒杀商品因为大批量的访问在一瞬间涌入，数据库扛不住。可以采用 redis缓存做decr处理，正常下单后，再使用mq异步更新到db。（秒杀不超卖课题的库存控制）
数据库层的调优，一般发生在大促前的预备阶段，一旦大促开始，对数据库的优化已经来不及了。
（业务篇红包雨课题里有缓存结构的深度应用）
热点数据预热：
（常规加载机制画图展示）
常规缓存设计趋向于懒加载，大促期间的热点数据尽量做到预热加载。比如某个促销专题，不要等待活动开始的一瞬间再读库加缓存，搞不好引发击穿。
细粒度设计：
（细粒度缓存结构画图展示）
集合与单体分开存储，缓存结构细粒度化。如某个橱窗的推荐商品列表，常规存储一个key，value为整个商品集合。优化为列表与每个商品详细信息设置两个独立缓存值，在查询环节组装，可以降低发生修改时对缓存的冲击。新增一个推荐则失效列表，修改商品则仅仅失效当前商品缓存。
可用性：
（回顾三种缓存问题）
优化缓存体系，对关键业务请求，如商品详情页，采用多级缓存处理
首先看浏览器缓存，一般浏览器缓存可分为两种手段，分别交给浏览器和服务端执行
CDN：借助CDN的dns解析，对用户做ip分流，CDN作为应用服务器的代理，抵挡前端的流量洪峰。同样，前面提到的http缓存策略对CDN依然有效。
nginx缓存：nginx除了作为负载均衡，也可以作为请求级别的缓存，一段典型配置如下：
proxy_cache_path 缓存文件路径
levels 设置缓存文件目录层次；levels=2:2:2 表示三级目录，每级用2位16进制数命名
keys_zone 设置缓存名字和共享内存大小
inactive 在指定时间内没人访问则被删除
max_size 最大缓存空间，如果缓存空间满，默认覆盖掉缓存时间最长的资源。
# 定义缓存路径、过期时间、空间大小等
proxy_cache_path /tmp/nginx/cache levels=2:2:2 use_temp_path=off keys_zone=my_cache:10m inactive=1h max_size=1g;
server {
listen 80;
server_name xxx.xxx.com;
# 添加header头，缓存状态信息
add_header X-Cache-Status $upstream_cache_status;
location / {
# 定义缓存名
proxy_cache my_cache;
# 定义缓存key
proxy_cache_key $host$uri$is_args$args;
# 针对返回状态码单独定义缓存时间
proxy_cache_valid 200 304 10m;
# url 上设置请求 nocache=true 时不走缓存。
proxy_cache_bypass $arg_nocache $http_nocahe;
proxy_pass http://localhost:8080;
}
}
复制代码 分布式缓存：redis做应用层缓存，不多解释。但是要注意做好扩容预案和业务层优化
（算法与数据结构应用 - 限流算法有详细实现）
CDN的引入本身起到了按ip分流的作用，但是我们可以在下层做到更细粒度化的控制。根据业务情况将不同的请求分流到各自的服务器。
限流不同与分流，是对下层的保护，当系统超过一定流量后，超过的流量做直接拒绝处理，以便保护后端的服务，原则就是要么不进来，进来的都正常服务。常见的限流算法有三种：计数器（滑动窗口）、漏桶、令牌桶。
根据不同的业务线分发请求，配备二级域名如b2b.xxx.com，b2c.xxx.com，或者在nginx软负载层针对不同虚拟主机名做upstream分发
新上的双11活动页，或者促销专题页面，采用新访问入口和机器部署，与主站分离。活动结束后也利于机器资源的快速释放（有没有遇到临时性需求的场景？上线就用1天）
按不同的请求终端分流，在header头的user-agent中可以捕获用户的访问终端。android，ios，pc，根据不同终端设备，做流量分发，到不同的应用机器。同时方便对用户终端流量的监控和统计。
评估双11可能的流量，结合具体业务模块，配备对应限流措施。主要有流量限制和连接数限制两个维度。
流量限制：限制访问频率，其目的是基于漏桶算法实现ip级别的防刷。Nginx中使用 ngx_http_limit_req_module 模块来限制请求的访问频率，基于漏桶算法原理实现。
#$binary_remote_addr 表示通过remote_addr这个标识来做限制
#binary_的目的是缩写内存占用量，是限制同一客户端ip地址
#zone=one:10m表示生成一个大小为10M，名字为one的内存区域，用来存储访问的频次信息
#rate=1r/s表示允许相同标识的客户端的访问频次
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /b2b/ {
#zone=one 设置使用哪个配置区域来做限制，与上面limit_req_zone 里的name对应
#burst=5,设置一个大小为5的缓冲区,当有大量请求时，超过了访问频次限制的请求可以先放到这个缓冲区内
#nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503,如果没有设置，则所有请求会等待排队
limit_req zone=one burst=5 nodelay;
}
}
复制代码 连接数限制：Nginx 的 ngx_http_limit_conn_module模块提供了对资源连接数进行限制的功能。（同一个出口ip，如公司内部共享一个出口ip，可能会被整体限制）
#$binary_remote_addr同上
limit_conn_zone $binary_remote_addr zone=addr:10m;
server {
location /b2b/ {
# 限制每个ip下最大只能有一个连接
limit_conn addr 1;
}
}
复制代码 从代理服务器放进来的流量，会进入应用服务器，第一道关卡是微服务的网关。应对大促，针对各个微服务具体业务具体分析，配备对应限流措施。zuul和gateway是团队中最常遇到的网关组件。
zuul.routes.userinfo.path=/user/**
zuul.routes.userinfo.serviceId=user-service
zuul.ratelimit.enabled=true
zuul.ratelimit.policies.userinfo.limit=3
zuul.ratelimit.policies.userinfo.refresh-interval=60
zuul.ratelimit.policies.userinfo.type=origin
复制代码routes:
- id: user_route
uri: http://localhost:8080
predicates:
- Path=/*
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 1
redis-rate-limiter.burstCapacity: 1
key-resolver: "#{@ipKeyResolver}
复制代码 当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。是一种舍车保帅的策略。
比如平时客户来我的店铺购买衣服。平时可以试穿，给出建议，帮助搭配，最后下单支付，送用户祝福卡片等。双11大促则简单粗暴响应下单支付收钱发货。其他不太重要的服务关闭开关，腾出资源让位主交易流程。
服务降级可以从前端页面，后端微服务两个点着手。
很好理解，针对页面元素处理，将不重要的操作入口置灰或屏蔽。平时调用后端接口实时呈现数据的地方替换为静态页也可以理解为一种降级操作。
配置接口开关，并通过配置中心可以灵活开闭。必要时关闭开关，屏蔽接口的实际查询，直接返回mock数据。例如，购买了本商品的用户还购买过哪些商品接口，在业务上需要调用数据中台订单统计服务，访问量大时，关闭对外调用，直接返回设置好的一批相关商品，起到降级保护作用。
快速熔断可以认为是在应对突发情况时，对服务请求结果准确性的一种妥协。避免因单一服务垮台导致整个调用链路崩溃。常用手段如下：
举个例子：商品页或订单详情页面，一般都会有猜你喜欢这个模块，通过对用户的购买行为、浏览记录、收藏记录等等进行大数据分析，然后给每一个用户推送自己可能喜欢的商品。在双11大促背景下，如果推荐服务压力过大，出现服务出错、网络延迟等等之类突发情况，导致最后调用服务失败，则可以配备一个fallback，直接返回当前商品同类别下的几款商品，作为备选方案，这比抛异常或者返回null空白页面体验要更优。
大促前做好安全防范。常见的DDos，Arp，脚本等攻击平时也会存在，日常防范已经配备。大促期间需要注意的可能更多的是业务层面的入侵，比如抢购或秒杀时的恶意刷接口。
（2018从一次断电看灾备的背景与经历，30分钟以内）
灾备是应对大型故障的保底措施，最好的结局是永远不要触发，但是大促前需要做好灾备切换演练，可以选择大促前用户量少的时间段进行：
1）前期准备：两地灾备程序同步维护，大促相关的迭代和活动专题上线确保两地测试ok，镜像版本统一
2）数据库配置两地主从，或双主单写。切换前做好数据同步性检查
3）启用脚本，切换代理服务器，代理流量转入灾备机房，正式环境还需要处理dns指向
4）分布式文件灾备日常采用rsync等实时同步，采用云存储的可以忽略
5）es索引等其他数据确保日常同步
6）注意挂好维护页，友好提示
7）配备自动化测试脚本以便快速验证切换结果
包括物理机、Docker 容器、以及对交换机、IP 进行监控 （容器课题）
借助zabbix等开源软件对机器资源配置监控，如果采用云化部署，各大云供应商都会配备完善的监控机制
主动监控，日志或消息队列形式打点输出，定时汇报 （日志平台追踪课题）
被动监控，添加监控接口，监控系统定时请求确认可用性
对具体业务点做监控处理，如订单量、登录量、注册量、某些页面的访问量等关键点采用异步消息方式推送到监控中心，监控中心针对特定队列的数据做统计和展示。
主动监控依然无法察觉的情况下，来自客服的一线反馈成为最后关卡。优先级也最高。开发故障快速响应平台，做到实时性保障。做到客服 - 业务线 - 产品 - 技术排查的及时响应，快速排查。
网络带宽是影响访问流量的重要因素，做好各个机房网络带宽预估，数据在两地机房间传输并且要求低延迟的场景，如数据库主从，可以考虑机房专线。使用公有云的服务，可以购买临时流量。
对容量做预估和硬件资源盘点。配合大促期间不同服务的架构设计，以及项目本身的特性，对cpu，内存做评估。偏运算的项目，重度使用多线程的项目偏cpu，需要大量对象或集合处理的项目偏内存。
所有项目容器化部署，基于镜像即版本理念，打好各个服务的镜像是docker快速复制扩容的基础。大促前对各个中心微服务做统计和盘点。
借助swarm和k8s等编排工具，快速实现容器的伸缩。 （运维篇会讲到）
数据中台多为大数据相关架构体系，大促期间，同样可能面临大批数据洪峰，比如订单量激增、用户行为数据暴涨等场景。简单看一下可能需要做的一些应对。（大屏实时计算课题）
对数据传输通道扩容，比如kafka扩大分区数，rabbitmq增加细分队列。一方面实现了扩容，另一方面在传输的起始阶段就对数据做了一定的分类。
数据降级，关闭某些非核心数据的通道采集，让位网络带宽给核心业务数据。
数据大屏开发。对实时性有一定要求，多采用流式运算。
对关键业务的体量做好预估。如用户的注册、下单量、首页，商品详情页等关键页面的qps，为压测提供参考指标。
架构师统计各中心服务关系，对各个服务扩容做预估，汇总。
（全链路压测课题）
（大家当前使用的环境都有哪些？上线模式是什么样的）
当前成熟系统都具备各种环境，开发环境、测试环境、准生产环境等，对线下可以选择准生产环境做为压测，模拟线上。
线下压测数据安全，不必担心对线上造成干扰。所压测的值可以用于相对性比较，比如其中全链路的某个环境哪个是瓶颈。但是无法精准反馈线上的真实场景。
重点看线上压测，线上压测压出的数据是最真实有效的。但是因为使用的是生产环境，操作不当可能引发灾难性后果。
1）在全链路压测环境下，服务调用关系错综复杂，最重要的是实现压测流量的标识，以及标识在服务上下文间如何有效传递不丢失。服务内借助threadlocal，但是要注意多线程下失效。服务间通过改写远程调用框架或借助框架提供的Context设置。（分布式日志平台，访问链路追踪课题）
2）数据隔离，数据库可以创建影子表，redis等缓存可以设置shadow_等前缀，从开发框架层面封装处理，对数据层持久化框架做二次开发，使其自动发现压测数据。
3）外部服务可以借助服务降级功能，添加开关判断属于压测流量时开关进入降级或mock，比如收银程序添加挡板，直接返回成功，短信应用直接默认一个短信号码。
4）日志打印需要隔离，可以借助分布式日志平台收集时采用不同的输出通道和队列。
5）压测数据最好的方式是流量克隆（TCPCopy工具等），将线上的实际访问请求克隆放大几倍加压到压测入口，如果实现不了，尽量模拟线上的真实数据结构和体量。
5）做好全压流量规划，按预估2~3倍加压，确定流量比例，打压。
人员互备，防止故障，及时响应，应对双11不是什么神秘事。
作者：博学谷狂野架构师
链接：https://juejin.cn/post/7107494985838100517
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
| 留言与评论（共有 0 条评论） “” |
