今天完成的：

Task5改完了，完成Task6的任务2.

收获：

1.MemCache实现原理。做Task6的时候发现加了缓存比不加缓存性能差了好几倍，探究了一下。

首先要说明一点，MemCache的数据存放在内存中，存放在内存中个人认为意味着几点：

1、访问数据的速度比传统的关系型数据库要快，因为Oracle、MySQL这些传统的关系型数据库为了保持数据的持久性，数据存放在硬盘中，IO操作速度慢

2、MemCache的数据存放在内存中同时意味着只要MemCache重启了，数据就会消失

3、既然MemCache的数据存放在内存中，那么势必受到机器位数的限制，这个之前的文章写过很多次了，32位机器最多只能使用4GB的内存空间，64位机器可以认为没有上限

然后我们来看一下MemCache的原理，MemCache最重要的莫不是内存分配的内容了，MemCache采用的内存分配方式是固定空间分配，还是自己画一张图说明：

这张图片里面涉及了slab_class、slab、page、chunk四个概念，它们之间的关系是：

1、MemCache将内存空间分为一组slab

2、每个slab下又有若干个page，每个page默认是1M，如果一个slab占用100M内存的话，那么这个slab下应该有100个page

3、每个page里面包含一组chunk，chunk是真正存放数据的地方，同一个slab里面的chunk的大小是固定的

4、有相同大小chunk的slab被组织在一起，称为slab_class

MemCache的高性能源自于两阶段哈希结构：第一阶段在客户端，通过 Hash算法根据Key值算出一个节点；第二阶段在服务端，通过一个内部的Hash算法，查找真正的item并返回给客户端。

通过stats slabs查看memcache内存使用情况，其序列化对象之后的空间占用比序列化为xml大了很多，性能差的原因也是由于序列化和反序列化太耗时。因此采用memcache缓存对象的时候一定不要直接使用序列化api。有两个解决办法：

1.考虑通过第三方的序列来封装客户端序列化机制，比如google的protobuf序列化

2.将对象List封装为格式化字符串存入memcache，取出时通过正则转回去

2.弄明白了Task5加密过程使用base64和URLEncoder的原因

计算机中任何数据都是按ascii码存储的，而ascii码的128～255之间的值是不可见字符。而在网络上交换数据时，那些不可见字符就有可能被处理错误，这是不利于传输的。所以就先把数据先做一个Base64编码，统统变成可见字符，这样出错的可能性就大降低了。

至于URLEncoder，比如http协议当中的key value字段，或者cookie的保存。必须进行URLEncode 不然出现的等号可能使解析失败，空格也会使http请求解析出现问题，比如 请求行就是以空格来划分的  POST /guowuxin/hehe HTTP/1.1 

3.小课堂里讲的

utf8中中文占3byte，英文2byte。DB中的varchar(20)中20表示字的长度，而不是字节长度。

4.junit与spring整合测试
@RunWith(SpringJUnit4ClassRunner.class) 用于配置spring中测试的环境 
@ContextConfiguration(Locations="../applicationContext.xml") 用于指定配置文件所在的位置 
@Test标注在方法前，表示其是一个测试的方法 无需在其配置文件中额外设置属性. 
多个配置文件时{"/applic","/asas"} 可以导入多个配置文件 

@Ignore可跳过测试方法

5.找了一个项目自动部署的脚本

遇到的问题：

1.已经使用fastjson包手动将list<Bean>序列化再加入缓存，可是加完缓存的压测速度竟然还比不加缓存慢。？？？

我测了一下查1000条数据的接口，测出来90Line在800ms左右。。加了缓存1000ms。。。

明天的计划：

先把上面的问题解决。配服务器，做任务2和任务3，了解一下redis。