内容
1-1 课程导学--------
二期课程主线：Tomcat集群、Nginx负载均衡、Redis分布式
一期的项目架构如下：（单服务架构）
二期会演进为Tomcat架构：然而往往想当然的以为是这样：（如下图错误示例）
以上架构存在诸多问题：（见以后分析）实际的架构如下：
我们可以看到主要区别在于左边多出来的redis服务器（分布式缓冲系统）：
二期课程主线：Tomcat集群、Nginx负载均衡、Redis分布式具体讲解内容见图：
包含redis原理与redis的五种数据结构
通过jedis来操作redis
通过redis缓存实现单点登录
通过spring session实现单点登录
当订单超时未支付时需要实现定时关单
Lombok Annotation Processor原理图
1-2 大型Java项目架构演进解析（学过一期的同学可跳过）------------------------------
从一个小网站说起：应用、文件服务器、数据库服务器都部署在一台机器上（俗称:all in one）架构如下：
但随着用户越来越大，访问越来越大，硬盘、cpu开始吃紧，一台服务器已经无法满足故将数据服务与应用服务进行分离，给应用服务器配置更好的cpu、内存等等，而给数据服务器配置更好、更快的硬盘，例如下图分离后：
可以在一定程度上的提高性能和可用性（即使文件服务器挂了，依然可以操作应用服务器和数据库），随着访问并发越来越高，为了节约访问时间，提高访问性能，继续演进如下：（因为很多业务数据并非每次都需要从数据库中获取，所以我们使用了缓存，因为80％的业务访问都集中在20％的业务数据上，俗称28原则，如果我们能够将这20％的数据缓存下来，性能一定能够得到提高）图中增加了Distributed Cache Server Cluster
缓存分为两种：
本地缓存：如下Application中
远程缓存：分远程单机缓存和远程分布式缓存
现在思考：具有哪几种业务特点的数据需要使用缓存？具有哪几种业务特点的数据需要使用本地缓存？具有哪几种业务特点的数据需要使用远程缓存？分布式缓存在扩容时会碰到什么问题？如何解决？分布式的算法都有哪几种？各有什么优缺点？
随着访问的QPS不断提高，服务器的处理能力（比如Tomcat）就会成为瓶颈（虽然可以通过使用更好的硬件来提升，但终究会有上限，并且成本到后期会成指数级上升），因此需要做一个服务器的集群，所以添加了一个负载均衡调度服务器，如下图，这样就可以横向扩展服务器（多台服务器），解决了服务器处理瓶颈的问题
现在思考：负载均衡的调度策略各有哪些？各有何优缺点？各适合什么场景？轮询：优（实现简单）缺点（未考虑每台服务器的处理能力） 无法实现session共享（如下图）权重：优（考虑了不同服务器处理能力的不同）地址散列：（原ip地址散列，目标ip地址散列，）优（能实现同一个用户访问同一台服务器）缺（ip hash不够分散，也不够均匀，有可能造成某些服务器压力过大，某些服务器一直空闲，这样机器网卡的带宽就可能成为一种瓶颈）最少连接：优（可以使集群中各个服务器负载更加均匀）
加权最少连接：
轮询：登录时登录到A服务器，session信息也存在A服务器上，但接下来的请求可能访问的是B服务器，导致session无法共享
解决方案:session stick（音）:对同一连接中的数据包，负载均衡服务器会转发到后端固定的服务器进行处理；缺点1，若服务器1重启，上面存储的session全部消失。2，负载均衡服务器成为了一个有状态的服务器，要实现容灾会有麻烦session Copy：如下图，会把在1中生成的session复制到服务器2上，同理，也会把2上的sesssion复制到1上，所有的服务器中都存储所有session。（不停复制占用大量带宽，若session多占用内存）
基于cookie：如下图(session每次都随cookie保存回本地，每次访问服务器都自带session）缺点：1，cookie的长度是有限制的 2，保存在本地浏览器会有安全性问题
session共享服务器：如下图
缺点：如下图 session是单点的，如何保证它的可用性，同时需要调整业务逻辑还可以把session server做成一个集群，适用于sesssion数量和web服务器大的情况
一些问题：为什么做单点登录，有哪些解决方案，各有什么优缺点，为什么选用这种解决方案，在选择这种解决方案时是如何平横和取舍的？
因为读写操作都需要经过数据库，当用户量达到一定量时，数据库就会成为瓶颈，解决方案如下：使用数据库的读写分离（读从库，写主库，且通过统一的数据模型进行访问（因为数据库读写分离了，应用程序需要做出一定的变化，通过数据访问模块，使上层写代码的人不知道有读写分离，这样即使是多数据源但对代码都没有侵入））问题：如何支持多数据源，如何封装对业务没有侵入，如何使用目前的业务使用的ORM框架完成对主从的读写分离，是否需要更换ORM，又各有什么优缺点？如何取舍？
当访问量过大时候，我们数据访问又会遇到以下问题：例如主库和从库在复制时候有没有延时，将主库和从库分机房部署，在跨机房传输同步数据也是一个问题，我们应用对数据源的路由问题？
下面增加CDN和方向代理服务器；使用CDN可以很好的解决不同地区的访问速度问题，反向代理则在服务器机房中缓存用户的资源；
若文件服务器出现瓶颈，则将文件服务器部署为分布式文件服务器集群，如下图：在使用分布式文件系统时，需要考虑以下几个问题：
1，如何不影响已经部署在线上的业务访问
2，是否需要业务部门清洗数据
3，是否需要备份服务器
4，是否需要重新做域名解析等等
若数据库依然出现瓶颈，则可以使用专库专用的方式，进行数据的垂直拆分，相关的业务都用自己的库，解决了数据并发量大的问题：如下图
当我们将这些表分为不同的库，又会代来哪些新的问题？跨业务/库的事务（一个事务使用了多个表），如何解决？使用分布式事务，或者去掉事务，或者不追求强事务跨库的（duoyes）如何实现？当单个库随着数据量访问增多可以对库进行水平拆分，如下图2
水平拆分User库（将同一个表的数据拆分到两个数据库当中，解决单数据库的瓶颈）有哪几种水平拆分的方式？需要注意什么？
还可能碰到sql路由问题，假如我们有一个用户，如何知道这个用户的信息存在user1这个库中还是user2中，
还可能应用服务器的搜索量飙升（推广的原因），所以可以将应用服务器中搜索功能单独抽取出来做了一个搜索引擎，同时部门场景可以使用NoSQL来提高性能。（同时需要一个统一的数据访问模块解决上层应用开发的数据源问题）
为提高服务的稳定性（只有一个的话，一旦崩溃整个服务都无法访问），将负载均衡服务器提升为一个集群，然后做一些主从的双机热备，自动切换的解决方案。
1-3 一期课程与问答服务回顾（学过一期的同学可跳过）---------------------------
1-4 一期项目结构和代码回顾(学过一期的同学可跳过)---------------------------
1-5 课程使用系统及技术版本介绍（一期+二期）------------------------
git status
git add .
git commit -am "the end"
git push
git branch
git branch -r
git checkout -b v2.0 origin/v1.0
git branch
git push origin HEAD -ugit status
操作系统：
centos 6.8 64位
windows7
mac 0s
jdk版本7u80
git 版本2.8.0
maven 版本 3.0.5
mysql版本5.1
nginx版本1.10.2
tomcat版本7.0
vsftpd版本2.2.2
redis版本2.8
idea 2017
rdm 0.8.8
jd 1.4.0
spring 4.0.3 release
mybatis 3.4.1
mybatis spring 1.3.0
logback 1.1.2
guava 20.0
joda-time 2.3
pagehelper 4.1.0
jedis 2.6.0
lombok 1.16.18
spring-session-data-redis 1.2.0.release
jackson 1.9.12
redisson 2.9.0
fasterxml 2.9.0
软件及环境配置参考：http://learning.happymmall.com/
1-6 二期项目初始化------------------------------------------------------------------------
首先在gitcangku上新建一个分支：
查看分支：git branch (查看本地仓库)
git branch -r (查看远程仓库)
基于v1.0新建一个v2.0的分支：
git checkout -b v2.0 origin/v1.0
推送到远程仓库：
git push origin HEAD -u
（需另外添加非maven管理的jar包）