面试题整理

从网上看到的面试题，随便整理几道

1.redis为什么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，
类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者
多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，
没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO； 5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样， Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求； 以上几点都比较好理解，下边我们针对多路 I/O 复用模型进行简单的探讨： （1）多路 I/O 复用模型 多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力， 在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒， 于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流）， 并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。 这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术 可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存 中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上 几点造就了 Redis 具有很高的吞吐量。 那么为什么Redis是单线程的 官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是 机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

2.zk怎么实现的分布式锁

1、互斥锁mutex lock
顾名思义就是排它锁，同一时间只允许一个客户端执行。

实现步骤：

首先，创建一个lock node，例如“locknode”
其次，客户端lock执行以下方式： 
创建（create）一个有序临时节点，例如“locknode/guid-lock-”，
其中guid可以是你客户端的唯一识别序号，如果发生前面说的创建失败问题，需要使用guid进行手动检查。
调用getChildren(watch=false)获取获取子节点列表，注意wtach设置为false，以避免羊群效应（Herd Effect），即同时收到太多无效节点删除通知。
从这个列表中，判断自己创建的节点序号是否是最小，如果是则直接返回true，否则继续往下走。
从步骤2中获取的list中选取排在当前节点前一位的节点，调用exist(watch=true)方法。
如果exist返回false，则回到步骤2；
如果exist返回true，则等待exist的哨兵（watch）回调通知，收到通知后再执行步骤2.
最后，客户端unlock只需要调用delete删除掉节点即可。

缺点：

没有解决锁重入问题，因为采用的是有序临时节点，因此多次调用create并不会触发KeeperException.NodeExists异常，
从而无法实现锁重入功能。如果需要解决，则在步骤1时，需要先进行判断当前节点是否已经存在，
即调用getChildren(watch=false)，判断当前节点是否已经创建（配合guid），已经创建，则直接从步骤3开始，没有创建则从步骤1开始。
这是一个公平锁，无法实现非公平锁。


共享锁Shared Locks或读写锁Read/Write Locks
Read读锁是共享锁，Write写锁是排它锁，当没有写时，允许多个read实例获取读锁，当有一个write实例获得写锁时，
则不允许任何其他write实例和read实例获得锁。

实现步骤：
首先，创建一个lock node，例如“locknode”
获取read锁步骤： 
创建（create）一个有序临时节点，例如“locknode/read-guid-lock-”，其中guid可以是你客户端的唯一识别序号，
如果发生前面说的创建失败问题，需要使用guid进行手动检查。
调用getChildren(watch=false)获取获取子节点列表，注意wtach设置为false，以避免羊群效应（Herd Effect），即同时收到太多无效节点删除通知。
从这个列表中，判断是否有序号比自己小、且路径名以“write-”开头的节点，如果没有，则直接获取读锁，否则继续如下步骤。
从步骤2中获取的list中选取排在当前节点前一位的、且路径名以“write-”开头的节点，调用exist(watch=true)方法。
如果exist返回false，则回到步骤2。
如果exist返回true，则等待exist的哨兵（watch）回调通知，收到通知后再执行步骤2。


获取write锁步骤： 
创建（create）一个有序临时节点，例如“locknode/write-guid-lock-”，其中guid可以是你客户端的唯一识别序号，
如果发生前面说的创建失败问题，需要使用guid进行手动检查。
调用getChildren(watch=false)获取获取子节点列表，注意wtach设置为false，以避免羊群效应（Herd Effect），
即同时收到太多无效节点删除通知。
从这个列表中，判断自己创建的节点序号是否是最小，如果是则直接返回true，否则继续往下走。
从步骤2中获取的list中选取排在当前节点前一位的节点，调用exist(watch=true)方法。
如果exist返回false，则回到步骤2；
如果exist返回true，则等待exist的哨兵（watch）回调通知，收到通知后再执行步骤2.
最后，客户端unlock只需要调用delete删除掉节点即可。
--------------------- 
原文：https://blog.csdn.net/koflance/article/details/78616206 

3.dubbo与springcloud比较

https://www.cnblogs.com/hankal/p/9818060.html

https://blog.51cto.com/13954634/2296010

4.装饰模式与代理模式区别

代理模式：https://www.runoob.com/design-pattern/proxy-pattern.html
装饰模式：https://www.runoob.com/design-pattern/decorator-pattern.html
装饰模式与代理模式区别：https://www.cnblogs.com/178mz/p/5824276.html

5.spring bean初始化过程

https://blog.csdn.net/zl834205311/article/details/78803530

6.hystrix实现机制

https://www.cnblogs.com/lexiaofei/p/7761982.html

7.docker常用命令

https://www.runoob.com/docker/docker-command-manual.html

8.docker网络模型

https://www.cnblogs.com/zuxing/articles/8780661.html

9.原子类哪个解决了aba问题

10.Kafka怎么保证高可用

https://www.cnblogs.com/756623607-zhang/p/10506360.html
https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247486245&idx=1&sn=a6ecb1026b6ef24cabe10ef9a4b7570d&source=41#wechat_redirect

11.Kafka可能会遇到后发先至的消息，如何限制消费顺序

12.有几种AOP，区别

13.final类能不能用JDK代理，cglib代理增强

https://blog.csdn.net/liangwenmail/article/details/78457106

14.JDK代理、Cglib代理、assist分别是什么时候进行的增强

https://blog.csdn.net/luanlouis/article/details/24589193

15、kafka如果有一条消息一直消费失败，如何操作

转载于:https://www.cnblogs.com/Java-Script/p/11095736.html