今天完成的事情

1. 负载均衡压测

2. redis 缓存

遇到的问题

1. 静态类中注入 bean

@Component
public class RedisUtil {
    private static RedisTemplate<String, Object> redisTemplate;

    @Autowired
    public void setRedisTemplate(RedisTemplate<String, Object> redisTemplate){
        RedisUtil.redisTemplate = redisTemplate;
}
}

2. redis 没生效

原因：

忘记加上 @Aspect 注解了，又浪费了我一个小时，一直以为是注解出问题了。

收获

无

1. 压测

之前压测是跑到了 1000 个线程，设置的是线程出错即停止，所有的线程停止压测则结束。

今天一开始也是这样去跑的，但是跑了一天之后慢慢发现这种方式其实也不太准确。

我现在是限制一个容器的内存为 1024m，两个这样的应用服务器做负载均衡，实测下来发现最先挂的是数据库，而且开 1000 个线程的话挂的很快。

今天我向测试一下 90% 线，就需要长时间的测试，而不是让他很快就挂了，慢慢跳转线程数，最后发现需要控制在 400-500 之间才能让服务稳定跑下来，这个承受能力和单实例无负载均衡是没区别的。

这也验证了我的一个疑惑，之前压挂了之后发现两个容器都无法访问，我一度怀疑是不是我容器配错了，尝试完配置一个 jetty一个 tomcat 之后还是同时无法访问我才怀疑是数据库挂了。

一开始挂了之后我去看数据库，发现 navicat 无法连接，报错 2013 。但是直接上服务器之进数据库数没有问题的，后台查看了一下有大量的休眠连接，排查后发现是数据库的超时时间设置的过大，导致连接不会被清理，重新设置 wait_timeout=10 之后这个问题解决。

其次我又修改了数据库连接上限与 网站应用的连接池配置，但是对数据库的影响不明显。

最后查看一下 jmeter 的 90% 响应线，发现这个线的意义不大，加了缓存之后 90 % 的响应时间都控制在 2ms 左右。

事后我仔细分析了一下，这个网站结构比较简单，一共只有三个页面，首页，职业详情，登录页。

其中登录页不需要查询数据库，响应时间最快，首页设计的表最多，响应时间最慢。但是我设计压测流程的时候首页与职业详情页面的比例不够多，导致之后这个 90% 响应时间没有参考意义。

这个压测流程是需要根据网站的访问需求来制定的，不能够瞎测，否则测再久，数据都没有意义。

明天的计划

1. 完成压测

2. 完成深度思考