面试题总结

1、mysql数据库插入过程
① 执行器先根据where条件查询修改的数据放入内存中，如果数据在内存中，直接返回给执行器，如果不存在，根据条件去磁盘中读取。
② 执行器获取返回的数据先进行数据的修改，得到新行数据，再调用引擎接口写入这行数据。
③ 写入过程，先更新内存，更新操作记录redo log，这时redo log处于 prepare状态。随时可以提交。
④ 然后执行器，将binlog日志写入磁盘
⑤ 最后执行器提交事务，刚刚redo log日志标记为已提交，此时返回更新完成。
⑥ 根据配置的磁盘写入策略，定时写入磁盘中。
2、mysql 各种日志作用及原理
binlog
redo log
undo log
error log
slow query log：慢sql日志
relay log 中继日志
3、binlog的格式
二进制日志,它记录了数据库的所有改变,并以二进制的形式保存到磁盘中。它可以用来查看数据库的变更历史,数据库增量备份,恢复,Mysql主从复制。从5.7.22版本开始，Mysql默认的格式由STATEMENT改为了ROW。
基于SQL语句的复制(Statement)
每一条会修改数据的sql都会记录到binlog中。
优点:不需要记录每一行的变化,减少了binlog的日志量,节约了IO,提高了性能。
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题。

基于行的复制(Row)

优点:binlog可以不记录执行sql语句的上下文相关信息,仅记录那一条数据(每个字段)被修改成了什么样子。所以row level的日志会非常清楚的记录每一行数据的变化细节,而且不会出现某些特定情况下,存储过程,函数,触发器无法被复制的过程。
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
新版本的MySQL中对row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。

混合模式复制(Mixed)
从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。
在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

4、SpringCloud组件都用的那些？OpenFeign底层封装
本质底层封装HttpURLConnection发出的HTTP请求。另外，如果有需要，你也可以替换成第三方库，HttpClient或者OkHttp。

5、redis 大Key
拆分多个kv,分配到不同的redis服务器中。

6、ZSet为什么不用B+树
ZSet：压缩链表+跳跃表
跳跃表（SkipList）是一种能高效实现插入、删除、查找的内存数据结构，这些操作的期望复杂度都是O（logN）。
与红黑树以及其他的二分查找树相比，跳跃表的优势在于实现简单，而且在并发场景下加锁粒度更小，从而可以实现更高的并发性。
正因为这些优点，跳跃表广泛使用于KV数据库中，诸如Redis、LevelDB、HBase都把跳跃表作为一种维护有序数据集合的基础数据结构。
redis基于内存，设计是尽可能提高读写效率。插入性能搞，操作简单，无需维护B+树特征。
而B+树是mysql InnerDB引擎的数据存储结构，磁盘存储，可存储数据量更大，需减少磁盘IO，提高访问效率。B+树层数少，进而减少磁盘IO。

禹数
1、nacos系列，对比eureka
nacos 有AP\CP, 默认是AP，也就是默认走distro 协议，可以通过配置设置为走Raft 协议来满足CP 原则。
eureka支持AP，数据同步。
nacos的AP
思路：读请求所有节点都可以处理；写请求是根据service_name 或者 实例信息(ip:port) 进行分片，分到对应的节点进行处理，节点处理完异步通知其他节点进行同步。
distro 协议 -AP (默认)
​核心参考： com.alibaba.nacos.core.distributed.distro.DistroProtocol
自研的一致性协议，主要用于在集群节点之间实现数据的快速同步和一致性保证。 思想是实现AP，节点分数据处理，也就是一个节点处理部分数据。 处理完之后通过异步任务，同步到其他节点，趋向于最终一致性。
大致过程：
初始化： 节点启动时初始化distro 相关组件，包含数据同步处理器以及服务监听器。
全量同步： 新加入集群的节点会请求全量数据，其他节点发送全量数据； 新节点收到全量数据后，进行校验和处理
增量同步：全量同步完成后，后续的同步是基于增量同步，只同步新产生的数据。 每个节点定期向其他节点发送增量请求，同步到本地进行处理
心跳与确认：节点之前定时发送心跳，以检测对方的存活状态

Raft 协议 - CP
核心参考： com.alibaba.nacos.naming.consistency.persistent.raft.RaftCore
思想： 有一个主节点，所有的写请求打到主节点。主节点然后同步阻塞将数据同步给其他节点，如果半数以上成功，就代表写入成功； 否则写入失败会抛出非法状态异常，可能就需要排查nacos 集群是否正常。
领导选举：
(1). Raft 系统中的节点在任何时候都处于三种状态之一：领导者（Leader）、跟随者（Follower）或候选者（Candidate）。
(2). 当系统启动或领导者失效时，节点会转换为候选者状态并发起选举，通过请求投票（RequestVote） RPC 向其他节点寻求支持。
(3). 基于任期（Term）的概念，每个选举都有一个独一无二的任期号，确保过时的投票无效，防止选票分裂。
(4). 获得大多数节点支持的候选者将成为新的领导者，负责处理客户端请求和管理日志复制
简单理解：

每个节点有一个随机等等时间，当集群暂未选出主节点或者没收到主节点心跳，且自己的随机等待时间到期之后，把自己的角色设为CANDIDATE、然后给自己投一票，然后向兄弟节点收集投票结果，假设B先到期 (com.alibaba.nacos.naming.consistency.persistent.raft.RaftCore.MasterElection#sendVote)；
兄弟节点A收到后和自己的票数term 比较，如果小于A当前的票数，那A投给A自己； 否则，A把自己的角色改为FOLLOWER 从节点，然后把自己的票数terms 设为和B节点的一样、重置自己的等待时间(com.alibaba.nacos.naming.controllers.RaftController#vote)
B每次收集完结果之后，判断票数最多且超过半数，那么就可以设为leader 主节点， 这是B已经知道自己是主节点
主节点每次心跳会将自己的信息同步给兄弟节点(只有主节点会发心跳给其他节点，其他节点记录主节点等信息-com.alibaba.nacos.naming.consistency.persistent.raft.RaftCore.HeartBeat#sendBeat)。
数据同步
(1). 所有的写请求会到达leader 节点
(2). leader 同步将数据发给其他兄弟节点，超过半数回复正常才会认为写入成功； 否则会抛出非法状态异常，这时候可能需要排查nacos 集群状态

参考： com.alibaba.nacos.naming.consistency.persistent.raft.RaftCore#signalPublish

nacos源码，启动过程，nacos数据落磁盘吗？
参考：https://www.cnblogs.com/stubborn-dude/p/15784097.html

2、sentinel相关，模式

3、redis cluster如何自动扩容
虚拟槽分布方式中，由于每个节点管理一部分数据槽，数据保存到数据槽中。当节点扩容或者缩容时，对数据槽进行重新分配迁移即可，数据不会丢失。
虚拟槽分区特点：
使用服务端管理节点，槽，数据：例如Redis Cluster
可以对数据打散，又可以保证数据分布均匀
顺序分布与哈希分布的对比

保证高可用，每个主节点都有一个从节点，当主节点故障，Cluster会按照规则实现主备的高可用性

4、redis集群方式
redis cluster 原理运行步骤：

• 把16384槽按照节点数量进行平均分配，由节点进行管理

1. 对每个key按照CRC16规则进行hash运算

• 把hash结果对16383进行取余
• 把余数发送给Redis节点
• 节点接收到数据，验证是否在自己管理的槽编号的范围，如果在自己管理的槽编号范围内，则把数据保存到数据槽中，然后返回执行结果，如果在自己管理的槽编号范围外，则会把数据发送给正确的节点，由正确的节点来把数据保存在对应的槽中。

需要注意的是：Redis Cluster的节点之间会共享消息，每个节点都会知道是哪个节点负责哪个范围内的数据槽

5、分布式锁，redis分布式锁缺陷，redissen是否解决了缺陷问题。

6、本地锁，sync的锁升级过程，如果执行hashcode，是否还会进入轻量级锁。

7、seata机制 源码

8、jvm相关 GC相关

9、dubbo+zk 与 springcloud 服务之间调用区别及优缺点。

10、nacos 有AP\CP 在什么场景使用AP 什么场景使用CP
在分布式系统中，Nacos 是一个流行的服务发现和配置管理工具。Nacos 支持两种模式：AP（Availability Partition Tolerance）和 CP（Consistency Partition Tolerance）。这两种模式在不同的场景下有不同的适用性。
AP（可用性优先）
AP 模式强调系统的可用性和分区容忍性。在这种模式下，系统在网络分区的情况下仍然能够继续提供服务，即使在某些情况下可能会牺牲数据的一致性。
使用场景
高可用性要求：当系统需要在网络分区或节点故障时仍然保持可用性时，可以选择 AP 模式。例如，在线购物平台在促销期间需要保持服务的可用性。
容忍临时不一致：在某些场景下，临时的数据不一致是可以接受的，系统可以在后台进行数据同步。例如，社交网络应用，用户可能会看到稍微过时的朋友动态，但不影响使用体验。
读多写少的场景：在读操作远多于写操作的场景下，AP 模式可以提供更好的性能和响应速度。
CP（一致性优先）
CP 模式强调系统的一致性和分区容忍性。在这种模式下，系统在网络分区的情况下可能会牺牲可用性，以确保数据的一致性。
使用场景
强一致性要求：在金融、银行等对数据一致性要求极高的场景下，选择 CP 模式是合适的。例如，银行转账操作必须确保数据的一致性，不能出现“钱丢失”的情况。

写多读少的场景：在写操作较多的场景下，CP 模式可以确保数据的一致性。例如，配置管理系统中，多个服务可能会同时更新配置，确保所有服务都能读取到最新的配置是非常重要的。
重要的业务逻辑：在某些关键业务逻辑中，确保数据的一致性是至关重要的。例如，订单处理系统必须确保每个订单的状态是一致的。

总结
AP 模式适合需要高可用性和容忍临时不一致的场景，尤其是在读多写少的情况下。
CP 模式适合需要强一致性和对数据一致性要求高的场景，尤其是写多读少的情况下。
在选择使用 AP 还是 CP 模式时，开发者需要根据具体业务需求和场景来权衡可用性和一致性之间的关系。

11、重写equals方法的同时为什么需要重写hashcode方法。
哈希运算需要相等，在进行equals判断。

12、最近工作难点

• 服务器升级部署，导致服务不可用，增加健康检查实现自动回滚，集群顺序部署，首个节点部署是吧集群停止升级自动回滚。
• 订单保存请求时间超长优化，做了并发操作改造。
• 内存溢出问题，excel 导入到处改为easyexcel。
• 消息挤压问题，拆分key，优化参数，优化消费增加消费能力。