面试：第二章：各种框架和中间件以及缓存数据库，面试题目100题

最新推荐文章于 2024-09-20 09:09:17 发布

2401_84412912

最新推荐文章于 2024-09-20 09:09:17 发布

阅读量922

点赞数 14

分类专栏： 2024年程序员学习文章标签：面试中间件缓存

本文链接：https://blog.csdn.net/2401_84412912/article/details/137986159

版权

2024年程序员学习专栏收录该内容

35 篇文章 0 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

Sql语句优化

缓存服务器（提高查询效率，减轻数据库压力）

搜索服务器（提高查询效率，减轻数据库压力）

图片服务器分离

2）项目层

采用面向服务分布式架构（分担服务器压力，提高并发能力）

采用并发访问较高的详情系统采用静态页面，HTML静态化 freemaker

使用页面缓存

用ActiveMQ使得业务进一步进行解耦，提高业务处理能力

使用分布式文件系统存储海量文件

3）应用层

Nginx服务器来做负载均衡

Lvs做二层负载

镜像

高可用:

目的：保证服务器硬件故障服务依然可用，数据依然保存并能够被访问。

高可用的服务

①分级管理：核心应用和服务具有更高的优先级，比如用户及时付款比能否评价商品更重要；

②超时设置：设置服务调用的超时时间,一旦超时,通信框架抛出异常,应用程序则根据服务调度策略选择重试or请求转移到其他服务器上

③异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

不是所有服务都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于

那些必须确认服务调用成功后才能继续进行下一步的操作的应用也不适合异步调用。

④服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对服务降级。

降级有两种手段：

一是拒绝服务，拒绝较低优先级的应用的调用，减少服务调用并发数，确保核心应用的正常运行；

二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源；

⑤幂等性设计：保证服务重复调用和调用一次产生的结果相同；

高可用的数据

保证数据高可用的主要手段有两种：一是数据备份，二是失效转移机制；

①数据备份：又分为冷备份和热备份，冷备份是定期复制，不能保证数据可用性。热备份又分为异步热备

和同步热备，异步热备是指多份数据副本的写入操作异步完成，而同步方式则是指多份数据副本的写入操作同时完成。

②失效转移：若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都

要重新路由到其他服务器，保证数据访问不会失败。

网站运行监控

”不允许没有监控的系统上线“

（1）监控数据采集

①用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具；

②服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO等，及时判断，防患于未然；

③运行数据报告：采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑；

（2）监控管理

①系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知；

②失效转移：监控系统在发现故障时，主动通知应用进行失效转移；

③自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正

常运行；—>网站柔性架构的理想状态

负载均衡:

什么是负载均衡？

当一台服务器的性能达到极限时，我们可以使用服务器集群来提高网站的整体性能。那么，在服务器集群

中，需要有一台服务器充当调度者的角色，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负

载情况将请求分配给某一台后端服务器去处理。

（1）HTTP重定向负载均衡。

原理：当用户向服务器发起请求时，请求首先被集群调度者截获；调度者根据某种分配策略，选择一台服务

器，并将选中的服务器的IP地址封装在HTTP响应消息头部的Location字段中，并将响应消息的状态码设为

302，最后将这个响应消息返回给浏览器。当浏览器收到响应消息后，解析Location字段，并向该URL发起请

求，然后指定的服务器处理该用户的请求，最后将结果返回给用户。

优点：比较简单

缺点：调度服务器只在客户端第一次向网站发起请求的时候起作用。当调度服务器向浏览器返回响应信息后，

客户端此后的操作都基于新的URL进行的(也就是后端服务器)，此后浏览器就不会与调度服务器产生关系，浏

览器需要每次请求两次服务器才能拿完成一次访问，性能较差。而且调度服务器在调度时，无法知道当前用户

将会对服务器造成多大的压力，只不过是把请求次数平均分配给每台服务器罢了，浏览器会与后端服务器直接交互。

（2）DNS域名解析负载均衡

原理：为了方便用户记忆，我们使用域名来访问网站。通过域名访问网站之前，首先需要将域名解析成IP地

址，这个工作是由DNS域名服务器完成的。我们提交的请求不会直接发送给想要访问的网站，而是首先发给域名

服务器，它会帮我们把域名解析成IP地址并返回给我们。我们收到IP之后才会向该IP发起请求。一个域名指向

多个IP地址，每次进行域名解析时，DNS只要选一个IP返回给用户，就能够实现服务器集群的负载均衡。

调度策略：一般DNS提供商会提供一些调度策略供我们选择，如随机分配、轮询、根据请求者的地域分配离他最近的服务器。

随机分配策略：

当调度服务器收到用户请求后，可以随机决定使用哪台后端服务器，然后将该服务器的IP封装在HTTP响应消息

的Location属性中，返回给浏览器即可。

轮询策略(RR) ：

调度服务器需要维护一个值，用于记录上次分配的后端服务器的IP。那么当新的请求到来时，调度者将请求依

次分配给下一台服务器。

优点：配置简单，将负载均衡工作交给DNS，省略掉了网络管理的麻烦；

缺点：集群调度权交给了DNS服务器，从而我们没办法随心所欲地控制调度者，没办法定制调度策略，没办法了

解每台服务器的负载情况，只不过把所有请求平均分配给后端服务器罢了。某一台后端服务器发生故障时，即

使我们立即将该服务器从域名解析中去除，但由于DNS服务器会有缓存，该IP仍然会在DNS中保留一段时间，那

么就会导致一部分用户无法正常访问网站。不过动态DNS能够让我们通过程序动态修改DNS服务器中的域名解

析。从而当我们的监控程序发现某台服务器挂了之后，能立即通知DNS将其删掉。

（3）反向代理负载均衡。

原理：反向代理服务器是一个位于实际服务器之前的服务器，所有向我们网站发来的请求都首先要经过反向代

理服务器，服务器根据用户的请求要么直接将结果返回给用户，要么将请求交给后端服务器处理，再返回给用

户。反向代理服务器就可以充当服务器集群的调度者，它可以根据当前后端服务器的负载情况，将请求转发给

一台合适的服务器，并将处理结果返回给用户。

优点：

1.部署简单

2.隐藏后端服务器：与HTTP重定向相比，反向代理能够隐藏后端服务器，所有浏览器都不会与后端服务器直接

交互，从而能够确保调度者的控制权，提升集群的整体性能。

3.故障转移：与DNS负载均衡相比，反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出

现故障时，能够及时通知反向代理服务器，并立即将其删除。

4.合理分配任务：HTTP重定向和DNS负载均衡都无法实现真正意义上的负载均衡，也就是调度服务器无法根据

后端服务器的实际负载情况分配任务。但反向代理服务器支持手动设定每台后端服务器的权重。我们可以根据

服务器的配置设置不同的权重，权重的不同会导致被调度者选中的概率的不同。

缺点：

1.调度者压力过大：由于所有的请求都先由反向代理服务器处理，那么当请求量超过调度服务器的最大负载

时，调度服务器的吞吐率降低会直接降低集群的整体性能。

2.制约扩展：当后端服务器也无法满足巨大的吞吐量时，就需要增加后端服务器的数量，可没办法无限量地增

加，因为会受到调度服务器的最大吞吐量的制约。

3.粘滞会话：反向代理服务器会引起一个问题。若某台后端服务器处理了用户的请求，并保存了该用户的

session或存储了缓存，那么当该用户再次发送请求时，无法保证该请求仍然由保存了其Session或缓存的服

务器处理，若由其他服务器处理，先前的Session或缓存就找不到了。

解决办法1：可以修改反向代理服务器的任务分配策略，以用户IP作为标识较为合适。相同的用户IP会交由同

一台后端服务器处理，从而就避免了粘滞会话的问题。

解决办法2：可以在Cookie中标注请求的服务器ID，当再次提交请求时，调度者将该请求分配给Cookie中标

注的服务器处理即可。

（4）IP负载均衡。

1.通过NAT实现负载均衡：响应报文一般比较大，每一次都需要NAT转换的话，大流量的时候，会导致调度器成为一个瓶颈。

2.通过直接路由实现负载均衡

3.VS/TUN 实现虚拟服务器

优点：IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。

缺点：负载均衡的网卡带宽成为系统的瓶颈，场景：某个服务器跑的应用非高峰期间都能达到500M以

上，晚高峰一般能够超过1G，主流服务器的网卡都是千兆的，超过1G的流量明显会导致丢包的问题，此时又不

能停止业务对网卡进行更换。

（5）数据链路层负载均衡。

对于linux系统来说，数据链路层的解决方案就是实现多个网卡绑定联合提供服务，把多张网卡捆绑做成一个

逻辑网卡。避免负载均衡服务器网卡带宽成为瓶颈，是目前大型网站所使用的最广的一种负载均衡手段。

linux bonding的七种模式，mod=0~6：平衡抡循环策略，主-备份策略，平衡策略，广播策略，动态链接聚

合，适配器传输负载均衡，适配器适应性负载均衡

讲讲你是怎么优化数据库（sql，表的设计）以及索引的使用有哪些限制条件（索引失效）

=============================================

a,选取最适用的字段：在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。另外一

个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOTNULL，

b,使用连接（JOIN）来代替子查询(Sub-Queries)

c,使用联合(UNION)来代替手动创建的临时表

d,事物：

a)要么语句块中每条语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整

性。事物以BEGIN关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以

把数据库恢复到BEGIN开始之前的状态。

b) 是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方

式，这样可以保证用户的操作不被其它的用户所干扰。

e,减少表关联，加入冗余字段

f,使用外键：锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。

g,使用索引

h,优化的查询语句

i，集群

j，读写分离

k，主从复制

l，分表

m，分库

o，适当的时候可以使用存储过程

限制：尽量用全职索引，最左前缀：查询从索引的最左前列开始并且不跳过索引中的列；索引列上不操作，范围之

后全失效；不等空值还有OR，索引影响要注意；like以通配符%开头索引失效会变成全表扫描的操作，字符串不

加单引号索引失效

讲讲Redis缓存，它的数据类型，和其他缓存之间的区别，及持久化，缓存穿透与雪崩它的解决方案

==================================================

redis是内存中的数据结构存储系统，一个key-value类型的非关系型数据库，可持久化的数据库，相对于关

系型数据库（数据主要存在硬盘中），性能高，因此我们一般用redis来做缓存使用；并且redis支持丰富的数

据类型，比较容易解决各种问题，因此redis可以用来作为注册中心，数据库、缓存和消息中间件。Redis的

Value支持5种数据类型，string、hash、list、set、zset（sorted set）;

String类型：一个key对应一个value

Hash类型：它的key是string类型，value又是一个map（key-value），适合存储对象。

List类型：按照插入顺序的字符串链表（双向链表），主要命令是LPUSH和RPUSH，能够支持反向查找和遍历

Set类型：用哈希表类型的字符串序列，没有顺序，集合成员是唯一的，没有重复数据，底层主要是由一个

value永远为null的hashmap来实现的。

zset类型：和set类型基本一致，不过它会给每个元素关联一个double类型的分数（score），这样就可以为

成员排序，并且插入是有序的。

Memcache和redis的区别：

数据支持的类型：redis不仅仅支持简单的k/v类型的数据，同时还支持list、set、zset、hash等数据结构

的存储；memcache只支持简单的k/v类型的数据，key和value都是string类型

可靠性：memcache不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的；redis支持数据持久

化和数据恢复，允许单点故障，但是同时也会付出性能的代价

性能上：对于存储大数据，memcache的性能要高于redis

应用场景：

Memcache：适合多读少写，大数据量的情况（一些官网的文章信息等）

Redis：适用于对读写效率要求高、数据处理业务复杂、安全性要求较高的系统

案例：分布式系统，存在session之间的共享问题，因此在做单点登录的时候，我们利用redis来模拟了

session的共享，来存储用户的信息，实现不同系统的session共享；

redis的持久化方式有两种：

RDB（半持久化方式）：按照配置不定期的通过异步的方式、快照的形式直接把内存中的数据持久化到磁盘的一

个dump.rdb文件（二进制的临时文件）中，redis默认的持久化方式，它在配置文件（redis.conf）中。

优点：只包含一个文件，将一个单独的文件转移到其他存储媒介上，对于文件备份、灾难恢复而言，比较实用。

缺点：系统一旦在持久化策略之前出现宕机现象，此前没有来得及持久化的数据将会产生丢失

AOF（全持久化的方式）：把每一次数据变化都通过write()函数将你所执行的命令追加到一个appendonly.aof文件里面，

Redis默认是不支持这种全持久化方式的，需要在配置文件（redis.conf）中将

appendonly no改成appendonly yes

优点：数据安全性高，对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机问题，也

不会破坏日志文件中已经存在的内容；

缺点：对于数量相同的数据集来说，aof文件通常要比rdb文件大，因此rdb在恢复大数据集时的速度大于AOF；

AOF持久化配置:

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会都调用fsync刷新到aof文件，非常慢，但是安全；

appendfsync everysec #每秒钟都调用fsync刷新到aof文件中，很快，但是可能丢失一秒内的数据，推荐使用，兼顾了速度和安全；

appendfsync no #不会自动同步到磁盘上，需要依靠OS（操作系统）进行刷新，效率快，但是安全性就比较差；

二种持久化方式区别：

AOF在运行效率上往往慢于RDB，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效；

如果缓存数据安全性要求比较高的话，用aof这种持久化方式（比如项目中的购物车）；

如果对于大数据集要求效率高的话，就可以使用默认的。而且这两种持久化方式可以同时使用。

redis-cluster集群，这种方式采用的是无中心结构，每个节点保存数据和整个集群的状态，每个节点都和其

他所有节点连接。如果使用的话就用redis-cluster集群。集群这块是公司运维搭建的，具体怎么搭建不是太了解。

我们项目中redis集群主要搭建了6台，3主（为了保证redis的投票机制）3从（高可用），每个主服务器都有

一个从服务器，作为备份机。所有的节点都通过PING-PONG机制彼此互相连接；客户端与redis集群连接，只

需要连接集群中的任何一个节点即可；Redis-cluster中内置了16384个哈希槽，Redis-cluster把所有的物

理节点映射到【0-16383】slot上，负责维护。

Redis是有事务的，redis中的事务是一组命令的集合，这组命令要么都执行，要不都不执行，保证一个事务中

的命令依次执行而不被其他命令插入。redis的事务是不支持回滚操作的。redis事务的实现，需要用到

MULTI（事务的开始）和EXEC（事务的结束）命令 ;

缓存穿透：缓存查询一般都是通过key去查找value，如果不存在对应的value，就要去数据库中查找。如果这

个key对应的value在数据库中也不存在，并且对该key并发请求很大，就会对数据库产生很大的压力，这就叫缓存穿透

解决方案：

1.对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。

2.将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从

而避免了对底层存储系统的查询压力。

3.如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但

它的过期时间会很短，最长不超过五分钟。

缓存雪崩：当缓存服务器重启或者大量缓存集中在一段时间内失效，发生大量的缓存穿透，这样在失效的瞬间

对数据库的访问压力就比较大，所有的查询都落在数据库上，造成了缓存雪崩。这个没有完美解决办法，但可

以分析用户行为，尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线

程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。

解决方案：

1.在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询

数据和写缓存，其他线程等待。

2.可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存

3.不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

4.做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间

设置为短期，A2设置为长期。

redis的安全机制（你们公司redis的安全这方面怎么考虑的？）

漏洞介绍：redis默认情况下，会绑定在bind 0.0.0.0:6379，这样就会将redis的服务暴露到公网上，如果

在没有开启认证的情况下，可以导致任意用户在访问目标服务器的情况下，未授权就可访问redis以及读取

redis的数据，攻击者就可以在未授权访问redis的情况下可以利用redis的相关方法，成功在redis服务器上

写入公钥，进而可以直接使用私钥进行直接登录目标主机；

解决方案：

1.禁止一些高危命令。修改redis.conf文件，用来禁止远程修改DB文件地址

2.以低权限运行redis服务。为redis服务创建单独的用户和根目录，并且配置禁止登录；

3.为redis添加密码验证。修改redis.conf文件，添加requirepass mypassword；

4.禁止外网访问redis。修改redis.conf文件，添加或修改 bind 127.0.0.1，使得redis服务只在当前主机使用；

5.做log监控，及时发现攻击；

redis的哨兵机制（redis2.6以后出现的）

哨兵机制：

监控：监控主数据库和从数据库是否正常运行；

提醒：当被监控的某个redis出现问题的时候，哨兵可以通过API向管理员或者其他应用程序发送通知；

自动故障迁移：主数据库出现故障时，可以自动将从数据库转化为主数据库，实现自动切换；

如果master主服务器设置了密码，记得在哨兵的配置文件（sentinel.conf）里面配置访问密码

redis中对于生存时间的应用

Redis中可以使用expire命令设置一个键的生存时间，到时间后redis会自动删除；

应用场景：

设置限制的优惠活动的信息；

一些及时需要更新的数据，积分排行榜；

手机验证码的时间；

限制网站访客访问频率；

讲讲ActiveMQ和其他消息中间件之间的区别

===========================

activemq的原理

原理：生产者生产消息，把消息发送给activemq。 Activemq 接收到消息，然后查看有多少个消费者，

然后把消息转发给消费者，此过程中生产者无需参与。消费者接收到消息后做相应的处理和生产者没有任何关系

对比RabbitMQ

RabbitMQ的协议是AMQP，而ActiveMQ使用的是JMS协议。顾名思义JMS是针对Java体系的传输协议，队列两

端必须有JVM，所以如果开发环境都是java的话推荐使用ActiveMQ，可以用Java的一些对象进行传递比如

Map、Blob（二进制大数据）、Stream等。而AMQP通用行较强，非java环境经常使用，传输内容就是标准字

符串。RabbitMQ安装比较麻烦。ActiveMQ解压即可用不用任何安装。

对比KafKa

Kafka性能超过ActiveMQ等传统MQ工具，集群扩展性好。

弊端是：

1、在传输过程中可能会出现消息重复的情况，

2、不保证发送顺序

3、一些传统MQ的功能没有，比如消息的事务功能。所以通常用Kafka处理大数据日志。

对比Redis

其实Redis本身利用List可以实现消息队列的功能，但是功能很少，而且队列体积较大时性能会急剧下降。对

于数据量不大、业务简单的场景可以使用。

如何解决消息重复问题

所谓消息重复,就是消费者接收到了重复的消息,一般来说我们对于这个问题的处理要把握下面几点,

①.消息不丢失(上面已经处理了)

②.消息不重复执行

一般来说我们可以在业务段加一张表,用来存放消息是否执行成功,每次业务事物commit之后,告知服务端,已经

处理过该消息,这样即使你消息重发了,也不会导致重复处理

大致流程如下:业务端的表记录已经处理消息的id,每次一个消息进来之前先判断该消息是否执行过,如果执行

过就放弃,如果没有执行就开始执行消息,消息执行完成之后存入这个消息的id

讲讲分布式事务的异步通信问题解决方案

==================

问题介绍：一个消息发送过去了，不管结果如何发送端都不会原地等待接收端。直到接收端再推送回来回执消息，

发送端才直到结果。但是也有可能发送端消息发送后，石沉大海，杳无音信。这时候就需要一种机制能够对这种不

确定性进行补充。

解决方案：

你给有很多笔友，平时写信一去一回，但是有时候会遇到迟迟没有回信的情况。那么针对这种偶尔出现的情况，你

可以选择两种策略。一种方案是你发信的时候用定个闹钟，设定1天以后去问一下对方收没收到信。另一种方案就

是每天夜里定个时间查看一下所有发过信但是已经一天没收到回复的信。然后挨个打个电话问一下。

第一种策略就是实现起来就是延迟队列，第二种策略就是定时轮询扫描。

二者的区别是延迟队列更加精准，但是如果周期太长，任务留在延迟队列中时间的就会非常长，会把队列变得冗

长。比如用户几天后待办提醒，生日提醒。

那么如果遇到这种长周期的事件，而且并不需要精确到分秒级的事件，可以利用定时扫描来实现，尤其是比较消耗

性能的大范围扫描，可以安排到夜间执行。

**讲讲怎么解****单点登录的访问，**分布式session跨域问题

=======================================

单点登录是相互信任的系统模块登录一个模块后，其他模块不需要重复登录即认证通过。

采用CAS单点登录框架，首先CAS有两大部分：客户端和服务端。

服务端就是一个web工程部署在tomcat中。在服务端完成用户认证操作。每次访问系统模块时，需要去CAS完成获

取ticket。当验证通过后，访问继续操作。对于CAS服务端来说，我们访问的应用模块就是CAS客户端。

什么是跨域？

当异步请求时，访问的请求地址的协议、ip地址、端口号任意一个与当前站点不同时，就会涉及跨域访问。

什么时候涉及跨域问题？当涉及前端异步请求的时候才涉及跨域。

解决方案：

1、jQuery提供了jsonp实现

2、W3C标准提供了CORS（跨域资源共享）解决方案。

用了CAS，所有应用项目中如果需要登录时在web.xml中配置过滤器做请求转发到cas端工作原理是在cas登录后会

给浏览器发送一个票据（ticket），浏览器cookie中会缓存这个ticket，在登录其他项目时会拿着浏览器的

ticket转发到cas，到cas后根据票据判断是否登录

讲讲linux命令awk、cat、sort、cut、grep、uniq、wc、top、find、sed等作用

==========================================================

awk:相较于sed 常常作用于一整个行的处理，awk 则比较倾向于一行当中分成数个『字段』来处理。因此，awk

相当的适合处理小型的数据数据处理

cat:主要用来查看文件内容，创建文件，文件合并，追加文件内容等功能。

sort:功能：排序文本，默认对整列有效

cut:cut命令可以从一个文本文件或者文本流中提取文本列

grep:是一种强大的文本搜索工具，它能使用正则表达式搜索文本，并把匹配的行打印出来

uniq:功能：去除重复行，只会统计相邻的

wc:功能：统计文件行数、字节、字符数

top:用来监控Linux的系统状况,比如cpu、内存的使用

find:功能：搜索文件目录层次结构

sed:sed 是一种在线编辑器，它一次处理一行内容

**讲讲什么是死锁，怎么解决死锁，****表级锁和行级锁，**悲观锁与乐观锁以及线程同步锁区别

===================================================

死锁：打个比方，你去面试，面试官问你，你告诉我什么是死锁我就让你进公司。你回答说你让我进公司我就告诉你什么是死锁

互斥条件：资源不能被共享，只能由一个进程使用。

请求与保持条件：进程已获得了一些资源，但因请求其它资源被阻塞时，对已获得的资源保持不放。

不可抢占条件：有些系统资源是不可抢占的，当某个进程已获得这种资源后，系统不能强行收回，只能由进程

使用完时自己释放。

循环等待条件：若干个进程形成环形链，每个都占用对方申请的下一个资源。

(1) 死锁预防：破坏导致死锁必要条件中的任意一个就可以预防死锁。例如，要求用户申请资源时一次性申请

所需要的全部资源，这就破坏了保持和等待条件；将资源分层，得到上一层资源后，才能够申请下一层资源，

它破坏了环路等待条件。预防通常会降低系统的效率。

(2) 死锁避免：避免是指进程在每次申请资源时判断这些操作是否安全，例如，使用银行家算法。死锁避免算

法的执行会增加系统的开销。

(3) 死锁检测：死锁预防和避免都是事前措施，而死锁的检测则是判断系统是否处于死锁状态，如果是，则执

行死锁解除策略。

(4) 死锁解除：这是与死锁检测结合使用的，它使用的方式就是剥夺。即将某进程所拥有的资源强行收回，分

配给其他的进程。

表级锁：开销小，加锁快；不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁)；锁定粒度大，发生锁冲

突的概率最高,并发度最低。

行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样

别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁

等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观

锁。通过for update来实现

乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会

判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以

提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中

java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。通过version版本字段来实现

同步锁：

场景：在开发中,遇到耗时的操作,我们需要把耗时的逻辑放入子线程中执行,防止卡顿。二个线程分别执行两个

任务，同时执行完成,同时解析文件,获取数据后,同时插入数据库,由于插入的表比较多，这样容易出现插入错

乱的bug

采用synchronized：

声明该方法为同步方法,如果一个方法正在执行,别的方法调用,则处于等待状态。当这个方法执行完成后,可以

调用解锁方法,wait():释放占有的对象锁，线程进入等待池。

区别：

synchronized是在JVM层面实现的,因此系统可以监控锁的释放与否,而ReentrantLock使用代码实现的,系统

无法自动释放锁,需要在代码中finally子句中显式释放锁lock.unlock();

在并发量比较小的情况下，使用synchronized是个不错的选择，但是在并发量比较高的情况下，其性能下降

很严重，此时ReentrantLock是个不错的方案。

讲讲怎么加快访问速度，怎样进行程序性能调优

=================================

加快访问：

硬件上加大网络带宽、和服务器内存

代码的处理：静态页面、缓存、优化sql、创建索引等方案

系统性能就是两个事：

Throughput ，吞吐量。也就是每秒钟可以处理的请求数，任务数。

Latency，系统延迟。也就是系统在处理一个请求或一个任务时的延迟。

那么Latency越好，能支持的Throughput就会越高。因为Latency短说明处理速度快，于是就可以处理更多的请求。

提高吞吐量：分布式集群，模块解藕，设计模式

系统延迟：异步通信

讲讲缓存的设计和优化，缓存和数据库一致性同步解决方案

==============================

1.降低后端负载：对于高消耗的SQL：join结果集、分组统计结果；对这些结果进行缓存。

2.加速请求响应

3.大量写合并为批量写：如计数器先redis累加再批量写入DB

4.超时剔除：例如expire

5.主动更新：开发控制生命周期（最终一致性，时间间隔比较短）

6.缓存空对象

7.布隆过滤器拦截

8.命令本身的效率：例如sql优化，命令优化

9.网络次数：减少通信次数

10.降低接入成本:长连/连接池,NIO等。

11.IO访问合并

目的：要减少缓存重建次数、数据尽可能一致、减少潜在危险。

解决方案：

1.互斥锁setex,setnx：

如果 set(nx 和 ex) 结果为 true，说明此时没有其他线程重建缓存，那么当前线程执行缓存构建逻辑。

如果 setnx(nx 和 ex) 结果为 false，说明此时已经有其他线程正在执行构建缓存的工作，那么当前线程将休

息指定时间 ( 例如这里是 50 毫秒，取决于构建缓存的速度 ) 后，重新执行函数，直到获取到数据。

2永远不过期：

热点key,无非是并发特别大一级重建缓存时间比较长，如果直接设置过期时间，那么时间到的时候，巨大的访

问量会压迫到数据库上，所以要给热点key的val增加一个逻辑过期时间字段，并发访问的时候，判断这个逻辑

字段的时间值是否大于当前时间，大于了说明要对缓存进行更新了，那么这个时候，依然让所有线程访问老的

缓存，因为缓存并没有设置过期，但是另开一个线程对缓存进行重构。等重构成功，即执行了redis set操作

之后，所有的线程就可以访问到重构后的缓存中的新的内容了

从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是“物理”不过期。

从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

一致性问题：

1.先删除缓存，然后在更新数据库，如果删除缓存失败，那就不要更新数据库，如果说删除缓存成功，而更新

数据库失败，那查询的时候只是从数据库里查了旧的数据而已，这样就能保持数据库与缓存的一致性。

2.先去缓存里看下有没有数据，如果没有，可以先去队列里看是否有相同数据在做更新，发现队列里有一个请

求了，那么就不要放新的操作进去了，用一个while（true）循环去查询缓存，循环个200MS左右再次发送到

队列里去，然后同步等待缓存更新完成。

讲讲消息队列和消息被重复消费怎么处理，消费者接收不到消息怎么办

===========================================

什么是消息队列？

就是消息的传输过程中保存消息的容器。

消息队列都解决了什么问题？

异步，并行，解耦，排队

消息模式？

订阅，点对点

一、重复消费：Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

二、丢消息：

1.用持久化消息

2.非持久化消息及时处理不要堆积

3.启动事务，启动事务后，commit()方法会负责等待服务器的返回，也就不会关闭连接导致消息丢失。

三、消息重发：

消息被重新传递给客户端：

1、使用事务会话，并调用滚退（）。

2、在调用commit()之前关闭事务会话。

3、会话使用CLIENT_ACKNOWLEDGE签收模式，并Session .recover()重发被调用。

4、客户端连接超时（也许正在执行的代码要比配置的超时周期更长）。

四、不消费：去ActiveMQ.DLQ里找找

什么是ActiveMQ.DLQ？

1.一旦消息的重发尝试超过了为重发策略配置的最大重发次数，一个“Poison ACK”被发送回the broker，让

最后总结

ActiveMQ+Kafka+RabbitMQ学习笔记PDF

RabbitMQ实战指南

手写RocketMQ笔记

手写“Kafka笔记”

关于分布式，限流+缓存+缓存，这三大技术（包含：ZooKeeper+Nginx+MongoDB+memcached+Redis+ActiveMQ+Kafka+RabbitMQ）等等。这些相关的面试也好，还有手写以及学习的笔记PDF，都是啃透分布式技术必不可少的宝藏。以上的每一个专题每一个小分类都有相关的介绍，并且小编也已经将其整理成PDF啦

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）