皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

苏宁 11.11: 如何 hold 住大促红包

作者 夏成

红包,这几年最火的营销系统。各大厂,无论双 11、春节都花费了大力气,五花八门的产品竭力吸引眼球。

那么如何设计一个能抗住亿级并发的红包系统了。这恐怕对任何一个团队来说,都是一个很大的挑战。经过这几年的大促红包开发(AR 小狮子,红包雨等),我们苏宁团队也在系统架构设计上积累一些经验。

架构设计

核心业务系统架构设计做到大系统小做,各个服务之间做到高内聚低耦合,服务之间做到异步化,突发事件的时候能够做到对非核心业务进行降级,保证核心功能可用,最大程度保证用户体验。

总体架构示意图

系统主要分前台和后台两个模块。

  • 后台:主要负责活动信息、奖项信息配置,并实时下发前台系统。
  • 前台:主要提供了活动资格校验、奖项配额扣减、概率服务、奖项列表服务等。

后台配置管理

后台配置管理维护活动信息及奖项信息,通过 MQ 下发给前台系统。前台系统将配置刷入本地缓存中。

准入验证

活动开启时间的,用户级别、是否实名认证,每天活动期间抽奖次数验证。

奖项配额管理(库存扣减)

在大规模的流量下,我们要做到奖项数量不多发、不少发,还有合理的奖项发放能力和发放速度。保证整个活动按照产权预期效果执行。

强大的奖项处理能力。通过概率服务计算完之后,奖项数量通过 redis 做扣减,异步落 DB 和异步发放。

异步发奖

通过 MQ 的形式,通知下游系统(促销中心,易付宝),发放券和现金红包。和下游系统完全解耦,在大流量并发场景下,保护下游系统,不被外部系统拖死。

数据实时计算

为了前端准确展示和数据决策的需要,我们需要知道准备的已发放的红包数和现金数。基于多个 IDC 的多集群部署,我们需要多 IDC 的数据汇聚进行统计,我们通过数据库 Binlog 抽数单向复制汇聚主机房,然后写入 kafka,通过 spark 的流式计算获得秒级数据,写入缓存。

流量控制与防刷

如何顺利扛过流量洪峰,我们通过客户端过载保护、流量清洗、流控控制、风控防刷、单机保护来保证系统平稳的运行。而且在过载保护和流控的时候,我们通过客户端的预埋逻辑来展示未中奖的彩蛋,保证用户体验。

客户过载保护:在客户端层面进行流量拦截,在系统处于过载状态的时候,通过客户端的预埋逻辑,获取实时配置,根据实时配置来限制流量往后发送。通过长连接推送和拉的形式来实现配置实时下发。

流量清洗:通过 CDN 和应用防火墙 WAF 进行流量清洗,有效的防止 CC 和 DDOS 等流量恶意攻击。

集群限流策略:通过 WAF 层来实现流量控制,总量通过令牌桶算法限制总量,通过其他行为策略(单 IP,单 UA)来限制异常流量。

单机限流策略:限制单台机器的总访问 QPS, 对超过阀值的流量进行限流。限制单机接口粒度的访问 QPS,对超过阀值的流量进行限流。

风控防刷策略:通过用户账号质量,用户行为,用户属性(各种认证),恶意 IP 等策略来进行风控防刷。

资源管理

  1. 单元化部署

路由层(CDN 层上实现)根据用户的会员号,按照规则算法(取模等),垂直上下切分,形成各个独立的集群。将流量分散到各个集群中,互不影响。而且不同集群可以部署到不同的机房。

  1. 故障切换

通过单元化的部署,在某一个 IDC 出现网络问题或不可预测的问题,可以短时间修改路由规则将流量切换到其他 IDC 集群。

  1. 弹性扩容

服务层扩容: 利用苏宁云的 Docker 的快速部署服务,当流量峰值超过预期的时候,通过 Docker 自动化操作集群,对服务层进行弹性扩容。

数据库扩容: 数据库部署为 1 主 2 备。预先设计好多个分表(比如 512 个表)并分配好主备对应的分表。在需要对数据库层进行水平扩容时,将备库切为写库,同时一键切换 MYCAT 的配置。

链路压测

任何系统设计再完美,也不能保证在线上能够完美达到预期,我们需要对系统在线上生产环境进行性能压测。通过整个链路的压测,我们能够清晰的了解我们各个服务间的能力和瓶颈(主机、数据库、网络、带宽等),能够针对瓶颈有效指定降级方案。

内部预热和流量模型修正

前期在产品设计阶段,我们通过往年数据和计划引流方案,估算到各个页面和各个系统的流量模型,通过模型来预估我们的系统容量。

在产品真正对外之前,发起几轮内部的预热,进行业务的演练,测试部分功能问题和体验问题。同时,通过页面埋点,根据真实的用户行为习惯,修正我们预估的流量模型,能够更好的来分配我们资源。

系统监控

当系统正式上线运行时,我们需要实时了解系统各个资源运行状态,流量大小,业务参数。充分的保障业务节点的可用性、性能可靠性。及时发现突发状况,按照预先准备的降级手段进行降级。

目前苏宁的监控手段还是比较丰富的,通过云迹 (日志)、调用链监控、ZABBIX 等平台,可以全面监控到:服务器负载监控、资源层负载监控、网络层监控、应用层接口监控、应用日志监控、应用服务器 jVM 层监控。

小结

每年的红包大战还在继续,越来越多的营销产品的不断迭代,对我们 IT 团队提出更高的要求。系统架构设计是没有最终完美的,我们需要根据不同产品形式和要求,不断迭代和重构我们的系统。未来,我们脚下的路还很长,苏宁 IT 人还在砥砺前行。

作者简介

夏成,苏宁易购 IT 总部消费者研发中心架构师,主要负责易购主站核心交易中心各系统的架构设计优化与大促保障工作。曾负责历次苏宁大促红包系统架构设计、苏宁小店系统开发、支付中台系统重构、流量控制组件开发。专注于打造高可靠、高性能、高并发服务系统的技术研究。

转自 http://www.infoq.com/cn/articles/suning-1111-red-packets

分享到:更多 ()