1、redis
优势：数据类型多String、hash、list、set、zset，通过redisObject直接存储；持久化AOF/RDB-默认RDB配置appendonly，RDB可手/自持久化，主流AOF；单线程纯内存操作 速度快；
淘汰策略：先进先出、最近最少使用、最近最不经常使用；
并发问题：redis是C语言开发的，单线程，采用队列 将并发访问变为队列串行；纯内存操作，cpu不是瓶颈，没有上下文切换和资源竞争，也不存在加锁；
分布式锁：
异步队列：list，lpush+lpop+sleep/blpop，
持久化：RDBSave/BGSAVE/RDBLoad；AOF的flush方法；redis序列化协议--客户端+服务器，规定格式请求，执行完毕返回结果；+回复-错误*数组等5种；
集群：单机/ 主从复制--没有降低主库写压力/ 哨兵--监控心跳-故障切换慢会丢失/代理/cluster-无主节点；
redis内存模型：内存分配器，分配总内存，线程内存，内存碎片比率；
实际操作：redis-server；redis-cli+keys/scan/del/exists；treeNMS-占用率/连接数/增删改查；配置文件名称、目录、开启AOF、持久化策略等；Incr一个int报错/1/++1；
新特性：Pub/Sub发布订阅-两个client；Bloom过滤-存在错误/位图数组同样k个hash函数更新1或查1判断；RedisSearch-索引+文档/安装配置，对中文不好；aof定期重写压缩，aof与bgsave混合写；同步磁盘策略；
redis实现原理：字典-字典type/hash/index-字典表size/isused-数据索引表-数据； redis单线程+队列+发配给处理器； 过期处理：定期-每100MS随机抽删除+惰性-请求时判断过期删除; set+eval；
redis集群：ruby环境，大等于6个redis，安装gem包，6节点配置port和集群true，redis-trib的create命令启动；分数据分片0-16383；新节点，不均衡，节点下线，分片迁移；通过meet命令相互通信创建stateNode节点等； redis单线程原子性；语法命令错误才会回滚；半支持事务； 不同key不同槽；
数据一致性：设置超时时间；定时去刷数据；canal伪装成从库去获取binlog；
2、zk
zab：恢复模式与广播模式；
zk选举流程和同步策略：初始流程-服务器LOOKING状态下，每个服务投票vote(sid, ZID)和自己的self（）比较，先value后key取大发出去；Leader变Leading，Follower变Following状态； 新节点/宕机不影响，leader挂了才影响会重选；非观察者全转LOOKING状态； 初始轮次+投票，接收投票 轮次和pk票，变更投票 统计，更改状态； Observer不参与投票和事务提交，提高读性能；
zk基于zab：过半机制+leader提交事务广播到所有follower；quorumPeer.start()磁盘读数据+上下文+选举；run方法有makeLeader()创建；leader.lead()创建StateSummary标记最新事务和提交次数+与Learner单线程长连接+LearnerHander监控新节点；followLeader方法-Follower.registerWithLeader()建立长链接5次+syncWithLeader()去同步数据-清空/删除无效；
3、dubbo-先把图讲一遍！！！
TCP4层：网络接口层(物理+数据链路)、网际层、传输层(tcp、udp)、应用层(+会话+表示)；
rpc远程调用的服务治理框架；节点间的服务请求；客户端将参数转字节流传给服务端操作再返回结果，涉及到序列化等问题； SOA思想-一个中心同一规范去处理或监控多个系统；
默认dubbo协议，支持http、hessian等协议；以zk、redis做注册中心；已经停止更新； spring-cloud以Eureka注册中心，仅支持http； 通信框架是netty框架；
Hessian：基于http-post，类似于http+自己的序列化，它着重数据仅带简单类型标记，文件小；java序列化-数据、类、继承关系等全部字节流序列化；
默认重试2次；tries+timeout+服务端处理业务；
dubbo原理：解析服务-类似Spring加载bean到容器，解析xml中dubbo标签加载成bean对象转化成url的参数传给protocol节点；暴露服务-通过RegistryProtocol类的export方法先将ip端口+url传到注册中心，再同步到protocol节点暴露服务；引用服务-通过RegistryProtocol的refer查询url并获得提供者引用；消费节点的zkRegistry的saveProperties会缓存全量URL，新服务不行；消费-通过ReferenceConfig的init方法调refer方法生成invoke实例来获取接口；
负载均衡：实现loadbalance接口继承*类，doselect方法，getWeight获取权重方法；随机数/轮训次数/活跃度数组等；
dubbo生产消费，通过xml中，配置retries 再重试次数/cluster 失败后操作-failfast报错、failsafe忽略等实现容错；
配置loadbalance实现负载均衡等，默认romdom随机，基本没人修改，还有 权重轮训/hash/最小活跃等；
容错与负载均衡：权重随机-大量均匀/轮训-慢服务卡积累/最小活跃数-调用前后计差越慢越靠后越少/一致性hash-参数一致调同台 服务挂掉去平分；
失败切换-查，失败报错-写；失败忽略；并行调用等单返回；retries/Cluster/forks/LoadBalance
标签：reference id声明服务；service ref引用服务；protocol 协议声明；application应用声明；provider超时声明；
监控：dubbo-admin，可视化页面搜索服务，查看生产消费者信息；
常见问题：No provider available/check registry--服务提供者挂了，或者version没对应上；启动时检查依赖可用，否则报错；Data length too large--返回数据太大，加条件而不是改payload；父子类同名变量覆盖--Hessian去重；
4、mysql
常用字段：bigint/varchar/int/datetime
超卖：sql加where语句校验-num大于等于0；
事务：异常情况下进行回滚+多个事务提交时的事务隔离；
ACID：原子性-修改要么全部成功； 一致性-事务执行前后所有数据保持一致状态； 隔离性-事务仅能读取到另一个事务前后的数据状态，不可能时中间状态； 持久性-完成后是永久的；
悲观锁：数据总会冲突，处理数据时锁住数据防止别人修改； select for update；但不影响查询；悲观锁必须走索引，否则全表扫描上锁；
乐观锁：数据不会冲突，处理时校验； 版本号/时间戳；将select查询也放到事务中，查master数据库；
共享锁：shared locks，共享读锁；读锁基础上只能加读锁，不能写； select … lock in share mode
排他锁：exclusive locks，排他写锁；独占，不能再加任何锁，可以读写； select … for update
意向锁：表锁，意向共享锁(IS锁)和意向排它锁(IX锁)； 判断表锁存在，行锁就等待；
间隙锁：防幻读，保证数据的恢复复制； 同一事务两次读结果一样； Next-key lock：record+gap
死锁：A-读+写，B-写； A-读区域，B-写区域； 加锁情况与 事务隔离级别、索引有关；主键、唯一索引、普通索引；
MVCC并发控制协议：优势-读不加锁，读写不冲突；
快照读-不加锁-普通select；
当前读-会加锁-读锁/写锁的select+写操作；
覆盖索引：查询字段全在索引字段中；
组合索引：左前缀，依次比较索引字段在where中；> < 单列索引：选取最有效的；
7种事务行为：
mysql加锁等待超时原因：inodb基于索引的行级锁，大表写没用到索引/普通索引重复率高 就会 锁表；行锁升级到表锁；----索引写；读写分离；
rc/rr实现：mvcc多版本并发控制，写版本+删版本；增-写版本；删-改删版本；改-复制 旧删新写；查-早于当前版本； 区别：gap锁+过滤不释放；
sql语句：先on临时表，再join表，最后where过滤临时表；inner无区别，outer就有区别；top/having/avg/min/count/sum/order by/group by等；
binlog：二进制文件，.index索引文件+.00*日志文件；
5、ES
节点node-索引index-分片shard/type-文件document
写流程：选择某node节点发送请求，节点会根据路由算法转发到主分片，主分片处理完毕再同步备份分片； 路由算法shard=hash(routing) %取余数 number_of_primary_shards索引下主分片数量
原理-近实时搜索refresh是：先写到内存中，同时写translog；每隔1s读取内存创建新阶段，新阶段先写入缓存，再写入磁盘；缓存数据可以直接被查询；flush实现磁盘持久化；
读流程：类似上述流程，只是读是会在 主分片 和 备份分片 之间随机轮训的去读取；
lucene：倒序索引算法；一词对应多文档；字典顺序生序；
translog：事务日志，针对的缓存与内存数据；flush持久化时清空，建磁盘+1log文件；索引文件和日志文件各有一份，冗余； 事务数，偏移量，log号；
6、Spring-cloud
Rest与RPC：RPC提供与调用方式依赖强，需要定义每个接口，严格按照版本控制；Rest是一种松耦合，约定规范，借助swagger来实现在线API接口文档；
ZK：CP强一致性，选举不可用，是一个进程；Eureka：CP可用性，自我保护机制；
Eureka：Client向Server注册服务ip端口url，消费者向注册中心获取提供者地址缓存到本地，从缓存读取调用；注册中心向订阅者提供宕机信息；节点每30s向注册中心发送心跳续约服务；90S无心跳剔除注册列表； 自我保护：统计15分钟内的失败比例，大于85%则不剔除防误杀，等待恢复心跳；
工作流程：等待注册或集群复制；注册/心跳续约/自我保护；获取服务到本地缓存；缓存无服务去注册中心刷新再缓存；缓存获取地址调用；
feign：集成来Ribbon，接口注解；
bus：通过消息代理连接各个节点；-pom+rabbitMq
断路器：自身或网络故障，很多请求等待响应；全开是请求不到服务；半开是有迹象恢复则调用成功则关闭；关闭是服务正常调用；
Zuul路由网关：分发消费者的请求；
Gateway：取代来Zuul，除了分发请求，还有流量控制，过滤请求等；
config：服务配置文件管理；
7、MQ
broker中有多个不同topic分片，每个分片中有多个同一topic的queue； topic在每个broker中都有1个分片，分片中有多个queue；
NameServer-路由注册中心，Broker-消息存储服务器； Broker每30S心跳到NameServer；NameServer每10s清除120s心跳Broker，更新topic的路由信息；Producer每30s去获取路由信息；
broker中保存 提交日志文件、磁盘索引文件、消息消费队列；
重复问题：消息重新发送、消费异常；消费进度本身的不及时；拉取异常后的重新拉取；
MQ的ack机制：重新投递retrytopic，重试多次到死信队列；以group+queue来管理offset消费进度；拉取消费组，从尾/首/某时间点开始消费，只回传最小offset值；卡必消费成功位置；
logbak，配置日志文件路径、名称规则、大小限制等； 定时判断大小实时写入文件，文件会超出大小限制； 服务重启后序号没有持久化，会写之前的；
linux：查看进程：ps -ef｜grep 查看当前路径：pwd 查看全文件：cat 分页查看：more/less 查看最新：tail -f 查看头：head 看网络：netstat 看ip：ifconfig 历史：history
df：系统或者文件所属磁盘大小使用等；du：显示文件目录的大小；
复制：cp/cp -r 移动改名：mv 建目录：mkdir 建文件：touch 删文件：rm -f 编辑：vim
杀进程：kill 远程拷贝：scp 远程调用连接：telnet 修改权限：chmod {u|a}{+|-|=}{r|w|x} filename 解压/压缩：tar -x/c
JAVA
1、红黑树：二叉树，根黑，叶子黑，红子是黑，路径黑点数一致；左小右大；左旋-上节点的左变下节点的右；
hashMap：1.7头插新元素概率高；1.8尾插是防环化，多线程同时卡到next位置；length-1全1&hashcode等于后几位值，hashcode本身均匀则均匀；final的string、Integer；hashcode+equals；
2、线程池工厂：创建线程，设置线程名、优先级等； 线程池队列：阻塞队列，生产消费+出队入队+等待唤醒
3、threadlocal，线程变量，用当前线程获取threadlocalMap，用threadlocal做key获取/设置value为值，记得remove释放；
4、mark word：标记位+锁线程/栈针锁记录/monitor对象；01未锁定/偏向+偏向时间；00轻量；10重量；11GC；
5、线程池阻塞队列：BlockQueue继承了collection，类似于生产消费者，put/take；wait/notify来实现；数组；reentranlock锁；LinkedBlockingQueue队列默认max，就可能oom；
6、String的trim方法去除首尾空格；concat连接到末尾；charAt下标位置字符；
7、ConcurrentHashMap，不允许null键null值--取出null时不知道是 null无值没找到 还是其他线程塞的null，所以null直接报空指针异常；
8、设置-Xloggc字段，设置GC日志路径信息；
9、反射机制：使用ClassLoader的native方法+synchronized+concurrentHashMap获取类及方法列表并 软引用缓存，调用无参构造函数来创建实例；
10、序列化：java对象转二进制字节码；二进制持久化到磁盘或网络传输；transient和static的变量不会序列化；过程是输出自下而上的超类元数据+自上而下的实例数据；
11、Object：hashCode()计算规则，equals()比较规则；getClass()获取对象的类（类名.class；+Class.forName()）；clone/toString；wait/notify；finalize用来做对象回收前最后逻辑，资源回收等
12、hashmap取下标：2次方扩容，length-1二进制都是1111..，所以偶数奇数分散会均匀些； 树初始化有64容量的判断，否则扩容；扩容为2倍newCap=oldCap<<1；创建新数组，循环原数组重新put定位计算到新数组；forEach方法遍历lambda；
Spring
1、bean加载顺序，B方法上加注解上注解@DependsOn({"a"})，意味B依赖A，先加载A；@Order类标记，越小越早加载；Spring有很多扩展点，BeanFactoryPostProcessor加载所有bean之前做一些逻辑；业务层flag，check-act；
2、大对象-大字符串/一维数组；超eden直接old，超old直接抛异常；超-XX:PretenureSizeThreshold字节直接放old，默认0不生效；
3、替换jar：写java编译替换jar中，同路径同名覆盖加载； 先加载目录下config+目录，再加载classpath下的config+目录；
4、mvc-前端控制器、映射器、处理器、视图解析器；视图、modelAndView、填充模型数据； @ResponseBody数据绑定-字符串到JAVA对象的数据转化；
5、装配：根据依赖关系将bean组装在一起；通过名字、类型、构造器、自动组装等方式；
6、核心：BeanDefinition、BeanDefinitionReader、BeanFactory、ResourceLoader、ApplicationContext；
7、bean生命周期：扫描过滤加载bean，初始化bean，setBeanName/BeanFactory/Context，BeforeInitialization/afterPropertiesS/afterInitialization，使用，destory；
8、单例bean安全问题：理论上全局变量和静态变量都会引起线程安全问题，用threadlocal、多例模式、加锁方式实现线程安全；
9、Spring用到的设计模式： 单例模式-bean，代理模式-AOP，工厂模式-创建bean；
一致性hash：hash是32位的无符号整型，对2^32取模，形成顺时针的虚拟环； 容错：问题节点/新节点 到 前一节点数据； 数据倾斜：虚拟节点到实际节点映射；
token：申请权限，同意并发放token，用token进行各种权限数据请求；
通过url或者form提交的一般用getParameter，且值为字符串，无set；getAttribute是对象，有set，存在内存中，一般用于重定向；
SpringBoot
1、初始化环境
MES：
排产计划-一测/二测/整修/改装/调拨工单；
生产工序-清洁/功能/测试/改配/功能/清洁/外观/出货功能/出货外观/打包/出库检/、调整工序、大修与大测、领退料；
质检统计、数据汇总-人员/工序完成数、基础设置-流程/地域/邮件/短信/钉钉等；