起于2009年，刚开始的双十一还并不出名，电商开展促销月都是以各自的店庆月作为基础的。国美在线是4月份，京东6月份，易购8月份，而淘宝商城选择了双十一作为促销月。促销的初衷是光棍节(11月11日)大家没事干，就该买点啥东西去当礼物送人。于是乎，双11就这样诞生了。
了解双11背景下电商公司的应对措施，有助于提升高访问量背景下的系统架构知识。
从组织架构到技术架构，当前各大电商系统基本趋于中台化。中台在2015由阿里提出，其实是一种企业架构而不是单纯的技术层面，目前几乎各大电商都进行着中台化的建设。
中台没有什么神秘的，说到底，中台就是对”共享“理念系统化的归纳和总结。
即大中台，小前台的前台，电商中直面用户的B2B,B2C等各个业务线。
业务中台基于公共服务的沉淀，需要收敛一些基础的业务服务，如商品、订单、会员、库存、财务、结算等等。
数据中台不是一个平台，也不是一个系统。数据仓库、数据平台和数据中台是有区别的。简单的举例：数据平台可以理解为数据库，数据仓库类比为报表，而数据中台更贴近上层业务，带着业务属性。
与业务无关的基础沉淀，中间件，系统框架，监控，日志，集成部署等等
（根据项目情况有所偏重，例如分布式与一致性是一对矛盾）
该小节从中台的各个团队角度，介绍双11期间的一些应对措施和遇到的问题。
（异步化的目的是什么？大家使用过的mq？遇到的问题？）
场景：
大促期间新增许多需要获取订单状态的服务，比如应对双11而临时增加的数据中台订单大屏展示等
解决：
异步化，并对消息队列调优，多队列分流
问题：
注意异步化引发的乱序问题，一是传输阶段，二是消费阶段
局部有序与绝对有序
图解：
rabbitmq传输：队列级别顺序保障，单消费者消费一个队列可以严格保障顺序性，需要扩充队列数提升性能
kafka传输：分区级别顺序保障，只能保障投放和传输阶段的顺序性
消费阶段：1对1消费存在性能问题，接收消息后对key做二次分发，放入多个内存队列，开启多线程消费
（场景及思考，如果让你做架构设计有什么方案？这些方案有什么优缺点）
双11抢单是最常见的场景，抢单不支付会占据大批量资源，如商品库存。如何取消过期订单是架构师必须面对的问题。主要有以下几种方案：
扫表实现
原理：
通过定时任务轮询扫描订单表，超时的批量修改状态
优点：
缺点:
java延迟队列实现
优点:
消息队列实现
缺点：
redis实现
被动取消
支付交互流程，支付系统设计偏重，关于做过的那些支付系统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为整个商品集合。优化为列表与每个商品详细信息设置两个独立缓存值，在查询环节组装，可以降低发生修改时对缓存的冲击。新增一个推荐则失效列表，修改商品则仅仅失效当前商品缓存。
可用性：
（回顾三种缓存问题）
优化缓存体系，对关键业务请求，如商品详情页，采用多级缓存处理
首先看浏览器缓存，一般浏览器缓存可分为两种手段，分别交给浏览器和服务端执行
nginx缓存：nginx除了作为负载均衡，也可以作为请求级别的缓存，一段典型配置如下：
proxy_cache_path缓存文件路径
levels设置缓存文件目录层次；levels=2:2:2表示三级目录，每级用2位16进制数命名
keys_zone设置缓存名字和共享内存大小
（算法与数据结构应用-限流算法有详细实现）
CDN的引入本身起到了按ip分流的作用，但是我们可以在下层做到更细粒度化的控制。根据业务情况将不同的请求分流到各自的服务器。
限流不同与分流，是对下层的保护，当系统超过一定流量后，超过的流量做直接拒绝处理，以便保护后端的服务，原则就是要么不进来，进来的都正常服务。常见的限流算法有三种：计数器（滑动窗口）、漏桶、令牌桶。
根据不同的业务线分发请求，配备二级域名如b2b.xxx.com，b2c.xxx.com，或者在nginx软负载层针对不同虚拟主机名做upstream分发
新上的双11活动页，或者促销专题页面，采用新访问入口和机器部署，与主站分离。活动结束后也利于机器资源的快速释放（有没有遇到临时性需求的场景？上线就用1天）
按不同的请求终端分流，在header头的user-agent中可以捕获用户的访问终端。android，ios，pc，根据不同终端设备，做流量分发，到不同的应用机器。同时方便对用户终端流量的监控和统计。
评估双11可能的流量，结合具体业务模块，配备对应限流措施。主要有流量限制和连接数限制两个维度。
#$binary_remote_addr同上limit_conn_zone$binary_remote_addrzone=addr:10m;server{location/b2b/{#限制每个ip下最大只能有一个连接limit_connaddr1;}}4）网关限流从代理服务器放进来的流量，会进入应用服务器，第一道关卡是微服务的网关。应对大促，针对各个微服务具体业务具体分析，配备对应限流措施。zuul和gateway是团队中最常遇到的网关组件。
比如平时客户来我的店铺购买衣服。平时可以试穿，给出建议，帮助搭配，最后下单支付，送用户祝福卡片等。双11大促则简单粗暴响应下单支付收钱发货。其他不太重要的服务关闭开关，腾出资源让位主交易流程。
服务降级可以从前端页面，后端微服务两个点着手。
很好理解，针对页面元素处理，将不重要的操作入口置灰或屏蔽。平时调用后端接口实时呈现数据的地方替换为静态页也可以理解为一种降级操作。
快速熔断可以认为是在应对突发情况时，对服务请求结果准确性的一种妥协。避免因单一服务垮台导致整个调用链路崩溃。常用手段如下：
大促前做好安全防范。常见的DDos，Arp，脚本等攻击平时也会存在，日常防范已经配备。大促期间需要注意的可能更多的是业务层面的入侵，比如抢购或秒杀时的恶意刷接口。
（2018从一次断电看灾备的背景与经历，30分钟以内）
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不是什么神秘事。