面试题汇总 - 持续更新

太过爱你忘了你带给我的痛 2022-10-06 05:58 267阅读 0赞

# 一.[linux查看日志的几种方法][linux] #

linux 日志查看

tail、head、 cat、tac、sed、less、echo

**1、命令格式: tail       \[必要参数\]     \[选择参数\]     \[文件\]**

\-f 循环读取

\-q 不显示处理信息

\-v 显示详细的处理信息

\-c<数目> 显示的字节数

\-n<行数> 显示行数

\-q, --quiet, --silent 从不输出给出文件名的首部

\-s, --sleep-interval=S 与-f合用,表示在每次反复的间隔休眠S秒

tail -n 100 catalina.out 查询日志尾部最后100行的日志;

tail -n +100 catalina.out 查询100行之后的所有日志;

tail -fn 100  catalina.out 循环实时查看最后100行记录(最常用的)

配合着grep用, 例如 : tail -fn 100 catalina.out | grep   -- '关键字'

如果一次性查询的数据量太大,可以进行翻页查看,

例如:tail -n 6000  catalina.out |more -100 可以进行多屏显示(ctrl + f 或者 空格键可以快捷键)  
\--------------------------------------------------------------------------------------------------------------------------

2、head

head -n  1000  catalina.out   //查询日志文件中的头10行日志;
    head -n -1000  catalina.out   //查询日志文件除了最后10行的其他所有日志;
    
    head其他参数与tail 类似
    -----------------------------------------------------------------------------------------------------
    
    3、cat 
    cat 是由第一行到最后一行连续显示在屏幕上

$ cat filename                    // 一次显示整个文件

$ cat > filename                 //从键盘创建一个文件

$cat file1 file2 > file            //将几个文件合并为一个文件,只能创建新文件,不能编辑已有文件.

$cat -n textfile1 > textfile2 //将一个日志文件的内容追加到另外一个 :

$cat : >textfile2                // 清空一个日志文件

**注意：     >意思是创建，       >>是追加。**  
cat其他参数与tail 类似

**4.tac**  
tac 则是由最后一行到第一行反向在萤幕上显示出来

**5.sed**

**这个命令可以查找日志文件特定的一段 , 也可以根据时间的一个范围查询**

//按照行号
      sed -n '2,100p'catalina.out

//这样你就可以只查看文件的第5行到第10行。
      //按照时间段
      sed -n '/2019-01-17 10:07:10/,/2019-02-14 16:54:01/p'catalina.out
    
    6.less

less log.log 
    
    shift + G 命令到文件尾部  然后输入 ？加上你要搜索的关键字例如 ？1213
    
    shift+n  关键字之间进行切换
    
    附录1

history // 所有的历史记录
    
    history | grep XXX  // 历史记录中包含某些指令的记录
    
    history | more // 分页查看记录
    
    history -c // 清空所有的历史记录
    
    !! 重复执行上一个命令
    
    查询出来记录后选中 :　!323
    
    -------------------------------------------------------------------------------------------------------------
    
    7、echo
    
    输出 echo "12345"
    
    ---------------------------------------------------------------------------------------------------------
    
    附录2

linux日志文件说明

/var/log/message 系统启动后的信息和错误日志，是Red Hat Linux中最常用的日志之一  
/var/log/secure 与安全相关的日志信息  
/var/log/maillog 与邮件相关的日志信息  
/var/log/cron 与定时任务相关的日志信息  
/var/log/spooler 与UUCP和news设备相关的日志信息  
/var/log/boot.log 守护进程启动和停止相关的日志消息  
/var/log/wtmp 该日志文件永久记录每个用户登录、注销及系统的启动、停机的事

附录3

tomcat运行日志

1、先切换到：cd usr/local/tomcat3/logs

2、tail -f catalina.out

3、这样运行时就可以实时查看运行日志了

Ctrl+c 是退出tail命令。  alt+E+R重置

# 二.mysql索引失效的几种情况（总结） #

**索引并不是时时都会生效的，比如以下几种情况，将导致索引失效：**

**    1.如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)**

**![5814854234b6d3131955bbcdfc344fcc.png][]**

**　　注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引**

**　　2.对于多列索引，不是使用的第一部分，则不会使用索引**

**　　3.like查询是以%开头**

**![0c8d55c6dc30a82bbbdcb352e1fcbb95.png][]**

**    4.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引**

**![5b896e77087cfb14c98ed3c0d12f3c4a.png][]  
  
　　5.如果mysql估计使用全表扫描要比使用索引快,则不使用索引**

**此外，查看索引的使用情况  
show status like ‘Handler\_read%';  
大家可以注意：  
handler\_read\_key:这个值越高越好，越高表示使用索引查询到的次数  
handler\_read\_rnd\_next:这个值越高，说明查询低效**

**1) 没有查询条件，或者查询条件没有建立索引 **

**2) 在查询条件上没有使用引导列 **

**3) 查询的数量是大表的大部分，应该是30％以上。 **

**4) 索引本身失效**

**5) 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+，-，\*，/，! 等) 错误的例子：select \* from test where id-1=9; 正确的例子：select \* from test where id=10; **

**6) 对小表查询 **

**7) 提示不使用索引**

**8) 统计数据不真实 **

**9) CBO计算走索引花费过大的情况。其实也包含了上面的情况，这里指的是表占有的block要比索引小。 **

**10)隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误. 由于表的字段tu\_mdn定义为varchar2(20),但在查询时把该字段作为number类型以where条件传给Oracle,这样会导致索引失效. 错误的例子：select \* from test where tu\_mdn=13333333333; 正确的例子：select \* from test where tu\_mdn='13333333333'; **

**12) 1,<> 2,单独的>,<,(有时会用到，有时不会) **

**13,like "%\_" 百分号在前. **

**4,表没分析. **

**15,单独引用复合索引里非第一位置的索引列. **

**16,字符型字段为数字时在where条件里不添加引号. **

**17,对索引列进行运算.需要建立函数索引. **

**18,not in ,not exist. **

**19,当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况。 **

**20,B-tree索引 is null不会走,is not null会走,位图索引 is null,is not null 都会走 **

**21,联合索引 is not null 只要在建立的索引列（不分先后）都会走, in null时 必须要和建立索引第一列一起使用,当建立索引第一位置条件是is null 时,其他建立索引的列可以是is null（但必须在所有列 都满足is null的时候）,或者=一个值； 当建立索引的第一位置是=一个值时,其他索引列可以是任何情况（包括is null =一个值）,以上两种情况索引都会走。其他情况不会走。**

# **三、谈谈****swoole的进程架构模型** #

swoole的强大之处就在与其进程模型的设计，既解决了异步问题，又解决了并行。

## 主线程MainReactor ##

swoole启动后主线程会负责监听server socket，如果有新的连接accept，主线程会评估每个Reactor线程的连接数量。将此连接分配给连接数最少的reactor线程。这样的好处是

1.  每个reactor线程持有的连接数是非常均衡的，没有单个线程负载过高的问题
2.  解决了惊群问题，尤其是拥有多个listen socket时，节约了线程唤醒和切换的开销

主线程内还接管了所有信号signal的处理，使Reactor线程运行中可以不被信号打断。

## 管理进程Manager ##

swoole运行中会创建一个单独的管理进程，所有的worker进程和task进程都是从管理进程Fork出来的。管理进程会监视所有子进程的退出事件，当worker进程发生致命错误或者运行生命周期结束时，管理进程会回收此进程，并创建新的进程。

管理进程还可以平滑地重启所有worker进程，以实现程序代码的重新加载。

## 异步Reactor线程 ##

swoole拥有多线程Reactor，所以可以充分利用多核，开启CPU亲和设置后，Reactor线程还可以绑定单独的核，节约CPU Cache开销。

swoole的Reactor线程是全异步非阻塞的，即使你的worker进程用了同步模式，依然不影响reactor线程的性能。在worker进程组很繁忙的状况下，reactor线程完全不受影响，依然可以收发处理数据。

TCP是流式的，没有边界，所以处理起来很麻烦。Reactor线程可以根据EOF或者包头长度，自动缓存数据，组装数据包。等一个请求完全收到后，再投递给Worker进程。

## 同步或异步Worker进程 ##

与传统的半同步半异步服务器不同，Swoole的worker进程可以是同步的也可以异步的，这样带来了最大的灵活性。当你的Server需要很高性能，业务逻辑较为简单时你可以选择异步模式。当业务逻辑复杂多变，可以选择同步模式。

这里要比Node.js强大太多了。

## TaskWorker进程池 ##

swoole除了Reactor线程，Worker进程外还提供了TaskWorker进程池，目的是为了解决在业务代码中，有些逻辑部分不需要马上执行。利用task进程池，可以方便的投递一个异步任务去执行，在Worker进程空闲时再去捕获任务执行的结果。

四、redis哨兵介绍  -  概念 、原理、部署

哨兵  
在一个典型的一主多从的Redis系统中，当主数据库遇到异常中断服务后，需要手动选择一个从数据库升级为主数据库，整个过程需要人工介入，难以自动化。

Redis2.8提供了哨兵2.0(2.6提供了1.0，但是问题较多)，哨兵顾名思义就是监控Redis系统的运行状况。它的功能包括一下两个：

监控主数据库和从数据库是否正常运行；  
主数据库出现故障时自动将从数据库升级为主数据库；  
哨兵是一个独立的进行，在一个一主多从的Redis系统中，可以使用多个哨兵监控整个Redis系统，哨兵之间也会互相监控。

配置

基于前面的一主两从架构，为他们加入哨兵。

可以在三个redis节点的redis目录下找到sentinel.conf文件，这个文件就是哨兵的配置文件，修改配置如下：

sentinel monitor mymaster 192.168.2.101 6379 3  
其中mymaster是要监控的主数据库名字，可以自定义；

接下来是主数据库的ip和端口；

最后一个3是指哨兵最低通过票数；

如果你需要后台启动，则修改daemonize参数：

daemonize yes  
配置后如果有防火墙，不要忘记打开哨兵的端口，默认是26379。

最后，开启哨兵：

redis-sentinel /yourpath/sentinel.conf  
做个测试，关闭主数据库(192.168.2.101)后，等待30秒(默认30秒)：

哨兵将从数据库中的一个节点升级成主数据库(192.168.2.102)；  
将另一个从数据库(192.168.2.103)的主数据库(192.168.2.101)切换到新的主数据库(192.168.2.102)；  
随后启动刚才关闭的主数据库(192.168.2.101)

哨兵自动将其转为从数据库；

原理  
监控过程  
哨兵启动后，会与要监控的主数据库建立两条连接：

一条用来用来订阅\_\_sentinel\_\_:hello频道以获取其他哨兵节点的信息；  
另一条用来定期向主数据库发送INFO等命令来获取主数据库本身的信息；  
在和主数据库建立连接后，哨兵会定时执行下面3个操作：

每10秒哨兵会向主数据库和从数据库发送INFO命令；  
每2秒哨兵会向主数据库和从数据库的\_\_sentinel\_\_:hello频道发送自己的信息；  
每1秒哨兵会向主数据库和从数据库和其他哨兵发送PING命令；  
第一个操作是发送INFO命令，目的是获取主数据库的信息，以及主数据库的从数据库的信息，从而实现新节点的自动发现，并对从数据库也建立两条连接。

第二个操作是订阅\_\_sentinel\_\_:hello频道，并发送哨兵本身的信息，与同样监控该数据库的其他哨兵分享自己的信息，同时也能识别哨兵是否是新哨兵。哨兵与哨兵之间也会建立一个链接，用来发送PING命令；

第三个操作是发送PING命令，在发现了从数据库和其他哨兵后，要做的就是定时监控Redis服务是否停止，时间间隔与配置文件中的down-after-milliseconds有关，当这个值小于1秒时，哨兵会每隔该值的时间发送PING命令，当这个值大于1秒时，哨兵会每隔1秒发送一次PING命令。

配置方式是在sentinel.conf文件中加入：

sentinel down-after-milliseconds mymaster 600 \# 600毫秒发送一个PING  
当超过down-after-milliseconds时，如果PING的数据库未回复，则哨兵认为其主观下线。主观下线可以理解为当前的哨兵认为该节点下线了。

如果该节点是主数据库，则哨兵们会进一步判断是否需要对其进行故障修复：

哨兵会发送SENTINEL is-master-down-by-addr命令询问其他哨兵，判断他们是否也认为该主数据库下线，如果达到quorum参数，也就是我们在配置哨兵时的命令：

sentinel monitor mymaster 192.168.2.101 6379 3  
的最后一个参数3，哨兵们会认为这个主数据库客观下线，并选举一个领头哨兵对主从系统发起故障恢复。

领头哨兵选举  
要进行故障恢复，则需要选举出一个领头哨兵，领头哨兵的选择算法是Raft算法，具体过程如下：

发现主数据库客观下线的哨兵节点(A节点)想每个哨兵节点发送命令，要求对方选择自己成为领头哨兵；

如果目标哨兵节点没有选择过其他人，则会同意将A设置成领头哨兵；

如果A发现超过半数且超过quorum参数个哨兵节点同意选择自己，则A成功成为领头哨兵；

当有多个哨兵同时参选，则会出现没有任何节点当选的可能，此时每个参选节点将等待一个随即时间重新发起竞选，直到选举成功。

故障恢复  
选择出领头哨兵后，会把从数据库中的一个挑选出来升级为主数据库：

所有先线的从数据库中，选择优先级最高的，优先级可以通过slave-priority来设置；  
如果有多个一样优先级的从数据库，则复制的命令偏移量越大，越优先(与down掉的主数据库最接近)；  
如果还有多个备选，则选择运行ID较小的(运行ID不会重复)；  
选择好节点后，领头哨兵将想这个节点发送slaveof no one，升级他为主数据库。

然后想其他从数据库发送slaveof命令切换主数据库。

最后更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，当其回复后自动以从数据库的身份加入到主从架构中。

哨兵部署  
哨兵的推荐部署方案：

为每个节点(无论是主数据库还是从数据库)都部署一个哨兵；  
使每个哨兵与其对应的节点的网络环境相同或相近；  
设置quorum的值为N/2+1，这样使得只有当大部分哨兵统一后才会选择领头哨兵进行故障恢复；

# 五、[Redis分布式锁的实现原理][Redis] #

一、写在前面

现在面试，一般都会聊聊分布式系统这块的东西。通常面试官都会从服务框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事务、分布式锁、ZooKeeper等知识。

所以咱们这篇文章就来聊聊分布式锁这块知识，具体的来看看Redis分布式锁的实现原理。

说实话，如果在公司里落地生产环境用分布式锁的时候，一定是会用开源类库的，比如Redis分布式锁，一般就是用Redisson框架就好了，非常的简便易用。

大家如果有兴趣，可以去看看Redisson的官网，看看如何在项目中引入Redisson的依赖，然后基于Redis实现分布式锁的加锁与释放锁。

下面给大家看一段简单的使用代码片段，先直观的感受一下：

![2739e723931b1416040a42a9c6386c3d.png][]

怎么样，上面那段代码，是不是感觉简单的不行！

此外，人家还支持redis单实例、redis哨兵、redis cluster、redis master-slave等各种部署架构，都可以给你完美实现。

二、Redisson实现Redis分布式锁的底层原理

好的，接下来就通过一张手绘图，给大家说说Redisson这个开源框架对Redis分布式锁的实现原理。

![c8d1685eb2f1e952f1f230931b3fc5a0.png][]

（1）加锁机制

咱们来看上面那张图，现在某个客户端要加锁。如果该客户端面对的是一个redis cluster集群，他首先会根据hash节点选择一台机器。

这里注意，仅仅只是选择一台机器！这点很关键！

紧接着，就会发送一段lua脚本到redis上，那段lua脚本如下所示：

![023f122ee8b715df11256c784dc198e8.png][]

为啥要用lua脚本呢？

因为一大坨复杂的业务逻辑，可以通过封装在lua脚本中发送给redis，保证这段复杂业务逻辑执行的原子性。

那么，这段lua脚本是什么意思呢？

KEYS\[1\]代表的是你加锁的那个key，比如说：

RLock lock = redisson.getLock("myLock");

这里你自己设置了加锁的那个锁key就是“myLock”。

ARGV\[1\]代表的就是锁key的默认生存时间，默认30秒。

ARGV\[2\]代表的是加锁的客户端的ID，类似于下面这样：

8743c9c0-0795-4907-87fd-6c719a6b4586:1

给大家解释一下，第一段if判断语句，就是用“exists myLock”命令判断一下，如果你要加锁的那个锁key不存在的话，你就进行加锁。

如何加锁呢？很简单，用下面的命令：

hset myLock

8743c9c0-0795-4907-87fd-6c719a6b4586:1 1

通过这个命令设置一个hash数据结构，这行命令执行后，会出现一个类似下面的数据结构：

![e20058e094106f58237f11903fba3365.png][]

上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”这个客户端对“myLock”这个锁key完成了加锁。

接着会执行“pexpire myLock 30000”命令，设置myLock这个锁key的生存时间是30秒。

好了，到此为止，ok，加锁完成了。

（2）锁互斥机制

那么在这个时候，如果客户端2来尝试加锁，执行了同样的一段lua脚本，会咋样呢？

很简单，第一个if判断会执行“exists myLock”，发现myLock这个锁key已经存在了。

接着第二个if判断，判断一下，myLock锁key的hash数据结构中，是否包含客户端2的ID，但是明显不是的，因为那里包含的是客户端1的ID。

所以，客户端2会获取到pttl myLock返回的一个数字，这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。

此时客户端2会进入一个while循环，不停的尝试加锁。

（3）watch dog自动延期机制

客户端1加锁的锁key默认生存时间才30秒，如果超过了30秒，客户端1还想一直持有这把锁，怎么办呢？

简单！只要客户端1一旦加锁成功，就会启动一个watch dog看门狗，他是一个后台线程，会每隔10秒检查一下，如果客户端1还持有锁key，那么就会不断的延长锁key的生存时间。

（4）可重入加锁机制

那如果客户端1都已经持有了这把锁了，结果可重入的加锁会怎么样呢？

比如下面这种代码：

![f01ab5f99a6e78ec520d9bec3c1a2855.png][]

这时我们来分析一下上面那段lua脚本。

第一个if判断肯定不成立，“exists myLock”会显示锁key已经存在了。

第二个if判断会成立，因为myLock的hash数据结构中包含的那个ID，就是客户端1的那个ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”

此时就会执行可重入加锁的逻辑，他会用：

incrby myLock

8743c9c0-0795-4907-87fd-6c71a6b4586:1 1

通过这个命令，对客户端1的加锁次数，累加1。

此时myLock数据结构变为下面这样：

![767fc896ff8397a6dfde05e37358acb7.png][]

大家看到了吧，那个myLock的hash数据结构中的那个客户端ID，就对应着加锁的次数

（5）释放锁机制

如果执行lock.unlock()，就可以释放分布式锁，此时的业务逻辑也是非常简单的。

其实说白了，就是每次都对myLock数据结构中的那个加锁次数减1。

如果发现加锁次数是0了，说明这个客户端已经不再持有锁了，此时就会用：

“del myLock”命令，从redis里删除这个key。

然后呢，另外的客户端2就可以尝试完成加锁了。

这就是所谓的分布式锁的开源Redisson框架的实现机制。

一般我们在生产系统中，可以用Redisson框架提供的这个类库来基于redis进行分布式锁的加锁与释放锁。

（6）上述Redis分布式锁的缺点

其实上面那种方案最大的问题，就是如果你对某个redis master实例，写入了myLock这种锁key的value，此时会异步复制给对应的master slave实例。

但是这个过程中一旦发生redis master宕机，主备切换，redis slave变为了redis master。

接着就会导致，客户端2来尝试加锁的时候，在新的redis master上完成了加锁，而客户端1也以为自己成功加了锁。

此时就会导致多个客户端对一个分布式锁完成了加锁。

这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。

所以这个就是redis cluster，或者是redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷：在redis master实例宕机的时候，可能导致多个客户端同时完成加锁。

# 六、使用Redis如何保证多个操作的原子性？ #

### 1.1方案一 ###

利用setnx和expire命令实现加锁。当一个线程执行setnx返回1，说明key不存在，该线程获得锁；当一个线程执行setnx返回0，说明key已经存在，则获取锁失败。expire就是给锁加一个过期时间。伪代码如下：

if(setnx(key,value)==1){
    
    expire(key,expireTime)
    
    try{
    
    //业务处理
    
    }finally{
    
    del(key)
    
    }
    
    }

该方案有一个致命问题，由于setnx和expire是两条Redis命令，不具备原子性，如果一个线程在执行完setnx()之后突然崩溃，导致锁没有设置过期时间，那么将会发生死锁。

### 1.2方案二 ###

利用setnx命令加锁，其中key是锁，value是锁的过期时间，1.通过setnx()方法尝试加锁，如果当前锁不存在，返回加锁成功。2. 如果锁已经存在则获取锁的过期时间，和当前时间比较，如果锁已经过期，则设置新的过期时间，返回加锁成功。伪代码如下：

long expires = System.currentTimeMillis() + expireTime;
    
    String expiresStr = String.valueOf(expires);
    
    
    // 如果当前锁不存在，返回加锁成功
    
    if (setnx(key, expiresStr) == 1) {
    
    return true;
    
    }
    
    
    // 如果锁存在，获取锁的过期时间
    
    String currentValueStr = get(key);
    
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
    
    // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
    
    String oldValueStr = jedis.getSet(lockKey, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
    
    // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才有权利加锁
    
    return true;
    
    }
    
    }
    
    
    // 其他情况，一律返回加锁失败
    
    return false;

此方案需要客户端时间同步，并且该线程的锁的过期时间可能被其他线程覆盖。

### 1.3方案三 ###

Redis2.6.12以上版本为set命令增加了可选参数，伪代码如下：

if(redis.set(key,value,"ex 180","nx")){
    
    //业务处理
    
    do something;
    
    //释放锁
    
    redis.delete(key);
    
    }

我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。

五、除了Redis分布式锁，还有其他方案吗？

**需求：两个客户端同时对\[key1\]执行自增操作，不会相互影响**

**操作：下面两个客户端并发操作会导致\[key1\]输出结果与预期不一致**

1.  \[客户端一\]读取\[key1\]，值为\[1\]
2.  \[客户端二\]读取\[key1\]，值为\[1\]
3.  \[客户端一\]将\[key1\]自增1，值为\[2\]
4.  \[客户端二\]将\[key1\]自增1，值为\[2\]
5.  \[客户端一\]输出\[key1\]，值为\[2\]
6.  \[客户端二\]输出\[key2\]，值为\[2\]

**解决思路**

1.  \[客户端一\]、\[客户端二\]的R（读）、M（自增）、W（写）三个操作作为一个原子操作执行
2.  \[客户端\]对RMW整个操作过程加锁，加锁期间其它客户端不能对\[key1\]执行写操作
3.  Lua脚本

**思路一：单命令操作**

1. 概念

Redis 提供了 INCR/DECR/SETNX 命令，把RMW三个操作转变为一个原子操作 Redis 是使用单线程串行处理客户端的请求来操作命令，所以当 Redis 执行某个命令操作时，其他命令是无法执行的，这相当于命令操作是互斥执行的

**思路二：加锁**

1. 概念

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> <p>2</p> <p>3</p> </td> 
   <td> <p><code>加锁主要是将多客户端线程调用相同业务方法转换为串行化处理，比如多个客户端调用同一个方法对某个键自增（这里不考虑其它方法或业务会对该键同时执行自增操作）</code></p> <p><code>&nbsp;</code>&nbsp;</p> <p><code>调用SETNX命令对某个键进行加锁（如果获取锁则执行后续RMW操作，否则直接返回未获取锁提示） 执行RMW业务操作 调用DEL命令删除锁</code></p> </td> 
  </tr> 
 </tbody> 
</table>

2. 加锁风险一

假如某个客户端在执行了SETNX命令加锁之后，在后面操作业务逻辑时发生了异常，没有执行 DEL 命令释放锁。 
    该锁就会一直被这个客户端持有，其它客户端无法拿到锁，导致其它客户端无法执行后续操作。 
    
    解决思路：给锁变量设置一个过期时间，到期自动释放锁 
    
    SET key value [EX seconds | PX milliseconds] [NX]

3. 加锁风险二

如果客户端 A 执行了 SETNX 命令加锁后，客户端 B 执行 DEL 命令释放锁，此时，客户端 A 的锁就被误释放了。如果客户端 C 正好也在申请加锁，则可以成功获得锁。 
    
    解决思路：加锁操作时给每个客户端设置一个唯一值（比如UUID），唯一值可以用来标识当前操作的客户端。在释放锁操作时，客户端判断当前锁变量的值是否和唯一标识相等，只有在相等的情况下，才能释放锁。（同一客户端线程中加锁、释放锁） 
    
    SET lock_key unique_value NX PX 10000

**思路三：Lua脚本**

1. 概念

多个操作写到一个 Lua 脚本中（Redis 会把整个 Lua 脚本作为一个整体执行，在执行的过程中不会被其他命令打断，从而保证了 Lua 脚本中操作的原子性）

2. 需求

限制所有客户端在一定时间范围内对某个方法（键）的访问次数。客户端 IP 作为 key，某个方法（键）的访问次数作为 value

3. 脚本

local current current = redis.call("incr",KEYS[1]) 
    if tonumber(current) == 1 
    then redis.call("expire",KEYS[1],60) 
    end

4. 调用执行

redis-cli --eval lua.script keys , args

# 七、基于TCP与HTTP的RPC调用的区别 #

RPC即远程服务调用

出现原因：随着项目越来越大，访问量越来越大，为了突破性能瓶颈，需要将项目拆分成多个部分，这样比起传统的项目都是本地内存调用，分布式的项目之间需要在网络间进行通信

服务之间的远程调用通常有两种方式，即基于TCP的远程调用和基于Http的远程调用

基于TCP的RPC实现  
主要是服务提供方定义socket端口和提供的方法名称已经需要的参数结构，服务调用方通过连接服务方的socket端口，进而调用相关方法，并且将需要通信的数据作为参数传递，需要值得注意的是参数在传递的时候需要在服务调用端进行序列化然后在服务提供端进行反序列化，个人理解就行netty之间的通信方式，就是一种基于tcp的远程调用

基于HTTP的RPC实现  
对于HTTP的RPC实现，本人觉得与现在的restful风格很类似，主要是在服务调用方通过标识请求，GET,POST然后通过url来定位到服务提供方提供的服务，数据通过xml或者json来传输，省去了TCP的序列化和反序列化

区别  
RPC是基于socket通信，在协议层面处于较底层，优点是传输效率高，但是开发难度相对较高，而HTTP处于较高层面，开发难度相对较小，不用维护socket端口和数据序列化相关问题，但是传输效率比起TCP来低了一些

#    八、软件设计的六大原则 #

一、单一职责原则（SRP: Single responsibility principle）

二、开放封闭原则（OCP: Open Closed Principle）

三、里氏替换原则  ( LSP: Liskov Substitution Principle)

四、接口隔离原则（ ISP: Interface Segregation Principle）

五、依赖倒置原则（ DIP: Dependence Inversion Principle）

六、迪米特原则（Law of Demeter）

一、单一职责原则（SRP: Single responsibility principle）  
一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。这样，每个软件模块都有且只有一个需要被改变的理由;

一个模块应该只服务于同一类客户，而不是多种客户。例如：有一个工资计算类，在初期由于公司不同部门之间的工资计算方式是一样的。把这个工资计算类用于计算所有部门的工资，将来公司的技术部工资计算方式变了，而其它部门保持不变。就有可能因为修改了这个工资计算类而影响了其它部门的工资计算。应该为不同的客户创建不同的类。

一个函数应该只提供一种功能，不能创建多功能的函数。例如：一个计算函数既可以计算加法又可以计算减法。

二、开放封闭原则（OCP: Open Closed Principle）  
如果软件系统想要更容易被改变，那么其设计就必须允许增加新的代码来修改系统的行为，而非只能靠修改原来的代码。

也就是说一个类在写完之后就不应该再发生改变（本身业务发生改变和改bug除外）。如果有新的功能加进来，应该可以通过增加新的类来实现。例如：我要实现 “加减乘除” 计算。如果只是简单的写一个类，里面包含“加减乘除”四个函数。这个时候如果需要增加“取余”计算的话，就需要在原来的类上增加“取余”函数。这就违反了开放封闭原则。我们应该创建一个接口，里面包含一个计算函数；然后编写“加减乘除”四个类来实现接口。这样当有“取余”计算方式加进来的时候只需要创建一个新类来实现这个接口就可以了。

三、里氏替换原则  ( LSP: Liskov Substitution Principle)  
如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换；

也就是说子类可以替换父类，且不会对业务产生任何影响。例如父类ParentA 有两个函数Method1 和Method2，子类ChildA继承自父类ParentA且实现了父类的Method1 和Method2函数。而子类ChildB继承自父类ParentA，但是只实现了父类的Method1；这个时候原先的代码是ParentA p = new ChildA();是没有问题的，但是将ChildB替换掉ChildA就可能发生问题了。因为ChildB没有去实现Method2函数；

ChildB中的Method2可能是个空函数；public override void Method2()\{\}

四、接口隔离原则（ ISP: Interface Segregation Principle）  
这项设计原则主要告诫软件设计师应该在设计中避免不必要的依赖。

一个类应该尽量少的把自己的信息透露给客户。应该采用接口的方式来隔离不同的功能函数。例如：ClassA中有20个函数，但是对于同一类客户B只需要用到其中的5个函数，那么应该采用接口Interface的方式来定义这五个函数，让ClassA实现这个接口。这样对于客户B来说就只能看到自己所需要的函数。

五、依赖倒置原则（ DIP: Dependence Inversion Principle）  
该设计原则指出高层策略性的代码不应该依赖实现底层细节的代码，两者都应该依赖抽象。

抽象工厂设计模式就是该设计原则最好的实践。使用抽象工厂类来向客户提供相应的功能。当需求发生改变的时候，只需要增加相应的具体实现代码， 并修改抽象工厂类就可以了， 无需更改客户端和原有的具体实现类的代码。

六、迪米特原则（Law of Demeter）  
又叫做最少知道原则，如果两个类不必彼此直接通信，那么这两个类就不应当直接调用，可以使用代理的方式通过第三方来转发调用。

一个对象应该对其它对象尽可能的少知道，或者说被引用的对象应该尽量不要把别人不需要的成员暴露出去。这就可以降低类与类之间的耦合度。类之间的耦合度越低就越有利于复用。

# 九、Linux中的零拷贝技术 #

本文探讨Linux中**主要的几种零拷贝技术**以及零拷贝技术**适用的场景**。为了迅速建立起零拷贝的概念，我们拿一个常用的场景进行引入：

## 引文\#\# ##

在写一个服务端程序时（Web Server或者文件服务器），文件下载是一个基本功能。这时候服务端的任务是：**将服务端主机磁盘中的文件不做修改地从已连接的socket发出去**，我们通常用下面的代码完成：

while((n = read(diskfd, buf, BUF_SIZE)) > 0)
        write(sockfd, buf , n);

基本操作就是循环的从磁盘读入文件内容到缓冲区，再将缓冲区的内容发送到`socket`。但是由于Linux的`I/O`操作默认是缓冲`I/O`。这里面主要使用的也就是`read`和`write`两个系统调用，我们并不知道操作系统在其中做了什么。实际上在以上`I/O`操作中，发生了多次的数据拷贝。

当应用程序访问某块数据时，操作系统首先会检查，是不是最近访问过此文件，文件内容是否缓存在内核缓冲区，如果是，操作系统则直接根据`read`系统调用提供的`buf`地址，将内核缓冲区的内容拷贝到`buf`所指定的用户空间缓冲区中去。如果不是，操作系统则首先将磁盘上的数据拷贝的内核缓冲区，这一步目前主要依靠`DMA`来传输，然后再把内核缓冲区上的内容拷贝到用户缓冲区中。  
接下来，`write`系统调用再把用户缓冲区的内容拷贝到网络堆栈相关的内核缓冲区中，最后`socket`再把内核缓冲区的内容发送到网卡上。  
说了这么多，不如看图清楚：

![94d9f16b8d0c6e0c9ea44455eab88428.png][]

数据拷贝

从上图中可以看出，共产生了四次数据拷贝，即使使用了`DMA`来处理了与硬件的通讯，CPU仍然需要处理两次数据拷贝，与此同时，在用户态与内核态也发生了多次上下文切换，无疑也加重了CPU负担。

在此过程中，我们没有对文件内容做任何修改，那么在内核空间和用户空间来回拷贝数据无疑就是一种浪费，而零拷贝主要就是为了解决这种低效性。

## 什么是零拷贝技术（zero-copy）？\#\# ##

零拷贝主要的任务就是**避免**CPU将数据从一块存储拷贝到另外一块存储，主要就是利用各种零拷贝技术，避免让CPU做大量的数据拷贝任务，减少不必要的拷贝，或者让别的组件来做这一类简单的数据传输任务，让CPU解脱出来专注于别的任务。这样就可以让系统资源的利用更加有效。

我们继续回到引文中的例子，我们如何减少数据拷贝的次数呢？一个很明显的着力点就是减少数据在内核空间和用户空间来回拷贝，这也引入了零拷贝的一个类型：

让数据传输不需要经过user space

使用mmap\#\#\#\#\#

我们减少拷贝次数的一种方法是调用mmap()来代替read调用：

buf = mmap(diskfd, len);
    write(sockfd, buf, len);

应用程序调用`mmap()`，磁盘上的数据会通过`DMA`被拷贝的内核缓冲区，接着操作系统会把这段内核缓冲区与应用程序共享，这样就不需要把内核缓冲区的内容往用户空间拷贝。应用程序再调用`write()`,操作系统直接将内核缓冲区的内容拷贝到`socket`缓冲区中，这一切都发生在内核态，最后，`socket`缓冲区再把数据发到网卡去。  
同样的，看图很简单：

![38deaad4a319a6a4dce89cda59f6007b.png][]

mmap

使用mmap替代read很明显减少了一次拷贝，当拷贝数据量很大时，无疑提升了效率。但是使用`mmap`是有代价的。当你使用`mmap`时，你可能会遇到一些隐藏的陷阱。例如，当你的程序`map`了一个文件，但是当这个文件被另一个进程截断(truncate)时, write系统调用会因为访问非法地址而被`SIGBUS`信号终止。`SIGBUS`信号默认会杀死你的进程并产生一个`coredump`,如果你的服务器这样被中止了，那会产生一笔损失。

通常我们使用以下解决方案避免这种问题：

1.  **为SIGBUS信号建立信号处理程序**  
    当遇到`SIGBUS`信号时，信号处理程序简单地返回，`write`系统调用在被中断之前会返回已经写入的字节数，并且`errno`会被设置成success,但是这是一种糟糕的处理办法，因为你并没有解决问题的实质核心。
2.  **使用文件租借锁**  
    通常我们使用这种方法，在文件描述符上使用租借锁，我们为文件向内核申请一个租借锁，当其它进程想要截断这个文件时，内核会向我们发送一个实时的`RT_SIGNAL_LEASE`信号，告诉我们内核正在破坏你加持在文件上的读写锁。这样在程序访问非法内存并且被`SIGBUS`杀死之前，你的`write`系统调用会被中断。`write`会返回已经写入的字节数，并且置`errno`为success。

我们应该在`mmap`文件之前加锁，并且在操作完文件后解锁：

if(fcntl(diskfd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
        perror("kernel lease set signal");
        return -1;
    }
    /* l_type can be F_RDLCK F_WRLCK  加锁*/
    /* l_type can be  F_UNLCK 解锁*/
    if(fcntl(diskfd, F_SETLEASE, l_type)){
        perror("kernel lease set type");
        return -1;
    }

使用sendfile\#\#\#\#\#

从2.1版内核开始，Linux引入了`sendfile`来简化操作:

#include<sys/sendfile.h>
    ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

系统调用`sendfile()`在代表输入文件的描述符`in_fd`和代表输出文件的描述符`out_fd`之间传送文件内容（字节）。描述符`out_fd`必须指向一个套接字，而`in_fd`指向的文件必须是可以`mmap`的。这些局限限制了`sendfile`的使用，使`sendfile`只能将数据从文件传递到套接字上，反之则不行。  
使用`sendfile`不仅减少了数据拷贝的次数，还减少了上下文切换，数据传送始终只发生在`kernel space`。

![2e40fb35b24510f82f0e1af955313934.png][]

sendfile系统调用过程

在我们调用`sendfile`时，如果有其它进程截断了文件会发生什么呢？假设我们没有设置任何信号处理程序，`sendfile`调用仅仅返回它在被中断之前已经传输的字节数，`errno`会被置为success。如果我们在调用sendfile之前给文件加了锁，`sendfile`的行为仍然和之前相同，我们还会收到RT\_SIGNAL\_LEASE的信号。

目前为止，我们已经减少了数据拷贝的次数了，但是仍然存在一次拷贝，就是页缓存到socket缓存的拷贝。那么能不能把这个拷贝也省略呢？

借助于硬件上的帮助，我们是可以办到的。之前我们是把页缓存的数据拷贝到socket缓存中，实际上，我们仅仅需要把缓冲区描述符传到`socket`缓冲区，再把数据长度传过去，这样`DMA`控制器直接将页缓存中的数据打包发送到网络中就可以了。

总结一下，`sendfile`系统调用利用`DMA`引擎将文件内容拷贝到内核缓冲区去，然后将带有文件位置和长度信息的缓冲区描述符添加socket缓冲区去，这一步不会将内核中的数据拷贝到socket缓冲区中，`DMA`引擎会将内核缓冲区的数据拷贝到协议引擎中去，避免了最后一次拷贝。

![85d5010d78f06504908ed5b2f4e4acbf.png][]

带DMA的sendfile

不过这一种收集拷贝功能是需要硬件以及驱动程序支持的。

使用splice\#\#\#\#\#

sendfile只适用于将数据从文件拷贝到套接字上，限定了它的使用范围。Linux在`2.6.17`版本引入`splice`系统调用，用于在两个文件描述符中移动数据：

#define _GNU_SOURCE         /* See feature_test_macros(7) */
    #include <fcntl.h>
    ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);

splice调用在两个文件描述符之间移动数据，而不需要数据在内核空间和用户空间来回拷贝。他从`fd_in`拷贝`len`长度的数据到`fd_out`，但是有一方必须是管道设备，这也是目前`splice`的一些局限性。`flags`参数有以下几种取值：

*  **SPLICE\_F\_MOVE** ：尝试去移动数据而不是拷贝数据。这仅仅是对内核的一个小提示：如果内核不能从`pipe`移动数据或者`pipe`的缓存不是一个整页面，仍然需要拷贝数据。Linux最初的实现有些问题，所以从`2.6.21`开始这个选项不起作用，后面的Linux版本应该会实现。
 *  \*\* SPLICE\_F\_NONBLOCK\*\* ：`splice` 操作不会被阻塞。然而，如果文件描述符没有被设置为不可被阻塞方式的 I/O ，那么调用 splice 有可能仍然被阻塞。
 *  \*\* SPLICE\_F\_MORE\*\*： 后面的`splice`调用会有更多的数据。

splice调用利用了Linux提出的管道缓冲区机制， 所以至少一个描述符要为管道。

以上几种零拷贝技术都是减少数据在用户空间和内核空间拷贝技术实现的，但是有些时候，数据必须在用户空间和内核空间之间拷贝。这时候，我们只能针对数据在用户空间和内核空间拷贝的时机上下功夫了。Linux通常利用**写时复制(copy on write)**来减少系统开销，这个技术又时常称作`COW`。

由于篇幅原因，本文不详细介绍写时复制。大概描述下就是：如果多个程序同时访问同一块数据，那么每个程序都拥有指向这块数据的指针，在每个程序看来，自己都是独立拥有这块数据的，只有当程序需要对数据内容进行修改时，才会把数据内容拷贝到程序自己的应用空间里去，这时候，数据才成为该程序的私有数据。如果程序不需要对数据进行修改，那么永远都不需要拷贝数据到自己的应用空间里。这样就减少了数据的拷贝。写时复制的内容可以再写一篇文章了。。。

除此之外，还有一些零拷贝技术，比如传统的Linux I/O中加上`O_DIRECT`标记可以直接`I/O`，避免了自动缓存，还有尚未成熟的`fbufs`技术，本文尚未覆盖所有零拷贝技术，只是介绍常见的一些，如有兴趣，可以自行研究，一般成熟的服务端项目也会自己改造内核中有关I/O的部分，提高自己的数据传输速率。

# 十、跳跃表和链表的区别 #

没法说 - 梳理下

[linux]: https://www.cnblogs.com/shigfdengys/p/11164615.html
[5814854234b6d3131955bbcdfc344fcc.png]: /images/20221005/2831941bf094469f84835a8b1f038d3f.png
[0c8d55c6dc30a82bbbdcb352e1fcbb95.png]: /images/20221005/6776abdeb50642e685ef36f286737aa5.png
[5b896e77087cfb14c98ed3c0d12f3c4a.png]: /images/20221005/bc132d4249ec467794bb34edec419194.png
[Redis]: https://www.cnblogs.com/williamjie/p/11250679.html
[2739e723931b1416040a42a9c6386c3d.png]: /images/20221005/4cd11be3e24046c7a99f25625077fc24.png
[c8d1685eb2f1e952f1f230931b3fc5a0.png]: /images/20221005/b0210790c7f84f6e80b917d5aef165cf.png
[023f122ee8b715df11256c784dc198e8.png]: /images/20221005/11c0ba45760645cc8cf2fd180d4a6e6c.png
[e20058e094106f58237f11903fba3365.png]: /images/20221005/d8709ea4a7b749c1a0b849e13609d2e6.png
[f01ab5f99a6e78ec520d9bec3c1a2855.png]: /images/20221005/fdf40f5680d642b39d83f1cde6cd3d50.png
[767fc896ff8397a6dfde05e37358acb7.png]: /images/20221005/46e10749983a412c800ed1843591e3f0.png
[94d9f16b8d0c6e0c9ea44455eab88428.png]: /images/20221005/e9d02f59de3f48b292bd5e6ac021e82b.png
[38deaad4a319a6a4dce89cda59f6007b.png]: /images/20221005/66cc8d6cc37c4297b3a950361b09fa66.png
[2e40fb35b24510f82f0e1af955313934.png]: /images/20221005/cc41c64299444bc6b00be2739178f9dd.png
[85d5010d78f06504908ed5b2f4e4acbf.png]: /images/20221005/aa17ad3e7eff4499b7b4884880913b18.png