这篇博文所列举的优化手段是针对比较传统项目,但是想提高系统的吞吐量现在时髦的技术还是那些前后端未分离, 使用nginx当成静态资源服务器去代理我们的静态资源
是谁限制了Throughput?#
当我们对一个传统的项目进行压力测试时,很容器就发现,系统的Throughput被数据库(mysql)限制的死死的,尽管代码看起来确实没毛病,逻辑也没有错误,但是过多的请求都被打向了数据库,数据库自个开启大量的IO操作,这样大的负载甚至会使Linux系统的整体负载骤然飙升,但是反观我们的系统的吞吐量,呵呵...
将目光投向缓存#
既然mysql的抗压能力限制了我们的系统,那就将数据缓存起来,尽一切可能减少用户和数据库之间的直接接触的次数,这样我们的系统的吞吐量,同一时间能处理器的请求数量自然会升上去
市面上的缓存技术很多, 比较火爆的是两款缓存数据库 Memcache 和 Redis ,
Redis 和 Memcahe的区别
- Redis不仅仅支持key-value键值对类型的数据,同时还支持list,set,hash等数据结构
- redis支持数据的备份,即master-slaver模式的集群备份
- Redis是支持数据持久化的,它可以将内存中的数据保存在磁盘中,支持RDB和AOF两种持久化形式
对Redis进行压测#
# 挨个测试redis中的命令 # 每个数据包大小是3字节 # 100个并发, 发起10万次请求 redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000 [root@139 ~]# redis-benchmark -h 127.0.0.1 -p 9997 -c 100 -n 100000 ====== PING_INLINE ====== 100000 requests completed in 1.04 seconds 100 parallel clients 3 bytes payload keep alive: 1 98.68% <= 1 milliseconds // 百分之98.68的请求在1毫秒内完成了 99.98% <= 2 milliseconds 100.00% <= 2 milliseconds 96525.09 requests per second // 每秒完成的请求数在9万六左右 -d 指定数据包的大小,看下面redis的性能还是很强大的 -q 简化输出的参数 [root@139 ~]# redis-benchmark -h 127.0.0.1 -p 9997 -q -d 100 -c 100 -n 100000 PING_INLINE: 98619.32 requests per second PING_BULK: 95877.28 requests per second SET: 96153.85 requests per second GET: 95147.48 requests per second INCR: 95238.10 requests per second LPUSH: 95328.88 requests per second RPUSH: 95877.28 requests per second LPOP: 95328.88 requests per second RPOP: 97276.27 requests per second SADD: 96339.12 requests per second HSET: 98231.83 requests per second SPOP: 94607.38 requests per second LPUSH (needed to benchmark LRANGE): 92165.90 requests per second LRANGE_100 (first 100 elements): 97181.73 requests per second LRANGE_300 (first 300 elements): 96153.85 requests per second LRANGE_500 (first 450 elements): 94428.70 requests per second LRANGE_600 (first 600 elements): 95969.28 requests per second MSET (10 keys): 98231.83 requests per second 只测试 指定的命令 -t 跟多个命令参数 [root@139 ~]# redis-benchmark -p 9997 -t set,get -q -n 100000 -c 100 SET: 97276.27 requests per second GET: 98135.42 requests per second
从上面的压力测试中,可以看到,Redis的性能是绝对实力, 相当强悍,和mysql相比不是一个量级的, 所以结论很明显,如果我们在用户和mysql中键加一层redis做缓存,系统的吞吐量自然会上去
于是为了提高系统的抗压能力,我们将压力从mysql逐步转移到redis中
页面缓存技术#
在说页面缓存之前,我们先说一下在一个传统的项目中,一个请求的生命周期大概是这样的: 从浏览器发出到服务端, 服务端查询数据库获取结果, 再将结果数据传递给模板引擎将数据渲染进html页面
想提高这个过程的速度,我们可以这样搞, 页面缓存, 顾名思义就是将 html 页面缓存到缓存数据库中
示例如下:
一开始我们会先尝试从缓存中获取出已经渲染好的html源码响应给客户端, 响应的格式通过@ResponseBody和produces中的属性进行控制,告诉浏览器自己会返回给它html文本
优点: 将用户的请求的压力从mysql转移到redis, 这点强度对redis单机来说根本不是事
缺点: 很明显,将请求扩大到页面级别,数据一致性难免会受到影响, 这也是使用页面缓存不得不考虑的一点
特点1 : 严格控制缓存的时间, 一定别忘了添加过期时间...
特点2 : 原来都是让thymeleaf自动完成数据的渲染,现在的话,很明显是我们手动在渲染数据
@RequestMapping(value = "/to_list",produces = "text/html;charset=UTF-8") @ResponseBody public String toLogin(Model model, User user, HttpServletResponse response, HttpServletRequest request) { // 先从redis缓存中获取数据 String html = redisService.get(GoodsKey.goodsList, "", String.class); if (html != null) return html; // 查询商品列表 List<GoodsVo> goodsList = goodsService.getGoodsList(); model.addAttribute("goodsList", goodsList); // 使用Thymeleaf模板引擎手动渲染数据 WebContext springWebContext = new WebContext(request,response,request.getServletContext(),request.getLocale(),model.asMap()); String goods_list = thymeleafViewResolver.getTemplateEngine().process("goods_list", springWebContext); // 存入redis if (goods_list!=null){ redisService.set(GoodsKey.goodsList,"",goods_list); } return goods_list; }
既然都说到这里了, 就接着说还能怎么玩吧...
你看, 上面通过手动控制模板引擎的api竟然得到的已经渲染好的html源代码了, 什么叫做已经渲染好的? 说白了就是原来我在前端写:th ${user},这样的占位符,现在已经被thymeleaf替换成了 张三 ... (说的够直接吧)
拿到了已经渲染好的源代码,我们就能通过IO操作,将这个文件写到系统的某个目录上去,不知道大家有没有发现,去逛京东淘宝浏览某个商品页面时,就会发现url是类似这样的 www.jjdd.com/aguydg/ahdioa/1235345.html
这个后缀123145.html 大概率说明京东使用静态页的技术, 这太明智了,面对如此巨大数量的商品信息后缀用数字来表示也不错,而且速度还快不是?
怎么实现这种效果呢?
就是上面说的,通过IO将这些源码的数据写到Linux中的某一个目录下面, 文件名就是上面URL中的最后的数字, 通过Nginx做静态资源服务器将这些xxx.html代理起来, 用户再访问的话就走这个静态页, 同样不会接触数据库, 而且nginx还支持零拷贝,并发数5万不是事...
还有,后缀数组最好也别乱写,直接使用商品id会更好,毕竟是先点击商品获取到id,再进入到静态页
对象缓存技术#
缓存java中的对象, 比如将用户的信息持久化进redis, 每次用户查询自己的信息先从redis中查询,有的话直接返回,没有的话再去查询数据库, 这样同样实现了在用户和数据库之间多添加出一层缓存,也可以大大的提高系统的吞吐量
一般会怎么玩呢?
用户的请求在查询数据库之前先尝试从redis中获取对象信息, redis中不存在的话就去数据库中查询, 查询完结果后将这个结果换存进redis
// todo 使用redis做缓存,减少和数据库的接触次数 public Label findById(Long labelId) { // 先尝试从缓存中查询当前对象 Label label = (Label) redisTemplate.opsForValue().get("label_id" + labelId); if (label==null){ Optional<Label> byId = labelRepository.findById(labelId); if (!byId.isPresent()) { // todo 异常 } label = byId.get(); // 将查出的结果存进缓存中 redisTemplate.opsForValue().set("label_id"+label.getId(),label); } return label; }
当用户update数据 ,先更新数据库,再删除/更新redis中响应的缓存
public void update(Long labelId, Label label) { label.setId(labelId); Label save = labelRepository.save(label); // todo 数据库修改成功后, 将缓存删除 redisTemplate.delete("label_id"+save.getId()); }
当用户删除数据,先删除数据库中的数据,再删除redis中的缓存
public void delete(Long labelId) { labelRepository.deleteById(labelId); // todo 数据库修改成功后, 将缓存删除 redisTemplate.delete("label_id"+labelId); }
模仿Vue实现页面静态化#
大家都在说页面静态化, 它真的有那么神奇吗? 其实也没有那么神奇, 说白了吧,传统的网页上的数据是通过模板引擎渲染上去的,(比如JSP或者是说thymeleaf这类模板引擎), 做了静态化的网页中数据的渲染通过js完成, 而且这个网页和项目中的 静态资源比如js,css 这类的文件放在一个目录下面, 地位和普通的静态资源相同, 还有个好处就是, 浏览器给的福利, 因为浏览器对静态资源是有缓存的, 如果你善于观察,就会发现有时候重复请求某个网页,网页正常显示,但是状态码是304... 请求依然会到达服务端,但是服务端会告诉浏览器它想访问的页面其实没有变化, 于是浏览器就找到本地的缓存使用
时下国内 最火爆的玩静态页面时下最火爆的技术就是 Angular.js 以及 Vue.js , 也确实好用, 前几个月我写过有关vue的笔记, 感兴趣的同学可以去看看 点击查看我的vue笔记
在本篇博客中恰恰好没用到VUE, 但是实现静态页的思路和vue是大差不差的, 同样是通过js代码实现页面的静态化
- 首先说后端的代码怎么写?
前后端分离嘛, 自然是json交互,后端通过@ResponseBody控制返回给前端json对象, 而且, 推荐大家也整一个VO对象,用这个VO对象将各式各样的数据封装在一起,一次性返回给前端, 这样看上去,后端确实是简单,也就是返回一个json对象
- 前端怎么写呢?
第一件事就是将html文件从template文件夹下move到static文件夹下面, 让这个html文件和js/css文件称兄道弟
然后是给这个xxx.html该名字, 为啥要改名换目录呢? 因为SpringBoot是约定大于编码的, 在什么目录下面就是什么文件, 此外Thymeleaf部分默认的配置信息如下
@ConfigurationProperties(prefix = "spring.thymeleaf") public class ThymeleafProperties { private static final Charset DEFAULT_ENCODING = StandardCharsets.UTF_8; public static final String DEFAULT_PREFIX = "classpath:/templates/"; public static final String DEFAULT_SUFFIX = ".html";
没办法,这些配置信息默认就认为类路径下的templates中都是xxx.html的文件
第二件事是将html标签中引入的类似thymeleaf这中命名空间都去掉,静态页不需要
<!DOCTYPE HTML> <html xmlns:th="http://www.thymeleaf.org"> <head> <title>商品列表</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <!-- jquery --> <!--<script type="text/javascript" th:src="@{/js/jquery.min.js}"></script>--> <script type="text/javascript" th:src="js/jquery.min.js"></script>
第三件事写一个ajax,当页面一加载就触发向后台发请求,获取数据, 通过jQuery操作各个节点完成数据的渲染
三步打完收工, 看上也不是很复杂, 但是我们的页面就是已然成为了静态页面, 从此她会被浏览器缓存起来,只要这个页面不发生变动,浏览器就会一直使用自己的缓存,在网络上的数据传输量有多带劲自己脑补,系统RT绝对飙升几个数量级
静态资源的优化手段#
说一下市面上常见的静态资源优化技术吧:
- js/css 的压缩与优化,减少流量
- 多个js/css组合在一起,减少连接数量
- Tengine 技术
- webPack , 使用vue开发时,它就会将一整套vue的依赖打包一个js一个html文件,岂不是爽歪歪?
- CDN加速技术, 很多云服务厂商都有提供,而且价格也不贵,将体型大的静态资源放在ＣＤＮ上进行加速也是不错的选择
- 使用Nginx做静态资源代理,而且Nginx就支持零拷贝,还支持将数据文件压缩后在网络上传输 ，自身的并发量也很强大，当静态资源服务器它绝对是不二首选， 相信我，你会爱上它的
另外当多个用户并发修改库存时,竟然将库存修改成了负数, 本身使用的数据库引擎是 innodb是存在行级锁的, 我们只要修改一下我们的sql就行 加条件 and stock_number > 0
为了防止同一个用户发送两次请求,偶尔秒杀到多个商品的情况,我们去miaosha_user表中去建立一个唯一的索引,将userId建立唯一索引,不允许相同的userId出现两次,从而避免上述的情况
验证码技术#
- 好处
让用户去输入验证码的好处有很多, 除了验证用户的身份信息之外, 最明显的好处就是分散用户对系统的压力, 前端如果不添加图片验证码的可能在1s内系统需要承载1万并发, 但是添加了图片验证码, 就能将这1万并发分散到10秒以内,甚至更多
- 整体的思路:
图片验证码不过是个image, 所以说前端想展示它,肯定需要一个img标签, 一个比较不好想的地方是啥呢? 就是这个图片的路径,src=啥的问题, 我们可以怎么做呢? 可以直接通过这个往src中写入后端的生成imge的Controller的路径, 每次刷新页面,它就会往这个路径中发起请求, Controller中去生成一个image, 通过HttpServletResponse的获取到输出流, 将生成的图片用流的发送会浏览器,再加上他是img标签,这不就ok了?
百度一下如何生成图片验证码一类的技术,确实真的很多,我就不贴代码了, 感兴趣的同学自行百度,代码一片片的
- 如何实现点击图片完成刷新操作呢?
因为这种图片是静态资源,如果你不禁用缓存,这个图片就会被缓存下来, 要想每次点击图片都实现更换验证码的话,参考下面的js实现, 添加时间戳
function refreshImageCode() { $("#verifyCodeImg").attr("src","/path/verifyCode?goodsId="+$("#goodsId").val()+"×tamp="+new Date()); }
接口限流技术#
- 什么是接口限流?
举个例子: 如说我们想限制在一分钟内单个用户访问 A Controller中的a方法的次数不能超过30次, 这其实就是一种接口限流的需求, 可以有效的防止用户的恶意访问
- 如何实现接口限流呢?
其实这件事结合缓存来实现并非是一件难事,比如我就用上面的例子: 不是想对a方法进行限流吗? 我们就在a方法中添加下面的逻辑
伪代码如下:
public void a(User user){ // 校验user合法性 // 限流 Integer count = redis.get(user.getId()); if(count!=null&&count>15) return ; // 到达了指定的阕值,直接返回不允许继续访问 if(count==null){ redis.set(user.getId(),30,1); // 表示当前用户访问了1次, 当前key的有效时间为30s }else{ redis.incr(user.getId()); } }
- 如何不让限流的逻辑侵染业务代码呢
我们可以使用拦截器技术, 如果我们的重写了拦截器的preHandler()方法,它就会在执行Controller中的方法前进行回调, 再配合自定义注解技术, 后面简直就是为所以为...
示例:
@Component public class AccessIntercepter extends HandlerInterceptorAdapter { // 在方法执行之前进行拦截 @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod){ HandlerMethod hd = (HandlerMethod) handler; LimitAccess methodAnnotation = hd.getMethodAnnotation(LimitAccess.class); if (methodAnnotation==null) return true; // 解析注解 int maxCount = methodAnnotation.maxCount(); boolean needLogin = methodAnnotation.needLogin(); int second = methodAnnotation.second(); // todo } return true; } }
