JAVA 思维导图模板_ProcessOn思维导图、流程图

12.框架

RSA数字签名算法

证明这消息是你发的

证明这消息内容确实是完整的---也就是没有经过任何形式的篡改（包括替换、缺少、新增）

消息中间件

主流消息中间件

ActiveMQ

JMS

JMS模型

消息事务

kafka

1.基本介绍

是什么

应用场景

特点

2.基本概念

Kafka文件存储机制

Broker

Kafka节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。

Topic

Topic是用于存储消息的逻辑概念，可以看作一个消息集合。
每个topic可以有多个生产者向其推送消息，也可以有任意多个消费者消费其中的消息。
每个topic可以划分多个分区（每个Topic至少有一个分区），同一topic下的不同分区包含的消息是不同的

Partition

topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

Segment

partition物理上由多个segment组成，每个Segment存着message信息

Producer

生产message发送到topic

Consumer

订阅topic消费message, consumer作为一个线程来消费

Consumer Group

一个Consumer Group包含多个consumer, 这个是预先在配置文件中配置好的。各个consumer（consumer 线程）可以组成一个组（Consumer group ），partition中的每个message只能被组（Consumer group ）中的一个consumer（consumer 线程）消费

消息可靠性

消息发送可靠性

消息存储的可靠性

副本机制

ISRISR（副本同步队列）

3.高可用

数据备份

Producer在发布消息

ACK前需要保证有多少个备份

如何处理所有Replica都不工作

领导选举Leader Election算法

Kafka “各自为政” Leader Eclection

Kafka基于 Controller 的 Leader Election

4.消费者

high-level api

Sample-api

Consumer group

5.Leader Eclection

6.kafka的高吞吐量的因素

1.顺序写的方式存储数据

2.批量发送

3.零拷贝

4.数据压缩

7.日志保留策略

RocketMQ

整体架构

RocketMQ 逻辑部署结构

RocketMQ 数据存储结构

RocketMQ 物理部署结构

架构设计

部署架构

技术架构

RocketMQ集群工作流程

NameServer保证AP

顺序消息

生成消息的顺序性

原理：同一类消息发送到相同的对列即可，为了保证先发送的消息先存储到对列，必须使用同步发送

顺序消费

原理：同一个消息对列只允许消费者中的一个消费线程拉取消息，顺序消费消费线程请求到broker时会先申请锁

消息幂等性

高性能设计

顺序写盘

数据零拷贝

消息实时投递

高可用设计

消息发送的高可用

消息发送的重试机制

故障规避机制

消息存储的高可用

消息持久化（同步刷盘、异步刷盘）

主从复制

读写分离机制

消息消费的高可用

消费重试机制

消息ACK机制来保证

集群管理的高可用

Broker集群部署

面试常问的问题

1.MQ消息中间件在分布式系统中的作用

2.如何保证消息队列的高可用

3.如何保证消息消费的幂等性？

4.如何保证消息的可靠性传输？

5.如何保证消息的顺序性

源码分析

Spring

1.IOC,DI

IOC

原理：反射+XML

控制反转，IOC容器负责实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。交由Spring来管理这些，实现解耦

2.AOP

3.SpringMVC

原理

4.Bean的生命周期

基本流程

图片

1.实例化

Spring启动，查找并加载需要被Spring管理的bean，进行Bean的实例化

2.填充属性

Bean实例化后对将Bean的引入和值注入到Bean的属性中

3.执行Aware接口

1.BeanNameAware

2.BeanFactoryAware

3.ApplicationContextAware

4.初始化

1.实现InitializingBean接口

2.使用@PostConstruct注解

3.xml中通过init-method属性指定初始化方法

5.可用状态

指bean已经准备就绪、可以被应用程序使用了，此时bean会一直存在于Spring容器中

6.销毁

1.实现DisposableBean接口

2.使用@PreDestroy注解

3.xml中通过destroy-method属性指定

7.扩展点

InstantiationAwareBeanPostProcessorAdapter

循环依赖

5.Spring事务

Spring声明式事务管理，核心实现就是基于Aop

4.Spring Boot

1.Spring Boot启动流程分析

流程

第一部分进行SpringApplication的初始化模块，配置一些基本的环境变量、资源、构造器、监听器，new

第二部分实现了应用具体的启动方案，包括启动流程的监听模块、加载配置环境模块、及核心的创建上下文环境模块

第三部分是自动化配置模块，该模块作为springboot自动配置核心

图片

自动化配置

图片

2.@SpringBootApplication注解的意思

3.SpringBoot源码解析专题

5.SpringCloud

1.服务发现与注册Eureka

Eurka基本工作流程

Eureka 核心概念

Eureka Server注册中心服务端

Eureka Client：注册中心客户端

Renew: 服务续约

Eureka 分区

Eureka 集群原理

图片

Eureka 如何保证 AP

自我保护机制

原理

作为服务注册中心，Eureka比Zookeeper好在哪里

2.客服端负载均衡Ribbon

3.断路器Hystrix

Hystix原理

熔断器模式

图片

Hystrix的内部处理逻辑

命令模式

图片

子主题

Hystrix Metrics的实现

使用Fallback() 提供降级策略

Hystrix隔离策略

线程池（默认）

图片

原理

信号量

比较

4.服务网关SpringCloud GateWay

6.OpenFeign 一种声明式、模板化的HTTP客户端。

7.服务限流与熔断：sentinel

使用滑动计数器限流

1.总体介绍

图片

2.Sentinel基本概念

3.Sentinel功能和设计理念

流量控制

图片

流量控制设计理念

4.工作原理分析

1.限流流程

2.工作原理

8.nacos服务注册与配置中心

官网地址

Nacos原理分析

Nacos架构

基本架构及概念

逻辑架构及其组件介绍

注册中心的原理

服务提供者和NameServer源码流程图

图片

解读Nacos源码

服务注册

图片

服务地址的获取

服务地址变化的感知

图片

Nacos配置管理原理分析

图片

客户端核心源码解析

动态监听

图片

服务端主要流程

9.分布式事务框架Seata

MyBatis

#{}和${}的区别是什么

框架原理

一级二级缓存

shiro

Shiro是什么

主要组件

Subject

SecurityManager

Realm

Authenticator

Authorizer

Session Manager

Shiro 运行原理

dubbo

服务调用

服务定义

服务是围绕服务提供方和服务消费方的，服务提供方实现服务，而服务消费方调用服务

服务注册

服务监控

远程通信与信息交换

子主题

RPC

目的

设计模型

子主题

重试策略

Failover Cluster

失败自动切换，当出现失败，重试其它服务器。(默认)

Failfast Cluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
可通过 forks=”2”来设置最大并行数。

Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0 开始支持) 通常用于通知所有提供者更新缓存
或日志等本地资源信息。

Dubbo 的连接方式

Dubbo 的客户端和服务端有三种连接方式，分别是：广播，直连和使用 zookeeper 注册中心。

负载均衡算法

dubbo提供的四种负载均衡策略

加权随机算法 Random LoadBalance

加权轮询负载均衡 RandomLoadBalance

最小活跃数负载均衡 LeastActive LoadBalance

ConsistentHash LoadBalance

Zookeeper

文件系统

zookeeper维护了一个类似文件系统的数据结构

四种节点

通知机制

客户端监听它关心的目录节点，节点变化时通知客户端

图片

ZooKeeper的Zab一致性协议

什么是Zab协议

Zab协议需要做到什么

Zab协议的基本使用情景

崩溃恢复

Zab 的四个阶段

1.选举阶段（Leader Election）

2.发现阶段（Descovery）

3.同步阶段（Synchronization）

4、广播阶段（Broadcast）

zookeeper的zab协议的具体实现

1.选举（Fast Leader Election）

子主题

2.恢复（Recovery Phase）

3.广播（Broadcast Phase）

消息广播

实现原理

事务请求的处理方式

Zookeeper保证CP

Leader Election

13.算法和数据结构

树

B+树

为什么MySQL InnoDB中的B+树索引

1. B+树的磁盘读取代价低

2. B+树的查询效率更加稳定

3. B+树便于执行扫库操作

是什么

图片

B+的特性

红黑树

特点

左旋

变色

右旋

红黑树插入总结

二叉查找树（BST）

B-树的特性

B树

图片

B-树的特性

子主题

1.java基础

1.集合框架

总体概述

图片

1.HashMap原理

原理

红黑树

手写HashMap,ArrayList

2.ConcurrentHashMap

JDK1.8中 ConcurrentHashMap 中的CAS 和 synchronized是如何使用的

添加数据的过程

JDK1.7版本的ConcurrentHashMap的实现原理

图片

3.Set

4.Queue

5.equals()与hashCode()

6. List、 Set 和 Map 的初始容量和加载因子

2.java类加载机制

双亲委派模型

具体过程

什么情况下需要开始类加载过程的第一个阶段加载

JAVA中执行顺序

程序的赋值步骤

3.java反射

程序运行期间发现更多的类及其属性的机制。

通过反射机制访问java对象的属性，方法，构造方法等。

Java程序中的各个Java类属于同一类事物，描述这类事物的Java类名就是Class

Class类代表Java类，它的各个实例对象代表各类的字节码，请注意一个Class对象实际上表示的是一个类型。而这个类型未必一定是一种类，例如int不是类，但int.class是一个Class类型的对象。Class对象实际上是个泛型类，例如 Employee.class的类型Class<Employee>.

获取Class实例方式

对象.getClass()

Class.forName("类名")

类名.class

4.java序列化

目的

序列化算法一般步骤

Java如何实现序列化和反序列化

实现序列化的要求

相关注意事项

serialVersionUID

5.JAVA异常

异常分类

Java异常类层次结构图

分类

异常处理的原则

6. Java 中 IO 流

按操作⽅式分类结构图

按操作对象分类结构图

2.设计模式

1.23种设计模式概述

1.设计模式的七大原则

1.开闭原则

2.里氏代换原则（抽象化）

3.依赖倒转原则

4.迪米特法则（最少知道原则）

5.单一职责原则

6.接口隔离原则

7.合成复用原则

2.创建者模式

工厂方法模式

抽象工厂模式

单例模式

建造者模式

原型模式

3.结构型模式

适配器模式

装饰器模式

代理模式

外观模式

桥接模式

享元模式

组合模式

4.行为型模式

2.常用的设计模式

1.单例模式

2.工厂方法

1.工厂方法模式

2.抽象工厂方法模式

3.代理模式

1.Aspectj静态代理

2.动态代理（原理：反射）

1.jdk动态代理

2.cglib动态代理

3.类图

4.模板模式

5.组合模式

6.责任链模式

7.包装器模式

8.委派模式

9.桥梁模式

10.门面模式

11.享员模式

12.策略模式

3.项目中用到的设计模式

模板模式

组合模式

责任链模式-tomcat过滤器

单例模式

4.框架中用到的设计模式

3.JVM

4.网络编程

1.nio,aio

nio,与aio的区别

nio的实现

2.http相关

1.http协议组成

图片1

图片2

2.http协议请求方式

3.http状态码

4.https超文本传输安全协议

HTTPS工作流程

图片

数字证书认证机构的业务流程

5.Sokect

我们经常把socket翻译为套接字，socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用以实现进程在网络中通信。

6.三次握手四次挥手

为什么不能两次握手

TCP是一个双向通信协议，通信双方都有能力发送信息，并接收响应。如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认

为什么连接的时候是三次握手，关闭的时候却是四次握手

三次握手

图片

过程

为什么要三次握⼿

四次挥⼿

图片

过程

为什么要四次挥⼿

3.netty

1.实现原理

2.实现一个RPC框架

3.Netty之TCP粘包/拆包

4.Netty之编解码技术

5.Netty之私有协议栈开发

6.轻量级分布式RPC框架--NettyRpc

4.webservice

5.hessian

6.RPC

RPC(远程过程调用协议)，程序可以使用这个协议请求网络中另一台计算机上的程序的服务而不需要知道具体的网络细节。位于网络层的第五层。

6.Restful

REST 风格

主要原则

具体实现

面向资源

在 Restful 架构中，所有的接口应当采用面向资源的接口设计，即对于接口的访问地址指向其 URI 地址。

表述性

状态转移

7.键入网址后，期间发生了什么

5.并发编程

6.NoSQL

1.redis

Redis优点

Redis快的主要原因

Redis数据类型

String

Hash（哈希)键值对集合

List（列表）

Set（集合）

Zset 有序集合

支持的类型及每个类型的使用场景

redis持久化

RDB

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照

AOF

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。

Redis数据过期策略详解

定时删除

惰性删除

定期删除

Redis采用的过期策略

Redis集群方式

主从模式

哨兵模式

Redis集群（cluster）

Redis的发布订阅

redis 内存淘汰机制

redis 的线程模型

更新一致性问题

2.mongodb

固定集合

MongoDB 主从复制，副本集，分片

mongodb主从复制

副本集

分片

NoSQL聚合数据模型

键值(Key-Value)存储数据库

列存储数据库

图形(Graph)数据库

文档型数据库

7.数据库

范式

1NF

即表的列的具有原子性,不可再分解，即列的信息，不能分解,只有数据库是关系型数据库(mysql/oracle/db2/informix/sysbase/sql server)，就自动的满足1NF

2NF

表中的记录是唯一的,就满足2NF,通常我们设计一个主键来实现

3NF

表中不要有冗余数据,就是说，表的信息，如果能够被推导出来，就不应该单独的设计一个字段来存放.

mysql

1.MySQL的架构与内部模块

1. （一条查询 SQL 语句是如何执行的）执行流程

图片

具体流程

1、查询缓存

查询缓存

MySQL的缓存默认是关闭的

MySQL 8.0中，查询缓存已经被移除了

2、解析器生成解析树

主要做的事情是对语句基于SQL语法进行词法和语法分析和语义的解析

3、预处理再次生成解析树

4、查询优化器

根据解析树生成不同的执行计划（ExecutionPlan），然后选择一种最优的执行计划，MySQL里面使用的是基于开销（cost）的优化器，那种执行计划开销最小，就用哪种。

优化器最终会把解析树变成一个查询执行计划，查询执行计划是一个数据结构。

Explain的结果也不一定最终执行的方式

5、查询执行计划

6、查询执行引擎

存储引擎

图片

如何选择存储引擎

如果对数据一致性要求比较高，需要事务支持，可以选择InnoDB

如果数据查询多更新少，对查询性能要求比较高，可以选择MyISAM

如果需要一个用于查询的临时表，可以选择Memory

7、查询数据返回结果

2.通信协议

连接方式：长连接或者短连接

3.通信方式

MySQL使用了半双工的通信方式

4.一条更新 SQL 是如何执行的

缓冲池 Buffer Pool

redo Log Buffer

undo log

bin log

2. 事务

1.特性

1、原子性：数据库事务不可分割的单位，我们对数据库的一系列的操作，要么都是成功

实现

2、一致性：事务的操作不会改变数据库的状态，比方说唯一约束

3、隔离性：事务是相互不可见的

4、持久性：事务一旦提交，即使宕机也是能恢复的

实现

2.分类

1、扁平事务：使用最频繁的事务，要么都成功提交，要么都失败回滚

2、带有扁平点的扁平事务：允许事务回滚到同一个事务中比较早的一个状态

3、链事务：回滚到最近的一个保存点，在所有的事务都提交之后才会释放锁，并且下一个事务的开始需要上一个事务来进行通知

4、嵌套事务：树结构，只有当父级事务提交之后子级事务才会提交，任意一个父级事务的回滚都会导致下面的子级事务回滚

5、分布式事务：操作两个不同的数据库，使其实现数据的同步，例如将中国银行的钱转到工商银行，这个不同银行的不同数据库，为分布式事务

3.事务问题

1.脏读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新，然后B回滚操作，那么A读取到的数据是脏数据。

2.不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。

3.幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

4.隔离级别

1.读未提交（READ UNCOMMITTED）：未提交读隔离级别也叫读脏，就是事务可以读取其它事务未提交的数据。

2.读已提交（READ COMMITTED）：在其它数据库系统比如 SQL Server 默认的隔离级别就是提交读，已提交读
隔离级别就是在事务未提交之前所做的修改其它事务是不可见的。

3.可重复读（REPEATABLE READ）：保证同一个事务中的多次相同的查询的结果是一致的，比如一个事务一开始
查询了一条记录然后过了几秒钟又执行了相同的查询，保证两次查询的结果是相同的，可重复读也是 mysql 的默认隔
离级别。

4.可串行化（SERIALIZABLE）：可串行化就是保证读取的范围内没有新的数据插入，比如事务第一次查询得到某个
范围的数据，第二次查询也同样得到了相同范围的数据，中间没有新的数据插入到该范围中。

图片

5. 数据库什么时候会出现事务

自动开启

手动开启事务

手动开启事务也有几种方式，一种是用begin；一种是用start transaction。

还有一种情况，客户端的连接断开的时候，事务也会结束。

6. MySQL InnoDB 对隔离级别的支持

图片

两大实现方案

基于锁的并发控制LockBased Concurrency Control（LBCC）

多版本的并发控制 Multi Version Concurrency Control
（MVCC）

7.锁

InnoDB

数据库读一致性问题

行锁的原理

InnoDB的行锁模式及加锁方法

MySQL InnoDB 锁的基本类型

共享锁（s-行锁）：又称读锁

排他锁（Ｘ-行锁）：又称写锁。

意向锁(意向锁都是表锁)

意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。

意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

锁的算法

记录锁

间隙锁

临键锁

四个事务隔离级别的实现

死锁

死锁的产生条件

（1）同一时刻只能有一个事务持有这把锁

（2）其他的事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺

（3）当多个事务形成等待环路的时候，即发生死锁。

图片

死锁的避免

查看锁信息（日志）

3.索引

1.类型

1,Normal:普通的索引;允许一个索引值后面关联多个行值;

2,UNIQUE:唯一索引;允许一个索引值后面只能有一个行值;之前对列添加唯一约束其实就是为这列添加了一个unique索引;当我们为一个表添加一个主键的时候,其实就是为这个表主键列(设置了非空约束),并为主键列添加了一个唯一索引;

3,Fulltext:全文检索,mysql的全文检索只能用myisam引擎,并且性能较低,不建议使用;

2.实现

1,b-tree:是一颗树(二叉树,平衡二叉树,平衡树(B-TREE);
使用平衡树实现索引，是mysql中使用最多的索引类型；在innodb中，存在两种索引类型，第一种是主键索引（primary key），在索引内容中直接保存数据的地址；第二种是其他索引，在索引内容中保存的是指向主键索引的引用；所以在使用innodb的时候，要尽量的使用主键索引，速度非常快；

2,hash:把索引的值做hash运算，并存放到hash表中，使用较少，一般是memory引擎使用；优点:因为使用hash表存储，按照常理，hash的性能比B-TREE效率高很多。
hash索引的缺点：
1，hash索引只能适用于精确的值比较，=，in，或者；无法使用范围查询;
2，无法使用索引排序；
3，组合hash索引无法使用部分索引；
4，如果大量索引hash值相同，性能较低；

B+tree

图片

3.创建

1，较频繁的作为查询条件的字段应该创建索引；

2，唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件；
作为索引的列,如果不能有效的区分数据,那么这个列就不适合作为索引列;比如(性别,状态不多的状态列) 
举例:SELECT sum(amount) FROM accountflow WHERE accountType = 0;
假如把accountType作为索引列,因为accountType只有14种,所以,如果根据accountType来创建索引,最多只能按照1/14的比例过滤掉数据;但是,如果可能出现,只按照该条件查询,那我们就要考虑到其他的提升性能的方式了;

3，更新非常频繁的字段不适合创建索引；原因,索引有维护成本;

4，不会出现在WHERE 子句中的字段不该创建索引；

5, 索引不是越多越好;(只为必要的列创建索引)
1,不管你有多少个索引,一次查询至多采用一个索引;(索引和索引之间是独立的)
2,因为索引和索引之间是独立的,所以说每一个索引都应该是单独维护的;数据的增/改/删,会导致所有的索引都要单独维护;

索引的创建原则

4.聚集索引和非聚集索引分别是什么意思，有什么区别

MyISAM索引文件和数据文件是分离的(非聚集)

InnoDB索引实现(聚集)

4.性能优化

分库分表

1.冗余数据的处理（可以提高系统的整体查询性能,三范式）

1、每一列只能有一个值

2、每一行可以被唯一的区分

3、不包含其他表的已包含的非关键信息

2.垂直分库

垂直分库的做法，把一个数据库按照业务拆分成不同的数据库：

3.水平分表

把单张表的数据按照一定的规则分布到多个数据库

4.数据分片规则

JOIN的原理

1,JOIN的原理:
在mysql中使用Nested Loop Join来实现join;
A JOIN B：通过A表的结果集作为循环基础，一条一条的通过结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果；

2,JOIN的优化原则:
1，尽可能减少Join 语句中的Nested Loop 的循环总次数，用小结果集驱动大结果集
2，优先优化Nested Loop 的内层循环
3，保证Join 语句中被驱动表上Join 条件字段已经被索引
4，扩大join buffer的大小；

执行计划与执行明细

1.Explain:可以让我们查看MYSQL执行一条SQL所选择的执行计划

2.Profiling:可以用来准确定位一条SQL的性能瓶颈；

sql优化原则

思路

1.开启慢查询日志 slow query log

打开慢日志开关

2.慢日志分析

3.选择需要优化的SQL

统计慢查询

4.Explain和Profile入手

1、任何SQL的优化，都从Explain语句开始；Explain语句能够得到数据库执行该SQL选择的执行计划；

2、首先明确需要的执行计划，再使用Explain检查；

3、使用profile明确SQL的问题和优化的结果；

原则

索引

1、永远用小结果集驱动大的结果集

2、在索引中完成排序

3、使用最小Columns

4、使用最有效的过滤条件

5、避免复杂的JOIN和子查询

6.尽量避免大事务操作，提高系统并发能力。

7.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

8.关于排序

关于索引

军规

8.分布式

1.分布式ID

1.数据库自增长序列或字段

2.uuid

3.snowkeFlake

4.Zookeeper

5. MongoDB的ObjectId

6.Redis

1.利用redis的原子操作INCR和INCRBY来执行

2.可以利用redis的lua脚本执行功能，在每个节点上通过lua脚本生成唯一ID。

2.分布式锁

1.基于数据库实现分布式锁

优点：简单

缺点：

1 数据库的可用性和性能将直接影响分布式锁的可用性及性能，所以，数据库需要双机部署、数据同步、主备切换； 2、不具备可重入的特性 3、没有锁失效机制； 4、不具备阻塞锁特性

2.基于Redis实现分布式锁

利用 Redis set key 时的一个 NX 参数可以保证在这个 key 不存在的情况下写入成功。并且再加上 EX 参数可以让该 key 在超时之后自动删除。两个命令(NX EX)一起执行

3.基于Zookeeper实现分布式锁

排他锁

共享锁

3.分布式session

1.session复制

2.Session Sticky 方式管理

3. 缓存集中式管理

5.单点登录

登录

分支主题

注销

分支主题

6.分布式事物

1.ACID

2.CAP和BASE

3.TCC

4.基于消息的异步确保型

5.最大努力通知型

开源框架

7.分布式缓存

缓存的工作原理：更快读写的存储介质+减少IO+减少CPU计算=性能优化。

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

缓存雪崩

由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

缓存穿透解决方案

1）采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

（2）如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓存中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴！

memcache与redis

数据库与缓存数据一致性解决方案

9.性能优化

1.jvm性能优化

2.数据库性能优化

3.tomcat性能优化

1.关闭AJP协议

2.3种运行模式，设置为nio模式

3.调节线程池参数

4.调节JVM

10.运维

1.linux

2.jenkins

3.docker

11.搜索引擎

Elasticsearch

ElasticSearch的一些特性和概念

近实时性

集群

分片和复制(Shards & Replicas)

设计结构

节点(Node)

1. 客户端节点

2.主节点

3.data节点(数据节点)

索引(Index)

文档(Document)

字段

图片

写入和查询的流程

写入

es读数据过程

es搜索数据过程

Solr

lucene

lucene是一个做搜索用的类库。 nutch和solr都是基于lucene的，二者都是可直接运行的应用程序；

Elasticsearch与Solr的比较