• NodeJs 面试题 2022.6

    ㅤㅤㅤ
    ㅤㅤㅤ
    ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ（要知道对好事的称颂过于夸大，也会招来人们的反感轻蔑和嫉妒。——培根）
    ㅤㅤㅤ
    ㅤㅤㅤ
    ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ在这里插入图片描述

    NodeJs相关

    • 什么是NodeJs

      • Nodejs是一个基于V8虚拟机的JavaScript的运行时平台，使用了事件驱动和非阻塞IO模型，让JavaScript能够像Java，PHP等语言一样运行在服务端

    • 应用场景

      • web开发，nodejs提供了js运行时，可以运行在服务端
      • 开发效率高，js动态语言， 不强制要求类型
      • io性能强劲，依靠libuv，不同考虑多线程等复杂操作(锁)，降低开发成本
      • 有强大的npm包平台，类似Java的maven
      • 前后端语言统一，降低开发成本

    • 和JavaScript的区别

      • JavaScript只能应用在前端，Nodejs可以让JavaScript运行在服务端
      • JavaScript的全局对象是windows，而Node是Global
      • JavaScript因为浏览器的差异要考虑兼容性，而Nodejs是服务端，所以不需要考虑兼容性
      • Node的事件循环依赖底层libuv，JavaScript的事件循环依赖的是浏览器

    • NodeJs和Java相比的区别和优缺点

      • node是单线程，java是多线程
        • javascript单线程，开发成本低，io多线程由libuv提供，去掉了操作多线程的成本。java多线程，性能没问题，相比node，虽然没有libuv，但可以自己管理线程池
        • javascript是解释性语言，运行时才进行编译检查。而java是半编译半解释型语言，
        • javascript是弱类型语言，编码中不强制类型。java是强类型语言，编码中强制类型
        • node使用的是js语言，前后统一，降低开发成本

    • NodeJs特性都有哪些

      • 事件驱动
      • 非阻塞io
      • 单线程(但io操作是多线程)

    • NodeJs事件驱动是什么

      • 典型的发布订阅模式，只有当事件发生的时候才会调用回调函数。其中会有一个事件队列不断的获取事件来执行

    • NodeJs事件驱动的优缺点

      • 优点

        • 适合处理密集型I/O任务：通过事件循环机制，多个并行的任务，在JavaScript处理起来，只是将不同的任务分配给不同的线程，等待返回结果执行即可。所以处理速度超级快，有很高的实时性。
        • 适合处理高并发：RESTful Api动辄发起成千上万条请求，但是请求本身并没有太多的计算量，开启多线程处理等待结果又太浪费机器性能。所以事件循环非常适合处理此种场景。
        • 适合处理少量业务逻辑：例如浏览器中，在处理用户交互事件，页面渲染等少量业务逻辑的场景上，具有很好实时性，能给用户提供很流畅的体验。

      • 缺点

        • 不适合cpu密集型应用：因为JavaScript单线程的设计，因此，对于高强度运算的任务，可能会因为运算能力有限，导致任务处理时间过长，影响后续任务执行。

        解决办法： 将单个cpu密集型任务拆成多个子任务，留出一定时间间隔执行其他任务。

        1. cpu利用率低：因为单线程的原因，cpu多核性能利用率低。

        解决办法： 1.开启宿主提供的多线程功能。 2. 如果在node端，通过nginx代理，同时开启多个node进程进行处理。

        1. 安全性低：因为单线程的原因，如果主线程发生错误，将直接导致应用崩溃。

    • NodeJs事件驱动原理

      • 事件循环是 Node.js 处理非阻塞 I/O 操作的机制——尽管 JavaScript 是单线程处理的——当有可能的时候，它们会把操作转移到系统内核中去。

        既然目前大多数内核都是多线程的，它们可在后台处理多种操作。当其中的一个操作完成的时候，内核通知 Node.js 将适合的回调函数添加到 轮询 队列中等待时机执行

      • 详解链接

        • https://blog.csdn.net/qq_42427109/article/details/125301276?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22125301276%22%2C%22source%22%3A%22qq_42427109%22%7D&ctrtid=5OEVl

    • libuv线程池运行原理

      • libuv最初是为nodejs编写的跨平台支持库。它是围绕事件驱动的异步 I/O 模型设计的

      • libuv 提供了一个线程池，可用于运行用户代码并在循环线程中获得通知。此线程池在内部用于运行所有文件系统操作，以及 getaddrinfo 和 getnameinfo 请求。

        它的默认大小是 4，但可以在启动时通过将 UV_THREADPOOL_SIZE环境变量设置为任何值来更改它，最大支持1024个线程

      • 线程池是全局的，并且在所有事件循环中共享。当特定函数使用线程池时（即使用时uv_queue_work()），libuv 会预先分配并初始化 允许的最大线程数 UV_THREADPOOL_SIZE。这会导致相对较小的内存开销（128 个线程约为 1MB），但会提高运行时线程的性能

    • NodeJs如何使用libuv中的线程池

      • node通过使用node-gyp将c++代码编译成.node文件，然后在js内部引入就可以使用了。
      • 通过c++提供的接口，在node里就可以利用libuv驱动来使用系统资源了

    • NodeJs事件驱动和浏览器的事件循环区别是什么

      • 在 nodejs 中事件循环不再是由单一个 task queue 和 micro-task queue 组成，而是由多个 阶段 phase 的多个回调函数队列 callbacks queues 组成一次事件循环 tick。 并且在每一个单独的阶段都存在一个单独的 回调函数 FIFO 队列

    • Http七层协议工作原理，都有哪些状态码，分别是什么意思

      • 为什么需要协议？

        • 如果苹果，三星，华为都是自己的协议，那么就只能和自己通信，所以就弄一个标准化的协议，所有人来实现，这样所有人就能互通了

      • 四层协议关系

        • 应用层：http协议，邮件服务协议
        • 传输层：TCP协议
          • SYN 建立连接
          • FIN 关闭连接
          • ACK 响应连接
          • PSH DATA数据传输
          • RST 连接重置
        • 网络层：IP协议
        • 数据链路层：以太网协议

      • 端口号范围0-65535，1024之前不允许用

      • 物理层

        • 过去：通过家里的猫来连接网线实现电脑间的通信，这个就属于物理层
        • 现在：连接无线网，属于无线讯号，也是物理层
        • 连接上之后传递010101的电路信号

      • 数据链路层

        • 是给电路信号分配规则的，过去每个公司都有自己的电路信号规则。
        • 后来出现了以太网协议，将电信号归纳成一个数据包，也叫一个帧。
          • 每一帧都分成两部分，标头head和数据data
          • 标头head包含了一些说明信息，比如发送者mac地址，接收者mac地址和数据类型等
        • 而电路信号的通信又依赖网卡，利用电脑间的网卡进行通信
          • 以太网协议规定网卡包含mac地址，mac地址是网卡的唯一标识，全球唯一
            • 12个16进制的数字表示mac地址
            • 前6个16进制数字是厂商编号
          • 后6个16进制数字是网卡流水号
            • windows使用ipconfig命令查看mac地址 物理地址 比如7C-67-A2-20-AB-5C
            • linux使用ifconfig -a命令查看mac地址
          • 所以以太网传递数据包就必须指定接收者的mac地址才能进行传输
          • 以太网协议如何根据网卡进行通信的？
            • 局域网情况下，也叫子网
              • 在以太网内一个数据包的发送，会先广播给局域网的所有电脑设备网卡，然后每台电脑都从数据包中取出接收者的mac地址和自己的mac地址进行对比，如果是一样的，则说明是给自己发送的数据包才进行处理，否则就丢弃数据包
            • 如何知道哪些电脑在当前局域网内呢？
              • 这就需要依靠网络层来支持了
                • 请看下面的网络层

      • 网络层

        • 网络层里有ip协议，ip协议定以的地址就是ip地址。ip地址理由ipv4和ipv6两种类型，目前广泛使用的是ipv4，是由32个二进制数字组成，但一般由4个十进制数字来表示，范围是0.0.0.0到255.255.255.255
        • 每台电脑都有一个ip地址，前24位(前3位十进制数字)代表网络，后8位(最后1个十进制数字)代表了主机，如果几台电脑是一个子网的，那么前3位十进制的数字就是一样的
          • 比如开虚拟机或者连接的都是同一个网线，无线网，则电脑的ip地址分别是192.168.0.180，192.168.0.181，192.168.0.182，192.168.0.183，可以看出192.168.0这三位数字是一样的就证明大家是一个子网的，最后一个数字就是主机编号
          • 但上面的描述不是百分百准备，需要将子网掩码进行二进制运算才可以真正对比出是不是属于同一个子网内
            • 比如192.168.0.180和192.168.0.181 通过二进制运算后的结果分别式
            • 11000000.10101000.0.10110100
            • 11000000.10101000.0.10110101
            • 然后判断前三位 如果相同则证明是一个子网
            • 最后一位表示主机编号
            • 所以通过子网掩码就可以确定局域网下的电脑，然后就可以互相通信了
            • 但如果不在一个子网内？是如何通信呢
            • 所以这就需要路由器
        • 路由器 也成为网关
          • 可以把多个子网给串联起来
          • 根据以太坊协议，网卡间只能在子网内进行通信，但要和其他网卡进行通信，就可以把包发给交换机，交换机再把包进行广播，路由器(路由器也有mac地址)上的网卡收到后判断是不是自己的，是自己的话，再通过交换用以太坊协议进行广播分发
          • 所以以太网要和多个子网进行通讯，就需要交换机和路由器
          • ARP协议
            • 一个局域网内的机器会互相给对方发送自己的mac地址，所以当一个机器要发送数据包时，就可以知道其他电脑的mac地址了
        • 交换机，一种工作在数据链路成的设备，网关是工作在网络层
        • 总结：子网间的机器如何通信，在数据包中写上对方的mac地址，通过交换机用以太坊协议进行广播。如果是跨子网通信，在包里写上目标和路由器的mac地址，路由器再根据目标地址通过交换机进行广播，一直持续找到最终mac地址为止
        • LAN 局域网
        • WAN 广域网
        • WLAN 无线局域网
        • 但同一个电脑下运行着qq，微信，视频等软件，怎么区分数据包是发给这个ip下的哪一个服务呢？那么就需要有一个端口的概念来进行区分，所以这也是为什么端口要唯一的原因。
        • 那么如何将数据包发到某一个ip的某一个端口上？这就需要TCP协议了

      • 传输层

        • TCP协议简述

          • 存在长连接和短连接

            • 短链接

              • TCP短连接：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。

                短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段

            • 长连接 keepalive

              • TCP长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
              • 如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态
              • 客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。
              • 客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
              • 客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
                客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

            • 什么时候用长连接或者短连接

              • 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
              • 而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

          • 服务于会话层

          • 建立在某个主机的某个端口到另一个主机下某个端口的连接和通信的，这个通信是使用socket来实现，通过socket实现上面的ip寻址，而且还会建立端口间的连接。规定了一套基于端口的通信协议，包括建立连接，发送和读取消息。

          • 大概机制就是在数据包中加入端口号，寻址到ip后，再去寻找监听该端口号的服务，将数据包发送过去

          • 特点

            • TCP依靠端口来进行通信 TCP头有自己的端口 TCPdata有目标的端口
            • 传输可靠，因为要经历三次握手和四次挥手
            • 可靠性传输依赖的是ARQ协议
            • 流量控制

        • UDP协议简述

          • UDP提供无连接服务
          • 不需要维护连接状态
          • 适用于效率高的应用
          • 不像TCP那样每一次发送都需要进行确认
          • 性能高，开销小
          • 连接不可靠

      • 会话层

        • 维护两个节点的传输连接，确保点到点传输不中断和管理数据交换等功能

      • 表示层

        • 提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别
        • 作用
          • 数据编码和解码
          • 数据加密和解密
          • 数据压缩和解压缩
          • 展示图片，音频和视频等
        • 总结
          • 表示层从应用层接收数据。这些数据是以字符和数字的形式出现的，表示层将这些数据转换成为机器可以理解的二进制格式，也就是封装数据，和格式化数据。例如：将ASCII码转化为别的编码，这个功能称为“翻译”。在传输数据之前，表示层减少了用来表示原始数据的比特数，这个过程被称为数据压缩，它可以是无损或者有损的，数据压缩减少了存储原始数据所需的空间，所以它可以在很短的时间内到达目的地，数据压缩对实时视频和音频的传输有很大的帮助。
          • 为了保持完整性的数据，传输前的会给数据加密，而加密和解密是敏感数据的安全保障，在中心端，数据在接受端被加密，数据被解密为SSL协议或者安全套接字。
          • 所以，表示层执行三个基本功能：翻译、压缩和加密/解密。

      • 应用层 http协议(80端口)，https(443端口)，ftp(21)，ssh(22)，smtp(25)

        • TCP能传输数据了，为什么还需要类似http这种应用层协议？

          • 因为如果每个公司都有自己的应用层协议，那么会导致两端数据无法识别。所以就需要抽象出国际协议，比如http(Hyper Text Transfer Protocol)。
          • 它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使开发和部署非常地直截了当
          • 因为我们在传输数据时，可以只使用TCP/IP协议进行传输，但是这样没有应用层的参与，会导致两端无法识别数据内容，这样传输的数据也就没有意义了。因此如果想让传输的数据有意义，那么就必须要用到应用层的协议，比如http
          • web使用http协议作为应用层协议，封装http文本信息，然后使用tcp协议进行传输

        • http长连接 keep-alive

          • 若开启后，在一次http请求中，服务器进行响应后，不再直接断开TCP连接，而是将TCP连接维持一段时间。在这段时间内，如果同一客户端再次向服务端发起http请求，便可以复用此TCP连接，向服务端发起请求，并重置timeout时间计数器，在接下来一段时间内还可以继续复用。这样无疑省略了反复创建和销毁TCP连接的损耗

          • 启用HTTP keep-Alive的优缺点：

            优点：keep-alive机制避免了频繁建立和销毁连接的开销。 同时，减少服务端TIME_WAIT状态的TCP连接的数量(因为由服务端进程主动关闭连接)

            缺点：若keep-alive timeout设置的时间较长，长时间的TCP连接维持，会一定程度的浪费系统资源。

            总体而言，HTTP keep-Alive的机制还是利大于弊的，只要合理使用、配置合理的timeout参数。

          • 和TCP的keepalive区别是

            • TCP的是为了检测心跳，保持活跃的
            • HTTP的主要是在TCP的保活基础上重用连接，提高性能的

      • 什么是DNS

        • 通常我们访问网址都需要输入一个域名，但协议都是根据ip进行寻址的，所以会有一个DNS服务器，输入一个域名的时候会先发给DNS服务器，DNS服务再告诉你对应的ip地址

    • WebSocket面试题

      • websocket和socket的区别

        • 什么是socket协议

          • socket是应用层与TCP/IP协议通信的中间软件抽象层，它是一组接口。而websocket协议是一个完整的应用层协议，基于TCP长连接实现的
          • Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
          • Socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作, socket就是该模式的一个实现，socket是一种特殊的文件，一些socket函数就是对其进行的操作(打开、读/写IO、关闭)。
          • 套接字（socket）是一个抽象层，应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。套接字允许应用程序将I/O插入到网络中，并与网络中的其他应用程序进行通信。网络套接字是IP地址与端口的组合。

        • sockey协议调用流程

          • 先从服务器端说起，服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。

        • socket核心api

          • **socket()：**创建套接字。

            **bind()：**指定本地地址。一个套接字用socket()创建后，它其实还没有与任何特定的本地或目的地址相关联。在很多情况下，应用程序并不关心它们使用的本地地址，这时就可以不用调用bind指定本地的地址，而由协议软件为它们选择一个。但是，在某个知名端口（Well-known Port）上操作的服务器进程必须要对系统指定本地端口。所以一旦创建了一个套接字，服务器就必须使用bind()系统调用为套接字建立一个本地地址。

          • **listen()：**设置等待连接状态。对于一个服务器的程序，当申请到套接字，并调用bind()与本地地址绑定后，就应该等待某个客户机的程序来要求连接。listen()就是把一个套接字设置为这种状态的函数。

          • **connect()：**将套接字连接到目的地址。初始创建的套接字并未与任何外地目的地址关联。客户机可以调connect()为套接字绑定一个永久的目的地址，将它置于已连接状态。对数据流方式的套接字，必须在传输数据前，调用connect()构造一个与目的地的TCP连接，并在不能构造连接时返回一个差错代码。如果是数据报方式，则不是必须在传输数据前调用connect。如果调用了connect()，也并不像数据流方式那样发送请求建连的报文，而是只在本地存储目的地址，以后该socket上发送的所有数据都送往这个地址，程序员就可以免去为每一次发送数据都指定目的地址的麻烦。

          • **accept()：**接受连接请求。服务器进程使用系统调用socket，bind和listen创建一个套接字，将它绑定到知名的端口，并指定连接请求的队列长度。然后，服务器调用accept进入等待状态，直到到达一个连接请求。

          • **read()、write()：**当服务器与客户已经建立好连接之后。可以调用网络I/O进行读写操作了，即实现了网咯中不同进程之间的通信，网络I/O操作有下面几组：

      • 什么是websocket

        • HTML5的一种新协议，允许服务器想客户端传递信息，实现浏览器和客户端双工通信

      • 运行原理

        • 为什么要用

          • 因为http协议请求后都会关闭连接，下次请求的时候又要重新建立连接。当长轮询过多时会对服务器负载造成较大影响。所以就用websocket协议来完成类似聊天室，实时状态推送等业务场景功能

        • 应用场景

          • 实时通信

        • 特点

          • 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器
          • 数据格式比较轻量，性能开销小，通信高效
          • 没有同源限制，客户端可以与任意服务器通信

        • 基于TCP再次封装的另一个协议

        • 首先在连接的时候会发送一个协议升级请求，在http请求上加上socket相关的请求头

          • Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: k1kbxGRqGIBD5Y/LdIFwGQ==
Sec-WebSocket-Version: 13
Upgrade: websocket

            • 1
            • 2
            • 3
            • 4

        • 服务端如果支持socket的话，会返回101状态码同意协议升级

        • 总结概述

          • websocket是HTML5新增的一种全双工通信协议，客户端和服务端基于TCP握手连接成功后，两者之间就可以建立持久性的连接，实现双向数据传输。它也是基于TCP协议的，建立连接时也是先通过TCP完成三次握手，然后再发送一个http请求，携带协议升级的相关请求标识，比如Upgrade: websocket。服务端同意协议升级并返回一个回包进行确认，这样websocket就连接上了
            • 后续的发送消息就依靠网络层协议来完成了，交换机，网关等

      • WebSocket和Http区别，相比的优缺点

        • 总结
          • websocket是全双工协议，客户端和服务端双向通信
          • websocket协议头是ws/wss，http是http/https
          • websocket只需要连接一次，http需要反复的创建和关闭连接
          • websocket不关注接收者的状态，http需要关注接收者的状态
          • 两个都是基于socket协议(socket基于TCP协议)
        • 相同点
          • 都是 TCP 协议；
            都使用 Request/Response 模型进行连接的建立；
            websocket 是基于 http 的，他们的兼容性都很好；
            在连接的建立过程中对错误的处理方式相同；
            都可以在网络中传输数据。
        • 不同点
          • websocket 是持久连接，http 是短连接；
            websocket 的协议是以 ws/wss 开头，http 对应的是 http/https；
            websocket 是有状态的，http 是无状态的；
            websocket 连接之后服务器和客户端可以双向发送数据，http 只能是客户端发起一次请求之后，服务器才能返回数据；
            websocket 是可以跨域的；
            websocket 连接建立之后，数据的传输使用帧来传递，不再需要Request消息。

      • 为什么用这个技术

        • 解决http长轮询造成的性能和资源浪费问题

      • WebSocket和Socket.io区别

        • socket.io是对websocket的再一次封装
          • 相比websocket，它提供了以下接口
          • 自动重连
          • 自动检测掉线
          • 广播
          • 如果
          • 解决因浏览器兼容导致的问题
            • 有些浏览器不兼容，所以默认还支持了长轮询的尝试
          • 前后端都要使用socket.io库

      • socket.io工作原理

        • 首先，socket.io通过一个http请求,并且该请求头中带有升级协议(Connection:Upgrade、Upgrade:websocket)等信息，告诉服务端准备建立连接，此时，后端返回的response数据
        • 当客户端收到响应之后，scoket.io会根据当前客户端环境是否支持Websocket。如果支持，则建立一个websocket连接，否则使用polling(xhr、jsonp)长轮询进行双向数据通信
        • 心跳参数配置
          • pingTimeout
            • Ping消息超时时间（毫秒），默认20秒，这个时间间隔内没有接收到心跳消息就会发送超时事件
            • 默认是20000，20秒
          • pingInterval
            • Ping消息间隔（毫秒），默认25秒。客户端向服务器发送一条心跳检测
            • 默认是25000，25秒
          • upgradeTimeout
            • 协议升级超时时间（毫秒），默认10秒。HTTP握手升级为ws协议超时时间
        • 心跳检测机制
          • 概述
            • 为了确保客户端与服务端的长连接正常，有时即使客户端连接中断，但是服务端未触发onclose事件，这就有可能导致无效连接占用。所以需要一种机制，确保两端的连接处于正常状态，心跳检测就是这种机制。客户端每隔一段时间，会向服务端发送心跳(数据包)，服务端也会返回response进行反馈连接正常。
          • socket.io与engine.io的一大区别在于，socket.io并不直接提供连接功能，而是在engine.io层提供。

    • 什么是跨域，如何解决

      • 跨域的概念
        • 浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域
      • 需要同源策略的原因
        • 设置同源策略的主要目的是为了安全,如果没有同源限制,在浏览器中的cookie等其他数据可以任意读取,不同域下的DOM任意操作,ajax任意请求其他网站的数据,包括隐私数据。
      • 哪些场景需要跨域
        • 需要本地联调测试环境，本地用的local，测试环境用的ip或者域名
        • 多个产品之间需要进行对接
      • 如何解决跨域问题
        • 请求头添加以下配置项 nginx和后端服务均可
          • Access-Control-Allow-Origin 允许哪些网站的跨域请求
          • Access-Control-Allow-Methods 允许的跨域ajax的请求方式
          • Access-Control-Allow-Headers 允许在请求中携带的头信息
        • jsonp请求
          • 事先定义一个用于获取跨域响应数据的回调函数，并通过没有同源策略限制的script标签发起一个请求（将回调函数的名称放到这个请求的query参数里），然后服务端返回这个回调函数的执行，并将需要响应的数据放到回调函数的参数里，前端的script标签请求到这个执行的回调函数后会立马执行，于是就拿到了执行的响应数据。
            • 优点
              • 它不像XMLHttpRequest对象实现的Ajax请求那样受到同源策略的限制
              • 它的兼容性更好，在更加古老的浏览器中都可以运行，不需要XMLHttpRequest或ActiveX的支持
              • 并且在请求完毕后可以通过调用callback的方式回传结果
            • 缺点
              • 它只支持GET请求而不支持 POST 等其它类型的 HTTP 请求
              • 它只支持跨域 HTTP 请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript 调用的问题

    • Nodejs的buffer原理和应用场景

      • JavaScript 起初为浏览器而设计，没有读取或操作二进制数据流的机制。Buffer类的引入，则让NodeJS拥有操作文件流或网络二进制流的能力
      • 也可以用来请求中的字符串转换
      • 对字符串进行其他类型的编码解码等

    • Nodejs的流的应用场景以及运行原理

      • 主要用于处理大文件，利用fs模块中的读取和写入流可以操作
      • 也可以用stream模块，但一般fs模块就满足了，因为fs内部就继承了stream模块

    • Nodejs await/async原理

      • async放在函数前 这个函数会返回promise
      • await放在函数前 则会等待这个函数执行完毕
      • 要了解await就要先理解generator函数
      • Generator 函数是 ES6 提供的一种异步编程解决方案，语法行为与传统函数完全不同
      • generator函数的特性有以下两点
        • 一是，function关键字与函数名之间有一个星号；
        • 二是，函数体内部使用yield表达式
      • generator是es6提供的函数同步执行的方法，使用*号标记函数为generator，内部使用yield暂停表达式，使用next进行放行

    • Nodejs多进程应用场景，如何做负载均衡和进程间通讯

      • master进程负责启动子进程，然后子进程工作
      • Worker 进程的数量一般根据服务器的 CPU 核数来定，这样就可以完美利用多核资源

    • 进程和线程的区别

      • 线程就可以当做是进程里面的执行的单元,同时它也是这个进程里面的一个能够调度的实体

    • CommonJs概念

      • 由于早期javascript缺少模块的概念，产生了commonjs规范
      • 规范特性
        • 通过require引入模块并应用在当前的上下文
        • 模块内部需要用exports来提供导出
      • 相关文章
        • https://blog.csdn.net/qq_42427109/article/details/88383123?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165633969016781432926292%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165633969016781432926292&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2blogfirst_rank_ecpm_v1~rank_v31_ecpm-1-88383123-null-null.nonecase&utm_term=CommonJs&spm=1018.2226.3001.4450

    • ExpressJs

      • 概念
        • node中上手最简单，内置功能多的框架
      • 特点
        • 内置了常用中间件，方便使用
          • express.static 提供静态资源，例如 HTML 文件、图像等
          • exporess.json 使用 JSON 有效负载解析传入请求
          • express.urlencoded 解析带有 URL 编码负载的传入请求
          • express.text(基于body-parser) 将请求参数解析为字符串
          • express.router 路由文件
        • 回调基于callback

    • KoaJs

      • 概念

        • 下一代的nodejs框架koa 是由 Express 原班人马打造的，致力于成为一个更小、更富有表现力、更健壮的 Web 框架。使用 koa 编写 web 应用，通过组合不同的 generator，可以免除重复繁琐的回调函数嵌套，并极大地提升错误处理的效率。koa 不在内核方法中绑定任何中间件，它仅仅提供了一个轻量优雅的函数库，使得编写 Web 应用变得得心应手

      • 特点

        • 洋葱卷模型

          • 概述

            • 先由内向外执行，再由外向内执行

          • 源码

            • function compose (middleware) {
              // …
              return function (context, next) {
              // last called middleware #
              let index = -1
              // 一开始的时候传入为 0，后续会递增
              return dispatch(0)
              function dispatch (i) {
              // 假如没有递增，则说明执行了多次
              if (i <= index) return Promise.reject(new Error(‘next() called multiple times’))
              index = i
              // 拿到当前的中间件
              let fn = middleware[i]
              if (i === middleware.length) fn = next
              // 当 fn 为空的时候，就会开始执行 next() 后面部分的代码
              if (!fn) return Promise.resolve()
              try {
              // 执行中间件，留意这两个参数，都是中间件的传参，第一个是上下文，第二个是 next 函数
              // 也就是说执行 next 的时候也就是调用 dispatch 函数的时候
              return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
              } catch (err) {
              return Promise.reject(err)
              }
              }
              }
              }

          • 为什么需要

            • 因为express的next在异步情况下的顺序不能保持一致，所以需要用await保证顺序，就形成了洋葱卷模型

        • 没有内置任何中间件，比express更轻量

        • 基于es6，默认await/async

        • 有一个统一上下文遍历ctx，方便业务处理，不再需要层层向下传递。

        • 比koa1中的generator更简单的异步，async/await

    • EggJs

      • 特点
        • 支持ts
        • 基于koa，内置洋葱卷模型
        • 约定大于配置
          • controller
          • service
          • router
        • 内置多进程模型
          • node内置了一个模块cluster 多进程
        • 插件机制
          • 比起传统的util文件，插件更适合拓展和维护，一个插件只做一件事。
            • 而且插件的约定也是按照egg的目录结构而来的，一个迷你的egg应用
              • 去掉了router和controller
        • 渐进式开发
          • 前期，最初团队抽象出了一些公共的方法 .util.ts
          • 中期，这个通用方法还不是很完善，直接用插件不好维护，但可以先写成插件的形式
          • 通过config/plugin.js来挂载
          • 后期，经过一段时间考验后，该插件已经完善且稳定，所以可以进行单独的抽离
            • 就是单独抽离出一个npm包，不过包结构要按照egg的格式来
          • 终期，已经积累了很多可以复用的插件，并且在多个团队和项目中可以复用，所以此时可以沉淀到框架中
            • 将可复用的插件单独抽象成一个框架给多个团队和项目使用
      • 应用场景

    • NestJs

      • 特点
        • 基于express
          • 因为为了设计一个开箱即用的框架，而express内置了很多模块，所以基于express
        • 完全支持typescript
          • 类型约束
          • 编译期间有类型检查，能预知错误
        • 守卫
        • 模块概念
          • 通过模块将每个应用功能进行解耦。相比express等框架，没有模块约束，代码相比nestjs，维护难度更高
        • 异常过滤器
          • 全局的异常过滤器，对全局的异常做定制化处理
        • 管道
          • 对请求参数进行转换或者验证
        • 守卫
          • 用户权限校验
          • 用户角色校验
          • 用户鉴权等
        • 更符合现代化编程的中间件模式
          • 相比较传统的express,koa等node框架，通过和路由编码的方式来进行绑定
          • 而nestjs是基于模块进行中间件配置的形式来绑定中间件
        • 拦截器，比如用于请求前后的日志链路追踪，或者请求和返回参数的定制化
        • 官方文档非常完善，每一个模块都提供了标准的示例
        • AOP(Aspect Oriented Programming)，面向切面编程
        • IOC
          • 控制反转。比如传统的开发模式是每次都要重新实例化一个对象。但是在nestjs的IOC模式中，只需要将对象注入到构造函数声明中就行
        • 生命周期钩子函数
          • OnModuleInit
            • 初始化主模块依赖处理后调用一次
          • OnApplicationBootstrap
            • 在应用程序完全启动并监听连接后调用一次
          • OnModuleDestroy
            • 收到终止信号(例如SIGTERM)后调用
          • beforeApplicationShutdown
            • 在onModuleDestroy()完成(Promise被resolved或者rejected)；一旦完成，将关闭所有连接(调用app.close() 方法).
          • OnApplicationShutdown
            • 连接关闭处理时调用(app.close())
        • OOP面向对象思想(暂时不讲，因为这个我讲不清楚)
          • 面向对象编程，通过对象内的各种属性和方法来完成编程。容易维护和扩展。
            • 封装 将通用的方法抽象到一个util内
            • 继承 扩展类的功能
              • super关键字用于访问和调用对象父类上的函数。可以调用父类的构造函数，也可以调用父类的普通函数
            • 多态
              • 同一操作作用于不同的对象上面，可以产生不同的解释和不同的执行结果
              • 比如两个方法都有send函数，要在一个函数内进行调用，就要根据不同的方法调用不同的send函数。那么利用多态，直接将类初始化，函数内部只需要执行send方法而不需要关注上层是谁了
        • FP函数式编程(暂时不讲，因为这个我讲不清楚)
          • 函数式编程是一种强调以函数使用为主的软件开发风格 ，也是一种范式
            • 用函数来编程，更好的模块化
            • 函数可以复用
            • 低耦合
          • 伪代码
            • 函数作为参数执行
            • 函数作为返回值执行
      • 应用场景
        • 中大型企业框架
          • ts支持，减少团队代码后期维护成本
          • 更现代的开发模式
      • 自定义注解

    • V8虚拟机

      • 什么是V8虚拟机？说说你对虚拟机的理解

        • v8引擎是谷歌浏览器用的虚拟机。用于解释和执行javascript代码
        • 说到底，JavaScript引擎就是用来执行JavaScript代码用的，为其提供了一个运行时环境，提供解释/编译、自动内存管理（GC）、对象模型、核心库等功能。

      • 为什么v8引擎的性能强劲

        • 相比较其他的javascript引擎，v8的性能更高
          • 热点代码缓存
          • 增量式的垃圾回收机制
          • 隐藏类，对相同属性的对象通过隐藏类共享，后续访问只需要根据设定的对象偏移量操作即可。如果位置发生变化，则重新生成隐藏类
          • 对隐藏类做缓存，因为获取隐藏类的地址依然有提升空间，所以就对隐藏类进行缓存，查找的时候先判断是否是相同的隐藏类，是的话直接使用该缓存结果

      • 垃圾回收机制

        • 64系统为1.4g
        • 32系统0.7g
        • 也可以通过启动参数来调整
        • 32和64区别，内存大小不同，兼容性不同
        • 新生代：存活周期短
        • 老年代：存货周期长
        • v8默认采用的是分代式垃圾回收机制
          • 原因
        • 其他垃圾回收机制
          • 标记清除
            • 标记清楚在标记阶段遍历堆中的所有对象，并标记活着的对象，在随后的清除阶段中，只清除没有被标记的对象。这样设计是因为存活的在对象占用比例小，所以才会更高效
            • 优点
              • 比较通用和简单的算法
            • 缺点
              • 内存不连续
          • 复制清除
            • 将堆内存一分为二，from和to这两个空间，分配对象的时候，会先检查from空间是否还有存活对象，有的话就复制到to空间中，那些非存活对象会被释放。完成复制后，to和from的空间再进行互换，下次分配的时候继续执行刚才的步骤。当一个对象检查多次依然存活，那么它就会晋升到老年代中。判断内存地址来区分是否被检查过
            • 优点
              • 解决内存碎片问题
              • 回收效率高
            • 缺点
              • 将内存缩小为原来的一半，代价高
              • 随着存活对象的比例提升，复制的成本会逐渐提高
          • 标记整理
            • 解决内存碎片化和复制清除内存利用率低的问题
            • 让所有存活的对象移动到一段，然后直接清理掉另一端的内存。这样就避免了内存碎片和内存利用率低的问题
            • 当存活对象过多时，v8采用增量式迁移，每次移动一小部分进行处理，提高处理效率
          • 分代式垃圾回收
            • V8 中会把堆分为新生代和老生代两个区域，新生代中存放的是生存时间短的对象，老生代中存放的生存时间久的对象
            • 新生代使用复制清楚回收算法
            • 老年代使用标记整理算法(因为标记清除会留下不连续的内存碎片)，并且v8对老年代的回收做了优化，使用增量标记提高了回收效率

      • 内存结构

        • 为什么需要堆栈区

          • 程序执行过程中，需要记录上下文，那么就要把数据记录到内存中合适的地方，并做好分配和初始化等工作。

        • 堆区

          • 堆区用来存储对象，由栈区的对象引用地址来进行调用
            • 这样设计的使对象实体的 运用 更加的灵活、隔离、模块化
              • 灵活：相当于业务数据存放到一个空间足够的池子，我想实现怎样的逻辑，需要怎么的业务数据，通过引用的方式直接获取想要的业务数据。
              • 隔离：业务数据和业务逻辑存放在不同的空间，互不干扰。
              • **模块化：**通过业务数据和业务逻辑的组合，形成具有特定功能的模块。
          • 对象内存的管理由垃圾回收机制来处理

        • 堆栈区(栈区)

          • 栈区用来记录程序的执行顺序，所以只存储了基本变量类型和对象的引用地址
          • 函数调用栈，先进后出
            • 原因
              • 要是在生活中我们也是按照栈的规则来排顺序，这个世界岂不是乱了套了，试想你去银行排队取钱，明明你是第一个去，却等到晚上晚上银行人员快下班了你才最后处理完业务，恐怕你早就跟人干起来了
              • 举个例子吧：我创建一个函数A,在函数A中调用了另一个函数B！那么堆栈中应该是先把A的压栈，再把B压栈！而只有当B这个函数执行完了才会继续执行A后面的代码，所以必须先把B弹栈！这就是后进先出！不然的话程序岂不是乱套了！
          • 主要作用
            • 保存函数的局部变量
            • 向被调用函数传递参数
            • 返回函数的返回值
            • 保存函数的返回地址。返回地址是指从被调用函数返回后调用者应该继续执行的指令地址
          • 工作流程
            • 每个函数在执行过程中都需要使用一块栈内存用来保存上述这些值，我们称这块栈内存为某函数的栈帧(stack frame)。当发生函数调用时，因为调用者还没有执行完，其栈内存中保存的数据还有用，所以被调用函数不能覆盖调用者的栈帧，只能把被调用函数的栈帧“push”到栈上，等被调函数执行完成后再把其栈帧从栈上“pop”出去，这样，栈的大小就会随函数调用层级的增加而生长，随函数的返回而缩小

        • 栈区和堆区的区别示例

          • 以图书馆作为例子，图书馆就是系统 全部 的内存空间，里面的任何东西都是基于图书馆来分配空间。

            每一本书就是一个 对象实体，他们存放在书架上，书架就是 堆。假设图书馆有各种各样的书架，可以满足所有大小的书本，即使书的大小各异，管理员只需要找到合适的位置存放。

            为了方便存取书本，图书馆管理员会为每一本书设计一个编号，并记录在一个表格上，编号就是对象实体的 内存地址。

            那什么是 对象引用 呢，答案就是读者的每一条借书记录，每一次的借书行为可以理解为对书本的一次引用。借书的记录都会登记在一个表格上，这个表格就是 栈。借书记录仅仅是一段文字，所需要的空间很小，而且大小基本固定，通常情况下用一个本子、一个电子表格、一个数据库，做一个表格就可以满足需求。

            书本、编号、借书记录三者的结合，相辅相成，让整个图书馆的对图书的管理更加的灵活、方便和规范。

            其实，代码世界中很多的设计原理都是源于我们的生活，又高于生活。设计模式就在我们身边，无处不在，善于观察生活中的事物，从生活中领悟设计模式吧

    • 都用过哪些NodeJs模块

      • 内置模块
        • cluster
          • 操作多进程
        • process
          • 处理环境变量，监听全局未捕获异常，控制进程退出，获取机器负载信息等
        • http
          • 给其他服务发起http请求
        • fs
          • 操作文件的增删改查
        • buffer
          • buffer是一个二进制数据流，操作文件，数据流转换，比如base64编码解码等
        • stream
          • 流，处理大文件，避免大文件占用内存过高的问题
      • 第三方模块
        • lodash
          • 判断数值是否为空 isEmpty
            • 对空字符串 null undefind 0 空数组的判断都很好用
          • 数组去重 uniq
            • 用js的话要么自己抽象一个方法，要么用set，lodash自己有封装好的
          • 对数字的高级操作，交集(intersection)，补集(xor)，过滤(difference)，分组(group)等
          • 等等等
        • bluebird/async 异步流程控制
          • 异步串行
          • 异步并行
          • 同时串并
          • 等等等
        • moment/dayjs
          • 日期处理
            • 时间戳转日期
            • 日期转时间戳
            • 获取某几个月的时间
            • 计算时间差
            • 等等等
        • node-xlsx
          • xlsx文件的导入导出解析
        • ioredis
          • 连接redis驱动，操作redis
        • mongoose
          • 连接mongodb驱动，操作Mongodb
        • log4js
          • 服务日志记录和输出
        • qiniu
          • 对接第三方云存储平台，处理文件的增删改查

    • 看过哪些模块的源码

      • lodash

        • 出于好奇，看了isEmpty源码

          1. 先判断是否为空

          2. 再判断是否像数组

            1. 判断是否拥有length属性
            2. 判断是否是函数
              1. 用typeof判断 object和function 此时都会被判定为对象

          3. 接下在像数组的情况下继续进行或的判断

            1. 判断是否是数组，使用Object.prototype.toString.call()判断，如果是’[object Array]'这个字符串，就是数组
            2. 不是数组，再判断是否是字符串
              • 用typeof判断是否是字符串
            3. 满足任意一项，则返回length长度，0对于js是false，大于0则证明是有值的

          4. 上面条件都不满足，则执行nativeKeys方法

            1. 先用Object强制转换，对于undefind，null等无效类型，默认返回空数组，其他的则转换为对应的string，number，json等类型
            2. 然后再用Object.keys获取变量的key列表，返回length
            3. 0是false，大于0的是true

          5. Object.prototype.toString.call()原理

            • 和instanceof相同，但使用的是就近原型链，而不会去向上寻找(比如找到了顶级Object)。所以传入一个数组时，就获取的是数组的原型链__proto__是Array

          6. 和instanceof，type of区别

            • typeof只能判断基本类型，引用类型都是object

            • instanceof判断构造函数的 prototype 属性是否出现在某个实例对象的原型链上

              • function instance_of(L, R) {//L 表示左表达式，R 表示右表达式 

 var O = R.prototype;   // 取 R 的显示原型 

 L = L.__proto__;  // 取 L 的隐式原型

 while (true) {    

     if (L === null)      

          return false;   

     if (O === L)  // 当 O 显式原型 严格等于  L隐式原型 时，返回true

          return true;   

     L = L.__proto__;  

 }

}

                • 1
                • 2
                • 3
                • 4
                • 5
                • 6
                • 7
                • 8
                • 9
                • 10
                • 11
                • 12
                • 13
                • 14
                • 15
                • 16
                • 17
                • 18
                • 19
                • 20
                • 21

              • instanceof 的工作原理就是将 s 每一层的 proto 与 F.prototype 做比较
                找到相同返回 true
                至最后一层仍没有找到返回 false

              • 比如判断 一个字段的类型是否是数组

                • 会先拿这个数组的原型链__proto__原型链对比数组的原型prototype
                • 如果一致则返回true，否则继续对比
                • 下一层的原型链就是Object的了，如果还是不一样就继续对比
                • 一直到为null，则返回false

              • 但instanceof有个缺点，不能用来判断是否为Object，因为最终都指向了Object。

      • koa-bodyparser

        • 平台服务总是报很多json类的转换异常，看不到具体的日志，因为没有执行到中间件就被捕获了。
        • 后来发现只要post请求的body参数不是json类型，该插件就会抛错，然后被全局异常捕获。然后单独把这个包拿出来，只做一个打印，然后由拦截器中间件来处理这个错误

    • 什么是原型和原型链

      • 原型
      • 每个对象都有prototype属性
      • 原型链
        • 对象的追踪过程，函数->对象->null

    • 什么是闭包

      • 函数内部保存的变量不随这个函数调用结束而被销毁就是闭包

      • 闭包的应用场景

        • 操作函数内部变量
        • 将变量维护在内存中不释放

      • 闭包的例子

        • const fun = ()=>{
    let num = 0;
    return (v)=>{
        return num += v;
    };
}

const data5 = fun(); //初始化函数fun并得到函数的匿名函数返回值(这里只初始化了一次)
console.log(data5(1)); //1    给匿名函数传参并得到累加的结果
console.log(data5(1)); //2 	由于fun函数未重新初始化，且此时num的值为1，所以累加得2
console.log(data5(1)); //3	与上面雷同

          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11

    • 什么是深拷贝和浅拷贝

      • 比如基本类型是深拷贝，拷贝的是值
      • 对象是浅拷贝，拷贝的是引用地址
      • 需要重新分配内存地址才能解决浅拷贝问题

    • JavaScript作用域

      • 分为全局和局部作用域

        • 每次代码执行前会先进行"预编译"

        • 比如有下面一段代码

          • var a = 1;
function foo(){
  var b = 2;
  function bar(){
   var c = 3;
   console.log(c + b + a);
  }
  bar();
}
foo();

            • 1
            • 2
            • 3
            • 4
            • 5
            • 6
            • 7
            • 8
            • 9
            • 10

        • 在执行之前会先预编译成一下的预编译代码

          • 生成全局作用域 global object 简称go

            • GO{
 a: undefined,
 foo: function foo{...}
}

              • 1
              • 2
              • 3
              • 4

          • 执行到foo的时候 生成foo的函数局部作用域 active object 简称ao

            • AO1{
 b: undefined,
 bar: function bar(){...}
}

              • 1
              • 2
              • 3
              • 4

          • 执行foo内部函数bar的时候，生成bar的函数局部作用域

            • AO2{
 c: undefined
}

              • 1
              • 2
              • 3

          • 然后先执行ao2，给变量c复制，在当前局部作用域可以找到，然后执行b，发现当前局部作用域没有，于是就去外层的作用域查找，找到了，执行。然后执行c，发现发现当前局部作用域没有，于是就去外层的作用域查找，发现也没有，一直找到全局作用域，找到了执行，没找到就当作undefind处理

            • 其中 这个查找的过程就是作用域链，有点类似js的原型链

    • JavaScript继承

      • es5

        • 原型继承

          • 使用prototype重新赋值，然后再扩展新对象的prototype

          • 示例

            • // 继承
B.prototype=new A()
// 扩展
B.prototype.splice = ()=>{};

              • 1
              • 2
              • 3
              • 4

        • call和apply

          • 用来改变this的指向，将一个对象作为另一个对象的实现

          • 示例

            • function myfunc1(){
    this.name = 'Lee';
    this.myTxt = function(txt) {
        console.log( 'i am',txt );
    }
}
 
function myfunc2(){
    myfunc1.call(this);
}
 
var myfunc3 = new myfunc2();
myfunc3.myTxt('Geing'); // i am Geing
console.log (myfunc3.name);	// Lee

              • 1
              • 2
              • 3
              • 4
              • 5
              • 6
              • 7
              • 8
              • 9
              • 10
              • 11
              • 12
              • 13
              • 14

            • 其中myfun2中没有任何实现，只是将myfun1替换了myfun2的实现

          • 区别

            • call的第二个参数可以是任意类型，而apply必须是数组

      • es6

        • 使用class类，通过extends关键字实现继承

          • 类只是一个语法糖，背后其实还是构造函数来实现的

          • 原理

            • 通过_inherits函数实现

            • 先判断当前对象是否是函数，如果不是函数则报错类型异常

            • 然后就是继承父类的原型和原型链，下面是示例

              • // 继承原型链
B.prototype._proto_ = A.prototype

// 

                • 1
                • 2
                • 3
                • 4

        • super关键字用来做什么

          • 用于访问和调用对象父类上的函数

        • super为什么在构造函数中必须写在前面，否则就不能用this？

          • 比如下面的代码

            • class Person {
 constructor(name) {
  this.name = name;
 }
}
class PolitePerson extends Person {
 constructor(name) {
  this.greetColleagues(); //这行代码是无效的，后面告诉你为什么
  super(name);
 }
 greetColleagues() {
  alert('Good morning folks!');
 }
}

              • 1
              • 2
              • 3
              • 4
              • 5
              • 6
              • 7
              • 8
              • 9
              • 10
              • 11
              • 12
              • 13
              • 14

            • 如果允许在调用super之前使用this的话。一段时间后，我们可能会修改greetColleagues，并在提示消息中添加Person的name：

            • greetColleagues() {
 alert('Good morning folks!');
 alert('My name is ' + this.name + ', nice to meet you!');
}

              • 1
              • 2
              • 3
              • 4

            • 但是我们忘记了super()在设置this.name之前先调用了this.greetColleagues()。 所以此时this.name还没有定义，就会出现出现undefind

            • 所以javascript强制在this之前调用super，先完成父类构造函数的构建，再执行子类

          • super的实现也是使用call方法

    • bind,call和apply应用场景和区别

      • 都可以用来改变this指向
      • call的第二个参数是任意类型
      • apply的第二个参数是数组
      • 应用场景
        • call和apply多用来实现继承
        • bind多用来改变this指向

    • 2个等于号和3个等于号区别

      • 2个会进行类型转换 比如判断1和’1’ 他们是相等的
      • 3个不会进行类型转换，所有是严格判断

    • 线上cpu高的问题

      • 定时器
        • 有一天突然线上服务的cpu不间断的飙升到三四百
        • 排查最近的提交代码，发现有一个定时器，每30s通过pbx列表查询数据库
        • 后来客户已经停用，就把代码注释了
        • 后续解决方案可以采用懒汉式，客户请求的时候再更新即可
      • redis
        • 有一天上午十点多redis告警cpu占用率高，于是就排查最近代码，发现有人用了keys*来查询所有
          • 当时立马改代码升级优化了一些
          • 后面还发现有一些大key，存储了一个账户的所有座席配置，频繁获取也会导致redis cpu飙升

    • 线上内存高的问题

      • 内存泄漏
        • 有一天下午，客户报问题，服务突然不可用了
          • 发现node接口服务自动重启了
          • 查看最近代码发现是因为有人用了global对象，全局缓存。用来给数据库降低压力的，但是有一个用户监控类的缓存没有清楚，导致内存持续升高
          • 后来改成放在redis中后解决
      • 流出宽带高
        • 数据库查询没有限制分页，导致查询量过高

    • 排查内存泄漏的方案是什么

      • 看最近代码是否有以下问题
        • 全局对象
        • 闭包
        • 定时器用过后没有清除
      • 或者使用easy-monitor可视化工具查看某段时间的内存使用情况

    • 数组和链表数据结构和区别

      • 数组 有顺序，大小固定，查询效率高
      • 链表 无顺序，没有固定大小，插入删除效率高

    • 什么是缓冲区

      • nodejs buffer是一个二进制数据流，在操作文件的时候会用到。处理数据流

    • Nodejs最近大版本都更新了什么

      • 官网维护的更新日志

      • https://github.com/nodejs/node/tree/main/doc/changelogs

      • node 10

        • 支持http2
        • 增加了n-api 支持
        • 修复了一些漏洞

      • node 12

        • 提供了打印堆快照的工具
        • http换成lhttp
        • Worker Threads 工作线程

      • node 14

        • 支持es module，使用import导入模块
        • 升级v8版本
        • 可选链，空值合并操作符
        • 异步本地存储。async 调用栈追踪，由此的来了trace，链路追踪id的插件

      • node 16

        • 更新v8版本
        • 返回promise的定时器
        • Node.js针对不同的平台提供预构建的二进制文件，给苹果芯片提供了新的二进制版本
        • 其他相关漏洞修复

      • node 18

        • 内置fetch，基于undiciundici
        • 内置test单元测试模块
        • 更新v8版本
        • 其他修复等

    • js如何判断数据类型

      • typeof，instanceof，Object.prototype.toString.call

      • Object.prototype.toString.call()原理

        • 和instanceof相同，但使用的是就近原型链，而不会去向上寻找(比如找到了顶级Object)。所以传入一个数组时，就获取的是数组的原型链__proto__是Array

      • 和instanceof，type of区别

        • typeof只能判断基本类型，引用类型都是object

        • instanceof判断构造函数的 prototype 属性是否出现在某个实例对象的原型链上

          • function instance_of(L, R) {//L 表示左表达式，R 表示右表达式 

var O = R.prototype;   // 取 R 的显示原型 

L = L.__proto__;  // 取 L 的隐式原型

while (true) {    

  if (L === null)      

       return false;   

  if (O === L)  // 当 O 显式原型 严格等于  L隐式原型 时，返回true

       return true;   

  L = L.__proto__;  

}

}

            • 1
            • 2
            • 3
            • 4
            • 5
            • 6
            • 7
            • 8
            • 9
            • 10
            • 11
            • 12
            • 13
            • 14
            • 15
            • 16
            • 17
            • 18
            • 19
            • 20
            • 21

          • instanceof 的工作原理就是将 s 每一层的 proto 与 F.prototype 做比较
            找到相同返回 true
            至最后一层仍没有找到返回 false

          • 比如判断 一个字段的类型是否是数组

            • 会先拿这个数组的原型链__proto__原型链对比数组的原型prototype
            • 如果一致则返回true，否则继续对比
            • 下一层的原型链就是Object的了，如果还是不一样就继续对比
            • 一直到为null，则返回false

          • 但instanceof有个缺点，不能用来判断是否为Object，因为最终都指向了Object。

    • node如何接受客户端上传的文件

      • 使用node的multer工具包
      • 接受前端的form表单文件
      • 然后使用node的stream流写入文件

    • 箭头函数

      • 缩短函数代码
      • 解决this指向问题

    • 单元测试

      • mocha框架
      • 提高项目质量
      • 减少测试成本
      • 精准定位bug

    TypeScript

    • 特点

      • 能够使用最新的esma规范
      • js的超集
      • 静态类型化编程
      • 提供了注解，更现代化的开发模式
      • 编译期间的类型检查

    • 应用场景

      • 中大型企业的最佳选择
      • 使用最新的ECMA规范
      • 更健壮的企业级服务

    • 缺点

      • 增加了类型，提高了开发工作量
      • 有一些库目前还不支持ts，比如缺少.d.ts文件
      • 需要学习

    • 目前用的什么版本，有什么特性

      • 目前用的最新的4.6版本

        • 特性

          • super关键字允许写在this后面，以前只能写在前面

          • 枚举类型支持解构

            • type Action =
    | { kind: "NumberContents", payload: number }
    | { kind: "StringContents", payload: string };
 
 // 以前结构会报错
 const { kind, payload } = action;
    if (kind === "NumberContents") {
        let num = payload * 2
        // ...
    }

              • 1
              • 2
              • 3
              • 4
              • 5
              • 6
              • 7
              • 8
              • 9
              • 10

          • 更智能的jsdoc，通过注释也可以看到类型

          • 其他的问题修复等

    • 经常用哪些类型接口

      • type 简单类型 字符串数字等
      • interface 复杂类型 对象等
      • Record 根据输入的索引生成新类型
      • Pick 取旧类型中的部分索引类型为新类型
      • Omit 提出原类型中的部分属性，生成新的类型
      • Exclude 根据索引移除类型中的key得到新的索引类型
      • ReturnType 获取函数返回值类型

    数据库

    Mongodb

    • 关系型和非关系型区别

      • sql语句不同，mongo的是json类型，而mysql是一个字符串语句，中间用空格间隔
      • 关系型支持连表，非关系型不支持
      • 非关系型数据结构灵活，比如mongo，都是key，value类型
      • 非关系型比关系型更灵活，比如mongo可以随时的动态增删字段

    • Mongodb应用场景

      • 操作简单，开发成本低。因为数据结构都是json，尤其和javascript很契合
      • 扩展性强。nosql型数据库不要求强一致的字段结构，可以随便的增删字段
      • 高性能和吞吐量。传统型数据库都有事务，导致速度没有mongo快
      • mongodb分片集群。提高集群性能和高可用性

    • Mongo优缺点

      • 优点
        • 弱一致性，不要求强一致数据结构
        • 高扩展性，任意扩展字段和数据库集群节点
        • mongodb是商业化的，发展稳定
        • 高性能和吞吐量
      • 缺点
        • 表关联查询支持弱
        • 不支持事务
        • 因为弱类型，所以可能出现维护成本高的问题
        • 占用空间大，因为都是bson结构的key，value形式

    • Mongo集群是否了解

      • 什么是副本集
        • 概念
          • mongodb的高可用方案
        • 应用场景
          • 数据备份
          • 数据恢复
          • 读写分离
        • 副本集最小可用方案
          • 一主两从
        • 都有哪些独写策略
          • primary 默认 所有的读操作都从当前副本集主节点
          • primaryPreferred 从主节点读取数据，但是如果主节点不可用了，会从从节点读取
          • secondary 所有读操作都从副本集的从节点读取
          • secondaryPreferred 从从节点进行读操作，但是如果从节点都不可用了，从主节点读取
          • nearest 从副本集中延迟最低的成员读取，不考虑成员的类型
      • 什么是分片
        • 概念
          • 把一张表中的数据分割到不同的服务器上进行保存。一般用在特别大量的数据库集群中，比如一张表的数据几百个g这种，通过分片到多台服务器上。比如传统的副本集，所有的数据都在一个服务器上，分片通过分布式存储来提高查询性能。
        • 组成
          • mongos路由，用于将请求转发给不同的分片，将多个分片的结果进行整合
          • config-server，保存集群的元数据，比如分片的路由规则，服务器配置等等
          • 分片，存储数据库数据，一个分片默认是64m。分片由分片键和分片算法组成
            • 分片键
            • 分片算法
              • 区间分片，基于某个范围进行查找
              • 哈希分片，根据hash值进行范围查找
            • 当一个分片的大小超过限制阈值时，会自动拆分成更小的片进行存储
      • 分片和副本集的区别
        • 副本集
          • 硬件和维护成本低
          • 发生故障时，备份直接可以直接恢复服务
        • 分片
          • 维护成本高，因为将数据分不到了很多
          • 对数据流大的应用来说能显著提高查询性能
      • 其他
        • 副本集默认每2秒检测心跳，感知其他节点是否宕机，角色发生转换等
        • 副本集依赖oplog，mongo的写操作日志来完成数据的同步的
        • 副本集的主从同步机制核心是，主节点在完成写操作后同步到oplog日志中，然后从节点主动拉取oplog日志中的日志

    • 都有哪些数据类型

      • 和mysql类似，底层存储的时候会有以下类型
        • string
        • array
        • boolean
        • date
        • double
        • int
        • object
        • 等等

    • ObjectId如何组成

      • 一个24位数的字符串
        • 前八位是时间戳
        • 后六位是主机标识
        • 后四位是进程id
        • 后六位是自增的随机数

    • 什么是索引

      • 索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。就好比书的目录，有了目录才能更精确的查找，否则只能进行全表搜索

    • 常用的索引类型

      • 唯一索引
        • 单一索引
      • 复合索引
        • 组合索引

    • 索引的优缺点

      • 优点
        • 提升数据查询性能
      • 缺点
        • 占用额外的空间
        • 维护索引成本

    • mongodb索引数据结构和原理

      • mongodb使用的是基于二叉树的B树
        • 因为在大多数场景中，都是读多写少。所以相比较传统的B+树(只有叶节点存放数据，其余节点用来索引)，mongodb的设计是为了更高的查询性能而来。B树的每个索引节点都会有Data域。所有对于B树来说，只要找到对应的索引节点，就可以访问，所以对于非范围类查询性能很高。
      • 叶子节点：没有孩子节点的节点叫作叶子节点
      • 非叶子节点：跟叶子节点相反，有孩子节点的节点

    • Mongo查询计划

      • db.find().explain
      • 都看哪些指标？
        • stage 直接看出是否使用索引
          • FETCH 根据索引位置查找
          • IXSCAN 索引扫描
          • COLLSCAN 全表扫描
        • nReturned 返回了多少
        • totalKeysExamined 索引扫描了多少
        • totalDocsExamined 文档扫描了多少
        • executionTimeMillis 整体执行时长
      • 一般看着这几个指标就能看出是否用到了索引，或者索引是否设计合理

    • 如何查找慢查询，找到之后如何优化

      • 开启mongodb慢查询检测

        • 有三个等级
        • 不开启
        • 对某个时间段的进行检测
        • 记录所有
      • --开启慢查询，且记录超过10ms的语句
db.setProfilingLevel( 1 , 10 );
-- 获取当前设置的级别
db.getProfilingLevel()
--设置profile级别
db.setProfilingLevel(2)

        • 1
        • 2
        • 3
        • 4
        • 5
        • 6
      • // 根据条件查询慢查询
db.system.profile.find( { millis : { $gt : 5 } } )

        • 1
        • 2

    • 数据库语句执行过程

    • 数据库cpu高的问题

      • 瞬间有很多大量的慢查询，一直没有处理完，导致cpu飙升
        • 是因为内部产品交互通过http，但是没有控制频率，导致大量请求瞬间打到服务和数据库
        • 当时解决的方案是
          • 通过日志分析平台，统计最近半小时的请求和频次
          • 查看代码用到该查询条件的代码
        • 找到了一个频次异常的接口
        • 找到了对应的代码
        • 锁定到是内部运营平台调用释放客服号码的接口，这个接口是释放一个租户内的所有号码，少则几十个，多则几百上千。运营平台来调用的时候没有控制频率，导致瞬间几千个请求打过来。数据库的cpu就飙升了
        • 然后联系到使用运营平台的人，暂停这个操作(因为系统有记录操作人)。暂停后，数据库负载恢复，后续我们的接口增加频次限制，运营平台也增加调用接口的频次控制
      • 内部报表统计接口查询报表，因为报表的数据流大，查询时间有时候会在几秒，统计的时候没有注意频次，cpu也会飙升

    • 数据库内存高的问题

      • 某一天数据库的内存频繁告警超过80%，于是先查看数据库慢查询(怀疑是查询的结果集过大)，然后锁定到了几张表。
      • 查找几个涉及到这个表查询的业务，导出，对外接口
      • 然后就分析导出和对外接口的调用频次
      • 发现有个请求，指定的查询结果数是1000，平均每秒1-2次请求
      • 然后我们内部有一个限流器
        • 根据ip限制它一分钟只能调用20次
        • 查询结果，一次最多100个
      • 然后数据库的内存占用量就恢复了

    • 数据库流量高的问题

      • 和上面的问题一样

    • Mongo底层存储结构

      • mongo使用的是WiredTiger存储引擎，该引擎使用B树作为数据结构
      • B-树是一种自平衡的搜索，和二叉树不同的是，二叉树最多两个子节点，而B树是每个节点的关键字=节点数-1
      • 每个树节点都存有数据，所以只要找到索引就可以进行访问，更适合查询

    Redis

    • 和其他传统数据库区别

      • redis的sql语句和传统的不同
      • redis基于省去了操作磁盘的时间，查询效率高
      • redis多用于热点数据查询，不像传统数据库用来存储大量数据

    • Redis应用场景都有哪些

      • 热点数据缓存
      • 缓存数据共享
      • 分布式锁 nx
      • 计数器 incr

    • 为什么Redis快

      • 基于内存，省去了操作磁盘的时间
      • 单线程，减去了多线程的上下文切换和锁的问题
      • 多路复用，类似nodejs事件循环，所有的读写都放入事件循环中，内部用多线程来执行

    • 常用的数据结构有哪些

      • set 简单字符串存储
      • exists 是否存在指定key
      • del 删除key
      • mset 存储多个键值对
      • incr 计数器
      • expire 过期时间

    • 缓存击穿

      • 概念
        • 高并发流量，访问的这个数据是热点数据，请求的数据在 DB 中存在，但是 Redis 存的那一份已经过期，后端需要从 DB 加载数据并写到 Redis
        • 但由于高并发，可能会把数据库击垮，导致服务不可用
      • 解决方案
        1. 热点key不设置过期时间
        2. 给热点key的过期时间设置一个随机值，避免同一时间过期
          • 给一个1-10分钟的过期时间
      • 问题场景
        • 比如用户信息

    • 缓存穿透

      • 概念
        • 意味着有特殊请求在查询一个不存在的数据，即数据不存在 Redis 也不存在于数据库。导致每次请求都会穿透到数据库，缓存成了摆设，对数据库产生很大压力从而影响正常服务
      • 解决方案
        • 缓存空值：当请求的数据不存在 Redis 也不存在数据库的时候，设置一个缺省值（比如：None）。当后续再次进行查询则直接返回空值或者缺省值
      • 问题场景
        • 在缓存击穿的基础上，数据库也查不到，也没有一个默认值，导致一直查询

    • 缓存雪崩

      • 概念
        • 大量的请求无法在 Redis 缓存系统中处理，请求全部打到数据库，导致数据库压力激增
      • 解决方案
        • 过期时间添加随机值
        • http接口限流
        • 服务熔断降级
      • 问题场景
        • 大量热点数据同时过期，导致大量请求需要查询数据库并写到缓存；
        • Redis 故障宕机，缓存系统异常

    • 过期策略

      • 定期策略
        • 当Redis运行到设定的时期时会在具有过期设置的key中随机测试一些key，并且把其中过期的key从内存中删除
        • 具体来说，Redis 每秒执行 10 次：
          1. 从具有关联过期的key集中测试 20 个随机key
          2. 删除所有发现过期的key
          3. 如果超过 25% 的key已过期，则从步骤 1 重新开始
      • 惰性策略
        • 当某个客户端试图访问key时，发现该key已超时会把此key从内存中删除

    • 内存淘汰策略

      • noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错
      • allkeys-lru：在主键空间中，优先移除最近未使用的key
      • volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key
      • allkeys-random：在主键空间中，随机移除某个key
      • volatile-random：在设置了过期时间的键空间中，随机移除某个key
      • volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除
      • 配置方法
        • 编辑redis.conf，更改maxmemory-policy配置
      • redis默认是noeviction

    • 持久化机制，优缺点

      • RDB

        • 概念

          • 在指定时间将当前时刻内存中的数据生成一个快照文件（.rdb文件，默认为dump.rdb），并将这个快照文件保存到磁盘上。这样，即使redis宕机了，下次重启时也可以通过读取这个快照文件来恢复数据

        • 备份策略

          • save 3600 1 -> 3600秒内有1个key被修改，则触发RDB

save 300 100 -> 300秒内有100个key被修改，则触发RDB

save 60 10000 -> 60秒内有10000个key被修改，则触发RDB

            • 1
            • 2
            • 3
            • 4
            • 5

          • 重写操作是redis主进程fork一个子进程来处理，避免阻塞主进程

        • redis默认是rbd策略

      • AOF

        • 概念

          • AOF是redis提供的另一种数据持久化方式，它会记录客户端对redis服务端的每一次写操作，并将这些写操作以redis协议追加保存到后缀为aof的文件末尾。在redis服务器重启时，会读取并加载aof文件，达到恢复数据的目的。

        • 开启aof

          • 更改reids.conf中的appendonly配置，0为不开启，1为开启

        • 备份策略

          • appendfsync always
            • 客户端对redis服务器的每次写操作都写入AOF日志文件。这种方式是最安全的方式，但每次写操作都进行一次磁盘IO，非常影响redis的性能，所以一般不使用这种方式。
          • appendfsync everysec
            • 每秒刷新一次缓冲区中的数据到AOF文件。这种方式是redis默认使用的策略，是考虑数据完整性和性能的这种方案，理论上，这种方式最多只会丢失1秒内的数据
          • appendfsync no
            • redis服务器不负责将数据写入到AOF文件中，而是直接交给操作系统去判断什么时候写入。这种方式是最快的一种策略，但丢失数据的可能性非常大，因此也是不推荐使用的

        • AOF重写

          • 背景

            • AOF是Redis增量模式的持久化方式，随着redis的持续运行，会不断有新的数据写入AOF文件中，逐渐占用大量磁盘空间，还会降低Redis启动速度。Redis中有rewrite机制来合并AOF历史记录。
            • 比如当我们对同一个key做多次写操作时，就会产生大量针对同一个key操作的日志指令，导致AOF文件会变得非常大，恢复数据的时候会变得非常慢

          • 触发命令 bgrewriteaof

          • 触发策略

            • auto-aof-rewrite-percentage 100
              • 当文件的大小达到原先文件大小（上次重写后的文件大小，如果没有重写过，那就是redis服务启动时的文件大小）的两倍
            • auto-aof-rewrite-min-size 64mb
              • 文件重写的最小文件大小，即当AOF文件低于64mb时，不会触发重写

          • 重写流程

            • （1）bgrewriteaof触发重写，判断是否存在bgsave或者bgrewriteaof正在执行，存在则等待其执行结束再执行；

              （2）主进程fork子进程，防止主进程阻塞无法提供服务；

              （3）子进程遍历Redis内存快照中数据写入临时AOF文件，同时会将新的写指令写入aof_buf和aof_rewrite_buf两个重写缓冲区，前者是为了写回旧的AOF文件，后者是为了后续刷新到临时AOF文件中，防止快照内存遍历时新的写入操作丢失；

              （4）子进程结束临时AOF文件写入后，通知主进程；

              （5）主进程会将上面的aof_rewirte_buf缓冲区中的数据写入到子进程生成的临时AOF文件中；

              （6）主进程使用临时AOF文件替换旧AOF文件，完成整个重写过程。

      • RDB优缺点

        • 优点
          • 体积比aof小，rdb更紧凑
          • 恢复的速度快，因为rdn是快照型数据，不用重新读取并写入内存
        • 缺点
          • 因为有同步间隔，所以宕机时毕竟存在数据丢失
          • 虽然是异步备份，但当redis机器负载高的时候，备份的时间也会加长

      • AOF优缺点

        • 优点
          • 数据备份比RDB可靠，因为可以设置每次写入追加
          • 自动重写机制，缩小aof文件
        • 缺点
          • 对redis性能有损耗，毕竟每次写入都同步
          • aof文件体积大，恢复时间长

    • redis高可用

      • 主从模式
        • 概念
          • 和传统数据库一样，一主两从，用来做数据备份，提高数据库读写能力的
        • 应用场景
          • 读写分离
            • 主写，从读，降低主节点压力，提高查询性能
          • 数据备份
            • 机器宕机，磁盘损坏等，可以用其他节点数据进行备份
          • 提高服务高可用性
            • 至少一主两从，主节点挂了，从节点顶上
        • 数据同步策略
          • 全量同步
            • 发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份
            • 1）从服务器连接主服务器，发送SYNC命令；
              　　2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
              　　3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
              　　4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照（快照文件先接收保存到磁盘，最后加载到内存中）；
              　　5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
              　　6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
          • 增量同步
            • Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
            • Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
              增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令
      • 哨兵
        • 概念
          • 用于监控Redis集群中Master状态的工具，是Redis高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有从服务。 某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。
          • 即使后来之前的master重启服务，也不会变回master了，而是作为slave从服务
        • 应用场景
          • 当主服务器宕机时，需要将从服务器手动切换(slaveof no one)到主从服务器，这需要人工干预。
        • 作用
          • 心跳检测
            • Sentinel会不断检查主服务器和从属服务器是否正常运行
          • 通知
            • 当受监控的Redis服务器出现问题时，Sentinel会通过API脚本向管理员或其他应用程序发送通知
            • redis发布订阅来完成
          • 自动故障转移
            • 当主节点无法正常工作时，Sentinel将启动自动故障转移操作。它将与发生故障的主节点处于主从关系的从节点之一升级到新的主节点，并将其他从节点指向新的主节点

    • 分布式锁的使用和问题，解决方案

      • 应用场景
        • 多个定时器任务扫描，如何避免同一个任务重复处理
      • setnx
        • 存在返回0
        • 不存在返回1
      • setex
        • 解决定时器问题，设置锁的同时设置过期时间

    • 什么是缓存重建

      • 热点key大量失效
        • key不过期
        • 或者惰性创建，访问的时候，先检查，有则读取，没有则创建

    • redis是单线程还是多线程，6.0以后多线程解决了什么问题

      • 单线程，减去了多线程的上下文切换和锁的问题
      • 多路复用，类似nodejs事件循环，所有的读写都放入事件循环中，内部用多线程来执行
      • 多线程还是为了解决io性能，引入多线程，每一个线程维护一个事件队列

    • redis事务

      • MULTI，EXEC，DISCARD，WATCH 四个命令是 Redis 事务的四个基础命令。其中：

        MULTI，告诉 Redis 服务器开启一个事务。注意，只是开启，而不是执行 。
        EXEC，告诉 Redis 开始执行事务 。
        DISCARD，告诉 Redis 取消事务。
        WATCH，监视某一个键值对，它的作用是在事务执行之前如果监视的键值被修改，事务会被取消。

      • 应用场景

        • 数据一致性

    • redis发布订阅

      • 和node事件机制一样，通过on监听，发送等

    • cpu高

      • 有一天上午十点多redis告警cpu占用率高，于是就排查最近代码，发现有人用了keys*来查询所有
        • 当时立马改代码升级优化了一些
        • 后面还发现有一些大key，存储了一个账户的所有座席配置，频繁获取也会导致redis cpu飙升

    • 内存高

      • 有一次线上的redis机器内存告警
        • 我们先查看目前存在的大key(数据量比较大的key)
          • bigkeys命令可以查看，但只能看到String、hash、list、set、zset这五种类型
            • 优点是可以在线扫描，不阻塞服务；缺点是信息较少，内容不够精确。
          • 使用redis-rdb-tools工具，它实例上执行bgsave，bgsave会触发redis的快照备份，导出csv形式的文件，然后就可以进行分析了
        • 解决方案
          • 当时这个大key hset占用了5m的空间，寸的时候是全量存进去。但实际使用只用了几个字段。所以当时就立刻更改代码，对这种key进行拆分，只存必要的字段。就解决了这个问题

    架构

    微服务的优缺点

    • 优势
      • 每一个应用都是独立的服务
        • 相比较单点服务，服务的升级和迭代不影响其他服务
      • 服务性能提升
        • 服务拆分后，体积变小，也没有其他服务的代码影响，整体性能提升
      • 更适合快速迭代
        • 相比较单点服务，每次发布都是一个整体，编译，打包时间长。微服务编译和打包时间短
      • 单一职责
        • 随着服务和团队的扩大，单体服务已经不能满足多个团队间的协作，因为一个团队的代码变动可能影响其他团队。所以拆分后，每个团队变更自己的服务，不影响其他人的
    • 劣势
      • 分布式部署后，调用关系变得复杂了，之前都是单点，服务内部就通信即可。现在多个服务都是http和消息中间件调用，维护成本变高
      • 测试难度提升，一个服务的接口变动会影响其他调用方
      • 运维难度提升，之前只需要升级，监控单点服务。现在多个服务，每一个服务的升级，监控都是更高的成本问题

    什么是restful风格

    • 简称rest，它是一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件，它主要用于客户端和服务端交互类的软件。基于这个风格设计的软件可以更简介，更有层次

    • 特性

      • 资源
        • 可以用一个URI（统一资源定位符）指向它，每种资源对应一个特性的URI。要获取这个资源，访问它的URI就可以，因此URI即为每一个资源的独一无二的识别符
      • 表现层
        • 比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式。
      • 状态转换
        • 四个表示操作方式的动词：GET、POST、PUT、DELETE。他们分别对应四种基本操作：GET用来获取资源，POST用来新建资源，PUT用来更新资源，DELETE用来删除资源

    • 如何设计

      • 路径设计：数据库设计完毕之后，基本上就可以确定有哪些资源要进行操作，相对应的路径也可以设计出来。

        动词设计：也就是针对资源的具体操作类型，有HTTP动词表示，常用的HTTP动词如下：POST、DELETE、PUT、GET

    常用的设计模式，应用场景，解决了什么问题

    • 单例 业务隔离
      • 单例模式可以保证内存里只有一个实例，减少了内存的开销
      • 可以避免对资源的多重占用
      • 更专注，只做一件事
    • 适配器模式 继承
      • 提高代码重用性
      • 提高代码的扩展性
    • 开放封闭
      • 当需要改变一个程序的功能或者给这个程序增加新功能的时候，可以使用增加代码的方式，尽量避免改动程序的源代码，防止影响原系统的稳定
    • 策略模式
      • 避免多重判断
      • 扩展性高
    • 工厂模式
      • 主要用来初始化对象，规范对象初始化过程，节省对象的初始化成本

    什么是DDD设计模式，应用场景，解决了什么问题

    • 概念
      • 领域驱动设计模式，把业务拆分成细粒度的领域，解决因为项目庞大而导致的耦合性问题
      • application 应用层 属于业务的上层，调用业务
      • domain 领域层 实现具体业务处理
      • interface 接口层 处理接口
        • 引入了DTO，数据校验
      • repository 仓储 处理存储
        • 只做增删改查 不做任何其他业务
    • 应用场景
      • 大项目
      • 团队大
    • 解决了以下问题
      • 传统模式一致都是在一个service下用不同的文件夹来区分
      • ddd使用领域划分，domain处理业务，application处理业务上层，repository处理仓储

    Kakfa

    • 概念
      • 业务解耦
        • 传统的http业务，每个接入放的介入都可能要为了兼容而更改代码，用消息队列，接入方只需要订阅消息，而不需要更改推送反感的代码
      • 削峰
        • 传统模式，并发量大的会导致业务异常，比如数据库负载过高。用消息会根据对方的消费能力来处理，可能会有短暂的挤压，但不会导致数据库负载过高
      • 可靠性传输
        • 传统http如果没有重试机制，会导致请求丢失。kafka会保证被消费者接收
      • 容易扩展
    • 组成
      • 生产者 消息发送方
      • 实例 kafka服务器
      • topic 消费队列
      • 分区 用于提高kakfa吞吐量
      • 副本 每个分区有多个副本 默认10个，不能大于broker的数量，用于做主备切换
      • 消费者 接受消息
      • 消费者组 多个消费者在一个消费组，一个分区的数据只能被一个组内的一个消费者消费。同一个消费者可以处理同一个主题下不同分区的数据
      • zookeeper 保证kafka集群的通信，配置和可用性
    • 当前使用的是2.8.0版本
    • 消费者获取消息的机制
      • 通过拉取的方式
      • pull模式消费者自主决定是否批量从broker拉取数据，而push模式在无法知道消费者消费能力情况下，不易控制推送速度，太快可能造成消费者奔溃，太慢又可能造成浪费
      • 生产者会发送给订阅这个主题的分区，如果指定分区，则发给指定分区。如果没有指定，则轮询发送。
    • kafka为什么用zookeeper
      • 主要用于在集群中不同节点之间进行通信，在 Kafka 中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取，除此之外，它还执行其他活动，如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等
    • 消息同步机制
      • ack=0 不关注消费者是否收到消息
      • ack=1 只要leader节点收到通知 就算成功
      • ack=-1 所有复制节点收到通知才算成功
    • 什么是分区
      • 如果你创建的topic有5个分区，当你一次性向 kafka 中推 1000 条数据时，这 1000 条数据默认会分配到 5 个分区中，其中每个分区存储 200 条数据
      • 这样做的目的，就是方便消费者从不同的分区拉取数据，假如你启动 5 个线程同时拉取数据，每个线程拉取一个分区，消费速度会非常非常快！
      • 发送消息时先发给主分区，主分区同步给子分区
        • 分配机制
          • 1、数据在写入的时候可以指定需要写入的分区，如果有指定，则写入对应的分区
          • 2、如果没有指定分区，但是设置了数据的key，则会根据key的值hash出一个分区
          • 3、如果既没指定分区，又没有设置key，则会轮询选出一个分区
      • 消费者从主分区中拉取消息
    • kafka消息顺序
      • 同一个分区内的消息是有序的
      • 多个分区是无序的
    • 消费者分区分配策略
      • RangeAssignor 范围分配
        • kafka默认的分配策略，假如现在有 10 个分区，3 个消费者，排序后的分区将会是0,1,2,3,4,5,6,7,8,9；消费者排序完之后将会是C1-0,C2-0,C3-0。那么第一个消费者就多消费一个分区
        • 默认按照编号排序分配
    • kafka如何跟踪消费状态
      • 通过offset偏移量来标记消费的位置
    • 分区策略
      • 轮询 一次将消息发给该topic下所有分区
      • 指定分区
    • kafka为什么性能强
      • 利用分区提高集群负载
        • 多个分区
      • 数据缓存
        • 如果在 Cache 中存在该数据且是最新的，则直接将数据传递给用户程序，免除了对底层磁盘的操作，提高了性能
      • 批处理
        • 控制分批发送
    • 应用场景
      • 日志收集
      • 对接多方，需要业务解耦
        • 用户上线下线
        • 账单
        • licence踢下线

    Apollo

    • 什么是apollo
      • 一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景
    • 特点，应用场景
      • 统一管理不同环境，不同集群的配置
      • 配置实时更新
      • 版本发布
      • 灰度发布
      • 权限管理
    • 组成
      • application 应用
      • environment 环境
      • cluster 集群
      • namespace 命名空间
    • 组件
      • config service
      • admin service
      • protal

    私有包使用nexus作为仓储

    Docker

    • 什么是docker
      • 使用go编写，开源的容器引擎。docker可以让开发者打包他们的应用和依赖到一个轻量的容器中，然后可以发布到任意的linux平台。
    • dockerfile
      • 用来构建docker镜像的文本文件，包含了构建镜像的指令和说明等
    • 应用场景和优缺点
      • 比起传统sh脚本，docker镜像更适合自动编译，打包和发布
      • 自动化集成，cicd
      • 维护成本低，容错率高
      • 隔离运行环境
    • 常用命令
      • docker info 查看docker版本信息
      • docker images 查看镜像列表
      • docker search 镜像名称 搜索镜像
      • docker run 镜像名称 运行镜像
      • docker ps -a 查看容器列表
      • docker image rm 镜像名 删除某一个镜像
    • 你们公司都是如何使用docker的
      • 公司内部使用k8s来管理和编排docker。
      • 在ci阶段，使用dockerfiler完成编译，打包。然后将镜像推送到harbor仓储。到cd阶段，上k8s环境更改镜像id，触发k8s的更新后，自动滚动发布。

    K8s

    • 什么是k8s，和docker区别

      • 概念
        • 一个容器编排工具，可以滚动升级，对运行的容器状态进行监控，还有健康检查等
      • docker是一个容器部署工具，运行环境隔离，有自己的文件系统等
        • 优点
          • 运行管理隔离，相互不影响
          • 有利于分布式，因为容器轻量，每一个应用都可以当作一个容器
        • 缺点：k8s解决的问题就是缺点

    • 特点，应用场景和优缺点

      • 中大型应用使用k8s比较合适，因为随着应用体积变大，运维监控成本会变高

    • k8s的组成

      • apiserver
        • Kubernetes API 服务器验证并配置 API 对象的数据， 这些对象包括 pods、services、replicationcontrollers 等。 API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端， 所有其他组件都通过该前端进行交互
      • etcd
        • etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
      • proxy
        • 工作节点上的一个网络代理组件，运行在每个节点上
          它维护节点上的网络规则，实现了Kubernetes Service 概念的一部分 。它的作用是使发往 Service 的流量（通过ClusterIP和端口）负载均衡到正确的后端Pod
      • kubelet
        • Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命：
          １．监视分配给该Node节点的pods
          ２．挂载pod所需要的volumes
          ３．下载pod的secret
          ４．通过docker/rkt来运行pod中的容器
          ５．周期的执行pod中为容器定义的liveness探针
          ６．上报pod的状态给系统的其他组件
          ７．上报Node的状态

    • k8s核心概念

      • pod
        • k8s内的一个容器单元，相当于一个拥有命名空间和存储卷的docker容器
      • deployment
        • 用来管理pod，控制pod的增删改
      • service
        • 实现pod的网络通信。因为pod每次变更都会发生ip变动，所以就需要一个入口来屏蔽ip的变动，实现通过service访问内部pod
        • service和pod没有直接关系，pod通过endpoints暴漏出来，只要pod变更就会同步到endpoints中。service通过endpoints的映射关系来访问pod

    • k8s的健康检查机制都有哪些

      • 存活探测器
        • 用来探测什么时候重启定时器
      • 就绪探测器
        • 用来探测什么时候可以接受请求流量
      • 启动探测器
        • 用来探测应用程序何时启动

    • 如何实现集群管理

      • 开发人员通过rancher可视化平台，实现对pod的生命周期管理

    • K8S基础

      • K8S的概念
      • 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制
      • 出现背景
      • 解决以下问题
        • 随着容器的增加,容器的协调和调度步骤主键繁琐
        • 服务升级如何保证不中断
          • 服务运行状态的监控
        • 容器的管理

    • K8S中POD的概念

      • k8s内的一个容器单元，相当于一个拥有命名空间和存储卷的docker容器

      • K8S的命名空间

      • 命名空间 namespace 是 k8s 集群级别的资源，可以给不同的用户、租户、环境或项目创建对应的命名空间，例如，可以为 test、devlopment、production 环境分别创建各自的命名空间

        • 命名空间适用于存在很多跨多个团队或项目的用户的场景

      • Deployment无状态应用的部署

      • 编写一个yml文件，按照k8s的格式定以命名空间，pod标签，端口号，镜像id等

    • Service的类型

      • clusterip

      • 通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType

      • NodePort

      • 通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。

      • LoadBalancer

      • 使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上

      • Service和pod的关系

      • service和pod并没有直接的关系。pod通过endpoints暴露出来，只要pod发生变更，便会同步至endpoints中。有了service和endpoints后，kube-proxy会实时监听它们的更新和删除操作，然后更新iptables代理规则，重新生成该service访问pod的ip和端口映射规则

      • labels标签

      • 当相同类型的资源越来越多，对资源划分管理是很有必要，此时就可以使用label为资源对象 命名，以便于配置，部署等管理工作，提升资源的管理效率

      • labels selector 标签选择器

      • Label selector(标签选择器)是Kubernetes核心的分组机制，通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象

        • 通过资源对象上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程
        • kupe-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立器每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制
          • 通过对某些Node定义特定的Label,并且在Pod定义文件中使用NodeSelector这种标签调度策略，Kube-scheduler进程可以实现Pod定向调度的特性

      • Ingress七层负载均衡

      • ingress其实类似nginx，通过k8s监听ingress资源的变化，重新生成nginx.conf文件，然后生效

        • 和tcp七层协议一样，只不过最后通过service完成负载均衡

    • K8S深入

      • K8S的资源配额、限制

        • 通常nodejs的pod限制在2c4g
          • 达到1.8c的时候扩容一个pod
          • 达到3.5g的时候库容一个pod

      • K8S的环境变量

        • 在yml配置文件中的env下定义即可

      • K8S配置管理（ConfigMap、Secret等）

        • configmap是k8s的一个配置管理组件，可以将配置以key-value的形式传递，通常用来保存不需要加密的配置信息，加密信息则需用到Secret，主要用来应对以下场景：
          • 使用k8s部署应用，当你将应用配置写进代码中，就会存在一个问题，更新配置时也需要打包镜像，configmap可以将配置信息和docker镜像解耦。
          • 使用微服务架构的话，存在多个服务共用配置的情况，如果每个服务中单独一份配置的话，那么更新配置就很麻烦，使用configmap可以友好的进行配置共享。
            其次，configmap可以用来保存单个属性，也可以用来保存配置文件

      • K8S的滚动更新

        • 所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成

      • K8S的健康检查

        • 存活探测器
          • 用来探测什么时候重启定时器
        • 就绪探测器
          • 用来探测什么时候可以接受请求流量
        • 启动探测器
          • 用来探测应用程序何时启动

      • K8S的存储管理（PV、PVC等）

      g) K8S的有状态服务StatefulSet

      h) K8S的Job、CronJob

      i) 使用流水线部署K8S应用

      四、 K8S进阶

      a) K8S集群规划、搭建

      b) K8S的概念架构、技术架构

      c) K8S负载类型

      d) K8S的调度策略（亲和、反亲和等）

      e) K8S的存储（本地存储、分布式存储等）

      f) K8S中的负载均衡（ClusterIP、NodePort、L4、L7负载均衡）

      g) K8S的弹性伸缩（HPA、CA等）

      h) 使用Helm Chart发布应用

      i) K8S的日志、监控、告警体系

      j) Istio服务网格与流量治理

      k) K8S技术演进路线（AKS、ASK、ACI、FaaS等）

    项目

    你们线上运行多少机器，都是什么配置，为什么这样配置

    • 旧平台 我们部门总共20台，大多都是4c8g的机器，一共14个服务
    • 新平台 由于时k8s动态管理，无法具体到机器数量，但是我们的node服务都是2c4g的，除了个别java，给的是8g，因为要处理导出

    QPS达到多少

    • 能打到1000-1200 200+ms

    你们登录加密token怎么做的

    • 直接用md5来做的
    • 后台通过加盐来对比数据库密码

    单点登录如何做的

    • 用redis存储单点登录状态，第三方发起/loginToken登陆时，调用单点登录接口进行登录

    说说对sass行业的理解

    • 是一种通过网络提供集中式服务的软件。
    • 不用购买，安装和维护任何软件硬件，只需要根据需要。每个月付钱即可。和"租"类似

    什么是线程安全和不安全

    • 安全
      • 有锁机制，避免了多个线程争抢资源问题
    • 不安全
      • 没有锁，多个线程可能争抢资源，导致业务异常

    什么是GRPC

    • 先看一下rcp和http区别
      • RPC 主要用于公司内部的服务调用，性能消耗低，传输效率高，实现复杂。
        HTTP 主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等。
    • grpc是基于rpc的一个框架

    ElasticSearch

    • 什么是Elasticsearch
      • 基于lucence的搜索引擎，接口风格基于resultful，使用Java开发的
      • 分片
        • 概念
          • 在ES中所有数据的文件块，也是数据的最小单元块，整个ES集群的核心就是对所有分片的分布、索引、负载、路由等达到惊人的速度
        • 假设 IndexA 有2个分片，我们向 IndexA 中插入10条数据 (10个文档)，那么这10条数据会尽可能平均的分为5条存储在第一个分片，剩下的5条会存储在另一个分片中。
        • 设置分片的关键字是number_of_shards
        • 设置分片副本的关键字是number_of_replicas
        • 设置分片的策略
          • 建议：（仅参考）
          • 1、每一个分片数据文件小于30GB
          • 2、每一个索引中的一个分片对应一个节点
          • 3、节点数大于等于分片数
      • 副本
        • 保障系统的高可用性，如果分片异常，副本分片会晋升为分片
    • 特点
      • 分布式文件存储
        • 和mongodb分片优点类似，将多条数据分布在不同的分片上，提高查询性能
        • 也有master和node节点
      • 实时分析的分布式搜索引擎
        • 基于倒排索引和lucence
      • 高扩展性
        • 扩展简单，只需要一台机器，根据配置文件指定集群节点加入即可
    • 优缺点
      • 优点
        • 高可用性，分布式部署，支持快照备份和恢复
          • 和传统的数据库集群一样，都是三个节点
          • 类似mongodb的分片机制，把数据存储在不同的分片中，提高查询性能和负载承受能力
        • 生态完善，部署简单，数据迁移简单等
          • 根据文档即可部署
          • kibana日志分析
          • elasticsearch内置了数据迁移api
        • 内置多种分词器，满足大部分业务场景
          • 完全模糊搜索 ngram
          • 中文分词 IK
          • 还有很多其他的
        • 搜索性能高
          • 每个字段都有索引
      • 缺点
        • 增加维护成本，毕竟是一个额外的组件
        • 不能随意更改索引结构，对于现有数据的结构，只能通过迁移数据到新索引结构上来解决
    • 应用场景
      • 模糊搜索，全文检索
      • 日志分析，kibana内部集成了elasticsearch
      • 运维监控
    • 当前用的是2.x版本
    • 索引比较大的 工单数据量是一千多万，占用空间三百多g
    • 一千多万数据量用默认的stander分词器，占用一百多g。使用ngram后占用三百多g
    • 正序和倒排索引区别
      • 正序索引
        • 概念
          • 好比mongodb，搜索一个关键字，要扫描表中每一个文档进行匹配
        • 好比在mongo中模糊搜索，包含这个关键字的文档
          • 数据库就会用这个关键字逐个匹配表中的文档，如果有100个文档，就扫描100次
          • 优点
            • 直接正序插入，不用对关键词进行拆分，所以插入效率高
          • 缺点
            • 检索性能差
      • 倒排索引
        • 概念
          • 和正序反过来，比如搜索苹果手机，那么倒排索引会拆分成苹，果，手，机这四个词，每一个词分别对应了包含该关键字的文档id
        • 三要素
          • 词条
            • 检索的关键词，关键字key
          • 词典
            • 词条的集合，拆分后的词组
          • 倒排表
            • 记录词条出现的位置和频率，每一项是一个倒排项
        • 优点
          • 检索性能高
        • 缺点
          • 插入的效率低，因为要对关键字进行拆分，构建索引
    • 当前使用的是什么版本 2.x版本
    • Elasticsearch基本概念
      • 集群
      • 节点
      • 索引
      • 文档
      • 类型
    • Elasticsearch如何保证写一致
      • 在操作写入的时候，es会进行以下步骤确保写一致性
        • 检查活跃的副本数，这个参数默认为1，也可以自己指定。如果活跃的副本数小于设定的值，则写入失败
        • 然后等待所有副本写入成功(中间会有一些重试措施)才返回，但并不是所有都写入才算成功
        • 写入中，如果有一个副本异常，持续失败，那么副本会通知主节点，将异常的副本关系移除。被移除的副本不接受任何请求。
    • 你们都用到了哪些分词器
      • stander
      • ngram
    • Elasticsearch基本语法
      • 插入或更新
        • index 索引
        • type 类型
        • id 字段id
        • routing 路由
        • body 数据体
      • 查询
        • query 查询器
        • should 或条件，至少满足一项
        • filter 过滤器，条件
        • term 精准匹配
        • match 模糊匹配
        • Match_phrase 短语模糊匹配
        • size 查询多少个
        • _source 返回指定字段
    • Elasticsearch数据类型
      • text：被分析索引的字符串类型
      • keyword：不能被分析，只能被精确匹配的字符串类型
      • date：日期类型，可以配合format一起使用
      • long：长整型，数字类型
      • integer：整型，数字类型
      • short：短整型，数字类型
      • double：双精度浮点型，数字类型
      • Boolean：布尔型，true、false
      • array：数组类型
      • object：对象类型，json嵌套
      • ip：ip类型
      • geo_point：地理位置类型
    • Elasticsearch使用中遇到的问题
      • 默认的stander不能满足业务场景模糊搜索的需求，然后使用ngram进行改造，设置最小和最小分次数，设置的是1_25。它会逐字分词，然后使用uniq对重复结果过滤，对于大文本的场景较少，所以再使用limit对结果数进行限制。
      • 数据迁移失败，因为es默认会字符串进行转换，比如’1.0’会被转成1，字符串’2022’会被转换成日期格式，但字符串是一个自由的文本内容，按照es隐式转换标准会失败，所以就把这两个配置项给关闭了numeric_detection 数字转换，date_detection 日期转换
    • 如何监控Elasticsearch状态
      • elasticsearch-head 开源地址在github

    综合

    该篇是对标了几个大厂常问和一些偏八股文的问题

    TCP和UDP是什么还有区别

    HTTP和HTTPS区别

    • HTTPS协议需要CA证书，费用较高；而HTTP协议不需要；
    • HTTP协议是超文本传输协议，信息是明文传输的，HTTPS则是具有安全性的SSL加密传输协议；
    • 使用不同的连接方式，端口也不同，HTTP协议端口是80，HTTPS协议端口是443；
    • HTTP协议连接很简单，是无状态的；HTTPS协议是有SSL和HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP更加安全。
    • HTTPS使用了非对称加密和对称加密：HTTPS是在HTTP的基础上增加了SSL层，服务器和客户端传输数据前先采用非对称加密算法生产一个秘钥，再用这个秘钥使用对称加密算法加密要传输的数据，这样做即保证了秘钥的安全，有提高了数据加密效率。

    HTTP长连接和短链接区别

    TCP使用问题，比如粘包

    TCP如何保证可靠性传输

    • ARQ协议(超时重传协议)
      • RQ 协议也就是超时重传机制。通过确认和超时机制保证了数据的正确送达，ARQ 协议包含停止等待 ARQ 和连续 ARQ
      • 正常传输过程
        只要 A 向 B 发送一段报文，都要停止发送并启动一个定时器，等待对端回应，在定时器时间内接收到对端应答就取消定时器并发送下一段报文

    浏览器输入网址后都发生了什么

    • 输入www.baiidu.com
    • 将域名发送给DNS服务器
    • DNS服务器返回一个ip地址
    • 然后客户端会把自己的ip和DNS返回的ip 分别换算成二进制，然后对比前三位数是否在一个子网
    • 在一个子网则直接发送
    • 不在一个子网，咋将数据包发给交换机，通过以太网协议广播到路由器(网关)，路由器再继续进行寻址，直到找到对应的ip服务器
    • 然后把http请求打包到数据包中构成请求报文
    • 然后就到了传输层，经过TCP协议需要设置接收方的端口。然后把应用层的数据包封装到TCP数据包中，并加上一个TCP头部，该头部包含了接收方的端口号
    • 然后就到了网络层，走ip协议，把tcp协议的头和数据包放入ip数据包中，再加一个ip头(包含了本机和接收方的ip地址)
    • 然后就到了数据链路层，再把ip数据包放入以太网数据包中，头部存放了本机网卡的mac地址，网关的mac地址。但是以太网的数据包限制大小在1500个字节，如果超出则进行分割，分割后的数据包报头都包含了mac地址。然后再通过交换机，用以太网协议进行广播分发
    • 直到找到最后的ip服务器。收到分割后的包根据ip头的序号再讲这分割后的包进行合并。然后从ip数据包中找到tcp数据包，再从tcp数据包中找到http数据包进行读取和处理。然后再把返回的数据封装成http响应报文并放在http数据包中，再放入tcp数据包，再放入ip数据包，最终封装成以太网数据包，通过网关寻址转发回去

    HTTP1.0,1.1,2.0的区别

    • http1.0 需要指定kepp-alive来保持连接，默认短链接，每次请求都要重新建立一次TCP连接，处理完毕后就释放连接。但这样的话当网页内容较多时，比如css,js比较多，那么每次都要重新请求，就很浪费资源
    • http1.1 支持长连接(keep-alive)，TCP连接之后不会马山断开，之后再加载静态资源，都会基于这个TCP连接。http1.1还保持了host头部，也支持虚拟主机。而且支持断点续传
      • 长连接详解
        • 第一次请求网页时会打开一个TCP连接，去加载css等静态资源，等这些请求加载完毕后才会释放连接。当一个请求对于的回包回来时，他却无法分辨是属于哪个请求的。所以回包只能按请求顺序返回，这就引来了另一个问题-线头阻塞。
    • http 2.0 多路复用。基于TCP连接并行发送多个请求和接受响应，解决http1.1请求串行的性能问题等
    • 其实长连接和短连接指的是TCP连接

    HTTP协议和TCP/IP协议区别

    HTTP协议是无状态的怎么理解

    HTTP三次握手和四次挥手过程

    • 三次握手
      • 第一次握手（进入同步已发送状态）
        • 向服务器发送连接请求报文段 包含了端口和序列号
        • 发送SYN序列号，此时seq=a
      • 第二次握手（进入同步收到状态）
        • 确认报文段，标识服务器希望从客户端这边接收到数据的序列号
        • 服务端返回SYN序列号，其中seq=b，并把ack+1进行返回
      • 第三次握手（已建议连接状态）
        • 客户端收到服务端发送的确认ACK后，还要再次向服务器给出确认，确认报文段的ACK设置为１
        • SYN内的seq=b+1
      • 三次握手的目的不仅在于通信双方了解一个连接正在建立，还在于用数据包的选项承载特殊的信息，确保通信双方是可靠的
    • 四次挥手
      • 第一次挥手（终止等待状态）
        • 客户端向服务器发出连接释放的报文段
        • 发送 FIN，seq=a
      • 第二次挥手（终止等待状态２）
        • 服务区收到连接释放报文段后立即发出确认
        • 服务端返回ACK，seq=b，ack=a+1
      • 第三次挥手（最后确认）
        • 如果服务器已经没有向客户端发送数据，其应用的进程就通知服务器释放连接
        • 服务端继续返回FIN，seq=b，ack=a+1
      • 第四次挥手（时间等待）
        • 客户端收到服务器的连接释放报文段后，立即对此发出确认
        • 这样就能够让TCP重新发送最终的ACK以避免出现丢失的情况，重新发送最终的ACK并不是因为TCP重新传递了ACK，而是因为通信的另一方重新传递了它的FIN序列号
        • 为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。
        • 客户端发送ACK，seq=b+1

    为什么是三次握手而不是两次

    • 可以想象如下场景。客户端发送了一个连接请求 A，但是因为网络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送一个连接请求 B。此时请求顺利到达服务端，服务端应答完就建立了请求。如果连接请求 A 在两端关闭后终于抵达了服务端，那么这时服务端会认为客户端又需要建立 TCP 连接，从而应答了该请求并进入 ESTABLISHED 状态。此时客户端其实是 CLOSED 状态，那么就会导致服务端一直等待，造成资源的浪费。

    TCP/IP四层网络模型

    进程，线程，协程区别

    线程之间如何通信

    GRPC

    时间和空间复杂度

    • O(1) 没有循环 一次性执行
    • O(logN) 对数型TCP
    • O(n)线性 一个循环
    • O(n2)平方 for循环嵌套for
    • O(n3)立方 for循环嵌套for再嵌套for
    • O(2^n)指数
    • …

    链路追踪如何做的

    一个对象的创建过程

    serverless

    • 核心概念
      • 弱化了储存和计算之间的联系。 服务的储存和计算被分开部署和收费，服务的储存不再是它本身的一部分，而是演变成了独立的云服务，这使得计算变得无状态化，更容易调度和缩扩容，同时也降低了数据丢失的风险
      • 代码的执行不再需要手动分配资源。 我们再也不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘…），只需要提供一份代码，剩下的交由serverless平台去处理就行了
      • 按使用量计费。 serverless按照服务的使用量（调用次数、时长等）进行计费，而不是像传统的serverful服务那样，按照使用的资源（ECS实例、VM的规格等）计费。
  • 相关阅读:
    Domino服务器SSL证书安装指南
    K8S：K8S自动化运维容器Docker集群
    stack-es-标准篇-ElasticsearchClient-match_phrase
    防止按钮点击事件如何多次重复点击
    一些逻辑漏洞案例
    Linux 基础入门
    198. 打家劫舍
    eclipse中使用Maven
    [免费专栏] Android安全之Android应用的汉化功能(修改so中的字符串内容)
    一. HTML基础开发标签
  • 原文地址：https://blog.csdn.net/qq_42427109/article/details/125498601