目录
（4）TCP的滑动窗口（1可靠性2tcp流控特性，同时滑动窗口机制还体现TCP面向字节流设计思路）
（1）TCP/IP参考模型
ISO制定的OSI参考模型过于庞大，复杂招致了许多批评，七层模型分别是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。TCP/IP参考模型：应用层、传输层、网络互联层、主机到网络层（链路层）。
应用层：为用户提供各种服务如FTP、Telnet、DNS、SMTP、HTTPS等
传输层：传输层对应OSI参考模型，为应用层实体提供了端到端的通信功能，保证了数据包的顺序传送以及数据完整性。该层主要包含：传输控制协议（TCP）和用户数据包协议(UDP)。
网络层：网络层主要解决了主机到主机的通信问题，他所包含的协议涉及数据包在整个网络上逻辑传输，组中重新赋予一个IP地址来完成对主机的寻址，他还负责数据包在多种网络中的路由，该层有三个主要协议，网际协议（IP）、互联网组管理协议（IGMP）和互联网控制报文协议（ICMP）
链路层：链路层与OSI参考模型中的物理层和数据链路层对应。他负责监视数据在主机和网络之间的交换。事实上，TCP/IP本身并未定义该层的协议，而由参与互联网各网络使用自己的物理层和数据链路层协议，然后与TCP/IP的网络接入层进行连接。地址解析协议（ARP）工作在此层。
（2）TCP相比UDP为什么是可靠的
（1）确认和重传机制：建立三次握手同步双方的“序列号”+“确认号”+“窗口大小信息”，是确认重传，流控的基础。
传输过程中，如果Checksum校验失败、丢包或延时，发送端重传。
（2）数据排序：TCP有专门的序列号SYN字段 提供数据re-order
（3）流量控制：窗口和计时器的使用，TCP串口中指明双方能够发送接收的最大量数据
（4）拥塞控制：TCP拥塞控制有四个核心算法组成，慢启动、拥塞避免、快速重传、快速回复。
（3）为什么说TCP/IP是不可靠的？
如果说TCO/IP是不可靠的，那么TCP的可靠性解释是基于系统内核态，因为TCP层、IP层以及链路层都是位于内核态。当然也有用户态的TCP实现，但你再通用操作系统上面通过socket api来变成肯定是内核态tcp。 虽然内核保证数据一定是可靠的，但你的应用层程序并不能做到这一点，所以应用层还要有一层ACK。（TCP的可靠性是相对于UDP来说的，主要是保证数据不会损坏和丢失，但这些都只是在基于传输层，最终应用层面去实现消息的可靠性）
（4）TCP的滑动窗口（1可靠性2tcp流控特性，同时滑动窗口机制还体现TCP面向字节流设计思路）
对于FTP这样的数据吞吐量比较高要求的，将总是希望每次尽量多的发送数据到对方主机上，就算就是点“延时”也无所谓，TCP也提供了一整套的策略来支持这样请求，TCP协议中16bit表示“窗口”大小，这是这些策略的核心。
这也是对ACK应答策略的改变，一般来说，发送端发送一个TCP数据包，那么接受端就应该发送一个ack数据报，但事实上却不是这样，发送端将会发送连续数据尽量填满接受方的缓冲区，而接受方对这样数据只要发送一个ACK就可以了，这是ACK累计特性，这个特性大大减少发送端与接受端的负担。（就是发送方填充接收方缓冲区的过程）
滑动窗口本质上是描述接收方的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长数据。如果发送方收到接收方的窗口大小为0的数据报时，发送方将停止发送数据报，等接收方发送窗口大小补位0的数据包的到来。TCP就是用这个窗口，慢慢的从数据左边移动到右边，把处于窗口范围内的数据发送出去。
（5）数据拥塞
上面的策略用于局域网内传输还可以，但在广域网中就会出现问题，最大问题就是当传输常出现瓶颈所产生的大量数据堵塞问题，为了解决这个问题，TCP发送方需要确认连接双方的线路的数据最大吞吐是多少，就是所谓拥塞窗口。 拥塞窗口的原理很简单，TCP发送方首先发送一个数据报，然后等待对方的回应，得到回应后就把这个窗口大小加倍，然后连续发送连个数据报，等到对方回应以后，再把这个窗口加倍（先是2的指数倍数，然后到一定程度就变成线性增长，这就是所谓的慢启动）发送更多的数据报，直到出现超时错误，发送端就了解到了通信双方的线路的承载能力，也就确定了拥塞窗口的大小，发送方就用这个拥塞窗口大小发送数据。
（6）zookeeper为什么被需要
Zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序就是基于 数据分布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁与分布式队列等功能。zk致力提供一个高性能、高可用，具有严格的顺序访问控制能力的分布式协调服务。
设计目标：简单的数据结构、冗余可以构建集群、有序访问、高性能。 Zookeeper没有沿用Master/Slave模式，使用了Leader、Follower、Obserfver三种角色。
ZAB原子消息广播协议：ZAB核心定义哪些会改变Zookeeper服务器数据状态事务请求的处理方式：所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，余下其他服务器被称为Follower服务器。 Leader将一个服务器请求转换成一个Proposal，然后这个Proposal分布给集群中其他Follwer，然后等待Follower处理Proposal反馈，当超过一定比例的Follower服务器发出正确反馈，Leader会发出Commit消息，将该Proposal提交。
（7）典型的应用场景
zk主要解决分布式应用的“部分失败问题”，即发送者无法知道接受者是否收到消息，他出现的可能性有网络传输出现问题，接受线程已经死掉。
（1）数据发布与订阅（配置中心）
发布与订阅模型，所谓一个配置中心，顾名思义就是发布者将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务室服务框架的服务地址列表等非常适合使用。
（2）负载均衡
这里是软负载均衡，在分布式环境中，为了保证高可用性，通常一个应用或同一个服务器的提供方会部署多份，达到对等服务，而消费者就必须在这些对等服务器上来选择一个来执行业务逻辑。
（3）命名服务
命名服务也是分布式系统中比较常见的一类场景。分布式系统中，通过使用命名服务，客户端应用能够指定名字来获取资源或者服务地址，提供者等消息。被命名的实体通常可以是集群中的机器，提供服务地址，远程对象等等——这些我们都可以称他们为名字。
（4）分布式通知/协调
zk中特有watcher注册与异步通知机制，能较好的实现分布式环境下不同系统之间的通知和协调，实现对数据变更实时处理。使用方法通常是不同系统都对zk上同一个node节点进行注册，监听znode的变化，其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理。
（5）集群管理与Master选举
集群机器监控：这通常用于那种对集群中机器状态，机器在线率有比较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器定时向监控系统汇报我还活着，这种做法比较明显问题。1、集群中机器有变动的时候，牵连的东西比较多 2、有一定延时
~~为了满足快速对集群中机器做出响应，往往由一个监控系统，实时检测集群机器是否存活。 （客户端在节点x上注册一个watcher，那么如果x的节点变化了，会通知该客户端 2、创建EPHEMERAL类型节点，一旦客户端和服务端的会话结束或过期，那么节点就会消失）
例如监控系统在/Monitor节点注册一个Watcher，以后每动态加载机器，那么就往/Monitor下创建一个EPHEMERAL类型的节点：/Monitor/{hostname}，这样监控系统就能够实时知道机器的增减情况，至于后序处理就是监控系统的业务了。
Master选举：在分布式环境中，有些业务逻辑只需要集群中某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，就是master选举。
利用zookeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局一致性，即：同时有多个客户端请求你创建/currentMaster节点，最终一定只有一个客户端请求能够创建陈宫。此外也可以利用Zookeeper的EPHEMERAL_SEQUENTIAL节点，由于Zookeeper保证SEQUENTIAL的有序性，因此我们可以简单的吧界定啊好最小的作为Master就完成了选主。
（8）原子广播的实现
Zookeeper实现的关键是他的原子广播特性，这个特性是Zookeeper各个Server之间一致性的保证，它分为两个阶段：
1、选举阶段 集群中的节点都要经过一个选举的过程，选出一个杰出的点作为leader，其他节点作为follower（随从者），一旦选出leader后，其他的follower都要和leader保持一致转态。
2、原子广播：所有的请求都要发送给leader，然后leader将update广播给follower，当所有的follower对于update持久话，那么leader将提交update，并返回给客户端一个成功修改的响应，这个过程是原子性，所以这个更改要么错误要么失败。
为了保证事务顺序执行的一致性，Zookeeper为每一个update操作加上了一个全局唯一标识，zxid（可以吧它理解为一个事务ID）update操作是有序的，如果zxid小于z2，那么z1将在z2之前发生。
1、顺序一致性，任何客户端的update都是按照他们发送的顺序来执行的。
2、原子性：update要么成功要么失败
3、单一系统镜像：无论客户端连接到哪一个server，都会看到同样的系统视图。就是说同一个会话中，客户端连接到一个新的的server，他不会看到比上一个server老的系统状态
4、持久性，如果一个update成功了，那么持久化并不会被撤销
5、及时性：客户端不会看到陈旧的数据
（9）初识Tomcat
tomcat架构分析：
Tomcat中最顶层的容器是server，代表着整个服务器，可以包含至少一个Service，用于具体提供服务。Service主要包含Connector和Container，从上图中可以看出Tomcat的新脏就是这连个组件。 Connector用于处理连接相关的事情，并提供socket与Request相关的转换。一个Container可以有多个Connector，这是因为一个服务可有多个连接，例如http与https连接，也可以提供向相同协议不同端口的连接。（Connector的配置就是例如端口号，协议“http/1.1” connectionTimeout=“20000”等等配置）
总结是：Tomacat中只有一个Server，一个Server可以有多个Service，一个Service可有多个Connector和一个Container（2）Server掌握整个Tomcat生死大权3、Service对外提供服务 4、Connector将请求封装成Request与Response具体处理。5、Container用于封装和管理Servlet，以及具体处理request请求。（整个请求的流程就是 一个请求发送到Tomcat之后，首先经过Service然后会交给我们的Connector，Connector用于接受请求并将接受请求封装成Request和Response来具体处理。Container处理完请求之后再返回给Connector，最后由Connector通过Socket将处理的记过返回给客户端）
Container用于封装和管理Servlet，以及具体处理Request请求，在Container内部包含了四个自容器。
1、Engine引擎，用来管理多个站点，一个Service最多只能一个引擎。
2、Host代表一个站点，也可以叫虚拟主机，通过配置Host可以增加站点；
3、Context代表一个应用程序，对应平时开发的一套程序，或者WEB-INF目录以及下面的web。xml文件
4、Wrapper：每一个Wrapper封装着一个Servlet
Container处理请求也是使用Pipeline-Value来处理的，这是一种责任链模式，责任模式是指在处理一个请求的过程中有很多矗立着依次多请求进行处理，每个处理者负责做自己相应的处理，处理完之后将处理后的请求返回，再让下一个处理继续处理。
前端请求被tomcat直接接受或者由前端代理，通过HTTP，此时请求被tomcat的connect接受，不同的connect和Engine被service组件关联起来，在一个Engine中定义了许多虚拟主机，有host容器定义，没给个host代表一个主机，在各自host中，又可以定义多个Context，用此来定义一个虚拟主机中多个独立的应用程序。
（10）Mybatis工作原理
Mybatis框架图，Mybatis整体核心对象，我更喜欢用自己的图表达Mybatis整个的执行流程。
Mybatis运行分为两个部分，第一部分是读取配置问题缓存到Confuguration对象，用SqlSessionFactory，第二部分是SqlSession的执行过程。
Mybatis实现的基本原理是利用：动态代理和反射机制。动态代理中用JDK动态代理和CGLIB代理，这两者区别，JDK动态代理是接口的，CGLIB是基于类的，Mybatis中两种代理都用到，Mapper中用到的是JDK动态代理，在延时加载的时候用到CGLIB代理。
（1）构建SqlSessionFactory过程，SqlSessionFactory是Mybatis的核心类，主要功能提供创建Mybatis的核心接口SqlSession，我们需要创建SqlSessionFactory，为此我们提供配置文件的相关参数。我们通过SqlSessionFactoryBuilder去构建。 首先通过org.apache.ibatis.session.Configuration类中，其次使用Configuration对象去创建SqlSessionFactory。
（2）构建Configuration
Configuration作用：
1、阅读配置文件，包括基础配置的XML文件和映射器的XML文件
2、初始化基础配置，比如Mybatis的别名，一些重要的类对象，例如，插件，映射器，ObjectFactory和typeHandler对象。
3、提供单例，为后序创建SqlSessionFactory服务并提供配置的参数
4、执行一些重要的对象的方法，初始化配置信息。
（3）映射器的内部组成
1、一般而言映射器有三部分组成MappedStatement、SqlSource和BoundSql
MappedStatement：他保存了一个映射器节点（Select/delete/update）。包括许多我们配置的SQL、SQL的ID、缓存信息、resultMap、parameterType、resultType等重要配置信息
2、SqlSource：提供BoundSql的地方，它是MapperStatement的一个属性，一个接口，主要作用是根据参数和其他规则组装SQL.
3、BoundSQL，建立sql的地方，通常有三个参数，SQL、parameterObject、parameterMappings
（4）构建SqlSessionFactory sqlsessionFactory = new SqlSessionFactoryBuilder（）.bulid(inputStream（);
（5）SqlSession运行过程，SqlSession是一个接口，使用它并不复杂，我们构建SqlSessionFactory就可以轻松容易的拿到SqlSeesion
SqlSession是一个接口，使用它并不复杂，我们构建SqlSessionFactory就可以轻松的拿到SqlSession了。
（1）映射器的动态代理
Mapper映射是通过动态代理实现的，代理器的xml命名空间对应的就是这个接口的全路径，那么他的根据全路径的方法名变能够绑定起来，通过动态代理技术，让这个接口跑起来。
（2）SqlSession下四个对象 映射器其实就是动态代理对象进入到了MapperMethod的execute方法，它经过简单的判断就进入了SqlSession的删除、更新、插入和选择等方法。
Mapper执行其实就是通过Executor、StatementHandler、ParameterHandler和ResultHandler来完成数据操作和结果的返回。
Executor 执行器，由它来调用StatementHandler、ParameterHander、ResultHandler来执行对应SQL。
总结：sqlsession通过Exector创建StatementHandler来运行，而StatementHandler要经过下面的三步。1、Prepared预编译SQL 2、parametersize设置参数 3、query/updata执行SQL
5287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
