java技术路线图（面试）

服务端需要更新本次心跳的时间，也就是最后更新时间。

Helthcheck()方法，进行健康检查任务，runnable 默认延时5秒处理

服务端拿到Instance的set集合后，遍历判断
使用（当前时间-最后更新时间>设置的健康超时时间（默认15秒）），如果超过了15秒，则将状态改为 不健康。
里面还有一个遍历判断：
使用（当前时间-最后更新时间>设置的健康超时时间（默认30秒）），如果超过了30秒，则认为服务挂掉了，则从注册表中将该服务剔除

在分布式环境下,经常需要对应用/服务进行统一命名 ,便于识别。
例如: IP不容易记住,而域名容易记住。

1.分布式环境下,配置文件同步非常常见。
( 1 )-般要求- -个集群中,所有节点的配置信息是一致的, 比如Kafka集群。
( 2)对配置文件修改后,希望能够快速同步到各个节点上。

2.配置管理可交由ZooKeeper实现。
( 1 )可将配置信息写入ZooKeeper上的一-个Znode.
(2)各个客户端服务器监听这个Znode.
( 3 ) - -旦Znode中的数据被修改, ZooKeeper将通知
各个客户端服务器。

ZooKeeper可以实现实时监控节点状态变化
( 1 )可将节点信息写入ZooKeeper,上的一一个ZNode.
(2)监听这个ZNode可获取它的实时状态变化。

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。

它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)

集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器接到Leader的时限。

集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。

主要用于保存 Zookeeper 中的数据。

1.消息广播模式

2.崩溃恢复模式

持久（Persistent）：客户端和服务器端断开连接后，创建的节点不删除

短暂（Ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除

说明：创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护

注意：在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

1.半数机制：集群中半数以上机器存活，集群可用。所以 Zookeeper 适合安装奇数台服务器

2.Zookeeper 虽然在配置文件中并没有指定 Master 和 Slave。但是，Zookeeper 工作时，是有一个节点为 Leader，其他则为 Follower，Leader 是通过内部的选举机制临时产生的。

3.选举机制举例

1.首先要有一个main()线程

2.在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）

3.通过connect线程将注册的监听事件发送给Zookeeper。

4.在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。

5.Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。

6.listener线程内部调用了process()方法。

注：常见的监听

1.Client向ZooKeeper的Server1上写数据，发送一个写请求。

2.如果Server1不是Leader，那么Server1会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leader会将写请求广播给各个Server，比如Server1和Server2，各个Server会将该写请求加入待写队列，并向Leader发送成功信息。

3.当Leader收到半数以上Server的成功信息，说明该写操作可以执行。Leader会向各个Server发送提交信息，各个Server收到信息后会落实队列里的写请求，此时写成功。

4.Server1会进一步通知Client数据写成功了，这时就认为整个写操作成功。

普通创建
-s 含有序列
-e 临时（重启或者超时消失）

spring:
  cloud:
    gateway:
      discovery:
        locator:
          #是否与服务发现组件进行结合，通过serviceId转发到具体实例
          #是否开启基于服务发现的路由规则
          enabled: true
          ##表示将请求路径的服务名配置改成小写 ,因为服务注册的时候，向注册中心注册时将服务名转成大写的了
          lowerCaseServiceId: true
      routes:
        - id: after_route
          uri: lb://bit-msa-pasm-api
          predicates:
            - Path=/service/**
          filters:
            - name: RequestRateLimiter
              args:
                # 令牌桶每秒填充平均速率
                redis-rate-limiter.replenishRate: 1
                # 令牌桶的上限
                redis-rate-limiter.burstCapacity: 2
                # 使用SpEL表达式从Spring容器中获取Bean对象
                key-resolver: "#{@pathKeyResolver}"

2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。

1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事 务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）

2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者 发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操 作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

1.基于数据库的XA 协议来实现2PC又称为XA方案

2.Seata方案

1. Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能 真正构成一个完整的业务逻辑。

2. Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则 认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引 入重试机制或人工处理。

3.Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采 用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

注：TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文， 追踪和记录状态，由于Confirm 和cancel失败需进行重试，因此需要实现幂等，幂等性是指同一个操作无论请求多少次，其结果都相同

1.tcc-transaction

2.Hmily

3.ByteTCC

注：Seata也支持TCC，但Seata的TCC模式对Spring Cloud并没有提供支持。

1.空回滚

2.幂等

3.悬挂

如果拿TCC事务的处理流程与2PC两阶段提交做比较，2PC通常都是在跨库的DB层面，而TCC则在应用层面的处 理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使 得降低锁冲突、提高吞吐量成为可能。

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此 外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。

1.本地事务与消息发送的原子性问题

2.事务参与方接收消息的可靠性

3.消息重复消费的问题

1.本地消息表方案

2.RocketMQ事务消息方案

方案一：以“下单时间”为标准，将3 个月前的订单数据当作冷数据，3 个月内的当作热数据。

方案二：根据“订单状态”字段来区分，已完结的订单当作冷数据，未完结的订单当作热数据。

方案三：组合方式，把下单时间 > 3 个月且状态为“已完结”的订单标识为冷数据，其他的当作热数据。

方案一：直接修改业务代码，每次业务请求触发冷热数据判断，根据结果路由到对应的冷数据表或热数据表。缺点：如果判断标准是 时间维度，数据过期了无法主动感知。

方案二：如果觉得修改业务代码，耦合性高，不易于后期维护。可以通过监听数据库变更日志 binlog 方式来触发

方案三：常用的手段是跑定时任务，一般是选择凌晨系统压力小的时候，通过跑批任务，将满足条件的冷数据迁移到其他存储介质。在途业务表中只留下来少量的热点数据。

判断数据是冷、还是热

将冷数据插入冷数据表中

然后，从原来的热库中删除迁移的数据

方案一：界面设计时会有选项区分，如上面举例的电商订单

方案二：直接在业务代码里区分。

索引：KEY `idx_shopid_orderno` (`shop_id`,`order_no`)

sql语句：select * from _t where orderno=''

查询匹配从左往右匹配，要使用order_no走索引，必须查询条件携带shop_id或者索引(shop_id,order_no)调换前后顺序。

索引：KEY `idx_mobile` (`mobile`)

sql语句：select * from _user where mobile=12345678901

隐式转换相当于在索引上做运算，会让索引失效。mobile是字符类型，使用了数字，应该使用字符串匹配，否则MySQL会用到隐式替换，导致索引失效。

索引：KEY `idx_a_b_c` (`a`, `b`, `c`)

sql语句：select * from _t where a = 1 and b = 2 order by c desc limit 10000, 10;

对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式：

1.一种是把上一次的最后一条数据，也即上面的c传过来，然后做“c < xxx”处理，但是这种一般需要改接口协议，并不一定可行；‘

2.另一种是采用延迟关联的方式进行处理，减少SQL回表，但是要记得索引需要完全覆盖才有效果，SQL改动如下：
select t1.* from _t t1, (select id from _t where a = 1 and b = 2 order by c desc limit 10000, 10) t2 where t1.id = t2.id;

索引：KEY `idx_shopid_status_created` (`shop_id`, `order_status`, `created_at`)

sql语句：select * from _order where shop_id = 1 and order_status in (1, 2, 3) order by created_at desc limit 10

in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高。

in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_dive_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。

解决：可以(order_status, created_at)互换前后顺序，并且调整SQL为延迟关联。

索引：KEY `idx_shopid_created_status` (`shop_id`, `created_at`, `order_status`)

sql语句：select * from _order where shop_id = 1 and created_at > '2021-01-01 00:00:00' and order_status = 10

范围查询还有“IN、between”。

如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用close方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。否则，如果在访问数据库的过程中，对Connection、Statement或ResultSet不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

一般而言，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为null，很有可能导致内存泄漏的发生。

如上面这个伪代码，通过readFromNet方法把接受的消息保存在变量msg中，然后调用saveDB方法把msg的内容保存到数据库中，此时msg已经就没用了，由于msg的生命周期与对象的生命周期相同，此时msg还不能回收，因此造成了内存泄漏。
实际上这个msg变量可以放在receiveMsg方法内部，当方法使用完，那么msg的生命周期也就结束，此时就可以回收了。还有一种方法，在使用完msg后，把msg设置为null，这样垃圾回收器也会回收msg的内存空间

public class Us ingRandom {
private String msg;
public void receiveMsg(){
readFromNet();//从网络中接受数据保存到msg中
saveDB();//把msg保存到数据库中
}

如果一个外部类的实例对象的方法返回了一个内部类的实例对象，这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄露。

当一个对象被存储进HashSet集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了，否则，对象修改后的哈希值与最初存储进HashSet集合中时的哈希值就不同了，在这种情况下，即使在contains方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄露

-XX:+PrintGC 输出简要GC日志
-XX:+PrintGCDetails 输出详细GC日志
-Xloggc:gc.log 输出GC日志到文件

1.JVM启动时增加两个参数:
# 出现OOME时生成堆dump:
-XX:+HeapDumpOnOutOfMemoryError
# 生成堆文件地址：
-XX:HeapDumpPath=/home/hadoop/dump/

2.jmap生成：发现程序异常前通过执行指令，直接生成当前JVM的dump文件
jmap -dump:file=文件名.dump [pid]
# 9257是指JVM的进程号
jmap -dump:format=b,file=testmap.dump 9257

第一种方式是一种事后方式，需要等待当前JVM出现问题后才能生成dump文件，实时性不高； 第二种方式在执行时，JVM是暂停服务的，所以对线上的运行会产生影响。所以建议第一种方式。

3.第三方可视化工具生成

排列有序，可重复

底层使用的数组结构

查询速度快，增删比较慢，getter()和setter()方法比较快

线程不安全

当容量不够时，ArrayList扩容为当前容量*1.5+1

排列有序，可重复

底层使用的数组结构

查询速度快，增删比较慢，getter()和setter()方法比较快

线程安全，效率低

当容量不够时，Vector默认扩容为一倍的容量

排列有序，可重复

底层使用的双向循环链表数据结构

查询速度慢，增删快，add()和remove()方法比较快

线程不安全

排列无序，不可重复

底层使用hash表实现

存取速度快

内部是hashmap

排列无序，不可重复

底层使用二叉树

排序存储

内部是TreeMap的SortedSet

采用hash表存储，并用双向链表记录插入顺序

内部是LinkedHashMap

1.堆溢出-java.lang.OutOfMemoryError:Java heap space

2.栈溢出-java.lang.OutOfMemoryError

3.栈溢出-java.lang.StackOverFlowError

4.元信息溢出-java.lang.OutOfMemoryError:Metaspace

5.直接内存溢出-java.lang.OutOfMemoryError：Direct buffer memory

6.GC超限-java.lang.OutOfMemoryError：GC overload limit exceeded

1.运行时异常，这种异常我们不需要进行处理，完全由虚拟机接管。写程序时不需要进行catch或者throw

2.NullPointerException-空指针引用异常

3.ClassCastException - 类型强制转换异常

4.IllegalArgumentException - 传递非法参数异常

5.ArithmeticException - 算术运算异常

6.ArrayStoreException - 向数组中存放与声明类型不兼容对象异常

7.IndexOutOfBoundsException - 下标越界异常

8.NumberFormatException - 数字格式异常

9.NegativeArraySizeException - 创建一个大小为负数的数组错误异常

10.SecurityException - 安全异常

11.UnsupportedOperationException - 不支持的操作异常

JVM栈中的引用

元空间中的静态引用

JNI中的引用（一般说的natice中的方法）

锁的引用

对象存活比较多的时候适用

适合老年代

提前GC

容易产生碎片空间

扫描了2次：标记存活对象、清除没有标记的对象

存活对象少，比较高效

扫描整个空间（标记存活对象并且复制移动）

适合年轻代

需要空闲空间

需要复制移动对象

1.JAVA 虚拟机提到过的处于方法区的元空间，它用来存储 class 类，常量，方法描述等。对元空间的回收主要包括废弃常量和无用的类。

2.对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存放对象的那一块)，少数情况会直接分配到老生代。

3.当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From Space 进行清理。

4.如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代。

5.在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环。

6.当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老年代中。之所以最大设置为15，是因为在对象头markword中表示的对象的分带年龄大小为4bit，最大值为15

单线程、复制算法

java虚拟机运行在Client模式下的默认新生代垃圾收集器

Serial+多线程

是Serial的多线程版本，java虚拟机运行在Server模式下的默认新生代垃圾收集器

多线程复制算法、高效

它重点关注的是程序达到一个可控制的吞吐量，高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而
不需要太多交互的任务。

自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个重要区别

单线程、标记整理算法

是Serial垃圾收集器的老年代版本

java虚拟机运行在Client模式下的默认老年代垃圾收集器

在 JDK1.5 之前版本中与新生代的 Parallel Scavenge 收集器搭配使用。作为年老代中使用 CMS 收集器的后备垃圾收集方案。

多线程、标记整理算法

Parallel Old 收集器是Parallel Scavenge的年老代版本。

Parallel Old 正是为了在老年代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略。

多线程、标记清除算法

其最主要目标是获取最短垃圾回收停顿时间，可以为交互比较高的程序提高用户体验

缺点

收集步骤

基于标记整理算法，不产生垃圾碎片，分配大对象不会提前GC

可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。充分利用cpu，多核条件下缩短stw

收集步骤

回收模式

与cms的区别

设置参数

Using filesort

Using index

Using temporary

ALL

order by会导致Using filesort，建立索引。数据量占大部分的情况下也会放弃使用索引。

group by会导致Using temporary; Using filesort，将分组字段使用索引即可解决；

由于 Using filesort是使用算法在 内存中进行排序，MySQL对于排序的记录的大小也是有做限制：max_length_for_sort_data，默认为1024。

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

比如场景：与别的公司进行对接数据，接口要暴露在外网，结果另外一家公司不靠谱泄露了秘钥之类的，所以拿这个顶上，因为布隆过滤器实际上是防止大量的不存在的key来攻击

当Redis版本小于4.0时，避免使用阻塞式命令KEYS，而是建议通过SCAN命令执行增量迭代扫描key，然后判断进行删除。

SCAN 命令是一个基于游标的迭代器，每次被调用之后， 都会向用户返回一个新的游标， 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程。

使用UNLINK命令安全的删除大key，该命令能够以非阻塞的方式，逐步的清理传入的key

Redis UNLINK 命令类似与 DEL 命令，表示删除指定的 key，如果指定 key 不存在，命令则忽略。
UNLINK 命令不同与 DEL 命令在于它是异步执行的，因此它不会阻塞。
UNLINK 命令是非阻塞删除，非阻塞删除简言之，就是将删除操作放到另外一个线程去处理。

优势是： 线程类只是实现了 Runnable 接口或 Callable 接口，还可以继承其他类。 在这种方式下，多个线程可以共享同一个 target 对象，所以非常适合多个相同线程来处理同 一份资源的情况，从而可以将 CPU、代码和数据分开，形成清晰的模型，较好地体现了面向 对象的思想。

劣势是：编程稍微复杂，如果要访问当前线程，则必须使用 Thread.currentThread()方法。

优势是：编写简单，如果需要访问当前线程，则无需使用 Thread.currentThread()方法，直接使用 this 即可获得当前线程。

劣势是：线程类已经继承了 Thread 类，所以不能再继承其他父类。

核心线程数和最大线程数大小一样；
没有所谓的非空闲时间，即 keepAliveTime 为 0；
 阻塞队列为无界队列 LinkedBlockingQueue，可能会导致 OOM(堆积的请求处理队列可能会耗费非常大的内存，甚至OOM)

提交任务；
如果线程数少于核心线程，创建核心线程执行任务；
如果线程数等于核心线程，把任务添加到 LinkedBlockingQueue 阻塞 队列；
如果线程执行完任务，去阻塞队列取任务，继续执行；

适用于处理 CPU 密集型的任务，确保 CPU 在长期被工作 线程使用的情况下，尽可能的少的分配线程，即适用执行长期的任务。

核心线程数为 0 ；
最大线程数为 Integer.MAX_VALUE，即无限大，可能会因为无限创建 线程，导致 OOM ；
阻塞队列是 SynchronousQueue；
非核心线程空闲存活时间为 60 秒；

当提交任务的速度大于处理任务的速度时，每次提交一个任务，就必然会 创建一个线程。极端情况下会创建过多的线程，耗尽 CPU 和内存资源。由 于空闲 60 秒的线程会被终止，长时间保持空闲的 CachedThreadPool 不 会占用任何资源。

提交任务；
因为没有核心线程，所以任务直接加到 SynchronousQueue 队列；
判断是否有空闲线程，如果有，就去取出任务执行。
如果没有空闲线程，就新建一个线程执行。 
执行完任务的线程，还可以存活 60 秒，如果在这期间，接到任务， 可以继续活下去；否则，被销毁

用于并发执行大量短期的小任务。

核心线程数为 1 ；
最大线程数也为 1；
阻塞队列是无界队列 LinkedBlockingQueue，可能会导致 OOM ；
keepAliveTime 为 0；

提交任务；
线程池是否有一条线程在，如果没有，新建线程执行任务 ；
如果有，将任务加到阻塞队列 ；
当前的唯一线程，从队列取任务，执行完一个，再继续取，一个线程 执行任务。

适用于串行执行任务的场景，一个任务一个任务地执行。

最大线程数为 Integer.MAX_VALUE，也有 OOM 的风险 ；
阻塞队列是 DelayedWorkQueue ；
keepAliveTime 为 0 ；
scheduleAtFixedRate() ：按某种速率周期执行 ；
scheduleWithFixedDelay()：在某个延迟后执行；

1.线程从 DelayQueue 中获取已到期的 ScheduledFutureTask （DelayQueue.take()）。到期任务是指 ScheduledFutureTask 的 time 大于等于当前时间。

2.线程执行这个 ScheduledFutureTask。

3.线程修改 ScheduledFutureTask 的 time 变量为下次将要被执行的时 间。

4.线程把这个修改 time 之后的 ScheduledFutureTask 放回 DelayQueue 中（DelayQueue.add()）。

周期性执行任务的场景，需要限制线程数量的场景

ABA问题：并发环境下，假设初始条件是 A，去修改数据时，发现是 A 就会执行修改。 但是看到的虽然是 A，中间可能发生了 A 变 B，B 又变回 A 的情况。此时 A 已经非彼 A，数据即使成功修改，也可能有问题。

解决方案：加版本号、时间戳等

问题：自旋 CAS，如果一直循环执行，一直不成功，会给 CPU 带来非常大的执行 开销。

解决方案：在 Java 中，很多使用自旋 CAS 的地方，会有一个自旋次数的限制，超过一 定次数，就停止自旋

问题：CAS 保证的是对一个变量执行操作的原子性，如果对多个变量操作时，CAS 目前无法直接保证操作的原子性的。

解决方案：可以考虑改用锁来保证操作的原子性；可以考虑合并多个变量，将多个变量封装成一个对象，通过 AtomicReference 来保证原子性。

如果你的代码只读数据，可以很多人同时读，但不能同时写，那就上读锁

如果你的代码修改数据，只能有一个人在写，且不能同时读取，那就上写锁。总之，读的时候上读锁，写的时候上写锁！

由于消息 topic 由多个 partition 组成，且 partition 会均衡分布到不同 broker 上，因此，为了有
效利用 broker 集群的性能，提高消息的吞吐量，producer 可以通过随机或者 hash 等方式，将消
息平均发送到多个 partition 上，以实现负载均衡。

是提高消息吞吐量重要的方式，Producer 端可以在内存中合并多条消息后，以一次请求的方式发送了批量的消息给 broker，从而大大减少 broker 存储消息的 IO 操作次数。但也一定程度上影响了消息的实时性，相当于以时延代价，换取更好的吞吐量。

Producer 端可以通过 GZIP 或 Snappy 格式对消息集合进行压缩。Producer 端进行压缩之后，在Consumer 端需进行解压。压缩的好处就是减少传输的数据量，减轻对网络传输的压力，在对大数据处理上，瓶颈往往体现在网络上而不是 CPU（压缩和解压会耗掉部分 CPU 资源）。

答：确保所有的follower与leader同步完成，leader再发送ack ,这样才能保证leader挂掉之后,能在follower中选举出新的leader

1.半数以上的follower同步完成，即可发送ack

2.全部的follower同步完成，才可以发送ack

3.kafka选择的是第二种方案(全部同步)

1.场景：采用第二种方案之后,设想以下情景: leader收到数据,所有follower 都开始同步数据，但有一个follower,因为某种故障,迟迟不能与leader进行同步,那leader就要- -直等 下去,直到它完成同步，才能发送ack。这个问题怎么解决呢?

2.解决方案：Leader维护了- -个动态的in-sync replica set(ISR)，意为和leader保持同步的follower 集合。当ISR中的follower完成数据的同步之后,leader就会给follower发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag. time.max.ms参数设定。Leader 发生故障之后，就会从ISR中选举新的leader.

3.Replica.lag.time.max.ms、Replica.lag.time.max.messages
低版本的kafka使用时间跟条数2个条件
0.9之后高版本的kafka只使用时间条件：在延迟时间内就加入进来，在延迟时间外就剔出。
默认延时时间为10秒（如果不能及时的发送抓取请求或者不能及时的消费到最后一个消息，这个follower会被leader移出ISR）

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。request.required.asks=0

1.acks=0：

2.acks=1：

3.acks=-1（All）：

follower发生故障后会被临时踢出ISR,待该follower恢复后，follower 会读取本地磁盘记录的上次的HW,并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。

leader发生故障之后，会从ISR中选出一个新的leader,之后，为保证多个副本之间的数据一致性,其余的follower会先将各自的log文件高于HW的部分截掉,然后从新的leader同步数据。.

注意:这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

将服务器的ACK级别设置为-1,可以保证Producer到Server之间不会丢失数据，即At Least Once语义。

At Least once语义可以保证数据不丢失，但是不能保证数据不重复

将服务器ACK级别设置为0,可以保证生产者每条消息只会被发送一次，即At Most Once语义。

At Most Once语义可以保证数据不重复但是不能保证不丢失，但是对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据即不重复也不丢失，即Exactly Once语义

1.在0.11版本以前的Kafka,对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况,每个都需要单独做全局去重,这就对性能造成了很大影响。

2.在0.11版本的Kafka,引入了一项重大特性:幂等性。所谓的幂等性就是指Producer不论向Server发送多少次重复数据，Server 端都只会持久化一条。幂等性结合At Least Once语义，就构成了Kafka的Exactly Once语义。即:At Least Once+幂等性= Exactly Once

3.要启用幂等性,只需要将Producer的参数中enable idompotence设置为true即可。Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer在初始化的时候会被分配一个PID， 发往同一Partition 的消息会附带Sequence Number。而Broker端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。

4.但是PID重启就会变化，同时不同的Partition也具有不同主键，所以幂等性无法保证跨分区跨会话的Exactly Once。

总结：1.需要设置acks为-1，保证了生产者到server之间数据不丢失，不能保证数据不重复；2.启用幂等性，这样在上游进行了去重，进而保证了数据不重复

RoundRobinAssignor的分配策略是将消费组内订阅的所有Topic的分区及所有消费者进行排序后尽量均衡的分配（RangeAssignor是针对单个Topic的分区进行排序分配的）。如果消费组内，消费者订阅的Topic列表是相同的（每个消费者都订阅了相同的Topic），那么分配结果是尽量均衡的（消费者之间分配到的分区数的差值不会超过1）。如果订阅的Topic列表是不同的，那么分配结果是不保证“尽量均衡”的，因为某些消费者不参与一些Topic的分配

举例1：4个分区3个消费者的场景，分配结果如下:
C0: [P0, P3]、C1: [P1]、C2: [P2]
无法完全均衡分配的场景，排序更靠前的消费者分配到更多的分区

举例2：2个topic，每个topic4个分区, 3个消费者的场景，分配结果如下:
CO: [TOPO，TOP3， T1P2]、C1: [T0P1， T1P0，T1P3]、C2: [T0P2，T1P1]
无法完全均衡分配的场景，排序更靠前的消费者分配到更多的分区

RangeAssignor对每个Topic进行独立的分区分配。对于每一个Topic，首先对分区按照分区ID进行排序，然后订阅这个Topic的消费组的消费者再进行排序，之后尽量均衡的将分区分配给消费者。这里只能是尽量均衡，因为分区数可能无法被消费者数量整除，那么有一些消费者就会多分配到一些分区

1.四个分区p0、p1、p2、p3,两个消费c0、c1，分配情况为：c0(p0、p1)、c1（p2、p3）

2.四个分区p0、p1、p2、p3,三个消费c0、c1、c2，分配情况为：c0（p0、p1）、c1（p2）、c2（p3），即无法完成均衡分配的场景。排序更靠前的消费者分配到更多的分区

3.四个分区p0、p1、p2、p3,五个消费c0、c1、c2、c3、c4，分配情况为：c0（p0）、c1（p1）、c2（p2）、c3（p3），即消费者大于分区数量，排名靠前的消费者分配到分区，排名靠后的分配不到分区

注：这种分配方式明显的一个问题是随着消费者订阅的Topic的数量的增加，不均衡的问题会越来越严重，比如上图中4个分区3个消费者的场景，C0会多分配一个分区。如果此时再订阅一个分区数为4的Topic，那么C0又会比C1、C2多分配一个分区，这样C0总共就比C1、C2多分配两个分区了，而且随着Topic的增加，这个情况会越来越严重。
分配结果：订阅2个Topic，每个Topic4个分区，共3个Consumer
C0：[T0P0，T0P1，T1P0，T1P1]
C1：[T0P2，T1P2]
C2：[T0P3，T1P3]

StickyAssignor分区分配算法，目的是在执行一次新的分配时，能在上一次分配的结果的基础上，尽量少的调整分区分配的变动，节省因分区分配变化带来的开销。Sticky是“粘性的”，可以理解为分配结果是带“粘性的”——每一次分配变更相对上一次分配做最少的变动。其目标有两点：
分区的分配尽量的均衡。
每一次重分配的结果尽量与上一次分配结果保持一致。
当这两个目标发生冲突时，优先保证第一个目标。第一个目标是每个分配算法都尽量尝试去完成的，而第二个目标才真正体现出StickyAssignor特性的

由于Consumer在消费过程中可能会出现断电宕机等故障，Consumer恢复后，需要从故障前的位置继续消费，所以Consumer需要实时记录自己消费到哪个位置，以便故障恢复后继续消费。Kafka0.9版本之前，Consumer默认将offset保存在zookeeper中，从0.9版本开始，Consumer默认将offset保存在Kafka一个内置的名字叫_consumeroffsets的topic中。默认是无法读取的，可以通过设置consumer.properties中的exclude.internal.topics=false来读取。

场景:业务处理伴随消息的发送，业务处理失败(事物回滚)后要求消息不发送。rabbitmq 使用调用者的外部事物，通常是首选，因为它是非侵入性的(低耦合)。

消息积压处理办法：临时紧急扩容：

先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。
新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不
做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。
这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费
数据。
等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消
息。