今天完成的：

学了一些零散的理论知识，看了看spring实战的书

收获：

1.总结了一下：redis有几种配置方法

1.通过java代码配置，不与spring整合。可以直接用jedis客户端使用。

2.通过RedisTemplate模板配置，过程类似mybatis-spring的整合。然后写一个接口，实现RedisTemplate，RedisTemplate提供了一些方法调用缓存。我用的stringRedisTemplate就是对jedis的封装。是spring-data-redis包中的。

spring-data-Redis为spring-data模块中对redis的支持部分，简称为“SDR”，提供了基于jedis客户端API的高度封装以及与spring容器的整合，事实上jedis客户端已经足够简单和轻量级，而spring-data-redis反而具有“过度设计”的嫌疑。

     1. 连接池自动管理，提供了一个高度封装的“RedisTemplate”类

     2. 针对jedis客户端中大量api进行了归类封装,将同一类型操作封装为operation接口

      3.提供了序列化和反序列化的接口，有多种选择

http://blog.csdn.net/fengzheku/article/details/49735785

3.基于注解的配置。通过spring cache提供的注解支持配置，推荐使用cacheManager，替代RedisTemplate。注意要开启cache的注解驱动。关于注解的部分下面讲的非常好。

http://www.cnblogs.com/duyinqiang/p/5696309.html

2.关于缓存

实体类最好始终实现jdk的序列化接口，并声明一个Serializable接口，以表明该实体类的版本。这是一个好的编程习惯。

3.spring里的一些坑

1. 1.xml配置文档中有5个特殊字符不能直接插入。&  <  >  “   ’需要进行转义。
2. 2.整合多个配置文件，可以使用java代码写String数组，也可以使用<import resources>标签将所有配置文件整合到一个，启动时加载一个就可以。或者在web.xml中配置cotextConfigureLocation和监听器。
3. 3.DTD和schema

   XML DTD ；XML Schema是XML文档常用的两种约束，比如spring1.0以前都是通过dtd声明的。

   相比dtd

   XML Schema符合XML语法结构。 

   DOM、SAX等XML API很容易解析出XML Schema文档中的内容。 

   XML Schema对名称空间支持得非常好。 

   XML Schema比XML DTD支持更多的数据类型，并支持用户自定义新的数据类型。 

   XML Schema定义约束的能力非常强大，可以对XML实例文档作出细致的语义限制。

   XML Schema不能像DTD一样定义实体，比DTD更复杂，但Xml Schema现在已是w3c组织的标准，它正逐步取代DTD。

4. schema的两个作用：1.xml解析器可以获取schema文件，对xml文档做合法性验证。2.schema会开启ide的补全诱导功能，方便配置。但其实没有也可以。

5. 4.了解了服务器架构的发展

   第一阶段：单一应用架构

         当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。其中1~10的意思是，当一个tomcat服务无法满足要求时，我们可以增加部署tomcat的数量并用反向代理来做负载均衡。由于不同的tomcat之间session要共享，方法就是要定时向其它节点进行广播，其它tomcat发现发现与之不同时便会进行同步，当节点数量较多时，广播将会占用大部分带宽，以至于真正的通信所用的带宽严重不足。因此该架构只能用于节点数小于10的情况。

   第二阶段：垂直应用架构

          当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。举个例子，比如把一个大的项目拆分成订单系统、会员系统、前台系统、后台系统、搜索系统，每个系统自成一家，服务层和web层都在一起，哪个系统压力大，就给那个系统增加节点以提升性能。此时用于加速前端开发的Web框架(MVC)是关键。

   第三阶段：分布式服务架构

          当垂直应用越来越多，应用之间交互不可避免，这时代码将非常臃肿（因为同一套代码逻辑可能会被写多遍）。这时将核心业务抽离出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能够更快速的响应市场需求。此时用于提高业务复用及整合的分布式服务框架(RPC)是关键。比如Task89的rmi和tuscany。

   第四阶段：流动计算架构

          当服务越来越多，容量的评估、小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时用于提高机器利用率的资源调度和治理中心(SOA)是关键。如dobbo+zookper。

6. 分布式架构：

7. http://www.cnblogs.com/yzlpersonal/p/5121073.html
   

8. SOA，Webservice，SOAP，REST，RPC，RMI，JMS的区别与联系 ：

9. http://blog.csdn.net/pcceo1/article/details/51245249

10. 5.一些nginx常用参数

11. nginx配置负载均衡后，当一台服务器挂掉，nginx可以自动切换到另外一台服务器，但这个时间有点长，可以通过proxy_connect_timeout参数指定超时时间。 

    至于tomcat等服务器共享session的问题，可以通过ip_hash参数设置。这样每个客户端固定访问一个后端服务器，可以解决session的问题，但这样做就失去了集群的意义了。

    更多参数配置如下：http://blog.csdn.net/lxb15959168136/article/details/53113996

    6.了解了github的用法

12. fork把别人的项目拉到自己的仓库中
13. star关注一个项目
14. commit提交版本更新
15. pull request将fork的项目修完bug，然后提交回去
16. merge收到别人的pull request，自己修bug
17. 更新别人仓库的流程：

    先 fork 别人的仓库，相当于拷贝一份，相信我，不会有人直接让你改修原仓库的clone 到本地分支，做一些 bug fix发起 pull request 给原仓库，让他看到你修改的 bug原仓库 review 这个 bug，如果是正确的话，就会 merge 到他自己的项目中。
    

遇到的问题：

1.一个小坑，用电脑模拟web和service时。通过域名配置的nginx转发请求时，jsp页面跳转路径中的<%=basePath%>将不会被解析，页面打不开，将proxy中域名配置更改为IP即可，但这样做会暴露IP，因此实际项目中不要这样写，仅作测试。

明天的计划：

解决Task9