最近几天整理的有关于面试的一些常见的问题

1. Java后端的研发流程

需求，系分，研发，测试，发布，运维

2.微服务架构的优点:

1.灵活性:微服务架构允许开发人员独立开发、部署和扩展不同的服务，从而使应用程序更加灵活。

2.可扩展性:微服务架构可以轻松地扩展， 因为每个服务都可以独立扩展。

3.可靠性:微服务架构可以提高系统的可靠性，因为每个服务都可以独立运行， 并且可以快速恢复故障。

 4.易于维护:微服务架构可以更容易地维护，因为每个服务都可以独立更新和升级。

微服务架构的缺点:

1.复杂性: 微服务架构比传统的单体应用程序更复杂，需要更多的管理和协调。 2.性能问题:微服务架构可能会导致性能问题，因为每个服务都需要与其他服务进行通

信。

3.分布式管理:微服务架构需要更复杂的分布式管理，包括服务注册、发现和负载均衡等。

4.数据一致性:微服务架构可能会导致数据一致性问题，因为每个服务可能使用不同的数据库或存储方式。

3.本地事务

1.对数据库一系列操作的集合

原子性(atomicity):一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 一致性(consistency):一事务必须是使数据库从一个一致性状态变到另一个致性状态，事务的中间状态不能被观察到的。

隔离性(isolation):一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相千扰。隔离性又分为四个级别:读未提交(read uncommitted)、读已提交(read committed, 解决脏读)、可重复读(repeatable read,解决虚读)、串行化(serializable,解决幻读)。

持久性(durability):持久性也称永久性(permanence),指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的，接下来的其他操作或故障不应该对其他有任何影响。

4.CAP

Consistency (一致性):在更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。

Availability (可用性):系统提供服务必须一直处于可用的状态。对于用户的请求需要在有限的时间内返回结果。

Partition tolerance (分区容错性):分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务。

在CAP理论中，三者是无法同时满的。P是必须要保证的。所以分布式服务只能满足CP或者AP。

5.BASE

BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性(Strong Consistency, CAP的一致性就是强一致性)，但应用可以采用适合的方式达到最终一致性(Eventual Consistency)

Partition Tolerance

基本可用(Basically Available)指分布式系统在出现不可预知故障的时候， 允许损失部分可用性。

·软状态(Soft State)指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。

最终一致(Eventual Consistency)强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

6.2PC

2PC:两阶段提交(Two-Phase Commit)

两阶段提交是分布式事务最常见的提交协议之一，主要包括两个阶段: 1.准备阶段(Prepare Phase):

·事务协调器(事务管理器)请求所有参与事务的节点(资源管理器)准备提交，这涉及锁定必要资源并确认执行操作的能力。 ·每个参与者(节点)准备完成后，向协调器发送一个"准备好了

(Ready)"的响应。

2.提交阶段(Commit Phase):

·如果所有参与者都报告准备好了，协调器会发出一个“提交

(Commit)”的命令，此时事务在所有参与者中提交。 如果任意参与者报告失败，协调器会发出一个"回滚(Rollback)”的命令，所有的参与者都会回滚它们的操作。

2PC协议容易产生阻塞，如果在第二阶段中协调器发生故障，参与者可能会无限期等待最终决定，从而导致资源锁定。从而引进了三阶段提交。

7.ЗРС

3PC:三阶段提交(Three-Phase Commit)

三阶段提交是两阶段提交的改进版本，增加了一个额外的阶段来减少阻塞的可能性，包括: 1.询问阶段(Can Commit Phase):

1.事务协调器询问参与者节点是否可以执行事务提交，参与者回复是(Yes)或否(No)。

2.准备阶段(Pre-commit Phase):

1.如果所有的参与者回复了是，协调器进入预提交状态，并发出预备提交(Pre-Commit)”指令。 2.参与者收到"预备提交"之后，准备数据并锁定资源，准备最终提交，并向协调器发送“准备好提交(Ack)"消息。

3.提交/中止阶段(Do Commit/Abort Phase):

·接收到所有参与者的“准备好提交”后，协调器发送"提交(Do Commit)”指令给所有参与者，事务提交完成。 ·如果准备阶段现故障或者某个节点回复了否(No),协调器发送"中止(Abort)”命令。

与2PC不同的是，3PC引入了超时机制， 如果参与者在等待时超过了预定义的时间仍未收到协调器的通知，则会进一步采取行动，要么提交要么中止该事务。这减少了协调器的单点故障造成的阻塞问题。

8.AT

1.AT是Automatic Transaction的缩写，是由Seata框架提出的分布式事务解决方案中的一种模式。

2.AT模式旨在降低分布式事务处理的复杂性，它是无侵入的，允许开发者不改变现有业务逻辑的情况下，使用分布式事务。

3.AT模式主要通过记录数据的变更情况(Undo Log),在事务执行过程中为每个数据库操作创建前后镜像。

4.AT事务的两个阶段包括:

·业务数据和Undo log记录阶段:在第一阶段，业务数据的更改被记录，同时记录Undo Log以便回滚。

·提交或回滚阶段:在第二阶段，根据第一阶段的执行结果，决定是提交事务并异步清理Undo Log,还是使用Undo Log进行回滚恢复数据。

9、透传Trace，确保链路的可观测性

在链路联调过程中，一般我们都是通过Trace进行问题定位和排查·什么时间生成Trace ID:在用户请求进入服务调用链的入口处生成一个唯一的Trace ID。 这个D将在整个请求链路中被传递。

·服务间传递:当服务调用另一个服务时，要确保传递包含Trace ID的信息。(举例两种)

对于HTTP调用，通常是通过HTTP头实现的； 对于消息队列，可以通过消息属性实现。

·日志记录:在服务中记录日志时，包含Trace ID,这样可以将日志条目关联到特定的请求链路。

·异常处理:在发生异常时，记录包含Trace ID的错误日志，以便于后续的问题追踪和调试。

10.发布三板斧

1、可监控:日志监控、核对、系统后台、系统内自检等；钉钉、短信、电话

目的:能够并且及时的发现不符合预期的事件

2、可灰度:技术灰度(预发可验证、灰度有流量、白名单等)；业务灰度(uid分表位、按照hash 值、按城市等维度圈人等)

目的:尽可能的降低未预期异常发生时造成的影响面(空间维度)

3、可应急:回切开关(回推配置[配置/DB]、入口流量)；快速迭代；代码回滚

目的:在应对未预期异常时能够尽快且安全的止损(时间维度)

11.微服务架构是一种软件架构风格，是一种弱架构模式，它提倡将应用程序拆分成一组小型、独立的服务，每个服务都有自己的功能和职责。这些服务可以独立部署、测试和扩展，使得整个应用程序更加灵活和可靠。每个服务运行在其独立的进程，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API或者基于TCP协议的RPC)

微服务架构的核心思想是“一个微服务一个职责”，即每个微服务只负责处理一个特定的功能或业务逻辑。这种架构风格使得开发人员可以更加灵活地设计和开发应用程序，因为每个微服务都可以独立开发、测试和部署。同时，这种架构风格也使得应用程序更加可靠和可扩展，因为每个微服务都可以独立扩展和部署。

微服务架构还有一些其他的特点例如:

1、松耦合

2、自治

3、独立部署

12.何时进行分库分表

优先MysQL调优，能不分就不分

·单表出现瓶颈

·单表数据量太大，导致读写性能变慢·单库出现瓶颈

·CPU压力过大·内存不足，导致读写变慢·磁盘空间不足，无法正常写入数据·网络带宽不足，导致读写性能变慢

这是近期参加面试较多的问到的一些问题在这里给大家总结一下，当然刚开始找工作的小伙伴肯定少不了的就是对于Java基础的理解，不过我相信大家的Java基础都已经过关了，在这里我就不再给大家细讲了。