redis缓存用在哪里,用本地缓存行不行?
数据库查询缓存,减小数据源压力,提高响应速度
页面缓存:将页面的渲染结果缓存在Redis中,以减少页面生成的时间和服务器负载。
频繁计算结果缓存:将频繁计算的结果缓存在Redis中,以避免重复计算,提高性能。
分布式锁:利用Redis的原子性操作和过期时间特性,实现分布式锁,保证多个线程或进程之间的互斥操作。
消息队列:利用Redis的发布/订阅功能,实现消息队列,用于解耦和异步处理。
本地缓存也有类似应用场景,但有许多不足:
本地缓存的容量有限,无法存储大量数据。
本地缓存无法实现多个应用程序之间的共享缓存。
本地缓存的数据在应用程序重启时会丢失。
说说缓存击穿?
一个并发访问量比较大的key在某个时间过期,导致所有的请求直接请求到DB上。
解决方法:
1.加锁更新,⽐如请求查询A,发现缓存中没有,对A这个key加锁,同时去数据库查询数据,写⼊缓存,再返回给⽤户,这样后⾯的请求就可以从缓存中拿到数据了。
2.将过期时间组合写在value中,通过异步的⽅式不断的刷新过期时间,防⽌此类现象。
数据库的读写分离,为什么要读写分离?
- 数据库服务器搭建主从集群,一主一从、一主多从都可以。
- 数据库主机负责读写操作,从机只负责读操作。
- 数据库主机通过复制将数据同步到从机,每台数据库服务器都存储了所有的业务数据。
- 业务服务器将写操作发给数据库主机,将读操作发给数据库从机。
为什么要读写分离?
减小主库压力;提高读取性能和并发处理能力;灵活的处理数据。
读写分离的数据一致性问题?
强一致性:可以在写入操作后,立即读取主库数据,以保证读取到最新的数据。但会增加主库的负载。
主从同步机制:数据库主从同步会将主库的写操作同步到从库,通过设置合适的同步延迟和同步策略,可以确保从库数据的实时性和一致性。
读写分离中间件
如何提高数据库的读写能力?
- 优化数据库设计:合理设计数据库表结构,使用适当的数据类型和索引,避免冗余和重复数据,以提高查询和更新的效率。
- 使用合适的数据库引擎:根据实际需求选择合适的数据库引擎,如MySQL的InnoDB引擎支持事务和行级锁,适用于高并发的读写场景。
- 使用数据库连接池:使用连接池管理数据库连接,避免频繁地创建和销毁连接,减少连接的开销,提高数据库的并发处理能力。
- 合理使用索引:根据查询的需求,合理创建索引,避免过多或不必要的索引,以提高查询的效率。
- 批量操作和事务处理:对于批量的读写操作,可以使用批量操作的方式,减少与数据库的交互次数。对于需要保证数据一致性的操作,使用事务来保证数据的完整性和并发处理能力。
- 数据库分库分表:当数据库的读写压力过大时,可以考虑将数据进行分库分表,将数据分散到不同的数据库实例或表中,以提高数据库的读写能力和并发处理能力。
- 缓存技术:使用缓存技术将热点数据缓存在内存中,减少对数据库的访问,提高读取性能。常见的缓存技术包括Redis、Memcached等。
- 数据库主从复制:使用数据库主从复制技术,将数据库的读操作分发到从库,减轻主库的读压力,提高读取性能。
说说分库分表?
分库:将一个数据库分成多个独立的数据库。用来解决数据库读写压力过大
-
垂直分库:按照业务归属不同进行拆分,例如用户,订单,商品三个业务。
-
水平分库:以字段为依据,按照一定的策略(hash,range等),将一个库中的数据拆分到多个库
分表:将一个数据库表分成多个独立的表,每个分表可以独立存储一部分数据,有自己的结构和索引。解决单表数据量过大问题,将数据分散到不同的表中,减少单表的数据量,提高查询和更新的效率。
- 水平分表:以字段为依据,按照一定策略(hash、range 等),将一个表中的数据拆分到多个表中。
- 垂直分表:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。
分库和分表的区别
分库主要关注的是将数据分布在不同的数据库实例中,以减轻单个数据库的负载,提高读写并发能力和扩展性。
而分表则是将一个大表分割成多个小表,以降低单个表的数据量,提高查询性能和写入吞吐量
分表用什么字段分比较好?
- 自增主键
- 时间字段
- 用户id
- 地理位置字段
- 业务逻辑字段
主从数据库如何同步?
主库将数据变更写入binlog
从库创建一个IO线程,读取主库binlog,并写入到中继日志(relay log)中
从库再开启一个sql线程读取relay log事件并在slave执行,来完成同步。
从库记录自己的binlog
SQL:查询某一班级内年龄大于20的男性数量;查询某一班级内年龄大于20的男性,女性数量并显示出来
假设有一个名为students的表,包含以下字段:id、name、age、gender、class
前:select count(*) as count from students class = “这个班级” and where age>20 and gender = “男”
后:select gender,count(*) as count from students where class = “这个班级” and age > 20 group by gender;
死锁的四个条件?
互斥条件:一个资源每次只能被一个进程使用,即在一段时间内某资源仅为一个进程所占有,此时若有其他进程请求该资源,则请求进程只能等待
请求与保持条件:进程已经保持了至少一个资源,但又提出了新的资源请求时,该资源已被其他进程占有,此时请求进程被阻塞,但对自己已获得的资源保持不放
不可剥夺条件:进程所获得的资源在未使用完毕之前,不能被其他进程强行夺走,即只能由获得该资源的进程自己来释放(只能是主动释放)
循环等待条件: 若干进程间形成首尾相接循环等待资源的关系
这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之一不满足,就不会发生死锁
什么是事务?
事务是数据执行的最小单元,不可以被分割
事务有四大特性:ACID
原子性:事务是数据处理的最小单元,事务的原子性保证事务的发生要么全部成功,要么全部失败。
隔离性:在并发事务中,各事务之间互不影响,相互独立
一致性:事务在执行前后总是由一个一致性状态转变为另一个一致性状态。
持久性:事务对数据的改变是持久的,即使中间数据库发生故障,也不会影响。
事务的隔离级别?
读未提交:最低的隔离级别,允许读取数据库尚未提交的数据。可能会发生幻读,脏读和不可重复读;
读已提交:允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读可能发生。
可重复读:对同意字段多次读取的结果是一致的,除非是事务本身修改,可以阻止脏读和不可重复读,但幻读有可能发生。
串行化:最高的隔离级别,所有事务以此逐个执行,完全服从ACID的隔离级别。但是一般不会使用。
什么是幻读、不可重复读、脏读?
事务 A、B 交替执行,事务 A 读取到事务 B 未提交的数据,这就是脏读。
在一个事务范围内,两个相同的查询,读取同一条记录,却返回了不同的数据,这就是不可重复读。
事务 A 查询一个范围的结果集,另一个并发事务 B 往这个范围中插入 / 删除了数据,并静悄悄地提交,然后事务 A 再次查询相同的范围,两次读取得到的结果集不一样了,这就是幻读。
浏览网站到返回网页的整个过程?
- 用户输入网址
- DNS解析
- 建立TCP连接
- 用户端发送HTTP请求
- 服务端响应HTTP请求并返回处理结果
- 用户端接收响应
- 用户端渲染页面
Tcp在哪一层,和udp的应用场景分别是什么
TCP/UDP在传输层,提高可靠的,面向连接的数据传输
- TCP是面向连接、可靠的传输协议,适用于对数据传输可靠性要求较高的场景。
- UDP是无连接的传输协议,提供简单、高效的数据传输,适用于实时性要求较高、但对数据丢失或乱序不敏感的场景。
1.springboot怎么声明一个类为bean
@Configuration注解
@Component注解
@Service、@Repository、@Controller注解都是@Component的派生注解,分别用于声明服务层、数据访问层和控制层的Bean。
在其他类中,可以通过@Autowired或@Resource等注解来自动注入这些Bean的实例。
2 @Autowired 和@Resource 的区别是什么?
联系:
- @Autowird和Resource注解都是作为bean对象注入的时候使用的
- 两者都可以声明在字段和setter方法上
区别:
- @Autowird注解是spring提供的,而@Resource注解是J2EE本身提供的
- @Autowird注解默认通过byType方式注入,而@Resource注解默认通过byName方式注入
Spring的自动装配 byName和byType的区别?
byName:根据属性名自动装配。此选项将检查容器并根据名字查找与属性完全一致的bean,并将其与属性自动装配。
byType:如果容器中存在一个与指定属性类型相同的bean,那么将与该属性自动装配;如果存在多个该类型bean,那么抛出异常,并指出不能使用byType方式进行自动装配;如果没有找到相匹配的bean,则什么事都不发生,也可以通过设置改变。
- @Autowired注解注入的对象需要在IOC容器中存在,否则需要加上属性required=false,表示忽略当前要注入的bean,如果有直接注入,没有跳过,不会报错
treeSet和treeMap的区别?
存储方式
-
TreeSet: 是一个有序的、不重复的集合类,它存储的是一组无序的、不重复的元素。
-
TreeMap: 是一个有序的、键值唯一的映射类,它存储的是键值对,并按照键的自然顺序进行排序
数据结构
- TreeSet: 内部使用TreeMap实现,底层为TreeMap,实现Set接口
- TreeMap: 基于红黑树实现,每个结点为红黑树结点,实现了Map接口
元素比较
- TreeSet 按照自然顺序排序或者传入的Comparator排序
- TreeMap 按照键的自然顺序排序或者传入的Comparator排序
操作方法
- TreeSet 提供了一些集合操作的方法,如添加元素、删除元素、查找元素
- TreeMap 提供了一些映射操作的方法,如添加键值对、删除键值对、查找键值对
小结
TreeSet和TreeMap都是有序的数据结构,用于存储有序的元素。
TreeSet用于存储一组无序的、不重复的元素
而TreeMap用于存储键值对,并按照键的有序性进行排序。
如果只需要存储一组有序的、不重复的元素,可以选择TreeSet;
如果需要存储一个有序的映射关系,可以选择TreeMap。
刚有提到treeMap的底层原理是红黑树,那红黑树有什么特点
-
二叉搜索树特性:红黑树是一种二叉搜索树,它满足二叉搜索树的特性,即左子树上的节点值小于节点值,右子树上的节点值大于节点值。
-
节点颜色:红黑树的每个节点都带有颜色属性,可以是红色或黑色。
-
根节点和叶子节点特性:根节点和叶子节点(空节点或NIL节点)都是黑色的。
-
红色节点特性:父节点是红色节点的子节点必须是黑色的。
-
黑色节点特性:从根节点到叶子节点的每条路径上都包含相同数量的黑色节点。
-
最长路径不超过两倍:由于红黑树保持平衡,任何节点到其子树中叶子节点的最长路径不会超过最短路径的两倍。这使得红黑树的查找、插入和删除等操作都能在相对较快的时间内完成。
还有哪些地方用到了红黑树
HashMap数据结构:链表数组红黑树
数据库索引结构:MySQL中的InnoDB存储引擎就使用了红黑树来维护主键和唯一索引
刚刚有提到索引有用到红黑树,那MySQL的索引是使用什么实现的?
对于普通的索引(非唯一索引和主键索引),MySQL使用B+树实现。B+树是一种多叉树,它在节点中存储了多个键值和对应的指针,且具有以下特性:
-
所有数据都存储在叶子节点中,内部节点只存储键值用于导航。
-
叶子节点通过链表连接,可以方便地遍历和区间查询。
-
内部节点根据键值分割子树,实现了高效的查询。
B+树在支持范围查询和顺序遍历等操作时非常高效。它也能够保证在大部分情况下,查询的复杂度为O(log n),其中n是索引数据的大小。
对于唯一索引或主键索引(包括聚簇索引),MySQL使用B树实现。B树和B+树类似,但在叶子节点存储的是键值和对应的数据,而不是仅存储键值。B树在保证有序性的同时,提供了更快的查找速度,因为存储了数据本身。
需要注意的是,虽然红黑树可以作为索引的实现之一,但在MySQL中,并不使用红黑树作为索引结构的实现方式。红黑树在其他应用中可能有用到,但在MySQL索引中的主要实现是B树和B+树。
为什么MySQL使用B+树,相比于红黑树来说?
B+树每一层存储元素更多,深度小,查询效率高,支持范围查询
计算三层B+树能够存储的数据量?
假设B+树深度为m 每个节点大小为s
B+树每个内部节点至少有m/2个孩子节点,最多有m个孩子节点。而叶子节点存储数据,不存储孩子节点指针。
第一层的叶子节点数量为1个,第二层的叶子节点数量为m,第三层的叶子节点数量为m2。因此,三层B+树的叶子节点数量为m2。
假设一个数据项的大小为D,那么每个叶子节点可以存储的数据量为S = m * D
总的数据量 = 叶子节点数量 * 每个叶子节点的数据量 = (m^2) * (m * D) = m^3 * D
所以,三层B+树可以存储的数据量为 m^3 * D。
你了解AVL树吗?红黑树相比AVL有什么优缺点
AVL树。AVL树也是一种自平衡的二叉搜索树
AVL树通过维护相对严格的平衡性来达到自平衡的目的。它在每个节点上存储一个平衡因子(Balance factor),表示该节点的左子树高度减去右子树高度的值。平衡因子可以为-1、0或1,如果平衡因子的绝对值超过1,就表示该树不平衡,需要通过相应的旋转操作进行调整。
相比之下,红黑树维护的平衡要求相对较宽松,并且通过节点的颜色属性进行平衡调整
AVL树的优点:
- 查找、插入和删除等操作的时间复杂度都是O(log n),其中n是树中节点数量,因为AVL树是严格平衡的。
- 在某些特定的查询场景下,AVL树可能会比红黑树更快,因为它有更严格的平衡性。
AVL树的缺点:
- 相对于红黑树,AVL树在插入和删除操作中需要更频繁地进行旋转操作,因为它要保持更严格的平衡性。这可能会导致性能略微下降。
- AVL树需要额外的平衡因子存储空间来记录每个节点的平衡因子,而红黑树只需要一个颜色位来标记节点的颜色,所以AVL树的空间开销可能会稍大一些。
MySQL索引碎片了解吗?怎么产生的?如何解决他?
索引碎片是指数据库索引中的数据分布不连续或不紧凑,导致查询效率下降的情况。它通常由以下原因产生:
- 插入、更新、删除操作:当数据库中进行频繁的插入、更新和删除操作时,索引会不断发生变动,导致数据的重新排列,从而产生碎片。
- 索引分裂和合并:如果索引分裂不及时或合并不完全,也会导致索引碎片的产生。
采取以下几种解决方法
- 重建索引:通过重建索引来解决碎片问题,该方法会将数据重新组织以达到紧凑存储的效果。可以使用ALTER TABLE语句中的ALTER INDEX子句来重建索引。
- 优化查询计划:MySQL可以通过重新优化查询计划来减少索引碎片对查询性能的影响。可以使用ANALYZE TABLE语句来收集数据统计信息,帮助优化查询计划。
- 分区表:将大表按照一定的规则分成多个小表,可以减少索引碎片的产生。每个小表的数据量相对较小,索引也相对较小,插入、更新和删除操作对索引的影响较小。
- 定期清理和优化:定期进行数据库的碎片清理和优化是保持索引性能的重要步骤。可以使用OPTIMIZE TABLE语句来进行碎片整理和优化。
Tcp三次挥手和四次挥手?
三次握手:
在建立连接时,第一次握手,客户端给服务端发送一个SYN包,表示申请连接,第二次握手服务端接收到SYN包并向客户端发送一个SYN+ACK确认包表示接收连接,第三次握手客户端收到确认包后,向服务端发送ACK确认包,服务端收到ACK报文后,三次握手建立完成。
四次挥手:
1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
2、第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。
3、第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
客户端发送一个SYN+ACK确认包表示接收连接,第三次握手客户端收到确认包后,向服务端发送ACK确认包,服务端收到ACK报文后,三次握手建立完成。
四次挥手:
1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
2、第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。
3、第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
4、第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态