项目架构相关问题

时间  2019-11-30
标签 项目 架构 相关 问题 栏目 系统架构 繁體版
原文   原文链接

rabitmq的三大做用：
1.同步变异步
2.解耦
3.削峰
javascript

redis 分布式锁用的是setnx命令加锁
JVM为何须要调优?
php

redis部分支持事务,入队列不报错，就能够运行，执行命令时候的报错，事务同样能够提交
单个redis能够达到并发量每秒10万次。
redis是单线程的，命令只能一个个去执行。
css

Rabbitmq自动确认消息问题
autoAck=true. 若是消费者发生异常，则这条消息也被mq丢弃，则消费者消息丢失。
html

Eureka比Zookeeper区别
Zookeeper保证CP
当向注册中心查询服务列表时，咱们能够容忍注册中心返回的是几分钟之前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。可是zk会出现这样一种状况，当master节点由于网络故障与其余节点失去联系时，剩余节点会从新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就致使在选举期间注册服务瘫 痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大几率会发生的事，虽然服务可以最终恢复，可是漫长的选举时间致使的注册长期不可用是不能容忍的。
前端

Eureka保证AP
Eureka看明白了这一点，所以在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工做，剩余的节点依然能够提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时若是发现链接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此以外，Eureka还有一种自我保护机制，若是在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现如下几种状况：
java

  1. Eureka再也不从注册列表中移除由于长时间没收到心跳而应该过时的服务
  2. Eureka仍然可以接受新服务的注册和查询请求，可是不会被同步到其它节点上(即保证当前节点依然可用)
  3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

所以， Eureka能够很好的应对因网络故障致使部分节点失去联系的状况，而不会像zookeeper那样使整个注册服务瘫痪。
web

  1. 总结 Eureka做为单纯的服务注册中心来讲要比zookeeper更加“专业”，由于注册服务更重要的是可用性，咱们能够接受短时间内达不到一致性的情况。不过Eureka目前1.X版本的实现是基于servlet的Java web应用，它的极限性能确定会受到影响。期待正在开发之中的2.X版本可以从servlet中独立出来成为单独可部署执行的服务。

SheetJS好像又叫js-xlsx前端导出Excel
首先咱们引入这个脚本文件。
ajax

<html>
<head>
	<style type="text/css">
		.buttonStyle{
			height: 40px;
			width:200px;
			padding: 40px
		}
	</style>
</head>
<body>
	<button class="buttonStyle" onclick="download()">导出</button>
</body>
<script type="text/javascript" src="https://unpkg.com/xlsx@0.14.0/dist/xlsx.full.min.js"></script>  
<script type="text/javascript">

	function download(){
		var filename = "file.xlsx"; //文件名称
		var data = [[1,2,3],[true, false, null, "sheetjs"],["foo","bar",new Date("2014-02-19T14:30Z"), "0.3"], ["baz", null, "qux"]];  //数据，必定注意须要时二维数组
		var ws_name = "Sheet1"; //Excel第一个sheet的名称
		var wb = XLSX.utils.book_new(), ws = XLSX.utils.aoa_to_sheet(data);
		XLSX.utils.book_append_sheet(wb, ws, ws_name);  //将数据添加到工做薄
		XLSX.writeFile(wb, filename); //导出Excel
	}
	
</script>
</html>

复制代码

Sheetjs导出能够减小服务器的压力，把生成Excel的工做放在客户端来处理。redis

3.Redis发布订阅
Redis 发布订阅(pub/sub)是一种消息通讯模式：发送者(pub)发送消息，订阅者(sub)接收消息。
下图展现了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：
spring

当有新消息经过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

1.先向通道发布消息
redisTemplate.convertAndSend(channel, message);
2.监听器 

<redis:listener-container connection-factory="cacheJedisConnectionFactory">
    <redis:listener ref="redisMessageSwitchListener" topic="channer" />
</redis:listener-container>
复制代码

http的各个版本
HTTP1.0、HTTP1.1 和 HTTP2.0 的区别
http发展的时间轴

影响一个 HTTP 网络请求的因素主要有两个：带宽和延迟。
1.带宽:
表示通讯线路所能传送数据的能力，在单位时间内从网络中的某一点到另外一点所能经过的“最高数据率”。对于带宽的概念，比较形象的一个比喻是高速公路。单位时间内可以在线路上传送的数据量，经常使用的单位是bps(bit per second)。计算机网络的带宽是指网络可经过的最高数据率，即每秒多少比特。

2.延迟:
浏览器阻塞（HOL blocking）：浏览器会由于一些缘由阻塞请求。浏览器对于同一个域名，同时只能有 4 个链接（这个根据浏览器内核不一样可能会有所差别），超过浏览器最大链接数限制，后续请求就会被阻塞。
DNS 查询（DNS Lookup）：浏览器须要知道目标服务器的 IP 才能创建链接。将域名解析为 IP 的这个系统就是 DNS。这个一般能够利用DNS缓存结果来达到减小这个时间的目的。
创建链接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的创建链接，可是这些链接没法复用会致使每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

HTTP1.0和HTTP1.1的一些区别
HTTP1.0最先在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始普遍应用于如今的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为普遍的HTTP协议。 主要区别主要体如今：

1）缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来作为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

2）带宽优化及网络链接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，而且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它容许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和链接。

3）错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

4）Host头处理，在HTTP1.0中认为每台服务器都绑定一个惟一的IP地址，所以，请求消息中的URL并无传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），而且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中若是没有Host头域会报告一个错误（400 Bad Request）。

5）长链接，HTTP 1.1支持长链接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，必定程度上弥补了HTTP1.0每次请求都要建立链接的缺点。

HTTPS与HTTP的一些区别
HTTPS协议须要到CA申请证书，通常免费证书不多，须要交费。
HTTP协议运行在TCP之上，全部传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，全部传输的内容都通过加密的。
HTTP和HTTPS使用的是彻底不一样的链接方式，用的端口也不同，前者是80，后者是443。
HTTPS能够有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTP2.0性能惊人
HTTP2.0和HTTP1.X相比的新特性
新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在自然缺陷，文本的表现形式有多样性，要作到健壮性考虑的场景必然不少，二进制则不一样，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

多路复用（MultiPlexing），即链接共享，即每个request都是是用做链接共享机制的。一个request对应一个id，这样一个链接上能够有多个request，每一个链接的request能够随机的混杂在一块儿，接收方能够根据request的 id将request再归属到各自不一样的服务端请求里面。

header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，并且每次都要重复发送，HTTP2.0使用encoder来减小须要传输的header大小，通信双方各自cache一份header fields表，既避免了重复header的传输，又减少了须要传输的大小。

服务端推送（server push），同SPDY同样，HTTP2.0也具备server push功能。

Websocket协议
首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来讲。
在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP链接中，能够发送多个Request，接收多个Response。可是请记住 Request = Response，在HTTP中永远是这样， 也就是说一个 request只能有一个response。并且这个response也是被动的，不能主动发起。

long poll 其实原理跟 ajax轮询 差很少，都是采用轮询的方式，不过采起的是阻塞模型 ，也就是说， 客户端发起链接后，若是没消息，就一直不返回Response给客户端。直到有消息才返回，返回完以后，客户端再次创建链接，周而复始。

因此在这种状况下出现了，Websocket出现了。他解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就能够主动推送信息给客户端。

可是Websocket只须要一次HTTP握手，因此说整个通信过程是创建在一次链接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。

1)websocket URL模式：
未加密：ws:// 已加密：wss://

2）建立WebSocket:先实例一个WebSocket对象并传入要链接的URL
var socket = new WebSocket("ws://www.example.com/server.php);
socket.close(); // 关闭链接

  1. 表示当前状态的readyState属性
    WebSocket.OPENING (0):正在创建链接
    WebSocket.OPEN (1):已经创建链接
    WebSocket.CLOSING (2):正在关闭链接
    WebSocket.CLOSE (3):已经关闭链接

4）发送数据
var message = { time: new Date(), text: "Hello world!", clientId: "asdfp8734rew" }; socket.send(JSON.stringify(message));// 复杂的数据结构要先进行序列化

5）接收数据
socket.onmessage = function(event){
var data = event.data;// data就是要解析的接收到的JSON字符串
}

6）其余事件：在链接生命周期的不一样阶段触发
open:在成功创建链接时触发
error:在发生错误时触发

springBoot 支持WebSocket
参见官网： https://docs.spring.io/spring-framework/docs/4.3.x/spring-framework-reference/html/websocket.html <br>
复制代码

DNS域名解析服务
域名与IP地址之间是多对一的关系，一个ip地址不必定只对应一个域名，且一个域名只能够对应一个ip地址，它们之间的转换工做称为域名解析。域名解析须要由专门的域名解析服务器来完成，整个过程是自动进行的。
DNS的全称是（ Domain Name System）是“域名系统”的英文缩写。

具体过程以下：
①用户主机上运行着DNS的客户端，就是咱们的PC机或者手机客户端运行着DNS客户端了
②浏览器将接收到的url中抽取出域名字段，就是访问的主机名，好比
www.baidu.com/, 并将这个主机名传送给DNS应用的客户端
③DNS客户机端向DNS服务器端发送一份查询报文，报文中包含着要访问的主机名字段（中间包括一些列缓存查询以及分布式DNS集群的工做）
④该DNS客户机最终会收到一份回答报文，其中包含有该主机名对应的IP地址
⑤一旦该浏览器收到来自DNS的IP地址，就能够向该IP地址定位的HTTP服务器发起TCP链接

DNS为何不采用单点的集中式的设计方式，而是使用分布式集群的工做方式？
DNS的一种简单的设计模式就是在因特网上只使用一个DNS服务器，该服务器包含全部的映射，在这种集中式的设计中，客户机直接将全部查询请求发往单一的DNS服务器，同时该DNS服务器直接对全部查询客户机作出响应，尽管这种设计方式很是诱人，但他不适用当前的互联网，由于当今的因特网有着数量巨大而且在持续增加的主机，这种集中式设计会有单点故障（嗝屁一个，全球着急），通讯容量（上亿台主机发送的查询DNS报文请求，包括但不限于全部的HTTP请求，电子邮件报文服务器，TCP长链接服务），远距离的时间延迟（澳大利亚到纽约的举例），维护开销大（由于全部的主机名-ip映射都要在一个服务站点更新）等问题

DNS服务器通常分三种，根DNS服务器，顶级DNS服务器，权威DNS服务器。

一、在浏览器中输入www.qq.com 域名，操做系统会先检查本身本地的hosts文件是否有这个 网址映射关系，若是有，就先调用这个IP地址映射，完成域名解析。

二、若是hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，若是有，直接返回，完成域名解析。

三、若是hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此咱们叫它本地DNS服务器，此服务器收到查询时，若是要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具备权威性。

四、若是要查询的域名，不禁本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具备权威性。

五、若是本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，若是未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来受权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，若是本身没法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找http://qq.com域服务器，重复上面的动做，进行查询，直至找到www . qq .com主机。

六、若是用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器若是不能解析，或找根DNS或把转请求转至上上级，以此循环。无论是本地DNS服务器用是是转发，仍是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程