今天完成的事情

继续优化

关于redis处理请求过慢的问题，大概时因为redis是单线程的，在压测时，大量请求涌入，而在对redis进行操作时，只能排队等待，一个一个地执行命令，从而造成延时

不过redis本身的性能是很快的，即使是单线程，速度也不必多线程的memcache差，所以，可以查看对redis的操作中，由哪些造成了大量的耗时

一共只有三个操作，

从缓存中获取数据：

‍‍ student =(Student) SerializeUtil.unserialize(jedis.get("1".getBytes()))

清空缓存：

‍‍jedis.flushAll()

重新写入数据：

‍‍ jedis.set(k.getBytes(),SerializeUtil.serialize(student))

经过排查，可以确定是jedis.flushAll()的原因，从名字也能看出来，这个操作是针对redis进行的全局操作，必然会耗费大量的时间，而在实际的开发中，应该是直接给数据设置一个有效期，不用这样频繁的清空操作的

针对这里的压测，为了模拟真实情况，需要对数据进行删除操作，不能用清空的话，可以可虑采用直接删除所操作的键值对，因为值针对单个数据进行操作，不会影响性能。

修改后的代码：

@RequestMapping("/12")
public String jsp_redis(Model model){
    Student student = null;
    Jedis jedis = jedisPool.getResource();
   student =(Student) SerializeUtil.unserialize(jedis.get("1".getBytes()));
   if (student==null) {
       student = studentService.get(1);
        int i = student.getID();
        String k = i + "";
        jedis.set(k.getBytes(),SerializeUtil.serialize(student));
    }
   int i = student.getID();
    String k = i + "";
   synchronized (this) {
  if (count3 % 3 == 0)
    jedis.del(k);
   }
   jedisPool.returnResource(jedis);
    count3++;
    model.addAttribute("student",student);
    return "12";
}

‍‍用 jedis.del()来代替，可以实行同样的效果

对本地web项目进行压测：

在500毫秒下，压测JSP，无负载均衡，无缓存，

线程250，TPS1227

在500毫秒以下，压测JSP，无负载均衡，memcache缓存：

线程250，TPS1397

在500毫秒以下，压测JSP，无负载均衡，redis缓存：

线程300，TPS1403

在500毫秒以下，压测JSON，无负载均衡，无缓存：

线程280，TPS1390

在500毫秒以下，压测JSON，无负载均衡，memcacahe缓存

线程290，TPS1549

在500毫秒以下，压测JSP，无负载均衡，reids缓存：

线程310，TPS1467

明天的计划

压测负载均衡下的情况

遇到的问题

无

收获

了解了单线程，多线程和并发的相关概念