- mysql如何解决幻读 - 幻读，一个事务前后两次读取到的事务条数不一致 - MVCC - 类似乐观锁，通过事务版本，通过undo的版本链进行管理，高版本可以看到事务的变更，低版本看不到高版本事务的变更，实现了不同事物之间的事物隔离 - 一个事务只能看到第一次查询之前已经提交的事务的修改以及当前事务的修改 - 一个事务不能看到当前事务第一次查询之后创建的事务，以及未提交的事务修改 - 如果存在当前读的情况下还是会出现幻读，当前读不是读的快照，而是内存 - 对于当前读LBCC基于锁的机制 - 行锁，表锁，间隙锁 - 在RR下，InnoDB采用一个MVCC的机制解决幻读的问题，如果存在当前读还是会幻读，尽量避免当前读或加锁来解决 - ![thumbnailwebp](https://static.flomoapp.com/file/2023-09-11/30463/1694258207_qFYxjC0q.jpg?OSSAccessKeyId=LTAI4G9PcaGksWVKCPrE1TVL&Expires=1703169857&Signature=s7w6CtfPnTidfhMkgHj10GvjuzM%3D) - MySQL锁 - **全局锁** - 针对整个数据库是锁，分为读锁和写锁 - 使用FLUSH TABLE WITH READ LOCK (FTWRL)添加全局读锁 - 使用UNLOCK TABLES释放锁定 - 在全库备份和全库导出时需要加全局锁 - 使用mysqldump --single-transaction -uroot -p example >example.sql导出备份文件添加single-transaction可以不用加全局锁 - **表锁** - MyISAM表的读操作会自动加上读锁，写操作加上写锁 - InnoDB在必要情况下使用表锁，主要使用行锁实现MVCC，提供更好的并发性能和更少的锁冲突 - lock table example read； - unlock tables； - 使用场景 - - - 读密集型应用 - - - 写操作不频繁 - - - 数据量不大 - - - 全表更新或删除 - 风险 - - - 性能下降 - - - 并发性能差 - - - 锁等待和超时 - - - 写操作影响大 - - - 死锁的可能性 - **行锁** - 锁定单行数据，粒度更细，但是需要更多系统资源 - 主要由InnoDB提供 - select for update - select lock in share mode - insert update delete都会添加排他锁 - 使用场景 - - - 高并发读写操作 - - - 单行操作 - - - 短期锁 - - - 实现并发控制 - - - 复杂的事物处理 - 风险 - - - 死锁 - - - 锁升级，升级为表锁，导致更多锁冲突 - - - 锁等待 - - - 资源消耗 - - - 难以排查和调试 - - - 事物隔离级别 - **乐观锁** - 使用版本号来实现乐观锁 - **悲观锁** - **意向共享锁和意向排他锁** - **临键锁和记录锁** - MySQL事物ACID特性 - 事物四大隔离级别 - 事务的底层锁机制 - MVCC并发优化机制 - volatile关键字 - - - 可以保证在多线程环境下共享变量的可见性 - - - 通过增加内存屏障防止多个指令之间的重排序 - 可见性是指当一个线程对于共享变量的修改，其他线程可以立刻看到修改后的一个值，可见性是由几个方面造成的，一个是CPU层面的高速缓存，CPU内部有三级缓存就会导致缓存一致性问题，而在多线程环境下缓存一致性就会导致可见性问题，对于增加了volatile关键字的一个共享变量，JVM虚拟机会自动添加一个#lock的汇编指令。而这个指令会根据不同的CPU型号添加总线锁或缓存锁 - 总线锁锁定cpu的前端总线，导致同一时刻只能有一个线程和内存通信，避免了多线程并发造成的可见性问题， 缓存锁是对总线锁的一个优化，总线锁导致cpu的使用效率大幅下降，缓存锁只针对cpu三级缓存中的目标数据加锁，缓存锁使用mesi一致性协议实现的 - 指令在编写的顺序和执行的顺序不一致导致内存可见性问题，指令重排序本质上是一种性能优化的手段，来自于几个方面，第一个方法是CPU层面针对于mesi协议的更进一步优化去提升cpu的利用率，引入一个叫storebuffer的一个机制，这种优化机制会导致cpu的乱序执行，为了避免这样的问题cpu提供了内存屏障指令，上层应用可以在合适的地方插入内存屏障避免cpu指令重排序 - 编译器在编译过程中在不改变单线程语义和程序正确性的前提下，对指令进行合理的重排序从而去优化整体的一个性能，添加了volatile关键字就不会触发编译器的优化，在jvm里面会插入内存屏障指令去避免重排序 - 除了volatile关键字从1.5开始jmm使用了一种Happens-Before的模型去描述多线程之间一个可见性的关系，如果两个操作具备happens-before关系那么这两个操作就具备可见性的一个关系 ，不需要通过volaitle增加可见性的保障 - mq中间件消息堆积 - 消费慢场景， - **jvm处理慢** - 加密解密，大数据量处理耗时，增加机器 - **数据入库慢** - 新增不会是瓶颈，新增不锁行，可能是因为索引太多导致新增的性能下降 - 更多是对同一行记录的更新操作，更新会锁行导致执行排队 - 采用分而治之，将资源分散在几条记录里面 - 确实达到了瓶颈，使用分布式数据库中间间mycat，或使用分布式数据库mongodb，es - **依赖外部慢** - 对外部提要求，增加性能 - 一些非实时场景数据先入库持久化 - 要求外部也提供异步能力，给他们提供回调入口来操作数据 - 如何分析一条sql的性能 - explain，执行计划 - mysql内置了一个优化器，优化器的任务就是优化sql，尽可能以更低的成本去执行 - type表示mysql访问数据的方式，常见的有全表扫描（all）、遍历索引（index）、区间查询（range）、常量或等值查询（ref、eq_ref）、主键等值查询（const）、表中只有一条记录（system） - system>const>eq_ref>ref>range>index>all - key表示查询过程中实际会用到的索引名称 - rows表示查询过程中可能需要扫描的行数，不一定准确，是mysql抽样统计的数据 - Extra表示一些额外信息，通常会显示是否使用了索引，是否需要排序，是否会有用到临时表等 - select * 需要回到主键索引上查找对应的字段，需要回表，如果筛选出来的数据大部分都回表，mysql会选择全表扫描，如果认为索引回表的效率高才会走索引 - 有时候利用复合索引可以利用索引覆盖在来避免回表的过程 - MySQL性能分析 - **查** - **看执行频次** - 使用show global status like ‘Com_______’查看增删改各种操作执行频次 - **慢查询日志** - 默认情况下超过10s就是慢查询，这个一般设置为1s long_query_time = 1 - 通过show VARIABLES LIKE 'slow_query_log' - **show profile** - 通过SELECT @@have_profiling 查看当前是否支持show profiles功能，返回yes就是支持 - 通过SELECT @@profiling 常看当前是否开启了show profiles性能分析功能，返回0不支持，返回1 支持 - 使用show PROFILES 查看执行的SQL列表，获取SQL的执行时间 - 使用show profile for query query_id 可以查看SQL执行各个阶段的用时 - 执行show profile cpu for query query_id可以查询指定query_id的SQL语句的CPU的使用情况 - **explain执行计划** - 在select语句前增加explain关键字，执行完成之后就会返回执行计划的信息，如果from中包含子查询，MySQL会执行子查询并将结果放入临时表中 - id：id列的编号时select的序列号，有几个select就有几个id，id按照select出现的顺序增长，id列值越大优先级越高，id相同按照执行计划从上往下执行，id为空最后执行 - select_type:表示对应行是简单还是复杂查询，有simple，primary，subquery，union - type：表示连接类型、性能由好到差为NULL、system、const、eq_ref、ref、range、index、all，需要避免all全表扫描的出现 - possible_keys:表示在当前语句中可能用到的索引 - key：表示当前语句中用到的索引 - key_len:表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精度的情况下，长度越短越好 - rows：MySQL认为必须执行查询的行数，在InnoDB中是一个估计值 - filtered：表示返回结果的函数占需要读取函数的百分比，越高越好 - 负载均衡算法 - **静态** - - - 轮询 - - - 随机 - - - 权重 - - - IP - - - URL哈希 - - - 一致性哈希，IP+URL - **动态** - - - 最少连接数 - - - 最快响应 - - - 观察：以连接数和响应时间为平衡依据 - - - 预测：收集当前服务器性能指标，预测下个时间段性能最佳服务器 - - - 动态性能分配：收集服务器各项性能指标，动态调整流量分配 - - - 服务质量：根据服务质量选择 - - - 服务类型：根据服务类型选择 - **自定义** - - - 灰度发布：平滑过渡的发布方式，降低发布风险，减少影响范围，出现故障快速回滚，不影响用户 - - - 版本隔离：为了兼容或过渡，某些应用有多个版本，保证1.0版本不会调到1.1版本服务 - - - 故障隔离： 生产出故障之后将故障的实例隔离，不影响其他用户，同时保留故障信息便于分析 - - - 定制策略：根据业务情况定制跟业务场景最为匹配的策略 - 轮询+权重=加权轮询 - 最快响应+权重，可以根据响应时间动态调整服务器权重 - **中间件使用的算法** - - - Nginx - - - RonundRobin：轮询 - - - WeightedRoundRobin:加权轮询 - - - IPHash：按照IP的Hash选择 - - - URLHash：按请求URL的Hah选择 - - - Fair：根据后端服务器响应时间判断选择复制最轻服务器分流 - - - Dubbo - - - RandomLoadBalance：加权随机 - - - RoundRobinLoadBanlance：加权轮询 - - - LeastActionLoadBalance：最少连接数 - - - ShortestResponseLoadBalance：最短响应时间 - - - ConsistentHashLoadBalance：一致性Hash - - - Ribbon - - - RoundRobinRule：轮询 - - - RandomRule：随机 - - - WeightedResponseTimeRule：根据响应时间来分配权重 - - - BestAvailableRule：先过滤掉由于多次访问故障处于断路器跳闸状态的服务，然后选择一个并发量最小的服务 - - - RetryRule：先按照轮询策略获取服务，如果获取服务失败在指定时间内进行重试，获取可用的服务 - - - ZoneAvoidanceRule:根据性能和可用性选择服务 - - - AvailableFilteringRule：会先过滤掉由于多次访问故障处于断路器状态的服务，还有并发量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问 - 什么是缓存穿透？如何避免？ - 被攻击，缓存key不存在，去数据库查询 - 布隆过滤器，bitmap - 一种概率的判断算法，判断一个数据是否存在，通过一个二进制数据和一个Hash算法实现 - 误判问题 - 哈希冲突，计算出来不一定存在 - 通过增大数组和增加哈希函数 - 如何解决重复消费 - 如果使用了消息中间件，没有办法避免MQ中消息重复的 - 消费是做幂等性处理 - - - MVCC多版本并发控制(生产的时候带上数据的版本号)，该方法有很多不便 - - - 去重表方案，利用数据库特性建立 - 为什么kafka不支持读写分离？ - 读写分离，主从架构，主写从读 - - - 数据一致性问题 - - - 延时问题，数据同步为异步操作，kafka保证数据可靠性需要保存到硬盘，延时比较高 - - - 实现了主写从读，负载均衡无法实现 - - - 不实现读写分离架构简单，出错可能性小 - - - 多副本机制简单很多 - 有几百万消息持续积压几小时，如何解决？ - 消息挤压，——线上故障（消费者）几百万消息MQ中挤压 - - - 修复消费者，可能消耗几个小时。 - 临时扩容，一个消费者1秒消费1000，3个消费者3000，一分钟18万，800万需要40-50分钟 - 临时借调机器，队列和消费者10倍 - 需要建立一个消费者同时也是一个生产者，将原来的消息消费然后重新生产传送到其他queue里面，同时将原来三个queue里面的消息扩散到30个queue中 - 1. 积压消息的类型，那些消息重要，那些不重要（快速消费）确定哪些业务的消息处理是优先级最高的，优先处理这些消息； 2. 考虑将部分业务逻辑转移到备用系统上，以减轻主系统的压力； 3. 查看具体业务是否有查询，插入，修改操作，评估 DB 处理能力（优化索引）； 4. 评估是否可以批量操作或者多线程处理 5. 水平扩展服务器资源，包括数据库，服务器，消息队列服务器，来提升性能； - AQS唤醒节点时，为什么从后往前找？ - Node节点插入到整个AQS队列时是先把当前节点的上一个指针指向前面的节点，再把tail指向尾，这个时候会有一个CPU调度的问题，如果卡在这个位置就会出现前一个节点的指针还是指向null，会总成一个节点丢失的问题 - 当某一个节点取消之后，会执行一个cancelAcquire方法，这个方法也是先去调整上一个指针的指向，next指针是后续才动的 - 插入和取消都是先动前面prev的节点，所有prev才是指向的优先级较高或时效性较好的指向 - 从前往后找会错过某个节点，造成某个null然后挂起，之前线程已经释放资源并没有释放锁 - hashmap方法体内线程安全 - 可能会存在逃逸现象，不能保证方法体内都是线程安全的，只要hashmap出现被多个线程引用的情况就会出行线程不安全问题 - 前后端自增数据ID容易被人猜到，长度大于16位给前端会有精度丢失问题 - 自增id，水平越权，不可能不考虑，属于重大隐私安全问题。用uuid会损失插入性能，再不济使用雪花算法 - 16位千万亿数据量级别 - long类型数据返回给前端会精度丢失，通过一个转换器转换为字符串解决 - mysql一主二从 - 解决高并发主从同步延迟数据不一致问题 - 提高效率降低延迟 - 增加从服务器配置，增加带宽，参数优化，修改并发复制的参数，避免长事务的sql，或者在主从服务器的负载均衡主服务器权重大一些，强一致性的方案，直接读取主库 - 分布式ID - mysql使用自增ID - 分布式ID的解决方案和算法没有太大关系，雪花算法顶多是一个主键解决方案（唯一主键解决方案）， - 假如让你设计一个订单表，订单号会用主键吗 - 主键代表的含义是这张表唯一的标识或流水号，不应该具备任何业务含义，可不可以用单表主键做业务ID？当然可以，很多小的后端系统就这么用的，但是大型的分布式式系统里面往往会有一个分布式ID的生成服务，这个服务用雪花算法用什么都和我们没有关系，但是需要保证给我们的业务ID在我们这个业务领域里面是唯一的，这个订单号不管在支付系统，物流系统还是财务系统，都应该是能够唯一标识订单的，有些ID还会用各种业务字符串来让这个业务ID更加清楚的表达业务含义，不如在订单号前加order前缀，或者加部门这些信息，所以你看现在这些快递单号为什么纯数字不行，邮政公司还要牵头加一个什么物流公司的拼音前缀，都是有原因的，小系统自增和雪花算法都没有区别，但是在大系统里面系统ID和业务ID是不一致的，最好分开，做关联查询的时候呢，最佳方案是用业务id - 分库分表重复的问题 - 为什么要分库分表，数量的增长单表无法容纳了，这个时候单纯用分库分表解决可能以后还要在分库分表，数据还要再重新散列一遍，需要分库分表时需要慎重考虑是否能够更引入一个可以横向扩展的分布式数据库来解决 - **基于stata的xa做分布式事务** - xa性能最差，但是强一致性， - 协调事务2pc，3pc - 最终一致性，本地消息表，事务消息 - 默认at是两阶段提交，两点对于sql进行分析，sql执行前后的数据镜像进行保存，生成一些回滚日志，优点代码无侵入，缺点是必须要基于关系型数据库 - tcc，try confirm and cancer，需要侵入代码，手动编写预留，确认，回滚的方法，本来是一个操作逻辑需要分散在三个方法里去做，因为设计到预留资源的问题，数据库也要一起跟着变化，特别不适合已经有完善数据库设计的项目，saga是基于最终一致性的方案，通过状态机去执行一个已经定义好控制流程的json文件来控制整个流程的提交，回滚的方式，但是和TCC一样也需要侵入代码去实现补偿逻辑，前面三种都有一个共同问题，都是补偿型事务，就是弱一致性，如果需要强一致性，只有xa模式。这个模式是只要实现了xa协议的数据库都可以很好支持，我们用的库是mysql5.7当然支持了，而且代码编写上和at模式一样没有侵入，还能和at模式进行简单切换，性能差该一个配置文件即可，实际业务和钱有关需要强一致性，并发量并不大，xa模式没有问题 - **分表之后按照时间查询** - 按照某一个字段进行水平拆分 - 决定按照某个字段去分表，就不可能不带着这个字段去查询 - 倒序查询，表少可以查询出来到内存中进行聚合，ES，MongoDB这种分布式数据库都是这么做的，但是mysql不是分布式的，单机会成为性能瓶颈，表太多这么做性能直线下降，分表的本意就是为了提高性能，做评论审核页面就是按照时间倒序去排序的，技术往往是结合来做的，我们有三张表，是按照用户维度，文章维度分表，还有一个全量表，因为有分页限制查询不会慢，审核完成后再同步到另外两套表中 ，完美解决了业务问题 - spring解决循环依赖 - 温柔方案 - 开启支持循环依赖的配置，spring就会在初始化bean的时候启用三级缓存来解决，a、b两个互相依赖的bean，spring在初始化a的时候先去一二三级缓存中拿a，如果没有就会去实例化a并把啊的对象工厂放到三级缓存中，然后初始化a的时候给a set了各种属性，发现依赖b，然后去创建b，创建b的过程也是一样的，b可以在三级缓存中拿到a的对象工厂，并且这个工厂对象会把a的对象放到二级缓存中，b可以顺利完成初始化，同时把b放入一级缓存中，b初始化完成之后， a顺利注入b完成初始化，这样就解决了循环依赖的问题 - 粗鲁方案 - Spring默认不启用支持循环依赖 - 循环依赖是代码不规范导致的，正确的情况是不应该出现循环依赖，写一个c去分别应用a和b - 为什么都使用hashmap - 使用时都是在方法体里面声明 - 每一个方法调用时都是单独线程 - 用static修饰变为静态全局变量，多线程调用put方法才会出问题，用currenthashmap才有意义，声明一个static的hashmap大部分情况下是当作一个jvm的缓存来使用的，有分布式缓存redis，jvm缓存caffeine不太用hashmap - **幂等性** - 新增收入利润的情况， - 提交两次编辑和新增同一个接口，编辑不会有问题，但是新增时会有问题，新增两个数据 - 底层逻辑是**串行查询** - 通过分布式锁解决 - 解决的核心是做重复性判断，高并发场景下两个线程同时查到没有然后分别插入，分布式锁锁的是查询的过程，保证查询是串行操作，查到的一定是数据库里面最新的数据，然后去做相应 的业务逻辑，先去通过唯一性的标识查询该条数据有没有，然后插入或更新数据 - **解决分布式事务** - 协调事务和最终一致性方案 - 协调事务：2PC，3PC，协调者高可用，协调不一致，一方提交或回滚成功了，第二方提交或回滚失败，只能降低这种情况发生概率，无法完全避免，存在一定的阻塞，性能相对来说差一些。XA - 最终一致性方案：本地消息表，TCC，Saga，无阻塞，可以提供较好的性能，但是无法保证强一致性，本地消息表存在写入失败或更新失败的问题，TCC需要先预留资源，涉及到幂等的问题 - 分布式事务一定遵循分布式理论的，当分区条件满足时，一致性和可用性就无法同时满足。 - 怎么同时解决一致性和可用性的问题？无法解决 - 用会员积分来兑换商品，会员积分和订单是两个服务，采用dubbo来交互，采用阿里云seata，seata最大核心功能就是事务协调器，支持dubbo，而且seata还支持4种模式at，tcc，saga，xa模式，积分来兑换商品的业务场景相对简单，不涉及到优惠券这种复杂的业务逻辑，综合考虑用at模式来实现。at模式基于 数据源代理对sql进行解析，把操作过的数据记录在undo'log表种，简单来说，就是参与事务的ab双方会注册到事务协调器，并且获取到一个全局事务ID注册到本地，a先开启本地事务拿到本地锁，事务提交前拿到全局锁释放本地锁，a的事务准备好之后b拿到本地锁，开始本地事务操作，b操作完成之后释放本地锁，开始争抢全局锁，此时ab双方都处于prepare状态，事务协调器向双发发起commit命令，a执行commit命令后会释放全局锁，b获取全局锁执行commit，a失败后b获取不到全局锁会回滚，a成功b失败，全局事务失败，事务协调器向a发送回滚命令。a根据全局事务的ID在本地表中查询回滚的数据回滚，由此来保证数据的强一致性 - 还有一个注册送积分的，这里面对一致性要求没有那么高，采用的方式是注册完成之后下发一条kafaka消息，如果要做分布式事务呢，在本地建一个本地消息表，在注册这个事务的时候往本地消息表里写一条赠送积分的消息，并把状态置于待确认，后期赠送完成之后可以把消息更新为已确认或者删除这条消息，但是真正工作里没有这样做，原因是我们发现赠送失败的场景几乎没有，并且这个数据就算是出错了，在业务层面也是可以接受的，采用无事务的思想，通过日日记录异常监控报警来保证赠送积分的成功，如果真的因为各种原因赠送失败了，通过人工介入来处理 - **hashmap的结构，put和get操作** - **hashmap为什么 @使用红黑树** - **concurrentHashMap，1.7segment，1.8synchronized和CAS，** - concurrenthashmap使用reentrantLock - **synchronized，jdk版本升级有优化**，reentrantlock是java代码实现的，优化比较少 - **synchronized对锁的优化** - 两个线程竞争锁，升级成为重量级锁 - 看是XX部门，部门的日常工作主要有哪些 - InnoDB和myISAM的区别 - InnoDB为什么能支持事务 - redolog和undolog的区别 - binglog作用 - 同步binlog主一个时间，从一个事件，底层怎么解决，或者说同一个sql主和从是不一致的，binlog是怎么让他们同步的？主生成的sql和从生成的sql不一定一致，他有没有做过什么处理 - volatile有什么作用 - synchronized底层怎么实现的 - synchronized锁升级 - 偏向锁的批量重偏向是多少次，为什么是这么多次（跟字节有关） - reentrantlock怎么实现公平，怎么实现可重入 - redis分布式锁的原理 - 看门狗还有多少时间会续期 - redis设置锁怎么保证原子性 - lua一定是原子性的吗 - cas的aba问题怎么解决 - 分布式id有了解吗，雪花算法怎么实现的，头几个代表的是什么，分布式id遇到时钟回拨怎么解决 - hashmap为什么升级为红黑树 - arraylist和linkedlist查询时间复杂度和空间复杂度 - 有没有可能redis因为主从哨兵，两个线程拿到同一个锁的情况，怎么办（红锁，有一半以上节点拿到锁才成功） - redis中的锁是ca还是ap（说ap，问有没有可能两个线程拿到同样锁的情况） - cp锁和ap锁有什么区别 - 主从同步 出了一些问题，怎么保证最终一致性 - DDD了解吗 - 生产环境上3主3从的数据库，现在有个机器要去连，你会连6个Datasource还是怎么连，yaml文件你怎么配置，或者说你会用什么样的中间件去做一些代理还是怎么样 - nginx有了解吗，nginx挂了怎么办，可不可以做集群 - 伪IP有了解过吗 - keep alive有了解过吗 - safe-hdfs这种分布式存储有了解过吗 - redis的rdb和aof有啥区别 - rdb突然断电怎么办 - 哨兵模式原理 - 双亲委派机制 - 垃圾回收机制原理 - 让你JVM调优，你会怎么调 - 聊了很多锁，IO密集型和CPU密集型分别适合哪些锁 - countdownlatch和信号量都知道吗 - rabbitMQ的死信队列和延迟队列有了解吗 - 消息丢失怎么办 - rabbitMQ能不能业务逻辑上最终一致性 - TCP和HTTP协议 - 为什么是三次握手 - 为什么挥手是四次 - Object的equals和hashcode是干什么用的 - hashmap怎么解决哈希碰撞 - 多线程线程越多越好吗 - Spring中一个类2个方法，a和b都加了事务注解，a方法调用b方法，b的事务会生效吗 - 直接声明string=a和new一个string构造传a有什么区别 - new一个字符串想要加入常量池里面应该怎么做 - 哈希数组，哈希桶原理，通过哈希取余计算得到下标 - synchorinzed锁升级 - 查询sql执行性能 - 可重复读，读取未提交的数据 - bean的生命周期 - spring加载时缓存预热 - 线程池核心参数 - 1. 离职原因：被裁员 面试时：原本的工作没有办法满足我的成长，期望找一个更大的平台发挥。 - 2. 离职原因：原单位钱太少 面试时：我觉得自己己经具备了一定的积累，希望可以迈向一个新的台阶。 - 3. 离职原因：跟同事处不来。 面试时：我很重视平台的发展，我认业个人才 只有放在合适的平台才能够最大程度的发挥出 自己的才干。 - 4. 离职原因：有个大领导。 面试时：虽然我已经有相当的经验和技能，但仍希望能够拓宽自己的知识面，进行更深入的学习和实践。 - 5. 离职原因：原单位扯皮甩锅大战。 面试时：我认为一个良好的工作氛围能够提高 工作氛围，明确的分 工和相对完善的制度是提高生产力的基本保障。 - 6. 离职原因：提拔无望。 面试时：我认为人不应该满足现状，而是应该积极进取，如果不能够适时挑战自己，逼自己 一把，怎么能够最大程度的挖掘自己的潜力呢？ - 7.离职原因：大*管理制度太多。 面试时：贵公司所推崇的人性化管理非常符合 我对工作环境的预期，我也相信在这样的环境中，我能够发挥出更大的主观能动性。 - MySQL为什么使用B+树索引 - B树是一种多路平衡树，存储大量数据时相对高度比二叉树矮很多，而数据存储在磁盘上，磁盘IO效率比较低，特别时随机磁盘IO，树的高度决定磁盘IO次数，IO次数越少，性能提升越大 - B+树优化 - - - 所有数据都存储在叶子节点上，非叶子节点只存储索引，每一层存储索引数据增加，相同层数下数据量更多 - - - 叶子节点中的数据使用双向链表方式进行关联，查询时只需查两个节点进行遍历即可 - - - 由于所有数据都存储在叶子节点，B+树的IO次数更加稳定 - - - 叶子节点存储所有数据，全局扫描能力更强，只需要扫描叶子节点 - - - 采用自增主键，能更好避免增加数据时带来叶子节点分裂导致大量运算的问题 - SpringIOC的工作流程 - - - IOC是什么 - 控制反转 - - - Bean的声明方式 - xml - - - IOC工作流程 - - - IOC容器初始化阶段 - 根据程序内部的xml或注解等Bean的声明方式，通过解析和加载后生成BeanDefination，然后将BeanDefination注册到IOC容器内部，通过注解和xml声明的注解解析后都会得到一个BeanDefination实体，这个实体包含Bean的一些定义和基本属性，最后将BeanDefination保存到一个map集合里面，完成IOC的初始化 - IOC容器的作用就是对这些注册的Bean 的定义信息进行处理和维护，它是IOC容器控制反转的一个核心 - 2.完成Bean的初始化和依赖注入 - - - 通过反射区去针对没有设置lazy-init属性的单例Bean进行初始化 - - - 完成Bean的依赖注入 - - - Bean的使用 - 通过@Autowired注解或BeanFactory.getBean()从IOC容器中获取一个指定的bean的实例，针对设置了lazy-init属性及非单例Bean的实例化，在每一次获取Bean对象时调用Bean的初始化方法完成实例化，并且SpringIOC容器不会去管理这些Bean - Redis哨兵和集群的区别 - 主从，读写分离，提升工作效率 - 哨兵，监控机制，主节点故障 - Cluster，Slot槽0-16383，分配区间，多个主从节点，主节点故障自动转移 - - - 客户端实现更加复杂 - - - Slave节点只是一个冷备节点，不分胆担读写压力 - - - 对于批量操作指令有限制 - 为什么禁止@Transactions - - - 方法上添加后会导致长事务，一个方法存在较多耗时操作，带来锁的竞争影响性能导致数据库连接池消耗殆尽，影响程序正常执行 - - - 如果有事务嵌套，容易引起事务混乱，导致程序运行结果出现异常 - - - 将事务控制逻辑放在注解里面，项目复杂度增加，事务控制变复杂，导致代码可读性和可维护性下降 - 使用编程式事务 - - - 灵活控制事务的范围 - - - 减少事务的锁定时间 - - - 提高系统的性能 - ES数据和数据库数据不一致 - SpringBoot优势 - SpringBoot自动装配流程 - Spring import注解 - 注册Bean注入IOC容器（5种） - 负载均衡算法 - kakfa如何确定key的分区 - HashMap 开放寻址法 - 头插法和尾插法 - redis使用头插 - Rdis优势，数据丢失场景，解决脑裂 - 分布式锁过期 - Redis分布式锁数据类型 - 时间轮实现 - 接口非常慢如何解决（慢SQL，SQL语句分页，数据量过大，频繁更新，分库分表） - 线程池在工作中如何使用，参数如何设置 - 线程池如何线程复用 - 关于招呼模版：您好，我对您的发布的岗位非常感兴趣，我有XX、XX、XX、等项目经验/工作经验，有XX\XX\XX项目成果/工作成果，熟练掌握XX\XX\XX软件应用，持有XX\XX等资格证书，对工作中XX\XX模块非常熟悉，具体您可以看看我的简历：（附上你的简历链接，简历链接推荐用腾讯文档，设置PDF，记住要生成永久链接） - 如果你在第一步就通过话术引导对方对你产生兴趣，再附上简历的链接，这样一目了然，做事逻辑性这么强，HR肯定排着队要录用你！最后记得登陆你的腾讯表格，看看该文件被查阅的数据，了解你自己的市场竞争力，知己知彼才能打胜仗。 - - - 先做一个自我介绍（这是必须的） - - - 说一下你之前做项目的一个业务流程（详细业务流程） - - - 这个项目你使用了多线程吗？你是如何实现的？ - - - 你说多线程这块你做了性能优化，你能说一下优化的方式和优化的结果吗？ - - - 事务使用过吗？事务和锁一起使用会不会有什么问题？是先使用锁还是先使用事务？ - - - springcloud 的注册服务使用的什么？除了这个还有其他的了解吗？ - - - 消息队列用过吗？你大致讲一下。 - - - 先做一个 10 分钟左右的简短介绍，包括几个方面：你工作的经验，你在这些工作中你的优势是什么？你擅长什么？ - - - mybatis 中的 #{} 和 ${} 有什么区别？默认使用哪个？为什么这么使用？ - - - 介绍一下 Spring，说一下 Spring 常用注解的用途。 - - - 说一下 SpringAOP 的概念，实际运用场景。 - - - 现在有个对象 user，通过参数传递到其他方法中去，然后 user 的 name 改变了，那么传递的这个对象是值传递还是引用传递，为什么？顺便解释一下值传递和引用传递。 - - - 项目中是如何使用事务的？ - - - 项目中用过多线程吗？如何保证多线程线程安全的？具体你做了哪些操作来实现的？ - - - 你之前做过 PHP？你讲一下 PHP 和 Java 的区别呢？ - - - 先做个自我介绍。 - - - 现有一多文件上传需求，要求在 5M 带宽的服务器上上传超过 100 张图片，并且保证用户可以尽快看到上传结果。 - - - springcloud 中 A 服务要调用 B 服务，同时需要将 token 传入 B 服务中，请问使用什么方式传递？ - - - 讲一下你现在做的系统的业务逻辑，用到了什么技术？ - - - mybatis 分页是怎么做的？ - - - 事务你用过吗？ - - - 用过哪些工具类？处理时间和 JSON 你是用的什么工具？ - - - MongoDB 中针对于百万级别的数据，如何优化查询？如何分页？如何创建索引？做过数据统计那么统计的精度是每天还是每个月还是每年？如果去动态查询这些统计数据？