不是每个程序员都有机会经历双11的波澜壮
?了解双11的历程?学习当前主流的电商系统架构体系?了解大促对电商系统的一些挑战?面对大促活动，站在架构师角度思考，可能有哪些问题，如何应对
1.1.2双11历程（最早接触双11的年份？）
起于年，刚开始的双十一还并不出名，电商开展促销月都是以各自的店庆月作为基础的。国美在线是4月份，京东6月份，易购8月份，而淘宝商城选择了双十一作为促销月。促销的初衷是光棍节(11月11日)大家没事干，就该买点啥东西去当礼物送人。于是乎，双11就这样诞生了。
?年销售额0.52亿，27家品牌参与;?年销售额9.36亿，家品牌参与；?年销售额33.6亿，家品牌参与；?年销售额亿，家品牌参与；?年销售额亿，家品牌参与；?年销售额亿，家品牌参与；?年销售额亿，家品牌参与；?年销售额亿，家品牌参与；?年销售额亿，1家品牌参与；?年销售额亿，家品牌参与；?截止到年11日23时59分59秒销售额亿。
了解双11背景下电商公司的应对措施，有助于提升高访问量背景下的系统架构知识。
1.2电商整体架构
1.2.1概述从组织架构到技术架构，当前各大电商系统基本趋于中台化。中台在由阿里提出，其实是一种企业架构而不是单纯的技术层面，目前几乎各大电商都进行着中台化的建设。
中台没有什么神秘的，说到底，中台就是对”共享“理念系统化的归纳和总结。
?重复功能建设和维护带来的重复投资?烟囱式建设造成系统壁垒，数据孤岛?业务沉淀促进可持续发展?大中台小前台快速响应市场的需要
1.2.2上层业务即大中台，小前台的前台，电商中直面用户的B2B,B2C等各个业务线。
1.2.3业务中台业务中台基于公共服务的沉淀，需要收敛一些基础的业务服务，如商品、订单、会员、库存、财务、结算等等。
1.2.4数据中台数据中台不是一个平台，也不是一个系统。数据仓库、数据平台和数据中台是有区别的。简单的举例：数据平台可以理解为数据库，数据仓库类比为报表，而数据中台更贴近上层业务，带着业务属性。
1.2.5技术中台与业务无关的基础沉淀，中间件，系统框架，监控，日志，集成部署等等
1.2.6运维中台不一定存在，系统运维相关的内容，硬件，机房，包括企业云平台的建设等可以划分为单独的运维中台
1.3面临挑战
1.3.1考量维度（根据项目情况有所偏重，例如分布式与一致性是一对矛盾）
?高性能：提供快速的访问体验。?高可用：网站服务7*24正常访问。?可伸缩：硬件弹性增加/减少能力（快速扩容与释放）。?扩展性：方便地增加/减少新的功能/模块（迭代与服务降级）。?安全性：安全访问和数据加密、安全存储等策略。?敏捷性：快速应对突发情况的能力（灾备等）。
1.3.2内部瓶颈?
木桶效应：水管最细的地方决定流量，水桶最低的地方决定容量（QPS压测调优为例）
?
CPU：序列化和反序列化、复杂运算、大量反射、大量线程的应用
?
内存：使用内存的中间件或服务，如redis，memcache，jvm大量对象堆积内存的应用等
?
网络带宽：大流量高并发环境下，双11用户访问量激增，造成网络拥堵
?磁盘IO：文件上传下载，数据库频繁读写，不合理或大批量的日志输出
?数据库连接数：应对双11，应用服务器连接池大批扩容，警惕底层数据库、Redis等连接数瓶颈
1.3.3外部服务?
短信：外部短信延迟与送达率问题，可以搭建短信平台，多家渠道做路由和切换分流（让你设计短信平台，会考虑哪些问题？如何做架构？）
?
支付：银行支付与回调延迟，搭建支付中心，对接多支付渠道
?
快递对接：快递服务对接（快递）
?
外部云存储：云存储文件访问，流量扩容（大家所使用的存储？nfs的架构与事故）
?CDN：外部静态文件访问提速服务（使用过的项目？）
2应对措施
该小节从中台的各个团队角度，介绍双11期间的一些应对措施和遇到的问题。
2.1业务中台
2.1.1订单中心1）异步化（异步化的目的是什么？大家使用过的mq？遇到的问题？）
场景：
大促期间新增许多需要获取订单状态的服务，比如应对双11而临时增加的数据中台订单大屏展示等
解决：
异步化，并对消息队列调优，多队列分流
问题：
注意异步化引发的乱序问题，一是传输阶段，二是消费阶段
局部有序与绝对有序
图解：
rabbitmq传输：队列级别顺序保障，单消费者消费一个队列可以严格保障顺序性，需要扩充队列数提升性能
kafka传输：分区级别顺序保障，只能保障投放和传输阶段的顺序性
消费阶段：1对1消费存在性能问题，接收消息后对key做二次分发，放入多个内存队列，开启多线程消费
2）过期订单（场景及思考，如果让你做架构设计有什么方案？这些方案有什么优缺点）
双11抢单是最常见的场景，抢单不支付会占据大批量资源，如商品库存。如何取消过期订单是架构师必须面对的问题。主要有以下几种方案：
扫表实现
原理：
通过定时任务轮询扫描订单表，超时的批量修改状态
优点：
?实现非常简单
缺点:
?大量数据集，对服务器内存消耗大。
?数据库频繁查询，订单量大的情况下，IO是瓶颈。?存在延迟，间隔短则耗资源，间隔长则时效性差，两者是一对矛盾。?不易控制，随着定时业务的增多和细化，每个业务都要对订单重复扫描，引发查询浪费
java延迟队列实现
原理：
通过DelayQueue，每下一单，放入一个订单元素并实现getDelay()方法，方法返回该元素距离失效还剩余的时间，当=0时元素就失效，就可以从队列中获取到。启用线程池对数据监听，一旦捕获失效订单，取出之后，调用取消逻辑进行处理。（多线程课题案例）
优点:
?基于jvm内存，效率高，任务触发时间延迟低。
缺点:
?存在jvm内存中，服务器重启后，数据全部丢失。?依赖代码硬编码，集群扩展麻烦?依赖jvm内存，如果订单量过大，无界队列内容扩充，容易出现OOM?需要代码实现，多线程处理业务，复杂度较高?多线程处理时，数据频繁触发等待和唤醒，多了无谓的竞争
消息队列实现
原理：
设置两个队列，每下一单放一条进延迟队列，设定过期时间。消息一旦过期，获取并放入工作队列，由consumer获取，唤起超时处理逻辑
如果采用的是RabbitMQ，其本身没有直接支持延迟队列功能，可以针对Queue和Message设置x-message-ttl，用消息的生存时间，和死信队列来实现，具体有两种手段，A:通过队列属性设置，队列中所有消息都有相同的过期时间，粗粒度，编码简单B:对消息进行单独设置，每条消息TTL可以不同，细粒度，但编码稍微复杂。
优点：
?消息存储在mq中，不占用应用服务器资源
?异步化处理，一旦处理能力不足，consumer集群可以很方便的扩容
缺点：
?可能会导致消息大量堆积?mq服务器一旦故障重启后，持久化的队列过期时间会被重新计算，造成精度不足?死信消息可能会导致监控系统频繁预警
redis实现
原理：
利用redis的notify-keyspace-events，该选项默认为空，改为Ex开启过期事件，配置消息监听。每下一单在redis中放置一个key（如订单id），并设置过期时间。
优点:
?消息都存储在Redis中，不占用应用内存。?外部redis存储，应用down机不会丢失数据。?做集群扩展相当方便?依赖redis超时，时间准确度高
缺点:
?订单量大时，每一单都要存储redis内存，需要大量redis服务器资源
被动取消
原理：
在每次用户查询订单的时候，判断订单时间，超时则同时完成订单取消业务。
优点：
?实现极其简单?不会有额外的性能付出?不依赖任何外部中间件，只是应用逻辑的处理
缺点：
?延迟度不可控，如果用户一直没触发查询，则订单一直挂着，既不支付也未取消，库存也就被占着
2.1.2支付中心支付交互流程，支付系统设计偏重，关于做过的那些支付系统与的架构变化，政策的变动经历。
1）重复支付（重复支付事故）
原因：
在第一步发起的时候，用户进入支付方式选择页。选第一个支付方式并支付完后因为通知延迟，以为支付失败。在支付又选了第二种，再次支付。
应对方案：
程序屏蔽，前端js触发按钮置灰或者遮罩提示（支付成功？遇到问题？），或者在支付方式选择页直接跳转。
后端处理，发现不同通道下的支付成功回调，抛消息队列或记录日志。
数据修复：
首先查支付日志，确认针对同一笔订单收到了不同支付渠道的回调。
其次，在支付平台管理后端可以查到入账记录，人工介入。
最后对账阶段会发现对方多帐，我方补单时出现重复订单。
问题处理：
调取退款接口或者在支付渠道的管理后台操作退款（一定要多次确认无误）。
2）异常订单支付但未开单
场景：
用户明明支付成功，但未开通订单
问题分析：
一般支付渠道会间隔性多次回调开单链接，如果支付未开单，银行未回调的可能性比较小，着重排查开单接口是否可用。如果可用追查日志是否出现异常记录。
应对措施：
?
对账阶段可以查漏，程序自动完成补单，但是处理相对延迟，取决于支付渠道的对账文件下发周期（-年，支付测试数据与财务人工对账的历程）
?
人工补单，人工查询支付渠道后台数据，确认已支付的情况下，介入补单流程人工处理
未支付但已开单
场景：
用户未支付，或者财务中心未收到这笔款项，订单状态已开通。这种就问题比较严重了
应对措施：
首先排除人为操作因素。其次排查系统是否存在漏洞或者级联开单的情况（支付中心测试环境数据回调造成线上意外开单经历）
3）回调延迟场景：
用户是期望支付完成的同时立马看到结果。但是中间多层远程的调用，可能发生订单状态更新延迟问题。
解决：
主动查询。在用户查看订单的时候，如果是类似“支付中”的中间态时，触发远程订单状态查询接口。（大家看到的点击“支付完成”跳转的过程，触发远程支付结果查询）
4）支付路由（*你所看到的收银台图标内情...*）
背景：
保障支付可用性及支付分流，支付中心对接多家渠道
方案：
?支付中心对接多个支付渠道，支付宝， proxy_cache_path缓存文件路径
levels设置缓存文件目录层次；levels=2:2:2表示三级目录，每级用2位16进制数命名
keys_zone设置缓存名字和共享内存大小
inactive在指定时间内没人访问则被删除
max_size最大缓存空间，如果缓存空间满，默认覆盖掉缓存时间最长的资源。
#定义缓存路径、过期时间、空间大小等proxy_cache_path/tmp/nginx/cachelevels=2:2:2use_temp_path=offkeys_zone=my_cache:10minactive=1hmax_size=1g;server{listen80;server_namexxx.xxx.
转载请注明：http://www.sonphie.com/jbby/14212.html
