Java面试整理2

3. 事务失效的情况

Spring事务的失效的几种原因--在类和类的方法上使用@Transactional

a. 数据库引擎不支持事务

mysql的myISAM引擎不支持事务。需要改成InnoDB才可以

b. @Transactional所在类非spring容器的bean

如果在service中没有加@service注解，则这个类不会被加载成bean，也就不会被spring管理。事务也就自然失效。

c. 方法不是public

@Transactional只能用于public，否则事务会失效；即使方法是public的，但是如果被private方法调用，事务同样也会失效。

d. 数据源没有配置事务管理器

@Bean

public PlatformTransactionManager transactionManager(DataSource dataSource) {

    return new DataSourceTransactionManager(dataSource);

}

e. 事务的propagation传播机制设置错误

Propagation.NOT_SUPPORTED 以非事务的方式执行，如果当前存在事务，就把当前事务挂起

f. Catch语句没有抛出异常

把异常吃了，然后又不抛出来，事务也不会回滚

g. 抛出异常类型错误

@Transactional 默认回滚的是RuntimeException 和error,而Exception是RuntimeException 的父类，事务不会生效

如果想触发其他异常的回滚，需要在注解上配置一下，如@Transactional (rollbackFor = Exception.class )

h. 确保业务和事务入口在同一个线程

该注解方法中如果又起线程，则业务事务不生效

i. 自身调用的问题

@Transactional的事务开启，或者是基于接口的或者基于类的代理被创建。所以在同一个类中一个无事务的方法调用另一个有事务的方法，事务是不会起作用的----类的内部方法调用是不起作用的

4.数据库的索引失效的情况

以复合索引name 和age 为例

1. 全职匹配 name = zhangsan and age = 18
2. 最佳左前缀法则，带头大哥不能死，中间兄弟不能少 where age = 18
3. 不要再索引列上做任何操作 where left(name,1) = zhang and age =18
4. 范围条件后列上索引失效，where age>1 and name =zhangsan  
5. 尽量使用覆盖索引，减少使用select *
6. 使用不等于 <, >,!= 索引会失效
7. 使用is null或者is not null也不能使用索引
8. Like 已通配符开头（%abc） 导致索引失效。解决方法，使用覆盖索引

Select * from student where name like ‘%zhangsan%’失效

Select name from student where name like ‘%zhangsan%’有效

    9. 少用or ，用它来链接索引会失效 where name = ‘zhangsan’or age =18

5.  单服务到微服务的拆分

单体服务架构的优势

1易于开发 2易于测试 3 易于部署

单体架构的不足

1复杂性高 2交付效率低3伸缩性差只能按整体横向扩展，无法分模块垂直扩展，IO密集型模块和CPU密集型模块无法独立升级和扩容 4可靠性差，一个bug可能影响整个项目的运行 5 阻碍技术创新

微服务架构的优势

1易于开发和维护 2 独立部署 3 伸缩性强 4 与组织结构想匹配 5 技术异构性

微服务面临的挑战

1 服务拆分

拆分原则：领域模型，组织结构，康威定律，单一职责

微服务拥有独立数据库

微服务之间确定服务边界

2 数据一致性

可靠性事件模式

补偿模式-sagas模式

3 服务通信

通信技术方案：RPC REST 异步消息

服务注册与发现

负载均衡

4 服务网关

API Gateway

为前端服务的后端

身份认证，路由服务，流量控制，日志统计

5 高可观察

健康检测，集中控制

日志聚合检索

分布式追踪

6 可靠性（客户端实现）

流量控制，超时监控

舱壁隔离（线程隔离），熔断机制

服务降级，幂等重试

拆分原则

a 单一原则，高内聚低耦合 b 服务粒度适中 c 考虑团队结构 d 已业务模型切入 e 演进史拆分 f 避免环形依赖和双向依赖 g DDD

拆分步骤

a 分析业务模型 弱耦合在一起，高内聚力 b 确定服务边界 服务应包含单一的界限上下文 c 微服务数据库拆分

微服务的数据一致性

1 分布式事务不适用微服务 2PC会有单点故障 由于锁的原因降低吞吐量 NoSQL数据库并不支持

2 采用最终一致性，来实现数据一致性  可靠性时间模型：消息队列（支付宝转余额宝） 补偿模式-sagas 一些列的有序事务（每个事务也都有一个补偿子事务）

6. 注册中心-zookeeper-eureka-consul

组件名     语言    CAP   服务健康检查    对外暴露接口    springCloud

Eureka     Java    AP    可配支持         HTTP           已集成

Consul     GO      CP     支持           HTTP/DNS        已集成

Zookeeper  Java    CP     支持             客户端        已集成

AP:满足可用性，分区容错性的系统，通常对一致性的要求低一些

CP:满足一致性，分区容错性的系统，通常性能不是特别高

CA:单点集群，满足一致性，可用性的系统，通常扩展性上不太强大

7. 微服务的数据一致性

ACID数据库事务正确执行的四个基本要素

原子性A:要么全部完成，要么全部不完成，不存在中间状态

一致性 C:事务必须保持系统处于一致的状态

隔离性 I:事务之间相互隔离，同一时间仅有一个请求用于同一数据

持久性D : 事务一旦提交，该事务对数据库所做的更改持久的保存在数据库之中，并不会被回滚

电商为例，支付，订单，积分功能抽成三个服务，每个服务都有独立的数据库做数据存储。无论是修改订单状态失败，还是增加积分失败，都会导致数据的不一致

支付---订单---积分

为了解决这种问题，最后的方法避免微服务，实现本地事务保证数据的强一致性。但微服务架构中，每个服务都有自己的数据库，导致微服务系统不能简单的满足本地事务的特性

8. JWT （json web token）

基于token的进行身份认证的方案

Jwt设计一个字符串由header，payload,signature组成

Jwt头 +有效载荷+签名

具备安全，自包含，紧凑等特点

优点：

安全性高，防止token被伪造和篡改

自包含，减少存储开销

跨语言，支持多种语言的实现

支持过期，发布者校验

注意：

消息体可以被base64解密成铭文

Jwt不适合存放大量信息

无法作废未过期的jwt (可以借用Redis实现)

9. 分布式系统的CAP理论和BASE理论

C:一致性，所有数据变动都是同步的

A:可用性，即在可以接受的时间范围内正确的相应客户的请求

P:分区容错性，即某节点或网络出现故障时，系统扔能提供满足一致性和可用性的服务

关系型数据库，单节点，保证了数据强一致性C和可用性A,但是却无法保证分区容错性P

然而在分布式系统下，为了保证模块的分区容错性P，只能在数据强一致性C和可用性A之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。

BASE理论

BA:基本可用

S:软状态，状态可以有一段时间不同步

E:最后一致，最终数据是一致的就可以了

BASE理论主要是通过牺牲强一直性来保证系统的可用性

可靠消息最终一致性

可靠消息最终一致性方案本质上是利用MQ组件实现的二阶段提交。此方案涉及3个模块

上游应用，执行业务并发送MQ消息

可靠消息服务和MQ消息组件，协调上下游消息的传递，并保证上下游数据的一致性

下游应用，监听MQ的消息并执行自身业务