大家好,我是小林。
新能源汽车今年是真的卷呀,小米汽车还没开卖,其他新能源汽车厂商已经主动降价了,有的甚至 50% 降幅。
小米一入局,妥妥影响了市场,确实让新能源车更适合年轻人了。
昨天看到消息,小米将会在 3 月底开小米汽车的发布会,期待一波小米汽车的价格,是否能感动人心。
聊到小米,那今天分享一位同学小米后端的面经,总共两轮技术面,面试内容除了后端八股,还有一些场景题,我把后端的内容帮大家解析了一下。
考察的知识点范围,我帮大家罗列了一下:
Redis 的读写操作都是在内存中,所以 Redis 性能才会高,但是当 Redis 重启后,内存中的数据就会丢失,那为了保证内存中的数据不会丢失,Redis 实现了数据持久化的机制,这个机制会把数据存储到磁盘,这样在 Redis 重启就能够从磁盘中恢复原有的数据。
Redis 持久化的方式有两种:
AOF 日志是如何实现的?
Redis 在执行完一条写操作命令后,就会把该命令以追加的方式写入到一个文件里,然后 Redis 重启时,会读取该文件记录的命令,然后逐一执行命令的方式来进行数据恢复。
我这里以「set name xiaolin」命令作为例子,Redis 执行了这条命令后,记录在 AOF 日志里的内容如下图:
Redis 提供了 3 种写回硬盘的策略, 在 Redis.conf 配置文件中的 appendfsync 配置项可以有以下 3 种参数可填:
我也把这 3 个写回策略的优缺点总结成了一张表格:
RDB 快照是如何实现的呢?
因为 AOF 日志记录的是操作命令,不是实际的数据,所以用 AOF 方法做故障恢复时,需要全量把日志都执行一遍,一旦 AOF 日志非常多,势必会造成 Redis 的恢复操作缓慢。
为了解决这个问题,Redis 增加了 RDB 快照。所谓的快照,就是记录某一个瞬间东西,比如当我们给风景拍照时,那一个瞬间的画面和信息就记录到了一张照片。
所以,RDB 快照就是记录某一个瞬间的内存数据,记录的是实际数据,而 AOF 文件记录的是命令操作的日志,而不是实际的数据。
因此在 Redis 恢复数据时, RDB 恢复数据的效率会比 AOF 高些,因为直接将 RDB 文件读入内存就可以,不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。
Redis 提供了两个命令来生成 RDB 文件,分别是 save 和 bgsave,他们的区别就在于是否在「主线程」里执行:
Redis 单线程指的是「接收客户端请求->解析请求 ->进行数据读写等操作->发送数据给客户端」这个过程是由一个线程(主线程)来完成的,这也是我们常说 Redis 是单线程的原因。
但是,Redis 程序并不是单线程的,Redis 在启动的时候,是会启动后台线程(BIO)的:
大 key 会带来以下四种影响:
解决方式:
UUID
,又或者Auto_increment
自增的主键,或者是雪花算法生成的主键等等;is_deleted
,以标记该数据已经逻辑删除,最好不要进行物理删除,因为恢复数据很困难,而且物理删除会使自增主键不再连续。NOT NULL
可以防止出现空指针问题。其次,NULL
值存储也需要额外的空间的,它也会导致比较运算更为复杂,使优化器难以优化 SQL。NULL
值有可能会导致索引失效5
个。因为创建过多的索引,会降低写得速度。索引创建完后,还是要注意避免索引失效的情况,如使用 mysql 的内置函数,会导致索引失效的。索引过多的话,可以通过联合索引的话方式来优化。然后的话,索引还有一些规则,如覆盖索引,最左匹配原则等等。MySQL 常见索引有 B+Tree 索引、HASH 索引、Full-Text 索引。
O(logdN)
,其中 d 表示节点允许的最大子节点个数为 d 个。在实际的应用当中, d 值是大于100的,这样就保证了,即使数据达到千万级别时,B+Tree 的高度依然维持在 3~4 层左右,也就是说一次数据查询操作只需要做 3~4 次的磁盘 I/O 操作就能查询到目标数据。而二叉树的每个父节点的儿子节点个数只能是 2 个,意味着其搜索复杂度为 O(logN)
,这已经比 B+Tree 高出不少,因此二叉树检索到目标数据所经历的磁盘 I/O 次数要更多。四个隔离级别如下:
按隔离水平高低排序如下:
针对不同的隔离级别,并发事务时可能发生的现象也会不同。
一般可以采用以下几种常见的分表策略:
如果在不考虑服务器的内存和文件句柄资源的情况下,理论上一个服务端进程最多能支持约为 2
的 48
次方(2^32 (ip数) * 2^16 (端口数
),约等于两百多万亿!
但是在实际中是支持不了这个数值的,每个 TCP 连接都是一个文件,会占用文件句柄资源,也会占用一定的内存空间。
一台服务器是可以有多个服务端进程的,每个服务端进程监听不同的端口,当然所有65535个端口你都可以用来监听一遍,这样理论上线就到了2的32次方(ip数)×2的16次方(port数)×2的16次方(服务器port数)个,这个基本相当于无穷个了。
但是 Linux每维护一条TCP连接都要花费内存资源的,每一条静止状态(不发送数据和不接收数据)的 TCP 连接大约需要吃 3.44K 的内存,那么 8 GB 物理内存的服务器,最大能支持的 TCP 连接数=8GB/3.44KB=2,438,956(约240万)。
实际过程中的 TCP 连接,还会进行发送数据和接收数据了,那么这些过程还是会额外消耗更多的内存资源的,并发很难达到百万级别。
之前有分享过这个文章:腾讯三面:一台服务器,最大支持的TCP连接数是多少?
之前图解过进程间通信的文章:凉了!张三同学没答好「进程间通信」,被面试官挂了....
由于每个进程的用户空间都是独立的,不能相互访问,这时就需要借助内核空间来实现进程间通信,原因很简单,每个进程都是共享一个内核空间。
Linux 内核提供了不少进程间通信的方式,其中最简单的方式就是管道,管道分为「匿名管道」和「命名管道」。
匿名管道顾名思义,它没有名字标识,匿名管道是特殊文件只存在于内存,没有存在于文件系统中,shell 命令中的「|
」竖线就是匿名管道,通信的数据是无格式的流并且大小受限,通信的方式是单向的,数据只能在一个方向上流动,如果要双向通信,需要创建两个管道,再来匿名管道是只能用于存在父子关系的进程间通信,匿名管道的生命周期随着进程创建而建立,随着进程终止而消失。
命名管道突破了匿名管道只能在亲缘关系进程间的通信限制,因为使用命名管道的前提,需要在文件系统创建一个类型为 p 的设备文件,那么毫无关系的进程就可以通过这个设备文件进行通信。另外,不管是匿名管道还是命名管道,进程写入的数据都是缓存在内核中,另一个进程读取数据时候自然也是从内核中获取,同时通信数据都遵循先进先出原则,不支持 lseek 之类的文件定位操作。
消息队列克服了管道通信的数据是无格式的字节流的问题,消息队列实际上是保存在内核的「消息链表」,消息队列的消息体是可以用户自定义的数据类型,发送数据时,会被分成一个一个独立的消息体,当然接收数据时,也要与发送方发送的消息体的数据类型保持一致,这样才能保证读取的数据是正确的。消息队列通信的速度不是最及时的,毕竟每次数据的写入和读取都需要经过用户态与内核态之间的拷贝过程。
共享内存可以解决消息队列通信中用户态与内核态之间数据拷贝过程带来的开销,它直接分配一个共享空间,每个进程都可以直接访问,就像访问进程自己的空间一样快捷方便,不需要陷入内核态或者系统调用,大大提高了通信的速度,享有最快的进程间通信方式之名。但是便捷高效的共享内存通信,带来新的问题,多进程竞争同个共享资源会造成数据的错乱。
那么,就需要信号量来保护共享资源,以确保任何时刻只能有一个进程访问共享资源,这种方式就是互斥访问。信号量不仅可以实现访问的互斥性,还可以实现进程间的同步,信号量其实是一个计数器,表示的是资源个数,其值可以通过两个原子操作来控制,分别是 P 操作和 V 操作。
与信号量名字很相似的叫信号,它俩名字虽然相似,但功能一点儿都不一样。信号是异步通信机制,信号可以在应用进程和内核之间直接交互,内核也可以利用信号来通知用户空间的进程发生了哪些系统事件,信号事件的来源主要有硬件来源(如键盘 Cltr+C )和软件来源(如 kill 命令),一旦有信号发生,进程有三种方式响应信号 1. 执行默认操作、2. 捕捉信号、3. 忽略信号。有两个信号是应用进程无法捕捉和忽略的,即 SIGKILL
和 SIGSTOP
,这是为了方便我们能在任何时候结束或停止某个进程。
前面说到的通信机制,都是工作于同一台主机,如果要与不同主机的进程间通信,那么就需要 Socket 通信了。Socket 实际上不仅用于不同的主机进程间通信,还可以用于本地主机进程间通信,可根据创建 Socket 的类型不同,分为三种常见的通信方式,一个是基于 TCP 协议的通信方式,一个是基于 UDP 协议的通信方式,一个是本地进程间通信方式。
图片
协程比线程快的主要原因有以下几点:
相同点:
sleep()
和 wait()
调用都会暂停当前线程并让出 CPU
不同点:
sleep()
是线程类(Thread
)的方法;wait()
是顶级类 Object
的方法;sleep
方法可以在任何地方使用;wait
方法则只能在同步方法或同步块中使用;sleep
方法只让出了CPU,没有释放同步资源锁!wait
方法则是指当前线程让自己暂时退让出同步资源锁,以便其他正在等待该资源的线程得到该资源进而运行,只有调用了notify
方法,之前调用wait()的线程才会解除wait状态,可以去参与竞争同步资源锁,进而得到执行。Java中的wait()
方法需要在同步块(synchronized block)中调用的原因是因为wait()
方法会释放对象的锁,而在同步块中可以确保线程在调用wait()
方法前持有对象的锁,从而避免多线程执行时的竞争和冲突。
具体原因如下:
wait()
方法可以确保线程在调用wait()
前已经获取了对象的锁,避免多线程之间的竞争和数据不一致性问题。wait()
方法会释放对象的监视器(monitor),其他线程可以获取该对象的监视器并执行同步操作,确保线程之间的协作和同步。wait()
方法后,线程会进入等待状态,只有在其他线程调用notify()
或notifyAll()
方法唤醒该线程时,线程才会继续执行。在同步块中调用wait()
可以保证线程被正确唤醒。