先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注Java）
正文
class A extends Thread{
public void run(){
for(int i=1;i<=100;i++){
System.out.println(“-----------------”+i);
}
}
}
A a = new A();
a.start();
实现Runnable接口，并实现里面的run方法
class B implements Runnable{
public void run(){
for(int i=1;i<=100;i++){
System.out.println(“-----------------”+i);
}
}
}
B b = new B();
Thread t = new Thread(b);
t.start();
实现Callable
class A implements Callable{
public String call() throws Exception{
//…
}
}
FutureTask ft = new FutureTask<>(new A());
new Thread(ft).start();
线程池
ExcutorService es = Executors.newFixedThreadPool(10);
es.submit(new Runnable(){//任务});
es.submit(new Runnable(){//任务});
…
es.shutdown();
实现Runnable和实现Callable的区别？
实现Callable接口，任务可以有返回值，Runnable没有。
实现Callable接口，可以指定泛型，Runnable没有。
实现Callable接口，可以在call方法中声明异常，Runnable没有。
Runnable和Thread二者的区别？
实现Runnable接口的方式，更适合处理有共享资源的情况。
实现Runnable接口的方式，避免了单继承的局限性。
Java自定义类加载器与双亲委派模型
==================
启动类加载器（Bootstrap）C++
扩展类加载器（Extension）Java
应用程序类加载器（AppClassLoader）Java
双亲委派模型工作原理：如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请
求委派给父类加载器完成。每个类加载器都是如此，只有当父加载器在自己的搜索范围内找不到指定的类时（即
ClassNotFoundException），子加载器才会尝试自己去加载。
讲讲jvm的组成与调优，内存模型，GC，tomcat调优
================================
tomcat调优：
增加JVM堆内存大小
修复JRE内存泄漏
线程池设置
压缩
数据库性能调优
Tomcat本地库
JVM调优：
-Xms – 指定初始化时化的堆内存，默认为物理内存的1/64
-Xmx – 指定最大的内存,默认为物理内存的1/4
-XX:+PrintGCDetails：输出详细的GC处理日志
在重启你的Tomcat服务器之后，这些配置的更改才会有效。
讲讲高可用的数据与服务怎么实现，负载均衡策略以及区别，分布式（及事物），集群，高并发以及遇到的问题和解决方案
==========================================================
分布式 :
分布式架构：把系统按照模块拆分成多个子系统，多个子系统分布在不同的网络计算机上相互协作完成业务流
程，系统之间需要进行通信。
优点：
把模块拆分，使用接口通信，降低模块之间的耦合度。
把项目拆分成若干个子项目，不同的团队负责不同的子项目。
增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
可以灵活的进行分布式部署。
缺点：
1、系统之间交互需要使用远程通信，接口开发增加工作量。
2、各个模块有一些通用的业务逻辑无法共用。
基于soa的架构
SOA：面向服务的架构。也就是把工程拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提
供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
分布式架构和soa架构有什么区别？
SOA，主要还是从服务的角度，将工程拆分成服务层、表现层两个工程。
分布式，主要还是从部署的角度，将应用按照访问压力进行归类，主要目标是充分利用服务器的资源，避免资源分配不均
集群:
一个集群系统是一群松散结合的服务器组，形成一个虚拟的服务器，为客户端用户提供统一的服务。对于这个
客户端来说，通常在访问集群系统时不会意识到它的服务是由具体的哪一台服务器提供。集群的目的，是为实
现负载均衡、容错和灾难恢复。以达到系统可用性和可伸缩性的要求。集群系统一般应具高可用性、可伸缩
性、负载均衡、故障恢复和可维护性等特殊性能。一般同一个工程会部署到多台服务器上。
常见的tomcat集群，Redis集群，Zookeeper集群，数据库集群
分布式与集群的区别：
分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起，实现同一业务。一句
话：分布式是并联工作的，集群是串联工作的。
分布式中的每一个节点，都可以做集群。 而集群并不一定就是分布式的。
举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一
业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。
而分布式，从窄意上理解，也跟集群差不多， 但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，
其它的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。
分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
举例：如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行该任务需10小
时。采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执
行完，这个任务只需一个小时。(这种工作模式的一个典型代表就是Hadoop的Map/Reduce分布式计算模型）
而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个
服务器将同时工作，1小时后，10个任务同时完成，这样，整身来看，还是1小时内完成一个任务！
高并发:
处理高并发常见的方法有哪些？
1）数据层
数据库集群和库表散列
分表分库
开启索引
开启缓存
表设计优化
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地址、端口号任意一个与当前站点不同时，就会涉及跨域访问。
什么时候涉及跨域问题？当涉及前端异步请求的时候才涉及跨域。
解决方案：
最后
本人也收藏了一份Java面试核心知识点来应付面试，借着这次机会可以送给我的读者朋友们
目录：
Java面试核心知识点
一共有30个专题，足够读者朋友们应付面试啦，也节省朋友们去到处搜刮资料自己整理的时间！
Java面试核心知识点
已经有读者朋友靠着这一份Java面试知识点指导拿到不错的offer了
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
且并不需要精确到分秒级的事件，可以利用定时扫描来实现，尤其是比较消耗
性能的大范围扫描，可以安排到夜间执行。
**讲讲怎么解****单点登录的访问，**分布式session跨域问题
=======================================
单点登录是相互信任的系统模块登录一个模块后，其他模块不需要重复登录即认证通过。
采用CAS单点登录框架，首先CAS有两大部分：客户端和服务端。
服务端就是一个web工程部署在tomcat中。在服务端完成用户认证操作。每次访问系统模块时，需要去CAS完成获
取ticket。当验证通过后，访问继续操作。对于CAS服务端来说，我们访问的应用模块就是CAS客户端。
什么是跨域？
当异步请求时，访问的请求地址的协议、ip地址、端口号任意一个与当前站点不同时，就会涉及跨域访问。
什么时候涉及跨域问题？当涉及前端异步请求的时候才涉及跨域。
解决方案：
最后
本人也收藏了一份Java面试核心知识点来应付面试，借着这次机会可以送给我的读者朋友们
目录：
[外链图片转存中…(img-hp1HWNdc-1713191958900)]
Java面试核心知识点
一共有30个专题，足够读者朋友们应付面试啦，也节省朋友们去到处搜刮资料自己整理的时间！
[外链图片转存中…(img-nayvOOxC-1713191958900)]
Java面试核心知识点
已经有读者朋友靠着这一份Java面试知识点指导拿到不错的offer了
[外链图片转存中…(img-GAejGCEz-1713191958901)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-vHV70mFP-1713191958901)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
3692
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
