学习通上的笔记创建者看了阅览记录上会显示吗

8.2.3.添加Web部署的插件(两种常用的服務器)

将下列两段代码分别添加到plugins内部

 

添加完后会报红就需要点击右侧Maven中的循环按钮进行下载

jetty:run命令执行后点击右侧绿色三角形,下方会顯示加载好的端口

tomcat7:run命令执行后会告诉是在哪个端口下执行的

1.将指定端口的代码整个注释掉

 

对于Maven来说仓库只有远程仓库和本地仓库。远程倉库中涵盖着可供下载的核心插件和jar包等等本地仓库则包含着所有原先在此电脑上加载过的插件等,可供所有在这个电脑上运行的Maven文件使用若在远程和本地仓库中都不存在所需要的文件,就会报错

远程仓库的概念:中央仓库、私服、其他公共库

中央仓库是默认配置下,Maven下载jar包的地方由于刚开始运行Maven时,电脑本地仓库是空的就需要从中央仓库中去下载。

私服是为了节省带宽和时间在局域网内架设嘚一个私有仓库服务器。其可代理外部的远程仓库也可将内部的项目部署到私服上供其他项目使用。也可以从本地上传一些无法从外部獲取的构件

9.2.如何去找寻依赖文件

1.在网页中搜索mvn

3.在里面搜索自己想要的文件内容并选择文件版本

4.点击后复制内部代码

10.Maven环境下构建多模块项目

將Maven划分成多个模块既有利于下载,也可以根据自己的需要选择特定的多模块进行下载以下列四个模块为例

基模块,也就是常说的parent(pom)
數据库的访问层例如jdbc操作(jar)
项目的业务逻辑层(jar)
用来接收请求,响应数据(war)

创建一个无模板的Maven项目 名称改为parent

只需要选择webapp模块别嘚同上一致

10.5.修改模式配置

10.6.设置模块间的依赖

在包中建立一个UserDao类

 
 
 

依照上节中tomcat的启动方法进行启动

若启动失败,则需要将四个项目分别用命令install┅下(在Add Configuration中Maven下进行install)来供其他项目使用

注意,install设置好后要将4个install全部执行一遍

首先要明确jar包是Java项目的压缩包,而war包是Web项目的压缩包

如果內部没有java目录就需要手动添加,添加过程与上面controller添加一致将java文件夹其作为 Resources Root(源文件夹)

同理,如果没有resources目录也要手动添加并将其作為 Resources Root(源文件夹)

11.2.创建需要用到的文件夹

内容在其余两个地方是可以不一样的,因为账号密码是可以不同的

 

这里需要注意的就是env中的值和id中嘚值尽量和文件名对应,这样就容易查找

11.4.设置资源文件配置

 

这里的格式都是固定的使用时直接copy就好

filtering与文件名的替换有关,这里直接关閉就可以

因为在外网用户访问你的项目时人家是直接拿来用的,不需要使用test文件因此在打包的时候跳过test的相关文件

例如执行package_test时,里面嘚对应bean.xml和db.properties就是我们自己设定好的对应值 以此类推会根据自身的执行来进行覆盖

12.1.依赖的基本配置

2.Type:依赖的类型 一般默认为jar

compile:编译依赖范围,没有指定时就会默认使用该依赖范围

test:测试依赖范围只对测试classpath有效

provided:已提供依赖范围,在运行时不需要对编译和测试classpath有效

runtime:运行时依赖范围,对测试和运行classpath有效

system:系统依赖范围和provided的有效范围一致,但由于与systemPath元素显式指定依赖路径有关可能造成构建的不可移植,因此应该谨慎使用

Maven在编译主代码时会使用到一套classpath具体即上面的五种依赖范围

比如A->B->C,我们在使用A的时候不用去考虑依赖了什么,有无多余嘚依赖Maven会解析各个依赖的pom,将必要的间接依赖以传递性依赖的方式引入到当前项目中

但传递性依赖可能会造成冲突问题。

Dbbo是一个框架用于服务间的调度,服务程序编写使用dubbo做接口dubbo实现了服务与服务之间还有zookeeper之间的通讯。

zookeeper用来注册服务进行负载均衡哪一个服务由哪一个机器来提供必需让调用者知道,简单来说就是ip地址和服务名称的对应关系当然也可以 通过硬编码的方式把这种对应关系放到调用方业务代码中实现,泹是如果提供服务的机器宕机调用者将无法知晓,此时如果不更改代码会继续请求挂掉的机器提供服务 zookeeper通过心跳机制可以检测挂掉的機器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发简单来说就是横向扩展,在不更改代码的情况下通过添加机器来提高运算能力通过添加新的机器向zookeeper注册服务,服务的提供者多了能服务的客户就多了于是便能支持更大的并发量。

管理中间层的工具在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度,dubbo提供一个框架解决这个问题注意这里的dubbo只是一个框架,至于你架孓上放什么是完全取决于你的就像一个汽车骨架,你需要配你的轮子引擎这个框架中要完成调度必须要有一个分布式的注册中心,储存所有服务的元数据你可以用zk,也可以用别的只是大家都用zk。

  • Hadoop、HBase组件集群架构,zk是作为集群管理者
  • 是一个分布式应用程序的协调服務很少做业务实现

Zookeeper从设计模式的角度理解:是一个基于观察者模式设计的分布式服务管理框架。它负责存储和管理大家都关心的数据嘫后接受观察者的注册,一旦数据的状态发生变化Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出响应的反应。

文件系统:服务端启动时詓注册信息(创建的都是临时节点)Zookeeper集群存储的是各种服务器的上线信息

通知机制:客户端获取到当前服务器列表,并且注册监听;Zookeeper集群通知客户端(服务端上下线事件通知)

  1. 集群中只要有半数以上节点(半数机制)存活Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器(假如现在有5台服务器,挂了2台集群依然能正常工作,但如果挂了3台就因为违背“半数以上节点存活”的规则而无法正常工作;假如現在有6台服务器挂了2台依然能正常工作,但是挂了3台因为3=(6/2),所以同样也不能正常工作所以,5台和6台在提升集群健壮性上没有任何帮助存在资源浪费)
  2. 全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个server数据都是一致的
  3. 更新请求顺序执行,来自同一个client的哽新请求按其发送顺序依次执行
  4. 数据更新原子性一次数据更新,要么成功要么失败(比如,每次写操作都有事务id(zxid)
  5. 实时性在一萣时间范围内,client能读到最新数据(比如一个client向一个服务器写入数据那其他client要拿到/读到这个数据,需要服务器之间同步数据zookeeper的同步速度非常快)

1.3 内存/数据结构

通知机制,Zookeeper数据模型的结构与Unix文件系统很相似整体上可以看作是一棵树,每个节点称作是一个ZNode每一个ZNode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识

  • 每个子目录如/znode1都被称作为一个znode(节点)。这个znode是被它所在的路径唯一标识
  • znode可以有子节点目錄并且每个znode可以存储数据
  • znode是有版本的,每个znode中存储的数据可以有多个版本也就是一个访问路径中可以存储多分数据(如一个节点中的數据,每次对其修改可对版本号递增1)
  • znode可以被监控,包括这个目录节点中存储的数据的修改子节点目录的变化,一旦变化可以通知设置监控的客户端(如可以使用Java客户端去监控一个节点如果修改,则zk会通知客户端)

问:能否用Zookeeper存储海量的数据

答:不行,它只适合存儲简单的配置信息

是指节点创建后,就一直存在直到有删除操作来删除这个节点——不会因为创建该节点的客户端会话失效而消失。該节点会存储到服务器的磁盘上无论宕机与否,都不会消失

这类节点的基本特性和上述节点类型一致额外的特性是,在ZK中每个父节點会为它的第一级子节点维护一份时序,会记录每一个子节点的创建的先后顺序基于这个特性,在创建子节点的时候可以设置这个属性,那么在创建节点过程中ZK会自动给节点名字加上一个数字后缀,作为新的节点名这个数字后缀的范围是整型的最大值

和持久节点不哃,临时节点的生命周期和客户端会话绑定也就是说,如果客户端会话失效那么这个临时节点也将失效(被自动清除掉)。注意这裏提到的是会话失效,而非断开连接另外,临时节点下面不能再创建子节点

具备临时节点和顺序节点的特性。

提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡(从软件层面而非硬件层面硬件非常贵,但是性能好)等

在分布式环境下经常需要对应用/服务进行统一命名,便于识别例如ip地址不容易记住,而域名容易记住

当client对一个域名访问的时候会洎动根据负载情况,去指定访问特定服务器而不用client自己设定。Nginx等很多框架也同样能实现这个事情

  1. 分布式环境下配置文件同步非常常见
    1. ┅般要求一个集群中,所有节点的配置信息是一致的比如Kafka集群或Hadoop集群
    2. 对配置文件修改后,希望能快速同步到各个节点上
    1. 各个客户端服务監听这个ZNode
    2. 一旦这个ZNode中的数据发生修改Zookeeper就通知所有监听这个ZNode的客户端
  1. 分布式环境中,实时掌控每个节点的状态是必要的
    1. 可根据节点的状态實时做出一些调整
  2. Zookeeper可以实现实时监控节点状态变化
  3. 监听这个ZNode可以获取它的实时状态变化

假如现在有一个Zookeeper集群在/GroupManager下面有多个/clientX,每个客户端鈳以在/clientX下注册/clientX中就可以存放这个客户端的相关运行信息(如服务几点上线、上线时运行状态如何)。而此时别人(Zookeeper或者其他节点)监聽这个节点,就能获取到它的实时状态变化从而做出相应策略(如运维就可以根据服务器运行好坏做出策略)

1.5.4 服务器动态上下线

客户端能实时洞察到服务器上下线变化

在Zookeeper中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请求

当然其他框架也能做负载均衡如Nginx

1.6 选举机制(面试重点)

Zookeeper的选举机制较为复杂,分为第一次启动非第一次启动(第一次选举出来的Leader挂了二次选举…三次选举…)。

假设一个Zookeeper集群中有5台服务器注意这里一开始就有5台,即想要成为leader必须有超过半数以上即至少有3票。每一台集群中的服务器都有一個自己的唯一idmyid

  1. 服务器1启动,发起一次选举每台服务器一开始都默认投给自己,服务器1投自己一票接着需要判断自己手里的选票是否超过总集群数的一半以上,1票不够半数以上(3票)选举无法完成,服务器1状态保持为LOOKING既不是Leader也不是Follower
  2. 服务器2启动,所有启动的服务器再發起一次选举服务器1服务器2分别投自己一票并交换选票信息:此时服务器1发现服务器2myid比自己投票推举的(服务器1myid=1)大,更改选票為推举服务器2此时,服务器1:0票服务器2:2票,判断后发现仍没有半数以上的结果选举无法完成,服务器1、2保持LOOKING状态
  3. 服务器3启动所囿启动的服务器再发起一次选举,并且都投自己然后交换选票信息后都改投服务器3。此次投票结果:服务器1:0票服务器2:0票,服务器3:3票判断后发现服务器3的投票已经达到3票,满足条件服务器3当选Leader。服务器1、2更改状态为FOLLOWING服务器3更改状态为LEADING
  4. 服务器4启动再发起一佽选举。此时服务器1、2、3已经不是LOOKING状态不会更改选票信息。选举结果:服务器3:3票服务器4:1票。此时服务器4服从多数更改选票信息為服务器3,并更改状态为FOLLOWING
  5. 服务器5启动,与服务器4一样状态改为了FOLLOWING

SID:服务器ID。用来唯一标识一台Zookeeper集群中的机器每一台机器不能重复,囷myid一致

ZXID:事务IDZXID是一个事务ID,用来标识一次服务器状态的更新在某一时刻,集群中的每一台服务器的ZXID值不一定完全一致这和Zookeeper服务器对於客户端“更新请求”的处理逻辑有关

Epoch:每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的,每投完一次票这个值会增加

  1. 当Zookeeper集群中的一台服务器出现以下两种情况之一时就会开始进入Leader选举

    1. 服务器初始化时(就是前面的启动时选举
    2. 服务器运行期间无法和Leader保持连接(比如服务器5在某一时刻与leader服务器无法保持连接,它可能认为leader服务器挂了于是会开始进入leader选举,如下)
  2. 当一台机器进入leader选举流程时当前集群也可能存在以下两种状态:

    1. 集群中本来就有一个leader(只是进入选举的服务器没有连接上)。此时该机器试图去选举Leader时会被告知当前Leader信息,对于该机器来说仅仅需要和Leader机器建立连接,并进行状态同步即可

    2. 集群中确实不存在leader

      所以SID为2的服务器会被选举为新的Leader

  1. tickTime=2000:通信心跳时间,Zookeeper服务器与客户端心跳时间单位是毫秒。注意不仅服务器与客户端之间有服务器与服务器之间也有

  2. 注意:默认的/tmp目录,嫆易被Linux系统定期删除所以一般不用默认的tmp目录,建议修改至zk包下

  3. maxClientCnxns=60:最大客户连接数即线程池线程数量。

定义:集合同一种软件服务的哆个节点同时提供服务

  1. 单节点并发访问的压力大
  2. 单节点故障问题(如硬件老化、自然灾害等)

关于为什么客户端可以对任意zk节点进行读写並且zk能保证数据一致请参考第七章节的ZAB协议(消息广播、崩溃恢复)

  1. ,教程里演示了如何在VMware Fusion中搭建多个centos虚拟机并进行简单的网络配置(鈳以ping得同)注意其中涉及到clone机器的操作需要Fusion Pro版本。然后可以用SecureCRT来通过ssh连接每一台虚拟机(这里如果是把虚拟机搭建在本地的话必须每次嘟启动每一台机器再用SecureCRT来ssh)
  2. 关闭防火墙时间同步,集群搭建JDK,ssh免密登录权限管理…

3.2 客户端命令行操作

  1. 首先要有一个main()线程
  2. main()线程中创建Zookeeper客户端,这时就会创建两个线程一个负责网络连接通信(connect),一个负责监听(listener)
  3. 通过connect线程将注册的监听事件发送给Zookeeper服务端
  4. 在Zookeeper服务端的紸册监听器列表中将注册的监听事件添加到列表中
  5. Zookeeper服务端监听到有数据或路径变化就会将这个消息发送给listener线程
  1. 监听节点数据的变化,注意:数据的变化注册一次,只能监听一次;想要再次监听就需要再次注册

  2. 监听子节点增删的变化,注意:路径的变化注册一次,只能监听一次;想要再次监听就需要再次注册

3.3.4 获取子节点并监听

3.4 客户端向服务端写数据

  1. Leader自己进行写操作,同时将这个写请求通知给他的所囿follower节点
  2. 如果超过半数以上的服务器都完成了写请求(与集群的选举一样)就会发送确认通知给Client,告知写请求已完成
  3. 如果还有没有通知的follower嘚节点Leader节点会继续将写请求通知给他们

这样的设计的好处是效率高,只要有半数的节点完成写请求就会被当作整个集群完成了写请求

  1. Leader洎己进行写操作,同时将这个写请求通知给他的所有follower节点
  2. 如果超过半数以上的服务器都完成了写请求Leader节点会通知一开始接收到写请求的Follower節点
  3. 然后该Follower节点会发送确认通知给Client,告知写请求已完成(因为一开始的连接是建立在Client和Follower节点服务器之间)
  4. 如果还有没有通知的follower的节点,Leader節点会继续将写请求通知给他们

该章节就是对应1.5中的第四个Zookeeper应用场景

服务器上线的过程对于Zookeeper集群来说就是Zookeeper创建目录节点的过程

某分布式系統中主节点可以有多台,可以动态上下线任意一台客户端都能实时感知到主节点服务器的上下线

注意这里有一个概念需要明确:在Zookeeper集群中服务器和客户端对于Zookeeper来说都是客户端,区别是服务器在Zookeeper中是作一个创建目录的操作(create)而客户端是监听一个节点的操作(get)

  1. 现在集群上創建/servers节点

在Dubbo框架或SpringCloud框架中,很多时候使用Zookeeper作为服务的注册中心其原理就是利用了zk的监听机制

  1. 首先AService在上线时,会通过客户端与zk建立连接并在zk中创建一个AService临时节点
  2. 然后BService在上线时,会通过客户端与zk建立连接也在zk中创建一个BService的临时节点,根据业务需要AService需要提供服务,而BService會消费服务所以BService需要对AService创建的临时节点进行监听
  3. 此时zk中存在两个永久节点,比如ANodeBNode这两个节点下各自都存在着临时节点,即自己集群Φ的所有ip地址
  4. 正常情况下某一时刻BService需要调用AService:调用的过程中,BService会带着AService服务名去注册中心获取AService服务列表(集群的所有ip地址)到本地嘫后根据负载均衡的策略去选择一台机器并调用服务
  5. AService集群中有机器出现宕机情况,AService应当去注册中心删除宕机的机器的对应ipZookeeper通过watch机制通知到BService,其监听的ANode下路径或数据发生(zk中的监听分为对路径变化进行监听和对数据变化进行监听)变化然后BService删除宕机机器的ip地址并不再调鼡

Zookeeper分布式锁可以用来分布式系统中的多个服务访问共享变量的情况

原生Java API实现分布式锁存在的问题:(在生产环境下,不具备解决实际问题嘚能力)

  1. 会话连接是异步的需要自己处理,如使用CountDownLatch

  2. Watch需要重复注册不然就不能生效

  3. 开发的复杂性还是比较高

  4. 不支持多点删除和创建,需偠自己递归

半数机制超过半数的投票通过,即通过

  1. 投票过半数时服务器id大的胜出

    1. EPOCH大的直接胜出
    2. EPOCH相同,事务id大的胜出
    3. 事务id相同服务器id夶的胜出

6.2 生产集群安装多少台zk合适?

生产经验(并非强制只是最佳):

  • 10台服务器:3台zk
  • 20台服务器:5台zk

zk服务器台数多,好处:提高可靠性;壞处:提高通信延时(半数机制)

思考:Zookeeper如何保持数据一致性这也是困扰分布式系统框架的一个难题

7.1 拜占庭将军问题

拜占庭将军问题是┅个协议问题,拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军问题是这些将军在地理上是分隔开来的,并且将 军中存在叛徒叛徒可以任意行动以达到以下目标:欺骗某些将军采取进攻行动;促成一个不是所有将军都同意的决定,如当将军们不希望进攻时促成进攻 行动;或者迷惑某些将军使他们无法做出决定。如果叛徒达到了这些目的之一则任何攻击行动的结果都是注定要失败的,只有完全达成一致的努力才能 获得胜利

这里只做一个简单记录,该算法可深入研究

Paxos算法:一种基于消息传递且具有高度容错性一致性算法

Paxos算法解决的问题:如何快速正确的在一个分布式系统中对某个数据值达成一致,并且保证不论发生任何异常都不会破坏整个系統的一致性

常见的故障和问题:1. 机器宕机 2. 网络异常(延迟、重复、丢失)

下面我们针对上述描述做三种情况的推演举例:为了简化流程,峩们这里不设置 Learner

  1. 以上情况,A1提出的议案(10%)会被执行但是A5提出的议案(20%)也会被执行,但是时间稍后会覆盖A1的议案

  2. Paxos 算法缺陷:在网絡复杂的情况下,一个应用 Paxos 算法的分布式系统可能很久 无法收敛,甚至陷入活锁的情况造成这种情况的原因是系统中有一个以上的 Proposer,哆个 Proposers 相互争夺 Acceptor 造成迟迟无法达成一致的情况。

    针对这种情况一种改进的 Paxos 算法被提出:从系统中选 出一个节点作为 Leader,只有 Leader 能够发起提案这样,一次 Paxos 流程中只有一个 Proposer不会出现活锁的情况,此时只会出现例子中第一种情况

Zab算法借鉴了Paxos算法,是特别为Zookeeper设计的支持崩溃恢复嘚原子广播协议基于该协议,Zookeeper设计为只有一台客户端(Leader)负责处理外部的写事务请求然后Leader客户端将数据同步到其他Follower节点。即Zookeeper只有一个節点可以发起提案

Zab算法包括两种基本模式:消息广播崩溃恢复


· 说的都是干货快来关注

学习通在电脑上答卷老师是可以看到离开的。

学习通考试的时候会监测每一位学生考试过程中的离开软件的次数老师一方都是可以看到具体數据和离开时间的。老师可以对试卷数据信息集中管理包括试卷的预览、编辑、导出、复制、发布考试、删除。

考试管理对已发布考试集中管理包括考试的详情、考生管理、监考、批阅。考试详情可以查看考试发布设置;并可根据学生违规情况对学生进行提醒考生;吔根据学生违规情况对学生进行强制收卷。

学习通考试的介绍如下:

查看可以看每一套卷子详细信息;可以查看、编辑修改、删除每一套試卷;支持试卷导出excel、word格式;可以复制一套试卷;发布考试并设置:选择考试试卷并发布可以进行相关设置、包括对象设置、基本设置。

抓拍监控可以查看所有学生在考试过程中抓拍的镜头,可以根据抓拍情况查看详情、提醒考生。进行中/已结束考试的批阅按钮对巳提交的试卷进行批阅。


· 没有比挣大米更让我开心的了

如果学习通后台监考老师没有选择在线监考摄像头则考生中途离开,后台监考咾师是会发现的学习通考试系统为所有用户构建了一个网上虚拟的交互空间,或者说一个虚拟的网上教考平台在这个虚拟学校中,有哆个网络多媒体教室可供学生使用每天根据需求不同,在这些教室里分别开设不同的课程

使用学习通答卷系统,教师可以将带有习题、语音的课前预习课件推送到学生手机师生沟通及时反馈;课堂上实时答题、弹幕互动,为传统课堂教学师生互动提供了完美解决方案学习通考试系统全面提升课堂教学体验,让师生互动更多、教学更为便捷

使用学习通考试系统的相关说明:

学习通科学地覆盖了课前-課上-课后的每一个教学环节,为师生提供完整立体的数据支持个性化报表、自动任务提醒,让教与学更明了

所有选修学习通课程的学苼和授课教师可在指定时间里进入该教室进行教学活动,在这个虚拟课堂中学生不光能够听到教师的讲课内容,还可以与教师进行问答與讨论;同时学生和教师之间可以彼此看到对方,就像真实课堂中面对面一样真切

学习通考试的时候在电脑上答卷老师可以看到离开記录。

学习通的监控功能监考老师可以看到每个同学的切屏次数、切屏时长以及离开次数等,除此之外还能进行前后摄像头的抓拍前置摄像头的画面学生本人可以看到,后置摄像头抓拍的画面只有几张照片学生不可见,监考老师能看到 

学习通的监考功能,这个系统呮能在考试过程中使用考试结束后,监考老师能看考试过程中的抓拍记录还有每个人的ip地址、以及每个人所有的异常记录。

学习通系統考试是可以开摄像头的摄像头的权限在于监考老师。开始考试的时候老师发试卷然后进入时会打开摄像头,进行第一次抓拍每个囚的摄像头权限都是开着的,老师那里可以看到而且要保证脸完整录上。

考试的时候也不能切屏老师在后台都是能看到记录的,就像昰在电脑上答题也是不能离开考试页面的,离开的话就会有记录要保证脸完全录上,同时后置摄像头进行不定时抓拍老师也能看到抓拍记录。


· 每个回答都超有意思的

下载百度知道APP抢鲜体验

使用百度知道APP,立即抢鲜体验你的手机镜头里或许有别人想知道的答案。

我要回帖

 

随机推荐