个人整理：
一 设计模式专题
二 多线程高并发专题

三 redis专题
1.redis持久化机制,redis事务
2.redis为什么这么快,redis的优点
3.redis丰富的数据结构,应用场景以及内部结构。
4.redis主从复制原理及缓存一致性问题
5.redis缓存穿透,缓存雪崩,缓存更新,缓存降级等
6.redis模式:单机/主从复制/高可用性(sentinal哨兵机制）/集群
7.redis性能及常见问题
8.redis线程模型–单线程模型
9.redis删除策略和淘汰机制
10.redis 集群数据倾斜 数据分片；redis 底层实现原理

四 rocketMq专题
1.mq如何保证消息100%投递?如何实现幂等性？
消息投递保证三种方式:
At most once 消息可能会丢，但绝不会重复传输
At least one 消息绝不会丢，但可能会重复传输
Exactly once 每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。
2.应用场景？异步处理,应用解耦,流量削峰,日志处理,消息通讯
3.activeMQ,rabbitMQ,rocketMQ,Kafka区别？性能,消息持久化,活跃度,综合评价
4.架构及组件概念
5.死信队列(消息拒绝且不重复投递,消息过期,队列达到最⼤长度)
6.流量量控制(qos即服务端限流，qos对于拉模式的消费⽅方式无效)

五 kafka专题
0.kafka为什么这么快
Kafka速度在于它把所有的消息都变成一个批量的文件，进行合理的批量压缩，减少网络IO损耗，通过mmap提高IO速度，写入数据的时候由于单个Partion是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。
1.顺序问题
a.为什么要保证消息的顺序？如何保证消息顺序？
b.顺序异常解决方案–异步重试机制elastic-job
2.消息积压
消息体过大,路由规则不合理,批量操作引起的连锁反应,表过大
3.主键冲突–ON DUPLICATE KEY UPDATE
4.数据库主从延迟
5.重复消费,多环境消费问题

数据文件分段segment(顺序读写、分段命令、二分查找)
数据文件索引(分段索引、稀疏存储)

六 ElasticSearch专题

七 微服务专题

八 中间件专题(dubbo,zookeeper,seata,sentinal,nacos,skywalking)
Dubbo:

01.Dubbo中的SPI机制
1.Dubbo 启动Main.main(args)原理 注册Zookeeper原理 多协议及配置
2.负载均衡算法–权重随机算法 最少活跃调用数算法 hash一致性算法 加权轮询算法
3.集群容错 （网络延迟，网络中断，服务异常）
在集群调用失败时，Dubbo 提供了多种容错方案，缺省为cluster–failover
failover:失败自动切换，当出现失败，重试其它服务器,适合读操作,延迟会更大,可通过 retries="2"来设置重试次数(不含第一次)
Failfast：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking：并行调用多个服务器，只要一个成功即返回。 通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 可通过 forks=“2” 来设置最大并行数。
Broadcast：广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0 开始支持) 通常用于通知所有提供者更新缓存或日志等本地资源信息。
在实际应用中 查询语句容错策略建议使用默认 Failover Cluster ，而增删改 建议使用 Failfast Cluster 或者 使用 Failover Cluster(retries=”0”) 策略 防止出现数据 重复 添加等等其它问题!建议在设计接口时候把查询接口方法单独做一个接口提供查询。
4.服务降级
自动降级和人工降级

1. 对一些非核心服务进行人工降级
2. 故障降级，比如调用的远程服务挂了，网络故障、或者 RPC 服务返回异常。降级的方案比如设置默认值、采用兜底数据
3. 限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能会导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阀值 时，后续的请求被降级，比如进入排队页面，比如跳转到错误页(活动太火爆，稍 后重试等)
   Dubbo 中如何实现服务降级呢?Dubbo 中提供了一个 mock 的配置，可以通过 mock 来实现当服务提供方出现网络异常或者挂掉以后，客户端不抛出异常，而是通过 Mock 数据返回自定义的数据
   5.启动时检查 registry、reference、consumer 都可以配置 check 这个属性.
   6.多版本支持
   当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间 不引用。
   7.动态配置规则
   Dubbo 能支持的配置中心有:apollo、nacos、zookeeper
   8.Dubbo 中的 SPI 机制(核心)
   SPI 的缺点
   \1. JDK 标准的 SPI 会一次性加载实例化扩展点的所有实现，如果你在 META-INF/service 下的文件里面加了 N 个实现类，那么 JDK 启动的时候都会一次性全部加载。那么如果有的扩展点实现初始化很耗时或者如果有些实现类并没有用到， 那么会很浪费资源
   \2. 如果扩展点加载失败，会导致调用方报错，而且这个错误很难定位到是这个原因 Dubbo 优化后的 SPI 机制
   基于Dubbo SPI 的实现自己的扩展，有两个规则
   \1. 需要在 resource 目录下配置 META-INF/dubbo 或者 META-INF/dubbo/internal 或者 META-INF/services，并基于 SPI 接口去 创建一个文件
   \2. 文件名称和接口名称保持一致，文件内容和 SPI 有差异，内容是 KEY 对应 Value
   Dubbo 针对的扩展点非常多，可以针对协议、拦截、集群、路由、负载均衡、序列化、容器…几乎里面用到的所有功能，都可以实现自己的扩展，这个是dubbo比较强大的一点。
   Dubbo 的扩展点原理实现
   所谓的扩展点，就是通过指定目录下配置一个对应接口的实现类，然后程序会进行查找和解析，找到对应的扩展点。
   扩展点，就是通过指定目录下配置一个对应接口的实现类，然后程序会进行查找和解析，找到对应的扩展点。(解析 实例化)
   ExtensionLoader.getExtensionLoader(Protocol.class).getExtension(“myProtocol”);
   Adaptive 自适应扩展点
   Compiler compiler=ExtensionLoader.getExtensionLoader(Compiler.class).getAdaptiveExtension();
   它是怎么实现的呢? 我们根据返回的 AdaptiveCompiler 这个类，看到这个类上面有一个注解@Adaptive。 这个就是一个自适应 扩展点的标识。它可以修饰在类上，也可以修饰在方法上面。这两者有什么区别呢? 简单来说，放在类上，说明当前类是一个确定的自适应扩展点的类。如果是放在方法级别，那么需要生成一个动态字节码来进行转发。
   Activate 自动激活扩展点
   设计的初衷是，对于一个类会加载多个扩展点的实现，这个时候可以通过自动激活扩展点进行动态加载， 从而简化配置我们的配置工作
   @Activate 提供了一些配置来允许我们配置加载条件，比如 group 过滤，比如 key 过滤。
   9.Dubbo服务发布源码—读取配置 服务注册 netty启动发布
   Dubbo中spring扩展就是使用 spring 的自定义类型，所以同样也有NamespaceHandler、BeanDefinitionParser。
   Dubbo中是DubboNamespaceHandler DubboBeanDefinitionParser
   如果我们想看 dubbo:service 的配置，就直接看 DubboBeanDefinitionParser(ServiceBean.class,true)
   服务发布和服务调用的两个配置的解析，试用的是ServiceBean 和 referenceBean
   ServiceBean 的实现
   ServiceBean 这个类，分别实现了 InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener, BeanNameAware, ApplicationEventPublisherAware
   spring 事件发送监听由 3 个部分组成
   1.ApplicationEvent:表示事件本身，自定义事件需要继承该类
   2.ApplicationEventPublisherAware:事件发送器，需要实现该接口
   3.ApplicationListener:事件监听器接口
   ServiceBean 中服务暴露过程
   在 ServiceBean 中，我们暂且只需要关注两个方法，分别是:
   在初始化 bean 的时候会执行该方法 afterPropertiesSet,
   spring 容器启动后会发一个事件通知 onApplicationEvent–export方法
   Invoke 本质上应该是一个代理，经过层层包装最终进行了发布。当消费者发起请求的时候，会获得这个 invoker 进行调用。
   服务注册和消费 源码
   Dubbo通信和负载均衡源码
   会从url中获得当前的负载均衡算法，然后使用spi机制来获得负载 均衡的扩展点。然后返回一个具体的实现

Zookeeper:
羊群效应：
最核心的思路就是获取锁时创建一个临时顺序节点，顺序最小的那个才能获取到锁，之后尝试加锁的客户端就监听自己的上一个顺序节点，当上一个顺序节点释放锁之后，自己尝试加锁，其余的客户端都对上一个临时顺序节点监听，不会一窝蜂的去尝试给同一个节点加锁导致羊群效应。

九 性能优化专题(JVM,Mysql,Tomcat)
Tomcat:架构 启动 优化
默认200 maxThreads=“150” minSpareThreads=“4” maxConnections acceptCount
1.标签优化
2.启动速度优化 删除无用的web应用,关闭webSocket,随机数优化(jvm),多线程启动
3.其他方面 Connector(配置压缩),数据库方面,浏览器缓存或nginx静态资源部署等

JVM:(内存区域 运行时内存 垃圾回收与算法/收集器 JavaIO 类加载机制及双亲委派)
1.栈 堆 方法区 相互指向。(一个类中诠释如何在内存区域中分配,堆-实例变量和数组)
2.java对象内存布局及内存模型
3.Minor GC:新生代 Major GC:老年代 Full GC:新生代+老年代
频发的Full GC消耗的时间很长,会影响大型程序的执行和响应速度;Full GC产生原因
-Xmx20M -Xms20M
Xss128k:设置每个线程的堆栈大小。JDK 5以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。
4.类加载机制及双亲委派模型
5.垃圾收集算法及收集器

十 源码专题(spring mybatis dubbo zookeeper)

十一 网络通信netty
1.阻塞 非阻塞;同步 异步;BIO NIO AIO
在多路复用模型，事件通知用户线程,自行读取数据 处理数据。
在异步IO模型,内核处理数据完成,存入用户线程指定缓冲区,通知用户读取处理数据。

十二：数据结构和算法
时间复杂度,算法思想,排序,搜索,查找,字符串匹配,线性表,散列表,树,图,其他。

十三：Docker K8S ServiceMesh lstio
监控平台(node-exporter+promethus+grafana)

在Istio中到底能解决哪些问题
(1)针对HTTP、gRPC、WebSocket等协议的自动负载均衡 (2)故障的排查、应用的容错、众多路由 (3)流量控制、全链路安全访问控制与认证 (4)请求遥测、日志分析以及全链路跟踪 (5)应用的升级发布、频率限制和配合等

我用kafka两年踩过的一些非比寻常的坑
https://my.oschina.net/u/4163222/blog/4958793

https://my.oschina.net/u/4641354/blog/4950890
防止sql注入
https://my.oschina.net/u/4163222/blog/4949354

ConcurrentHashMap源码逐行解析
https://my.oschina.net/u/4346143/blog/4794594

二叉树遍历
https://my.oschina.net/langgege/blog/1087653
为什么哈希表、完全平衡二叉树、B树、B+树都可以优化查询，为何Mysql独独喜欢B+树？
1.哈希表的特点就是可以快速的精确查询，但是不支持范围查询
2.完全平衡二叉树是有序的，所以也是支持范围查找的。存在高度问题
3.同样的元素，B树的表示要比完全平衡二叉树要“矮”，原因在于B树中的一个节点可以存储多个元素。
4.Mysql选用B+树这种数据结构作为索引，提高查询索引时的磁盘IO效率，可以提高范围查询的效率，B+树里元素是有序的
B+树是多路查找树，不是二叉树。

kafka
https://my.oschina.net/javaFamily/blog/4500892

可能不走索引的3种情况
对索引字段做函数操作
隐式类型转换，字符串与数字比较，字符串会转换为数字
隐式字符集转换，utf8m4是utf8超集，utf8，与utf8mb4会比较，utf8会转换为utf8mb4.
https://blog.csdn.net/guanfengliang1988/article/details/107357853/

https://www.processon.com/special/template/5e55d17ee4b069f82a120d06#map
AQS:
https://my.oschina.net/itstack/blog/4714141
独占模式下的tryRelease()在完全释放掉资源（state=0）后，才会返回true去唤醒其他线程，这主要是基于独占下可重入的考量；而共享模式下的releaseShared()则没有这种要求，共享模式实质就是控制一定量的线程并发执行，那么拥有资源的线程在释放掉部分资源时就可以唤醒后继等待结点。

https://www.jianshu.com/p/da9d051dcc3d

@Transactional失效场景
底层数据库不支持事务,非public方法,异常未try-catch到,
事务传播属性设置错误或者rollbackFor属性设置错误,同类中方法调用(非事务方法调用事务方法)等。

算法：
1.求一个数组,堆积中连续的最大值。譬如[-2,0,-1] 是0,[-2,-4,-1,4]是8
思考:hashmap容量设置和存储10000个数组,是否引发扩容？若是1000呢？源码可以分析
2的10次幂1024,2的14次幂16384
2.给定一个数组长度为50000的数组nums,求数组中的逆序对的个数
譬如:给定数组[9,6,8,5] 最终结果输出 5。 (分治算法)
3.输入一个字符串str,打印出该字符串中字符的所有排列的字符串数组。要求：不重复。(回溯算法和深度优先搜索dfs)
4.给定一个字符串,找出不含有重复字符的最长字串的长度(思路：暴力破解或滑动窗口)
5.删除字符串中出现次数最少的字符(思路：hash表)
6.快乐数问题(思路：hash表或快慢指针)

分布式系统：数据一致性解决方案
cap和base理论
C–>一致性,分布式系统备份数据,在同一时刻是否相同。
A–>可用性,集群中部分节点丢失后,集群是否可以响应客户端的读写请求。
P–>分区容忍性,相对于通信时限。系统不能在时限内达到数据一致性,则发生了分区。
base理论
基本可用—>遇到不可预知的故障时,允许牺牲部分可用。
软状态—>允许系统中的数据存在中间状态,允许数据同步过程存在延迟。
最终一致性–>强调所有数据副本,经过一段时间同步后,数据最终达成一致。

ElasticSearch分页查询
1、from + size 浅分页 2、scroll 深分页 3、search_after 深分页
2. 倒排索引

秒杀系统难点：
事务和行级锁—

https://www.zhihu.com/question/21556347
PV、TPS、QPS是怎么计算出来的，20w用户，活跃用户2w,
每个用户点击量50次，100w的pv, 按计算公式算下来 QPS 才 45 ，
https://www.zhihu.com/question/21556347
tps qps 是误解，还是统一的规则？
有大神说一句话，一台机器超过50qps，已经非常棒了

职业规划
1.发展分支
技术 管理(TL,PM,技术总监) 创业(好点子 人脉 情商)
2.成长路线
理解发展阶段,达到什么程度,资深,架构,领域方面。

Happen-before;
1.程序顺序规则 2.锁规则,unlock必须在下一个lock之前。
3.volidate规则 4.传递性规则 5.线程启动规则 6、线程终止规则 7对象终结规则