2024年Java高阶

一、在面对千万条并发请求的情况下如果数据库频繁查询导致崩溃可以采取以下措施来解决问题:1.缓存数据:可以使用缓存技术来减少对数据库的查询次数。将经常查询的数据存储在缓存中例如使用Redis等内存数据库以减少每次查询时对数据库的访问。2.限流和降级:在高并发场景下需要对请求进行限流和降级以防止系统过载。这可以通过使用限流算法(如令牌桶、漏桶等)或者设置接口级别的限流规则来实现。降级则是指当系统负载过高时自动降低部分服务的可用性以保护整个系统的稳定性。扩展答案自行研究elasticsearch二、有很多个服务一个功能出现问题怎么快速定位是哪个服务出现的问题?ZIPKIN分布式链路追踪Zipkin可以确定对应用程序的请求在哪里花费了更多时间。无论是代码内部的调用还是对另一服务的内部或外部API调用您都可以对系统进行检测以共享上下文。微服务应用的响应时间过长使用Zipkin的话就可以轻松了解应用程序是否花费了大部分时间来查询数据库。通过 Zipkin 提供的请求延迟时间可视化可能会发现导致请求时间过长的原因是由于高速缓存服务器已关闭所有调用都直接发送到数据库从而增加了微服务的延迟。ZIPKIN扩展问题面试官会顺流而下继续问的问题经常问的能不能具体说说怎么实现的1、搭建zipkin-server2、Zipkin就会以单个 span的形式将跟踪数据异步发送到 Zipkin 的数据追踪收集器跟踪是通过带有 context header 的 HTTP 协议发送的。3、Zipkin 自带有一个可访问的用户界面可以通过可视化看出哪里浪费了时间哪里有问题。三、Zookeeper是怎么注册的1.1、当服务启动时服务的信息会存储到ZooKeeper临时节点上这就是Zookeeper的注册。四、Zookeeper什么是临时节点和什么是持久节点临时节点服务注册后连接丢失或session超时注册的节点会自动被移除 。持久节点服务注册后保证节点不会丢失注册中心重启也会存在 。五、zookeper的选举机制Leader 节点宕机了Zookeeper中的每一个节点都会向集群里面的其他节点发送一个票据 Vote每个节点都会选自己当 Leader所以第一次投票的时候携带的是当前节点的信息。接下来每个节点用收到的票据和自己节点的票据做比较根据 epoch、zxid、myid的顺序逐一比较以值最大的一方获胜。比较结束以后这个节点下次再投票的时候发送的投票请求就是获胜的 Vote 信息。然后通过多轮投票以后每个节点都会去统计当前达成一致的票据以少数服从多数的方式最终获得票据最多的节点成为 Leader。六、zookeper和nacos的区别1、一致性算法它是一种基于原子广播的一致性算法。它保证了分布式系统中数据的一致性和顺序性。而 Nacos 使用的是基于 Raft 算法实现的一致性协议也保证了数据的一致性。zookeper用的是ZAB算法2、功能特性Zookeeper 主要用于分布式协调和共享状态的管理提供了有序的命名空间和监听机制支持分布式锁、选举、队列等基础功能。Nacos 不仅提供了服务发现和配置管理还提供了动态配置、流量管理、服务治理、服务路由等更丰富的功能。3、数据存储Zookeeper 将数据存储在内存中并将数据变更写入磁盘中的事务日志中因此适合存储较小的元数据和配置信息。Nacos 则使用数据库作为持久化存储可以存储更大量级的配置数据。4、生态系统Zookeeper 作为一个成熟的分布式协调服务拥有广泛的应用和生态系统支持被广泛用于大型分布式系统。而 Nacos 是阿里巴巴开源的项目逐渐发展成为云原生领域的服务发现和配置管理的首选工具受到越来越多的关注和使用。5、部署模式Zookeeper 需要以集群模式运行至少需要三个节点组成一个 ZK 集群保证高可用性。Nacos 可以以单机模式或集群模式运行可以根据实际需求进行部署。七、zookeper节点为什么是奇数防止由脑裂造成的集群不可用选举机制公式可用节点数量 总节点数量/2 所以集群仍然能选举出 leader。很明显4个节点下的b脑裂不满足选举条件不能提供服务。5个节点(a) 小集群 A1个节点小集群 B4个节点或A、B互换(b) 小集群 A2个节点小集群 B3个节点或A、B互换4个节点(a) 小集群 A1个节点小集群 B3个节点或 A、B互换(b) 小集群 A2个节点小集群 B2个节点八、QPS访问量那么大怎么解决的8.1、什么是QPS?QPS 是 Queries Per Second的缩写意为每秒查询数。它是衡量系统或服务在单位时间内能够处理的查询或请求的数量。QPS 是评估系统性能和承载能力的重要指标之一。8.2、什么是TPSTPS 是 Transactions Per Second 的缩写意为每秒事务数。与 QPS 类似TPS 是衡量系统或服务在单位时间内能够处理的事务数量的指标。事务可以是数据库事务、网络事务或其他系统中定义的操作单元。8.3、统计QPS的工具Prometheus一个开源的监控和警报系统可以通过使用 Prometheus 的客户端库来收集和记录 QPS 数据。Grafana一个用于可视化数据的开源工具可以与 Prometheus 结合使用来创建仪表盘和图表以展示 QPS 数据。8.4、面对上万的QPS怎么解决硬件方面增加服务器、增加资源以处理更多的请求。可以考虑使用负载均衡来分发请求确保每个服务器都能均衡地处理负载。 例如我们负载下游的节点只有3台虚拟机那么我们就增加节点或者增加机器配置。数据库方面使用适当的索引和查询优化技术。考虑使用缓存技术如Redis或Memcached来减轻数据库的负载。异步处理将一些耗时的操作转换为异步任务如使用消息队列来处理后台任务从而减少请求的响应时间。代码优化检查应用程序代码识别并优化性能瓶颈如减少不必要的计算、避免重复查询等。接下来是重点也是面试官愿意听到的8.5.1、降级服务在面对大流量时可以暂时关闭或降低某些非关键服务的可用性以减轻服务器负载。例如可以关闭某些不必要的功能模块或限制某些操作的访问频率。8.5.2、限流措施通过设置请求频率限制或并发连接数限制限制系统接受的请求量。可以使用令牌桶算法或漏桶算法等限流算法来控制请求的流量。8.5.3、熔断Circuit Breaking熔断是一种针对服务间依赖关系的保护机制。当某个服务出现故障或响应时间过长时可以进行熔断即暂时断开对该服务的请求避免故障的扩散和影响其他服务。熔断可以快速失败减少对故障服务的依赖保护整个系统的可用性。九、QPS是多少每天访问量是多少多少台服务器高频考点标准120QPS公式( 总PV数 * 80% ) / ( 每天秒数 * 20% ) 峰值时间每秒请求数(QPS)机器峰值时间每秒QPS / 单台机器的QPS 需要的机器通过公式得出总访问量为259.2WPV即访问量单台机器QPS为40QPS机器数量为3120/40 等于3台单台机器访问量86.4W(单台机器PV即访问量)十、zookeper的缺点10.1、单点故障 在 ZooKeeper 集群中Leader 是单点如果 Leader 节点宕机会导致整个集群的不可用。尽管选举会尽快选出新的 Leader但仍然存在短暂的不可用性。10.2、写入性能 由于所有的写操作都由 Leader 处理并且需要进行复制写入性能可能受到影响特别是在高负载情况下。10.3、数据限制 ZooKeeper 的数据模型对于每个节点的数据有一定的大小限制不适合存储大量的数据。10.4、复杂性 虽然 ZooKeeper 提供了强大的功能但对于一些简单的应用场景使用 ZooKeeper 可能会增加系统的复杂性。十一、springboot和spring的区别11.1、应用程序Spring 是一个开源轻量级框架广泛用于开发企业应用程序。Spring Boot 建立在传统的 Spring 框架之上广泛用于开发 RESTAPI。11.2、Spring 框架最重要的特性是依赖注入。Spring Boot 最重要的特性是自动配置11.3、Spring有助于创建松散耦合的应用程序。Spring Boot有助于创建一个独立的应用程序例如微服务等。11.4、务器要运行 Spring 应用程序我们需要显式设置服务器。Spring Boot提供Tomcat和Jetty 等嵌入式服务器。11.5、要运行 Spring 应用程序需要部署描述符。Spring Boot不需要部署描过符。11.6、为创建一个 Spring 应用程序开发人员需要编写大量代码和配置。Spring Boot显著减少了代码和配置行。11.7、Spring默认不提供内存数据库支持。Spring Boot默认提供了对内存数据库的支持例如 H2。十二、redis的哨兵模式高频考点Redis 官方推荐一种高可用方案也就是 Redis Sentinel 哨兵模式它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常当主机发生故障时 Sentinel 会自动进行 Failover即故障转移并将其监控的从机提升主服务器master从而保证了系统的高可用性。哨兵的作用master 状态检测如果 master 异常则会进行 master-slave 切换将其中一个 slave 作为 master将之前的 master 作为 slavemaster-slave 切换后master_redis.conf、slave_redis.conf 和 sentinel.conf 的内容都会发生改变即 master_redis.conf 中会多一行 slaveof 的配置sentinel.conf 的监控目标会随之调换。十三、项目中异步处理的数据失败后如何补偿消息队列本地消息表1、需要发送到消费方的消息的保存和业务处理绑定在同一个本地事务中需要额外建立一张本地消息表。2、本地事务提交之后可以在事务外对本地消息表进行查询并且进行消息推送或者采用定时调度轮询本地消息表进行消息推送。3、下游服务消费消息成功可以回调一个确认到上游服务这样就可以从上游服务的本地消息表删除对应的消息记录。十四、什么是 spring cloudSpring Cloud 是一个微服务框架相比 Dubbo 等 RPC 框架, Spring Cloud 提供的全套的分布式系统解决方案。十五、spring cloud 断路器的作用是什么Spring Cloud 中使用了Hystrix 来实现断路器的功能断路器可以防止一个应用程序多次试图执行一个操作即可能失败允许它继续而不等待故障恢复或浪费CPU周期而它确定该故障是持久的。十六、spring cloud 的核心组件有哪些服务注册中心Eureka客户端负载均衡Ribbon熔断器Hystrix声明式的Http客户端Fegin服务网关Zuul十七、什么是 SpringBootSpring Boot是由Pivotal团队提供的一套开源框架可以简化spring应用的创建及部署。它提供了丰富的Spring模块化支持可以帮助开发者更轻松快捷地构建出企业级应用。Spring Boot通过自动配置功能降低了复杂性同时支持基于JVM的多种开源框架可以缩短开发时间使开发更加简单和高效。十八、为什么要用SpringBootSpring Boot 优点非常多独立运行Spring Boot而且内嵌了各种servlet容器Tomcat、Jetty等现在不再需要打成war包部署到容器中Spring Boot只要打成一个可执行的jar包就能独立运行所有的依赖包都在一个jar包内。简化配置spring-boot-starter-web启动器自动依赖其他组件减少了maven的配置。自动配置Spring Boot能根据当前类路径下的类、jar包来自动配置bean如添加一个spring-boot-starter-web启动器就能拥有web的功能无需其他配置。无代码生成和XML配置Spring Boot配置过程中无代码生成也无需XML配置文件就能完成所有配置工作这一切都是借助于条件注解完成的这也是Spring4.x的核心功能之一。应用监控Spring Boot提供一系列端点可以监控服务及应用做健康检测。十九、分布式锁常见的分布式锁方案有基于DB、Redis、zookeeper等DB在数据库创建一个锁表lock_table通常会包含以下几个字段:lock_business_id(业务ID)lock_stat(锁状态0 未锁 1 已锁)lock_time(锁定时间)version(版本)其中一条记录表示一个排它锁用字段lock_business_id对应相关资源, lock_stat表示锁状态再通过version字段采用乐观锁更新方式来保证处理的原子性。特点:适用于低并发场景只保证了基本的排他性处理。zookeeper对zookeeper来说开源客户端curator已提供多种实用的锁工具类如:InterProcessMutex分布式可重入排它锁InterProcessSemaphoreMutex分布式排它锁InterProcessReadWriteLock分布式读写锁特点:不仅提供对资源的排他性处理还对抢占资源的队列进行了排队先到先的很是公平。Redis三种方式实现redis分布式锁setnx、Redisson、RedLocksetnx锁实现可以用在测试或者简单场景但是它存在问题锁可能被误删和临界区代码不安全使其不适合用在正式环境Redisson 是一个基于 Java 的客服端通过 Redisson 我们可以快速安全的实现分布式锁。Redisson 框架具有可重入锁的支持、分布式锁的实现、锁的自动续期、红锁支持等多种特点给我们开发过程中带来了极大的便利。RedLock 又叫做红锁是 Redis 官方提出的一种分布式锁的算法红锁的提出是为了解决集群部署中 Redis 锁相关的问题。二十、索引失效和如何查看索引走没走1.最佳左前缀法则2.主键插入顺序3.计算、函数、类型转换(自动或手动)导致索引失效4.范围条件右边的列索引失效5.不等于(! 或者)导致索引失效6.is null可以使用索引is not null无法使用索引7.like以通配符%开头索引失效8.OR 前后只要存在非索引的列都会导致索引失效9.数据库和表的字符集统一使用utf8mb4索引走没走EXPLAIN SQL语句查询结果中key实际使用的索引如果为NULL则表示没有使用索引二十一、mysql锁有了解嘛模式分类乐观锁和悲观锁粒度分类全局锁、表级锁、页级锁、行级锁属性分类共享锁S、排他锁X状态分类意向共享锁、意向排他锁算法分类间隙锁、临键锁、记录锁乐观锁乐观锁顾名思义就是非常乐观乐观锁认为数据一般情况下不会造成冲突所以在数据提交更新的时候才会去检测。悲观锁悲观锁是相比较乐观锁而言的就是比较悲观悲观锁认为数据每次操作都会被修改所以在每次操作数据时都会加上锁。二十二、redis查询慢的原因1、Redis实例之间以及内部数据传输阻塞客户端、磁盘、主从通信、切片集群通信解决方法 — 主从集群时限制主库RDB文件大小。2、多CPU多核架构解决方法—绑核绑CPU。3、sql语句执行阻塞慢查询、过期key解决方法—避免慢查询指令、客户端做聚合、对key设置不同的过期时间、使用异步线程删除bigkey。4、AOF文件系统RDB大内存页AOF持久化阻塞、大内存页解决方法—AOF级别调整使用高速硬盘、关闭大内存页机制。5、操作系统Swap操作内存磁盘数据转换、内存清理解决方法—增加机器内存、使用Redis集群、调整内存清理机制触发参数。