端点科技1面

1.自我介绍；

2.RocketMQ顺序消息场景及魔改方案；
没有表达好，应该说为了保证订单消息其状态的正常流转，比如从状态10->20->30，所以用了顺序消息；
顺序消息的消费，即使加了机器后，仍然慢到无法忍受，然后讲个人对于RocketMQ顺序消费者的魔改。

3.说一下ES的优化经验？
用filter替代must、mustnot，不算分，子句被视为用于缓存；
filter条件选择数据量小的，比如一个bool字段true占5%，false占95%，如果需要查询false的数据，查询条件应该写成查true再取反，这样性能会更好。

4.说下动态线程池？
为了保证系统的性能，我们一般都会基于业务量设置核心线程数和最大线程数，当秒杀活动开始时，我们需要适当调大核心线程数，没有动态线程池之前，修改核心线程数必须要发布，有动态线程池之后，就不需要发布了，直接在配置中心上修改即可。

5.分布式锁是怎么做的？
基于redis

6.基于redis做的分布式锁，和基于zookeeper做的，各有什么优缺点？
基于Redis的实现方式
选用Redis实现分布式锁原因

Redis有很高的性能；
Redis命令对此支持较好，实现起来比较方便

实现思想

获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。
获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
释放锁的时候，若是该锁，则执行delete进行锁释放

基于ZooKeeper的实现方式

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：

创建一个目录mylock；
线程A想获取锁就在mylock目录下创建临时顺序节点；
获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

优缺点
优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。
缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。

Redis 分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能。
Zookeeper分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。

单点的redis能很好地实现分布式锁，如果redis集群，会出现master宕机的情况。如果master宕机，此时锁key还没有同步到slave节点上，会出现机器B从新的master上获取到了一个重复的锁；另外一点就是，如果是Redis获取锁的那个客户端出现 bug 挂了，那么只能等待超时时间之后才能释放锁。
而 Zookeeper的话，因为创建的是临时znode，只要客户端挂了，znode 就没了，此时就自动释放锁。但是zookeeper也会有弊端，那就是有可能会出现“羊群效应”，会造成zookeeper性能突然下降，这样会影响zookeeper的使用。

羊群效应是使用zookeeper比较容易犯的一个错误。

问题描述：

   羊群效应常出现于通过zookeeper实现分布式锁的场景。
   客户端创建节点，序号最小的获取锁
   其他客户端监控最小节点，最小节点完成任务，发出通知，并释放
   其他客户端获取通知后，获取所有节点，序号最小的获取锁，依此类推。

没有回答好。

7.说说对AOP的理解？
blabla

8.mysql索引数据结构？
blabla

9.JVM年轻代的算法？
复制算法，blabla。

10.说说NIO？
没有回答好
开启多路复用器selector处理信道，注册自己感兴趣的事件(比如连接事件)，对于每一个连接都建立一个信道，调用java.nio.channels.Selector#select()，如果没有连接事件发生，会阻塞；有连接事件发生，往下处理有意义的事件，比如发生读事件，此时通过ByteBuffer把数据读到缓冲区，再进行处理。
NIO底层是epoll模型，很像发布-订阅。

11.说说微服务架构的好处？
解耦；
相较于分布式，资源利用更充分；
可以自由进行技术选型；
降低理解成本；

结论：挂。