前言

大家好,之前在公司自己设计并开发了一套完整的秒杀系统，自己构建了一个小的demo，希望和大家分享一下，希望大家能从中收益，如果有意见和好的想法请加我！ ＱＱ:3341386488 邮箱：QiuRunZe_key@163.com

我会不断完善，希望大家有好的想法拉一个分支提高，一起合作！

觉得不错对您有帮助，麻烦右上角点下star以示鼓励！长期维护不易 多次想放弃 坚持是一种信仰 专注是一种态度！

秒杀设计整体流程

需注意几点：

1.如何解决卖超问题

① sql加上判断如果防止数据变为负数
② 数据库加唯一索引防止用户重复购买
③ redis预减库存减少数据库访问　内存标记减少redis访问　请求先入队列缓冲，异步下单，增强用户体验

如何解决分布式session

① 生成一个随机的uuid一类的写回到cookie中
② redis 内存写入
③ 下一个页面拿到uuid 内存取对象

3.如何优雅解决接口防刷限流

如果有缓存的话 这个功能实现起来就和简单，在一个用户访问接口的时候我们把访问次数写到缓存中，在加上一个有效期。 通过拦截器. 做一个注解 @AccessLimit 然后封装这个注解，可以有效的设置每次访问多少次，有效时间是否需要登录！

4.通用缓存key的封装采用什么设计模式？

模板模式的优点
①具体细节步骤实现定义在子类中，子类定义详细处理算法是不会改变算法整体结构。
②代码复用的基本技术，在数据库设计中尤为重要。
③存在一种反向的控制结构，通过一个父类调用其子类的操作，通过子类对父类进行扩展增加新的行为，符合“开闭原则”。
缺点：　每个不同的实现都需要定义一个子类，会导致类的个数增加，系统更加庞大

5.LVS , tomcat(apr) , keepalive 高可用 －－待更新

6.限流算法　令牌桶，漏桶算法－－待更新

7.Nginx优化（前端缓存）

①并发优化
②keepAlive长链接（nginx,tomcat默认没有配置长链接）
③压缩优化.配置缓存
监控工具：１.nginx_status并发统计,Ngxtop缓存统计

nginx负载均衡

8.服务降级--服务熔断(过载保护)

自动降级： 超时.失败次数,故障,限流
人工降级：秒杀，双11

9.所有秒杀相关的接口比如：秒杀，获取秒杀地址，获取秒杀结果，获取秒杀验证码都需要加上
秒杀是否开始结束的判断

10.redis的库存如何与数据库的库存保持一致?

redis的数量不是库存,他的作用仅仅只是为了阻挡多余的请求透穿到DB，起到一个保护的作用
因为秒杀的商品有限，比如10个，让1万个请求区访问DB是没有意义的，因为最多也就只能10
个请求下单成功，所有这个是一个伪命题，我们是不需要保持一致的。

11.redis 预减成功，DB扣减库存失败怎么办？

其实我们可以不用太在意，对用户而言，秒杀不中是正常现象，秒杀中才是意外，单个用户秒杀中
本来就是小概率事件，出现这种情况对于用户而言没有任何影响
2.对于商户而言，本来就是为了活动拉流量人气的，卖不完还可以省一部分费用，但是活动还参与了，也就没有了任何影响
3.对网站而言，最重要的是体验，只要网站不崩溃，对用户而言没有任何影响

12.为什么redis数量会减少为负数？

	//预见库存
       long stock = redisService.decr(GoodsKey.getMiaoshaGoodsStock,""+goodsId) ;
		if(stock <0){
			localOverMap.put(goodsId, true);
			return Result.error(CodeMsg.MIAO_SHA_OVER);

假如redis的数量为1,这个时候同时过来100个请求，大家一起执行decr数量就会减少成-99这个是正常的

13.为什么要单独维护一个秒杀结束标志？

1.前提所有的秒杀相关的接口都要加上活动是否结束的标志，如果结束就直接返回，包括轮寻的接口防止一直轮寻
2.管理后台也可以手动的更改这个标志，防止出现活动开始以后就没办法结束这种意外的事件

14.redis挂掉了怎么办？

1.具体我会有时间更新关于redis的知识

15.rabbitmq如何做到消息不重复不丢失即使服务器重启？

1.exchange持久化2.queue持久化3.发送消息设置MessageDeliveryMode.persisent这个也是默认的行为4.手动确认