针对商城项目优化高并发-Java

迈不过友情╰ 2024-04-18 10:08 80阅读 0赞

一个数据多个人读写，主要问题：**读写冲突，锁非常严重**

1.  **将请求尽量拦截在系统上游**（不要让锁冲突落到数据库上去）。传统秒杀之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高，响应慢，几乎所有请求都超时，流量虽大，下单成功得有效流量小。秒杀下访问量很高，但是请求有效为0，买成功很低。
2.  **充分利用缓存**，秒杀商品，典型得读多写少，大部分请求是商品查询，下单和支付才是写请求。大约写比例是0.1%，读比例是99.9%，适合缓存来做。

## **3.1 常见秒杀架构** ##

![20190905091112581.png][]

1.  浏览器，最上层执行js代码，完成绘制和渲染；
2.  站点层，访问后端数据，组合html内容，返回给浏览器；
3.  服务层，向上游屏蔽底层数据细节，提供数据访问；
4.  数据层，最终的库存数据mysql、缓存数据库；

## **3.2 各层优化** ##

### **1）客户端（浏览器、app）** ###

用户进行商品查询，若没反应，会多次点击，多次点击没有引起具体反应，而且会增加负载。

1.  用户查询后，**按钮置灰**，禁止用户重复提交请求；
2.  JS层，限制用户在**x秒内只能提交一次请求**；

也就是将请求尽量拦截在系统上游。如果“黑客”来个for循环，进行多次请求访问，这个无法拦截，所以就有了下一层拦截。

### **2）站点层请求拦截** ###

不想要考虑ip或者cookie id，直接考虑用户id就行，因为操作想要用户进行登录。在站点层对**uid进行请求计数和去重**，直接一个uid，5秒只准通过一个请求，就能拦截for循环。

5秒一个请求，其余请求进行缓存，**页面缓存**。5秒内均返回同一个页面。保证用户体验（没返回404），又保证系统的健壮性（利用页面缓存，把请求拦截在站点层）。

但是弱遇到高端黑客，控制10w的uid，同时发送请求，如何？

### **3）服务层拦截** ###

**请求队列，**写一个请求队列，每次有限的写请求去数据层（下单，支付）。

读请求：分时分段售卖；将流量分摊均匀；

数据粒度优化：粗粒度显示库存等数据；

业务逻辑异步：下单和支付业务分离，进行一些业务优化；

### **4）数据库层** ###

Redis缓存进行库存预减操作；

索引优化查询速度；

查询优化：查找有效数据，常用limit少用\*；explain优化sql语句；分解大连接查询；

# **3.3 Redis宕机怎么办？会抛出异常，请求不会怼到数据库** #

Redis的持久化机制，实现宕机也不会数据丢失：

1.  快照，全量备份；二进制序列化形式；

AOF日志:连续的增量备份；记录文本;长期运行，aof日志会越来越常，十分耗时，需要瘦身。

## 3.4 测试过哪些QPS，redis和mysql的QPS？ ##

QPS每秒Query量，show  global  status like 'Question%';

## 3.5 用户id在秒杀的时候是通过url的方式传输的，还是request（cookie，sso）？ ##

我觉得吧。通过url可以多次请求，而sso是单点登录的，也就是说，用户只需要能录一次，你请求的再多，我只认一次。所以，我觉得还是sso的方式拿到。

![image][]

如上图所示，我们在浏览器（Browser）中访问一个应用，这个应用需要登录，我们填写完用户名和密码后，完成登录认证。这时，我们在这个用户的session中标记登录状态为yes（已登录），同时在浏览器（Browser）中写入Cookie，这个Cookie是这个用户的唯一标识。下次我们再访问这个应用的时候，请求中会带上这个Cookie，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户是否登录。如果不做特殊配置，这个Cookie的名字叫做jsessionid，值在服务端（server）是唯一的。

[SSO单点登录：https://yq.aliyun.com/articles/636281][SSO_https_yq.aliyun.com_articles_636281]

### 3.5 Redis限流的key是怎么样的？ ###

> 第一种：基于Redis的setnx的操作；使用Redis的分布式锁的时候，大家都知道是依靠了setnx的指令，在CAS（Compare and swap）的操作的时候，同时给指定的key设置了过期时间（expire），我们在限流的主要目的就是为了在单位时间内，有且仅有N数量的请求能够访问我的代码程序。
> 
> 比如我们需要在10秒内限定20个请求，那么我们在setnx的时候可以设置过期时间10，当请求的setnx数量达到20时候即达到了限流效果。代码比较简单就不做展示了。
> 
> 第二种：基于Redis的数据结构zset；
> 
> 将请求打造成一个zset数组，当每一次请求进来的时候，value保持唯一，可以用UUID生成，而score可以用当前时间戳表示，因为score我们可以用来计算当前时间戳之内有多少的请求数量。而zset数据结构也提供了range方法让我们可以很轻易的获取到2个时间戳内有多少请求。
> 
> 第三种：基于Redis的令牌桶算法；
> 
> 令牌桶算法提及到输入速率和输出速率，当输出速率大于输入速率，那么就是超出流量限制了。

也就是说我们每访问一次请求的时候，可以从Redis中获取一个令牌，如果拿到令牌了，那就说明没超出限制，而如果拿不到，则结果相反。

*  两次MD5的原理，为什么两次，第二次salt放在数据库里面，客户端如何获得？

密码明文传输或直接写到数据库中，都有被偷看的风险，两次可以更好的加密，防止md5反查。

MD5(MD5(pass明文+固定salt)+随机salt)

第一次固定salt写死在前端；

第二次加密采用随机的salt 并将每次生成的salt保存在数据库中；

salt是盐值，用来实现散列，再比较散列值；

*  限流使用的是ip还是用户id？

1）如果用户登录了，登录才能进行购买的这种行为，直接统计用户id就行；

2）如果是匿名登录或者是浏览未登录，则采用ip限制；

*  Redis的负面问题有哪些？

分布式缓存系统，key-value数据结构

Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快**照比较大时对性能影响是非常大的，会间断性暂停服务**，所以Master最好不要写内存快照。

Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是**AOF文件会不断增大**，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内

[20190905091112581.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/a6dba7fe7997456895c9c8f92cd68979.png
[image]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly95cWZpbGUuYWxpY2RuLmNvbS81NTVmMWE2ODU2NDY4NTc4MDIwZWEwNDg2ZjU2M2IzNjMzODEzMDUwLnBuZw?x-oss-process=image/format,png
[SSO_https_yq.aliyun.com_articles_636281]: https://yq.aliyun.com/articles/636281