字节跳动——飞书后端一面

后端开发实习生-飞书

深圳|实习|研发 - 后端

自我介绍

问项目：

你服务端你能解释一下负载均衡你是怎么理解的？

Nginx中的负载均衡是指将客户端请求分发到多个服务器上，从而提高系统的可靠性和性能。Nginx通过四种策略实现负载均衡：轮询、IP hash、最少连接数和权重。其中，轮询是默认的策略，根据请求的顺序依次将请求分发给不同的服务器。IP hash则是根据客户端IP地址的hash值来分配请求，最少连接数则会优先将请求分配给连接数最少的服务器，权重则是根据权重值来分配请求。

nginx里面的负载均衡你有了解过里面的实现吗？

Nginx实现负载均衡的原理是在worker进程中维护一个共享的状态，记录所有upstream server的状态信息，然后根据选定的负载均衡算法分配请求到合适的upstream server，最后将响应返回给客户端。Nginx还提供了健康检查、故障切换等机制来保证负载均衡的高可用性。此外，Nginx还支持动态添加和删除upstream server，提供了灵活的配置和管理方式。

cookie、session 、JWT token了解过他们是干什么的吗？

Cookie、Session和JWT Token都是用于Web应用程序中的身份验证和授权机制。

Cookie是在客户端存储的小数据片段，用于跟踪用户的会话状态。

Session是在服务器端存储的用户信息，用于在多个页面间共享用户状态。

JWT Token是一种用于身份验证和授权的安全令牌，包含了用户的信息和数字签名，可以在多个系统间共享。

八股文：

操作系统：

进程和线程有什么区别？

进程是操作系统中资源分配的基本单位，拥有独立的内存空间和系统资源，进程间通信需要通过IPC机制；

线程是进程中的一个执行单元，共享所属进程的内存空间和系统资源，线程间通信可以直接读写共享内存。

简而言之，进程是资源分配的单位，线程是执行的单位。

刚刚你也提了线程可以共用资源对吧？那进程之间如何做到共用资源呢？进程间的通信方式有哪些？

进程间通信方式包括管道、消息队列、共享内存、信号量、套接字等。其中，管道、消息队列和共享内存属于同一台机器上的进程通信方式，而套接字则可用于网络中不同机器间的进程通信。信号量则可用于同步和互斥。

数据库：

事务的ACID这部分了解吗？

ACID是指数据库事务应该具备的四个特性，包括：

原子性（Atomicity）：事务中的所有操作要么全部成功，要么全部失败回滚。

一致性（Consistency）：事务执行前后，数据库都应该保持一致性状态。

隔离性（Isolation）：多个并发的事务之间应该互相隔离，避免互相干扰。

持久性（Durability）：事务提交后，对数据库的修改应该永久保存，即使系统故障也不应该丢失。

原子性、一致性、隔离性和持久性他们分别是有什么作用？

ACID中的四个特性分别具有以下作用：

原子性：保证事务中所有操作要么全部成功，要么全部失败回滚，避免因为部分操作失败导致数据不一致或错误的结果。

一致性：保证事务执行前后，数据库都应该保持一致性状态，避免数据的不一致性。

隔离性：保证多个并发的事务之间应该互相隔离，避免读取到未提交的数据或者脏数据，避免并发操作导致的数据冲突。

持久性：保证事务提交后，对数据库的修改应该永久保存，即使系统故障也不应该丢失，避免数据的丢失和不可恢复。

那对脏读、幻读、不可重复读了解过吗？

脏读、幻读和不可重复读是数据库中的三种并发问题：

脏读（Dirty Read）：指一个事务读取了另一个事务未提交的数据，如果另一个事务回滚，则读取的数据是无效的。

幻读（Phantom Read）：指一个事务执行了两次查询，第二次查询发现了第一次查询没有发现的新数据或者没有查询到第一次查询中存在的数据。

不可重复读（Non-Repeatable Read）：指一个事务执行两次查询，第二次查询读取到了第一次查询中未提交的数据或另一个事务提交的数据。

这些问题的出现是由于多个事务同时访问数据库，而缺乏一定的隔离性和同步机制。为了解决这些问题，可以采用不同的隔离级别和锁机制来保证数据的一致性和可靠性。

事务的隔离级别有哪几种，作用分别是？

数据库事务的隔离级别有四种，分别为读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。

读未提交：最低的隔离级别，允许一个事务读取另一个事务未提交的数据。这种隔离级别会导致脏读、不可重复读和幻读问题。

读已提交：允许一个事务读取另一个事务已提交的数据，避免了脏读问题。但是仍然可能存在不可重复读和幻读问题。

可重复读：保证一个事务多次读取同一数据时，能够得到相同的结果，避免了不可重复读问题。但是仍然可能存在幻读问题。

串行化：最高的隔离级别，强制事务串行执行，避免了所有并发问题，但是会导致性能下降。

选择合适的隔离级别取决于应用场景和性能要求。通常情况下，可重复读是一个比较好的选择，能够在保证数据一致性的同时兼顾性能。

了解什么设计模式吗？应该准确来说叫代码编程，就比如像单例模式

设计模式是指在软件开发中，经过实践验证的通用解决方案。常见的设计模式有以下几种：

工厂模式：将对象的创建和使用分离，客户端只需知道产品的接口，无需关心具体实现。

单例模式：保证一个类只有一个实例，并提供全局访问点。

观察者模式：对象间的一种一对多的依赖关系，当一个对象状态发生改变时，所有依赖它的对象都会得到通知并自动更新。

装饰器模式：动态地给一个对象添加一些额外的职责，同时又不改变其结构。

策略模式：定义一系列算法，将每个算法封装起来并可互换使用，使得算法的变化不会影响到使用算法的客户端。

适配器模式：将一个类的接口转换成客户端所期望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。

模板方法模式：定义一个算法的骨架，将一些步骤延迟到子类中实现，使得子类可以不改变算法的结构即可重定义该算法的某些特定步骤。

建造者模式：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。

计算机网络：

你可以跟我讲述一下“三次握手，四次挥手”的过程吗

当客户端要向服务端发送数据时，需要先建立TCP连接，这个过程被称为“三次握手”。TCP连接的释放需要四次挥手来完成。

三次握手的过程如下：

客户端向服务端发送SYN报文，表示客户端请求建立连接。

服务端接收到SYN报文后，向客户端发送SYN+ACK报文，表示服务端已经收到请求，并同意建立连接。

客户端接收到服务端的SYN+ACK报文后，向服务端发送ACK报文，表示客户端已经收到服务端的确认，连接建立完成。

四次挥手的过程如下：

客户端发送FIN报文，表示客户端不再发送数据，请求断开连接。

服务端接收到FIN报文后，向客户端发送ACK报文，表示服务端已经接收到客户端的请求，并准备好断开连接。

服务端发送FIN报文，表示服务端不再发送数据，请求断开连接。

客户端接收到服务端的FIN报文后，向服务端发送ACK报文，表示客户端已经接收到服务端的请求，并断开连接。

需要注意的是，在四次挥手完成后，TCP连接就被彻底关闭了，双方不能再进行数据传输。

那四次挥手的服务端不是会有个ack吗？然后再发一个释放连接，那这两次可以合并吗？就是确认报文和释放连接可以同时发送吗？

不可以。因为ACK报文和FIN报文的作用是不同的。ACK报文用于确认客户端发送的FIN报文已经被正确接收，而FIN报文则用于通知客户端服务端已经准备好释放连接。在这两个报文中，ACK报文是必须的，因为客户端需要收到服务端的确认才能确定服务端已经接收到了自己发送的FIN报文。因此，这两个报文不能合并成一个发送。

tcp怎么保证可靠传输？可以具体讲一讲吗？

TCP保证可靠传输的机制包括以下几个方面：

序号和确认号：TCP通过序号和确认号来保证数据的可靠传输。发送方将每个数据报文都标记一个唯一的序号，接收方收到数据后需要回复一个确认号，表示已经成功接收到了这个数据。

超时重传：发送方在发送数据后会设置一个计时器，如果在规定的时间内没有收到确认，则会重新发送数据。这可以保证即使某个数据包在传输过程中丢失，也能够被及时地重传。

滑动窗口：TCP通过滑动窗口机制来控制发送方和接收方的数据发送和接收速率。发送方通过滑动窗口机制来控制发送数据的数量和速度，接收方则通过滑动窗口机制来控制接收数据的数量和速度。

确认机制：TCP通过确认机制来确保数据的可靠传输。发送方将每个数据报文都标记一个唯一的序号，接收方收到数据后需要回复一个确认号，表示已经成功接收到了这个数据。

拥塞控制：TCP通过拥塞控制机制来避免网络拥塞。发送方会根据网络状况和接收方的反馈来调整数据发送的速率，以避免网络拥塞。

有其他方法，其他层上的方式保证它可靠吗？比如说在报文上是不是会有些检验之类的

除了TCP本身提供的可靠传输机制之外，还有其他层上的方式可以保证数据的可靠传输。比如在数据链路层和物理层上，常用的技术包括循环冗余校验（CRC）、帧检验序列（FCS）等，用于检测和纠正数据传输中的错误。

在应用层上，常用的方法包括数据重传、数据校验等。例如，HTTP协议通常会在应用层上进行数据重传，以保证数据的可靠传输。另外，应用层协议也可以使用一些校验算法，如MD5、SHA等，来验证数据的完整性，以保证数据在传输过程中不被篡改。

总之，在不同层次上都可以采用不同的技术和机制来保证数据的可靠传输，这些机制相互配合，共同保障了数据的安全和可靠性。

两道算法题