总结2

中间件

1、kafka

• 发送消息为push推模式，消费消息为pull拉模式（优点是可以批量消费，提高效率）
• broker：一个kafka实例
• partions分区：topic消息均匀分布到不同的分区上，用于存储消息，本身就是一个文件夹(segment)，里面的文件是index和log,log文件存放消息.
• 集群中的角色(broker的主节点叫Controller,分区主节点的角色Leader,其它副本角色follower)，Controller的数据存放到zk中，分区Leader的元数据信息存放到Controller中；消息数据通过defaultPartion(根据hash取值)，消息分到对应的broker中。
• Broker的主节点由zk进行选举，同时Broker向zk发送心跳，Partion的Leader由Controller进行选举。
• AR:所有的副本，对应的有ISR+OSR；
• ISR:副本同步队列，由leader维护，里面维护着副本跟Leader同步的数据，后续用于选择新的Leader；如果同步存在延迟或者超时，则会将该follower移到OSR中,新加入的Follower也是加入到OSR中。
• 对应选举新的Leader，如果ISR中没有节点或者全部下线，那么就看配置unclean参数是否为true，如果为true，就代表可以从OSR中选择节点进行选择Leader，但是这样容易导致数据丢失；如果全部下线或者没有存活的节点，那么就进行等待，直到有新的节点上线，就选为Leader
• kafka的读写操作是主读主写，体现在Controller，所有的操作都向Controller进行咨询，获取到要操作的主分区，
• kafka快的原因：是用pageCache,顺序读写(不需要进行寻址)，数据批处理，零拷贝（数据的消费者而言：数据直接在内核完成输入和输出，不需要拷贝到用户空间再写出去，不经过应用空间，减少了2次copy；后续的发送者来说：kafka数据写入磁盘前，数据先写到进程的内存空间。）
• kafka发送消息的方式：同步发送和异步发送
• 同步发送：可以采用ack机制（0：不ack,，1：leader节点收到数据就返回；-1：leader和replica收到数据才返回）
• 异步发送：有缓存区，如果保证数据不丢失，就不设置缓存阻塞超时时间
• 可以动态的增加分区或者消费Consumer，可以reblance，有kafka中的Conorditor中进行维护。

2、kafka消息发送与消费

• kafka的消费偏移量offset是作为消息提交到__consumer_offset分区中，通过的group.id作为key进行写入，默认的分区是50个。
• kafka的发送路由策略：指定key，指定分区，不指定进行轮询。
• 消息的发送：连接到Controller，返回对应的分区Leader，然后跟分区Leader进行通信，将消息写入
• HW(高水位)：指客户端能消费到的最后一条偏移量消息（消费者只能拉取这个offset之前的消息），它是由各自分区的LEO进行维护偏移量，当每个分区的LEO维护到同一个offset时，即位HW
• HW截断机制：就是分区主节点挂断，有新的主节点启动，当老的Leader又恢复时，此时会将自身的LEO回退到宕机时的HW水位，就将自己HW之后的数据全部截断，后续的数据按照新的主节点进行数据同步。
• https://www.cnblogs.com/yoke/p/11486196.html  每个分区同步到主节点上的数据后，LEO向下一个偏移量移动，直到所有的分区的LEO到达同一offset，此时形成HW,即客户端可以消费了。
• 
• kafka发送重复消息的机制：KafkaProducer后台创建一个线程KafaThread会扫描RecordAccumulator中是否有消息，当客户端调用kafkaProducer.send时，其实是把消息保存到RecordAccumulator中；然后后台KafkaThread进行扫描，有消息就将消息发送到集群中，如果成功，就返回，如果失败，就就行判断是否允许重试：①是否允许重试，不允许就直接返回失败；②判断失败的次数是否达到上限，可以重试的话，则又把消息保存到RecordAccumulator中，等待通过KafaThread线程扫描，又消息则进行重新发到集群中，如果已达到上限，则丢弃该消息。
• 重复消费：产生的原因就是偏移量offset未进行提交或者reblance；有2种提交方式：自动提交和手动提交
• 自动提交：可以设置seesion.time.out来设置默认消费的提交时间，然后消费的数据量通过max.pull.record进行设置，如果在规定的时间内，没有消费完record，这种情况就不会进行自动提交。因为需要维持seesion,time.out和max.pull.size之间的关系，适当延长session的超时时间，还要auto.commit.interval.ms参数也是定期的提交offset。
• 手动提交：自己消费完消息后，手动提交offset，可以消费一条提交一次，也可以批量提交这样不会重复消费。

redis

• redis的分布式锁实现方式：线程间共享（天然满足），互斥性（api返回值不同判断），锁释放（锁的自定义名称、带超时时间的key），可重入性（计算获取锁的次数）、api操作的原子性（lua脚本）
• redis的三种集群模型：主从，哨兵，集群（redis从3.0开始支持的）
• redis持久化方式：RDB（定时的内存快照），AOF（写操作日志进行持久化）
• redis的主从节点数据同步机制：全量同步（新的从节点或者节点发送SYNC命令到主节点，此时主节点适应RDB+快照后续的日志文件进行全量同步）、增量同步（主节点接收到的数据命令立刻同步到从节点，使用replicationFeedSlaves函数同步到从服务器）
• 跳跃表：在有序链表的基础上进行了扩展，解决了有序链表结构查找特定值困难的问题，查找特定值的时间复杂度为O(logn)
• redis快的原因：基于内存的操作，而且是多路复用（一次连接多次请求），单线程操作，减少了资源的切换，提供效率
• redis的淘汰策略：6中淘汰策略，通常使用：RLU算法【最近最少使用】
• reids的事务实现：Multi开始事务，exec:执行指令集合的序列；discard:清除集合中的指令，watch：当某个key的值发生变化时，指令集合也被清空。redis的事务没有回滚操作，只是将指令集合中的指令清空。

mysql

• mysql使用的存储引擎（存储引擎针对表来说），主要有：innodb,myisam,memory,其中innodb是默认的，有2个存储文件（.frm和.db），myisam比较快，但是不支持事务和行锁。
• 日志文件：①二进制(bin-log)文件：用于做数据恢复和备份使用的，只要是通过记录dml,ddl语言实现的。②慢查询日志：设置sql语句执行的超时时间，找出查询慢的sql语句可进行explain分析（分析的维度：type，key,rows,extra等）③事务日志：主要为redolog，undolog
• innodb的存储数据结构：B+Tree，特点：叶子节点存储行数据，而且是有序的，每个叶子节点之间有链表指针指向，非叶子节点存储的是键值信息。
• 索引类型：聚集索引（主键id的索引，叶子节点存储的是行数据）、非聚集索引（存储的都是键值信息）。由此引出索引覆盖：就是通过在非聚集索引的主键值，在聚集索引上找到对应的行数据，此操作避免了回表，增加了查询效率。
• 执行计划关注的点：type：ref,index,range这些，rows：所需要扫描的行数，值越小越好，key：查询中使用到的索引，extra:关注一些use where,use condition这些条件。
• 组合索引，最左前缀原则：带头大哥不能时死，中间不能断。
• 行锁：由innodb存储引擎实现，范围为：记录锁，间隙锁，next-key锁；从功能上分为共享读锁，排他写锁。
• 事务的隔离级别及解决的问题：RU【未授权读，读取未提及数据】，RC【读取别的事务提交的数据，可以避免脏读】，RR【repeatable read可重复读，不会读取别的事务修改后的数据，避免不可重复读】，Serializable【序列化，所以的操作都加行锁，最安全，避免幻读】；说明①不可重复读是针对数据的修改不会再次读取，强调的是数据本身值②幻读是指数据的条数更改（增加或者删除记录），强调的是数据的行数。
• 事务的保证：redolog,undolog https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html 在概念上，innodb通过force log at commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。
• redolog:通常是物理日志，记录的是数据页的物理修改，用于保证数据的持久性。
• undolog:提供回滚和多个行版本控制(MVCC)；用来回滚行记录到某个版本，一般是逻辑日志，根据每行记录进行记录。
• 怎么进行sql优化：①开启慢查询日志，找出执行sql语句超过规定时间的sql②使用explain执行计划，查看一些关键参数指标（type：index,rang,ref；rows：所需要扫描的行数，越小说明需要扫描的行数少；key：语句中用到的索引；extra：一些附属说明：use condition,use where）三profile查看硬件瓶颈④表层面的优化（冗余字段设计，索引，组合索引）④sql语句的优化（join查询，on条件索引创建，组合索引，索引覆盖，少用count(*)）
• MVCC的实现：多版本并发控制，在有行锁记录的时候，不影响读操作。通过undolog+readview实现，readview里面有事务链表，记录当前所有事务的id，当读操作的事务id小于当前链表的最小值，那么就都可以查看，大于当前链表中的最大值，就不看查看记录。
• 分库分表实现及原则：使用sharding-jdbc;其实就是配置逻辑表与数据节点（真实的表和所在的db）的绑定关系，使用分片的键key进行分片，原则是E-R分片和全量表，尽量减少跨库的join查询。

分布式事务

• 在分布式事务中，主要就是CAP【一致性(Consistency)，可用性(Availability)，分区容错性(Partition tolerance)的缩写】理论和Base理论【基本可用(Basically Available),软状态(soft state)和最终一致性(Eventually consistent)】
• 一致性：进程对其中一个节点的数据进行更新，同时其它的数据副本也需要实时的更新，另一个级进程读取其它节点的数据也能保证是最新的。
• CAP理论：三者不可兼得，取CP【强调的是：数据强一致性，比如zk】或者AP【强调的是：高可用性，比如euraka】
• base理论：核心思想是即使无法做到强一致，但应用根据自身特点，得到最终一致性，反应在分布式设计中，主要考虑AP，然后最终实现一致性。
• 实现的理论：二阶段提交【RocketMQ】，三阶段提交，tcc【ttc-transation已实现，过程是try-confirm-cancle；先try欲占用资源，然后提供就confirm确定，失败就cancle取消】

Java

1、线程池

• 并行与并发的区别：并行是指利用CPU的多核机制（多个处理器同时处理多个任务）在某一个时间点上，有多个任务在同时执行；并发是在某一个时间点上，只有一个任务在执行，只是利用cpu进行资源的切换，"看上去"多个任务在同时执行。
• 常用的线程池：

  newFixedThreadPool,固定大小的线程池，所谓的固定大小是指core=max，使用的阻塞队列是无界队列LinkedBlockingQueue 
  newSingleThreadExecutor:单线程执行任务的线程池，里面的core和max都是1，也是使用无界的队列   
  newCachedThreadPool：带缓冲的线程池，此时的max是Integer.MAX_VALUE，意思为最大的线程数可以一直增大，使用的队列是有序队列：SynchronousQueue，它的特点是里面阻塞的，只能存一个线程任务在队列，其它的任务再进来则继续创建新线程(core时，max再创建一个)                                                                                  newSingleThreadScheduledExecutor:带定时任务的单线程池                                     newScheduledThreadPool：定时任务线程池，里面直到core的大小,对应的max也是最大值，只是使用的队列时延迟队列DelayedWorkQueue:延迟队列

• 接口参数

corePoolSize：核心池的大小,超过后放到缓存队列当中.
maximumPoolSize:线程池最大线程数，表示线程中最多能创建多少个线程
keepAliveTime:当前线程数多余核心线程数，多余下来的线程最长的空闲时间。
workQueue：阻塞队列，一般有数组(ArrayBlocking)，链表(LinkedBlocking)和带有优先级权限的队列,一般都是使用LinkedBlockingQueue
handler:有四种处理模式：①拒绝，抛出异常②不做任何处理；三：使用当前线程执行任务④将阻塞队列的头部元素丢弃，当前任务执行或者放入阻塞队列。

流程：poolSize < core,直接创建，当前线程池种线程>core;则会进入阻塞队列 进行等待，如果阻塞队列也满了，且core<max，则也会继续创建线程执行，如果core得到max,阻塞队列也满了，那么进行策略选择。

• 都会产生OOM，只是原因不同，一个是因为无界的阻塞队列，一个是因为max是Integer的最大值。

2、锁及升级

• synchorized与lock的区间:

1. synchorized是关键字，使用jvm的monitorEnter和monitorExist进行加锁和释放锁，lock是接口，使用它的接口进行锁操作
2. synchorized的锁出现异常后可以自动释放，而lock不行，因此一定要在finally里面释放
3. synchorized的锁是不可中断的，lock可以进行尝试获取锁，中断锁，可以区分读锁和写锁
4. lock和Condition的组合可以做到经确获取（可以实现线程ABC按照顺序启动，线程池中的阻塞队列就是按照此组合实现的，里面的Condition时Full，empty），synchorized的唤醒是随机的，要么全部唤醒

• 锁(synchorized)升级：无锁，偏向锁，轻量级锁，重量级锁（由低到高，锁可以升级，但是不能降级，从低到高的的过程叫做锁膨胀）

偏向锁：只有一个线程进行资源的获取，利用CAS算法进行一次置换ThreadID,得到对应的锁资源，

轻量级锁：当有线程进行资源竞争时，通常是第二个线程进行尝试获取锁，此时偏向锁升级为轻量级锁，两个线程交替执行进行获取，没有拿到锁的线程进行自旋（就是cpu空转，进行循环尝试），如果自旋的时间过长则会损耗一定的性能，优点是减少线程切换，响应速度加快。

重量级锁：当竞争的线程达到多个时或者自旋到一定时间还未获得锁时，此时锁升级为重量级锁，此时线程进行阻塞等待，不会自旋，减少占用CPU时间。

3、Spring的事务传播级别与AOP概念

requried:默认的级别，当前方法如果有事务，则加入当前事务，没有事务就创建新事务
requried_new:新创建事务，如果当前存在事务，则把当前事务挂起
support：有事务就加入该事务，如果没有事务，就以非事务的方式继续执行
mandatory：必须存在事务，否则就会刨出异常
nerver:如果存在事务，就会抛出异常

切面：进行代理增强的类，主要的功能写在这里

连接点：针对被增强类里面的普通方法

切入点：通过切入点表达式找到对应的连接点，切入后根据不同的通知方式进行增强

通知：具体增强的方式：前置，正常后置通知【出现异常则不会执行】，环绕，异常返回通知【出现异常则会调用】，后置【不管有无异常，都是执行】

execution表达式写法: 方法访问修饰符  返回值类型  包路径.类.方法(参数)
* 【任意方法返回和方法修饰符】com.wm.cloud.microservice.mno.service.api.IOTServiceApi.*(..)【名称，参数都是任意的】
代表api包下的IOTServiceApi类所有的方法（方法访问权限，方法返回值，名称，参数都是任意的）

4、并发编程下常用的类：

• countdownlatch：是一个同步工具类，用来协调多个线程之间的同步，能够使一个线程在等待另外一些线程完成各自工作之后，再继续执行。使用一个计数器进行实现。计数器初始值为线程的数量。当每一个线程完成自己任务后，计数器的值就会减一【cdl.countDown()】。当计数器的值为0时，表示所有的线程都已经完成一些任务，然后在CountDownLatch上等待的线程就可以恢复执行接下来的任务【保证多个线程使用的是同一个CountDownLatch对象】【作用：可以使多个线程同时执行】【秦国统一六国，一个个减】
• CyclicBarrier：也是线程同步工具类，它与countdownlatch不同的是，它的计算器是加1，当累加器的值到某一个值时，阻塞的线程才会全部启动【召唤七颗龙珠，一个个加】
• 信号量：以上两种的计数都是一个方向的增或者减，信号量是多个线程同时竞争多个资源，信号量里面维护的数值即为资源个数，当信号量值大于0是，此时线程就可以进行抢占资源做事，如果为0则进行阻塞【停车场的车位与外面等待进场的车子类似】，线程执行完后，需要进行release释放资源。