大家好，我是IT修真院北京分院第30期学员，一枚正直善良的java程序员，今天给大家分享一下，修真院java任务中的一个知识点：Redis性能分析报告
（1）首先是系统可以在500ms返回时的tps：
经过很多次变更调试，最终确定全部请求时键500ms以内的线程数最大是22，最大循环次数1：
也尝试了微调，比如23线程：
也就不满足条件了，也尝试稍微加上一次循环，也就是22线程2次循环：
也已经不符合条件。
那么符合条件的就是22线程1s启动循环1次，它的tps视图：
因为线程数和循环数都很小，总请求就很少，所以它是一条直线。那就得出结论了，系统可以再500ms内返回时的tps是18.3。
（2）系统宕机时候的负载：
首先我得定义宕机，我认为测试被迫停止或者就是宕机，没有按照设置跑完就宕机了。
100线程1s启动的情况：
虽然没有宕机，但是响应时间已经非常的长了，但是这还没宕机，调到200线程：
虽然各个参数都挺惨，但是仍然没有宕机，接下来调到300线程：
嗯。。还没有，直接加到500线程：
已经卡住了，并且出现了错误，在观察过程中错误率一直在波动，是因为错误在不断的出现，可以认为此时已经宕机了。
于是结论是：500线程1s启动的时候宕机了。
（3）TPS稳定时的响应时长：
那么调整线程数，达到让tps稳定：
可以看到除了画圈的部分，整体比较稳定，分别对应的是0-20s和49-59s以及1.19-1.39s，那么查看这几个区间的响应时间：
那么可以看到这写区间的响应时间，但是这个图并不是很好，因为刻度太大了，我们只能估摸着来，稳定的时候大概在1.5s左右，不过很多值是小于这个数的
2.那么接下来就是模拟缓存穿透的情况：想想一想要怎么模拟，而且缓存穿透是什么？
这样说吧，本来存在缓存的时候，请求会从环中取出数据，而有的时候突然跑到了数据库中去拿数据，就是缓存穿透了，缓存没能拦住这个请求。也就是说要创走啊这样一个情况：让请求又从缓存拿的，有从数据库拿的，然后对比一下情况。看看缓存穿透的时候会发生些什么。
那么需要在代码里面更改一些，加上一个判断，来查看一波
public static int i =0;//定义全局静态变量，来保存数据
public ListgetAllPros(){
i++;
System.out.println(i);
List pross;
if (redisUtil.get("pross") !=null&&i%9!=0){
pross = (List)redisUtil.get("pross");
System.out.println("从缓存中取到的哦");
// return pross;
}else{
pross =pageDao.getAllPros();
redisUtil.set("pross",pross);
System.out.println("从数据库取到的哦");
// return pross;
}
return pross;
}
这样的话，只有9的倍数次访问的时候才会模拟击穿缓存。
很清晰。
然后在使用jmeter测试的时候效果并不直观，数据太过笼统，于是选择了postman来测试：
这是一次缓存穿透的响应时间。然后下面是直接使用缓存的：
然后赶上下一次的穿透：
还是比较直观的，大概20%的提升吧，而且我觉得在多线程访问的时候肯定效果更好。
