基于微服务架构如何设计电商秒杀系统，实现探讨

03.09号至11号已经近一周没有更新blog 了，今天凌晨更新下，贵在坚持，不能断更。

电商秒杀系统的重要性仅次于 支付系统，是整个应用平台的重要臂膀，怎么实现一个能抗的电商秒杀系统呢？

服务网关 Zuul
服务注册发现 Eureka + Ribbon
认证授权中心 Spring Security OAuth2、JWT Token
服务框架 Spring MVC/Boot
服务容错 Hystrix
分布式锁 Redis
服务调用 Feign
消息队列 Kafka（大数据情况下选用kafka）
文件服务 私有云盘 / HDFS
富文本组件 UEditor
定时任务 XXL-JOB
配置中心 Apollo （或者选用config ）

这里先不空谈怎么样个架构，先说秒杀活动开始高QPS问题解决，整个秒杀都是针对QPS数据访问流来处理的，所以，有效解决该问题，并保证服务的可用性，以及用户的体验度是整个设计的关键；

1/ 限流 : 防刷
2/ 流量削峰： 减少request 次数，有效减少 瞬间QPS峰值 对 mysql 的影响 ;
3/ redis 缓存处理数据， 内存处理数据速度高、
4/ 系统设计可水平扩展： 活动来时候加 机器、

首先说限流，限流有很多种方式，常规方式验证码， 这里采用 限定 QPS 的方式，当请求大于 某一QPS时候，直接返回默认值：请刷新重试。。。

2019.03.13    23：40     更新

1、整个流程图如下：

1、把 静态资源存放在 CDN（ 内容分发网络） 上 ，这样 有效的减少对服务器带宽压力，防止带宽在活动开始时候就被 图片吃完；

2、项目核心代码如下：

2.1 、 redis 中操作 数据、对请求进行限流

long count = redisRepository.incr("BM_MARKET_SECKILL_COUNT_" + stallActivityId);
if( count > 500 ) {
   
   
    return new BaseResponse(false, 6405, "活动太火爆，已经售罄啦！");
}

检验用户的重复性购买、

if( redisRepository.exists