Java面试题

MyBatis 面试题
1、什么是 Mybatis？
1、Mybatis 是一个半 ORM（对象关系映射）框架，它内部封装了 JDBC，开发时
只需要关注 SQL 语句本身，不需要花费精力去处理加载驱动、创建连接、创建
statement 等繁杂的过程。程序员直接编写原生态 sql，可以严格控制 sql 执行性
能，灵活度高。
2、MyBatis 可以使用 XML 或注解来配置和映射原生信息，将 POJO 映射成数
据库中的记录，避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。
3、通过 xml 文件或注解的方式将要执行的各种 statement 配置起来，并通过
java 对象和 statement 中 sql 的动态参数进行映射生成最终执行的 sql 语句，最
后由 mybatis 框架执行 sql 并将结果映射为 java 对象并返回。（从执行 sql 到返
回 result 的过程）。
2、Mybaits 的优点：
第 34 页 共 485 页
1、基于 SQL 语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任
何影响，SQL 写在 XML 里，解除 sql 与程序代码的耦合，便于统一管理；提供 XML
标签，支持编写动态 SQL 语句，并可重用。
2、与 JDBC 相比，减少了 50%以上的代码量，消除了 JDBC 大量冗余的代码，不
需要手动开关连接；
3、很好的与各种数据库兼容（因为 MyBatis 使用 JDBC 来连接数据库，所以只要
JDBC 支持的数据库 MyBatis 都支持）。
4、能够与 Spring 很好的集成；
5、提供映射标签，支持对象与数据库的 ORM 字段关系映射；提供对象关系映射
标签，支持对象关系组件维护。
3、MyBatis 框架的缺点：
1、SQL 语句的编写工作量较大，尤其当字段多、关联表多时，对开发人员编写
SQL 语句的功底有一定要求。
2、SQL 语句依赖于数据库，导致数据库移植性差，不能随意更换数据库。
4、MyBatis 框架适用场合：
1、MyBatis 专注于 SQL 本身，是一个足够灵活的 DAO 层解决方案。
2、对性能的要求很高，或者需求变化较多的项目，如互联网项目，MyBatis 将是
不错的选择。
第 35 页 共 485 页
5、MyBatis 与 Hibernate 有哪些不同？
1、Mybatis 和 hibernate 不同，它不完全是一个 ORM 框架，因为 MyBatis 需要
程序员自己编写 Sql 语句。
2、Mybatis 直接编写原生态 sql，可以严格控制 sql 执行性能，灵活度高，非常
适合对关系数据模型要求不高的软件开发，因为这类软件需求变化频繁，一但需
求变化要求迅速输出成果。但是灵活的前提是 mybatis 无法做到数据库无关性，
如果需要实现支持多种数据库的软件，则需要自定义多套 sql 映射文件，工作量大。
3、Hibernate 对象/关系映射能力强，数据库无关性好，对于关系模型要求高的
软件，如果用 hibernate 开发可以节省很多代码，提高效率。
6、#{}和${}的区别是什么？
#{}是预编译处理，${}是字符串替换。
Mybatis 在处理#{}时，会将 sql 中的#{}替换为?号，调用 PreparedStatement 的
set 方法来赋值；
Mybatis 在处理${}时，就是把${}替换成变量的值。
使用#{}可以有效的防止 SQL 注入，提高系统安全性。
7、当实体类中的属性名和表中的字段名不一样 ，怎么办 ？
第 1 种： 通过在查询的 sql 语句中定义字段名的别名，让字段名的别名和实体类
的属性名一致。
第 36 页 共 485 页
me.gacl.domain.order”>
select order_id id, order_no orderno ,order_price price form
orders where order_id=#{id};

第 2 种： 通过来映射字段名和实体类属性名的一一对应的关系。
resultMap="orderresultmap">
select * from orders where order_id=#{id}




为数据表中的属性–>



8、 模糊查询 like 语句该怎么写?
第 1 种：在 Java 代码中添加 sql 通配符。
string wildcardname = “%smi%”;
list names = mapper.selectlike(wildcardname);
第 37 页 共 485 页

select * from foo where bar like #{value}

第 2 种：在 sql 语句中拼接通配符，会引起 sql 注入
string wildcardname = “smi”;
list names = mapper.selectlike(wildcardname);

select * from foo where bar like "%"#{value}"%"

9、通常一个 Xml 映射文件，都会写一个 Dao 接口与之对应，
请问，这个 Dao 接口的工作原理是什么？Dao 接口里的方法，
参数不同时，方法能重载吗？
Dao 接口即 Mapper 接口。接口的全限名，就是映射文件中的 namespace 的值；
接口的方法名，就是映射文件中 Mapper 的 Statement 的 id 值；接口方法内的
参数，就是传递给 sql 的参数。
Mapper 接口是没有实现类的，当调用接口方法时，接口全限名+方法名拼接字符
串作为 key 值，可唯一定位一个 MapperStatement。在 Mybatis 中，每一个
、、、标签，都会被解析为一个
MapperStatement 对象。
第 38 页 共 485 页
举例：com.mybatis3.mappers.StudentDao.findStudentById，可以唯
一找到 namespace 为 com.mybatis3.mappers.StudentDao 下面 id 为
findStudentById 的 MapperStatement。
Mapper 接口里的方法，是不能重载的，因为是使用 全限名+方法名 的保存和寻
找策略。Mapper 接口的工作原理是 JDK 动态代理，Mybatis 运行时会使用 JDK
动态代理为 Mapper 接口生成代理对象 proxy，代理对象会拦截接口方法，转而
执行 MapperStatement 所代表的 sql，然后将 sql 执行结果返回。
10、Mybatis 是如何进行分页的？分页插件的原理是什么？
Mybatis 使用 RowBounds 对象进行分页，它是针对 ResultSet 结果集执行的内
存分页，而非物理分页。可以在 sql 内直接书写带有物理分页的参数来完成物理分
页功能，也可以使用分页插件来完成物理分页。
分页插件的基本原理是使用 Mybatis 提供的插件接口，实现自定义插件，在插件
的拦截方法内拦截待执行的 sql，然后重写 sql，根据 dialect 方言，添加对应的物
理分页语句和物理分页参数。
11、Mybatis是如何将sql执行结果封装为目标对象并返回的？
都有哪些映射形式？
第一种是使用标签，逐一定义数据库列名和对象属性名之间的映
射关系。
第二种是使用 sql 列的别名功能，将列的别名书写为对象属性名。
第 39 页 共 485 页
有了列名与属性名的映射关系后，Mybatis 通过反射创建对象，同时使用反射给
对象的属性逐一赋值并返回，那些找不到映射关系的属性，是无法完成赋值的。
12、如何执行批量插入?
首先,创建一个简单的 insert 语句:

insert into names (name) values (#{value})

然后在 java 代码中像下面这样执行批处理插入:
list < string > names = new arraylist();
names.add(“fred”);
names.add(“barney”);
names.add(“betty”);
names.add(“wilma”);
// 注意这里 executortype.batch
sqlsession sqlsession =
sqlsessionfactory.opensession(executortype.batch);
try {
namemapper mapper = sqlsession.getmapper(namemapper.class);
for (string name: names) {
mapper.insertname(name);
}
sqlsession.commit();
} catch (Exception e) {
e.printStackTrace();
sqlSession.rollback();
第 40 页 共 485 页
throw e;
}
finally {
sqlsession.close();
}
13、如何获取自动生成的(主)键值?
insert 方法总是返回一个 int 值 ，这个值代表的是插入的行数。
如果采用自增长策略，自动生成的键值在 insert 方法执行完后可以被设置到传入
的参数对象中。
示例：
id”>
insert into names (name) values (#{name})

name name = new name();
name.setname(“fred”);
int rows = mapper.insertname(name);
// 完成后,id 已经被设置到对象中
system.out.println(“rows inserted = ” + rows);
system.out.println(“generated key value = ” + name.getid());
14、在 mapper 中如何传递多个参数?
第 41 页 共 485 页
1、第一种：
DAO 层的函数
public UserselectUser(String name,String area);
对应的 xml,#{0}代表接收的是 dao 层中的第一个参数，#{1}代表 dao 层中第二
参数，更多参数一致往后加即可。

select * fromuser_user_t whereuser_name = #{0}
anduser_area=#{1}

2、第二种： 使用 @param 注解:
public interface usermapper {
user selectuser(@param(“username”) string
username,@param(“hashedpassword”) string hashedpassword);
}
然后,就可以在 xml 像下面这样使用(推荐封装为一个 map,作为单个参数传递给
mapper):

select id, username, hashedpassword
from some_table
where username = #{username}
and hashedpassword = #{hashedpassword}

3、第三种：多个参数封装成 map
第 42 页 共 485 页
try {
//映射文件的命名空间.SQL 片段的 ID，就可以调用对应的映射文件中的
SQL
//由于我们的参数超过了两个，而方法中只有一个 Object 参数收集，因此
我们使用 Map 集合来装载我们的参数
Map < String, Object > map = new HashMap();
map.put("start", start);
map.put("end", end);
return sqlSession.selectList("StudentID.pagination", map);
} catch (Exception e) {
e.printStackTrace();
sqlSession.rollback();
throw e;
} finally {
MybatisUtil.closeSqlSession();
}
15、Mybatis 动态 sql 有什么用？执行原理？有哪些动态 sql？
Mybatis 动态 sql 可以在 Xml 映射文件内，以标签的形式编写动态 sql，执行原理
是根据表达式的值 完成逻辑判断并动态拼接 sql 的功能。
Mybatis 提供了 9 种动态 sql 标签：trim | where | set | foreach | if | choose
| when | otherwise | bind。
16、Xml 映射文件中，除了常见的 select|insert|updae|delete
标签之外，还有哪些标签？
第 43 页 共 485 页
答：、、、、
，加上动态 sql 的 9 个标签，其中为 sql 片段标签，通过
标签引入 sql 片段，为不支持自增的主键生成策略标
签。
17、Mybatis 的 Xml 映射文件中，不同的 Xml 映射文件，id 是否可以重复？
不同的 Xml 映射文件，如果配置了 namespace，那么 id 可以重复；如果没有配
置 namespace，那么 id 不能重复；
原因就是 namespace+id 是作为 Map的 key
使用的，如果没有 namespace，就剩下 id，那么，id 重复会导致数据互相覆盖。
有了 namespace，自然 id 就可以重复，namespace 不同，namespace+id 自然
也就不同。
18、为什么说 Mybatis 是半自动 ORM 映射工具？它与全自动
的区别在哪里？
Hibernate 属于全自动 ORM 映射工具，使用 Hibernate 查询关联对象或者关联
集合对象时，可以根据对象关系模型直接获取，所以它是全自动的。而 Mybatis
在查询关联对象或关联集合对象时，需要手动编写 sql 来完成，所以，称之为半自
动 ORM 映射工具。
19、 一对一、一对多的关联查询 ？


第 44 页 共 485 页
resultMap="ClassesResultMap">
select * from class c,teacher t where c.teacher_id=t.t_id and
c.c_id=#{id}





javaType="com.lcb.user.Teacher">





resultMap="ClassesResultMap2">
select * from class c,teacher t,student s where c.teacher_id=t.t_id
and c.c_id=s.class_id and c.c_id=#{id}




javaType="com.lcb.user.Teacher">

第 45 页 共 485 页


ofType="com.lcb.user.Student">





20、MyBatis 实现一对一有几种方式?具体怎么操作的？
有联合查询和嵌套查询,联合查询是几个表联合查询,只查询一次, 通过在
resultMap 里面配置 association 节点配置一对一的类就可以完成；
嵌套查询是先查一个表，根据这个表里面的结果的 外键 id，去再另外一个表里面
查询数据,也是通过 association 配置，但另外一个表的查询通过 select 属性配置。
21、MyBatis 实现一对多有几种方式,怎么操作的？
有联合查询和嵌套查询。联合查询是几个表联合查询,只查询一次,通过在
resultMap 里面的 collection 节点配置一对多的类就可以完成；嵌套查询是先查
一个表,根据这个表里面的 结果的外键 id,去再另外一个表里面查询数据,也是通过
配置 collection,但另外一个表的查询通过 select 节点配置。
第 46 页 共 485 页
22、Mybatis 是否支持延迟加载？如果支持，它的实现原理是
什么？
答：Mybatis 仅支持 association 关联对象和 collection 关联集合对象的延迟加
载，association 指的就是一对一，collection 指的就是一对多查询。在 Mybatis
配置文件中，可以配置是否启用延迟加载 lazyLoadingEnabled=true|false。
它的原理是，使用 CGLIB 创建目标对象的代理对象，当调用目标方法时，进入拦
截器方法，比如调用 a.getB().getName()，拦截器 invoke()方法发现 a.getB()是
null 值，那么就会单独发送事先保存好的查询关联 B 对象的 sql，把 B 查询上来，
然后调用 a.setB(b)，于是 a 的对象 b 属性就有值了，接着完成 a.getB().getName()
方法的调用。这就是延迟加载的基本原理。
当然了，不光是 Mybatis，几乎所有的包括 Hibernate，支持延迟加载的原理都
是一样的。
23、Mybatis 的一级、二级缓存:
1）一级缓存: 基于 PerpetualCache 的 HashMap 本地缓存，其存储作用域为
Session，当 Session flush 或 close 之后，该 Session 中的所有 Cache 就
将清空，默认打开一级缓存。
2）二级缓存与一级缓存其机制相同，默认也是采用 PerpetualCache，HashMap
存储，不同在于其存储作用域为 Mapper(Namespace)，并且可自定义存储源，
如 Ehcache。默认不打开二级缓存，要开启二级缓存，使用二级缓存属性类需要
实现 Serializable 序列化接口(可用来保存对象的状态),可在它的映射文件中配置
；
第 47 页 共 485 页
3）对于缓存数据更新机制，当某一个作用域(一级缓存 Session/二级缓存
Namespaces)的进行了 C/U/D 操作后，默认该作用域下所有 select 中的缓存将
被 clear。
24、什么是 MyBatis 的接口绑定？有哪些实现方式？
接口绑定，就是在 MyBatis 中任意定义接口,然后把接口里面的方法和 SQL 语句绑
定, 我们直接调用接口方法就可以,这样比起原来了 SqlSession 提供的方法我们可
以有更加灵活的选择和设置。
接口绑定有两种实现方式,一种是通过注解绑定，就是在接口的方法上面加上
@Select、@Update 等注解，里面包含 Sql 语句来绑定；另外一种就是通过 xml
里面写 SQL 来绑定, 在这种情况下,要指定 xml 映射文件里面的 namespace 必须
为接口的全路径名。当 Sql 语句比较简单时候,用注解绑定, 当 SQL 语句比较复杂
时候,用 xml 绑定,一般用 xml 绑定的比较多。
25、使用 MyBatis 的 mapper 接口调用时有哪些要求？
1、Mapper 接口方法名和 mapper.xml 中定义的每个 sql 的 id 相同；
2、Mapper 接口方法的输入参数类型和 mapper.xml 中定义的每个 sql 的
parameterType 的类型相同；
3、Mapper 接口方法的输出参数类型和 mapper.xml 中定义的每个 sql 的
resultType 的类型相同；
4、Mapper.xml 文件中的 namespace 即是 mapper 接口的类路径。
26、Mapper 编写有哪几种方式？
第 48 页 共 485 页
第一种：接口实现类继承 SqlSessionDaoSupport：使用此种方法需要编写
mapper 接口，mapper 接口实现类、mapper.xml 文件。
1、在 sqlMapConfig.xml 中配置 mapper.xml 的位置




1、定义 mapper 接口
3、实现类集成 SqlSessionDaoSupport
mapper 方法中可以 this.getSqlSession()进行数据增删改查。
4、spring 配置

ref="sqlSessionFactory">

第二种：使用 org.mybatis.spring.mapper.MapperFactoryBean：
1、在 sqlMapConfig.xml 中配置 mapper.xml 的位置，如果 mapper.xml 和
mappre 接口的名称相同且在同一个目录，这里可以不用配置




2、定义 mapper 接口：
第 49 页 共 485 页
1、mapper.xml 中的 namespace 为 mapper 接口的地址
2、mapper 接口中的方法名和 mapper.xml 中的定义的 statement 的 id 保持一
致
3、Spring 中定义




第三种：使用 mapper 扫描器：
1、mapper.xml 文件编写：
mapper.xml 中的 namespace 为 mapper 接口的地址；
mapper 接口中的方法名和 mapper.xml 中的定义的 statement 的 id 保持一致；
如果将 mapper.xml 和 mapper 接口的名称保持一致则不用在 sqlMapConfig.xml
中进行配置。
2、定义 mapper 接口：
注意 mapper.xml 的文件名和 mapper 的接口名称保持一致，且放在同一个目录
3、配置 mapper 扫描器：


value="sqlSessionFactory"/>

第 50 页 共 485 页
4、使用扫描器后从 spring 容器中获取 mapper 的实现对象。
27、简述 Mybatis 的插件运行原理，以及如何编写一个插件。
答：Mybatis 仅可以编写针对 ParameterHandler、ResultSetHandler、
StatementHandler、Executor 这 4 种接口的插件，Mybatis 使用 JDK 的动态代
理，为需要拦截的接口生成代理对象以实现接口方法拦截功能，每当执行这 4 种
接口对象的方法时，就会进入拦截方法，具体就是 InvocationHandler 的 invoke()
方法，当然，只会拦截那些你指定需要拦截的方法。
编写插件：实现 Mybatis 的 Interceptor 接口并复写 intercept()方法，然后在给
插件编写注解，指定要拦截哪一个接口的哪些方法即可，记住，别忘了在配置文
件中配置你编写的插件。
ZooKeeper 面试题
1. ZooKeeper 面试题？
ZooKeeper 是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群
中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用
的接口和性能高效、功能稳定的系统提供给用户。
分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名
服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Zookeeper 保证了如下分布式一致性特性：
第 51 页 共 485 页
1、顺序一致性
2、原子性
3、单一视图
4、可靠性
5、实时性（最终一致性）
客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了
监听器，这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求，这些
请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功。因此，
随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。
有序性是 zookeeper 中非常重要的一个特性，所有的更新都是全局有序的，每个
更新都有一个唯一的时间戳，这个时间戳称为 zxid（Zookeeper Transaction Id）。
而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个
zookeeper 最新的 zxid。
2. ZooKeeper 提供了什么？
1、文件系统
2、通知机制
3. Zookeeper 文件系统
Zookeeper 提供一个多层级的节点命名空间（节点称为 znode）。与文件系统不
同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放
数据而目录节点不行。
Zookeeper 为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这
种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为
1M。
第 52 页 共 485 页
4. ZAB 协议？
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广
播协议。
ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。
当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导
致不存在过半的服务器与 Leader 服务器保持正常通信时，所有进程（服务器）进
入崩溃恢复模式，首先选举产生新的 Leader 服务器，然后集群中 Follower 服务
器开始与新的 Leader 服务器进行数据同步，当集群中超过半数机器与该 Leader
服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader 服务器开始
接收客户端的事务请求生成事物提案来进行事务请求处理。
5. 四种类型的数据节点 Znode
1、PERSISTENT-持久节点
除非手动删除，否则节点一直存在于 Zookeeper 上
2、EPHEMERAL-临时节点
临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与
zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都
会被移除。
3、PERSISTENT_SEQUENTIAL-持久顺序节点
基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维
护的自增整型数字。
第 53 页 共 485 页
4、EPHEMERAL_SEQUENTIAL-临时顺序节点
基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的
自增整型数字。
6. Zookeeper Watcher 机制 -- 数据变更通知
Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听，当服务
端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件通
知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出
业务上的改变。
工作机制：
1、客户端注册 watcher
2、服务端处理 watcher
3、客户端回调 watcher
Watcher 特性总结：
1、一次性
无论是服务端还是客户端，一旦一个 Watcher 被触发，Zookeeper 都会将其从相
应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频
繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的
压力都非常大。
2、客户端串行执行
客户端 Watcher 回调的过程是一个串行同步的过程。
3、轻量
第 54 页 共 485 页
3.1、Watcher 通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具
体内容。
3.2、客户端向服务端注册 Watcher 的时候，并不会把客户端真实的 Watcher 对
象实体传递到服务端，仅仅是在客户端请求中使用 boolean 类型属性进行了标记。
4、watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步
的，这就存在一个问题，不同的客户端和服务器之间通过 socket 进行通信，由于
网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于 Zookeeper 本身
提供了 ordering guarantee，即客户端监听事件后，才会感知它所监视 znode
发生了变化。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化。
Zookeeper 只能保证最终的一致性，而无法保证强一致性。
5、注册 watcher getData、exists、getChildren
6、触发 watcher create、delete、setData
7、当一个客户端连接到一个新的服务器上时，watch 将会被以任意会话事件触发。
当与一个服务器失去连接的时候，是无法接收到 watch 的。而当 client 重新连接
时，如果需要的话，所有先前注册过的 watch，都会被重新注册。通常这是完全
透明的。只有在一个特殊情况下，watch 可能会丢失：对于一个未创建的 znode
的 exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上
之前又删除了，这种情况下，这个 watch 事件可能会被丢失。
7. 客户端注册 Watcher 实现
1、调用 getData()/getChildren()/exist()三个 API，传入 Watcher 对象
2、标记请求 request，封装 Watcher 到 WatchRegistration
3、封装成 Packet 对象，发服务端发送 request
4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理
5、请求返回，完成注册。
第 55 页 共 485 页
8. 服务端处理 Watcher 实现
1、服务端接收 Watcher 并存储
接收到客户端请求，处理请求判断是否需要注册 Watcher，需要的话将数据节点
的节点路径和 ServerCnxn（ServerCnxn 代表一个客户端和服务端的连接，实现
了 Watcher 的 process 接口，此时可以看成一个 Watcher 对象）存储在
WatcherManager 的 WatchTable 和 watch2Paths 中去。
2、Watcher 触发
以服务端接收到 setData() 事务请求触发 NodeDataChanged 事件为例：
2.1 封装 WatchedEvent
将通知状态（SyncConnected）、事件类型（NodeDataChanged）以及节点路
径封装成一个 WatchedEvent 对象
2.2 查询 Watcher
从 WatchTable 中根据节点路径查找 Watcher
2.3 没找到；说明没有客户端在该数据节点上注册过 Watcher
2.4 找到；提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher（从这里
可以看出 Watcher 在服务端是一次性的，触发一次就失效了）
3、调用 process 方法来触发 Watcher
这里 process 主要就是通过 ServerCnxn 对应的 TCP 连接发送 Watcher 事件通知。
9. 客户端回调 Watcher
第 56 页 共 485 页
客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调 Watcher。
客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。
10. ACL 权限控制机制
UGO（User/Group/Others）
目前在 Linux/Unix 文件系统中使用，也是使用最广泛的权限控制方式。是一种粗
粒度的文件系统权限控制模式。
ACL（Access Control List）访问控制列表
包括三个方面：
权限模式（Scheme）
1、IP：从 IP 地址粒度进行权限控制
2、Digest：最常用，用类似于 username:password 的权限标识来进行权限配
置，便于区分不同应用来进行权限控制
3、World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标
识“world:anyone”
4、Super：超级用户
授权对象
授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器灯。
权限 Permission
1、CREATE：数据节点创建权限，允许授权对象在该 Znode 下创建子节点
第 57 页 共 485 页
2、DELETE：子节点删除权限，允许授权对象删除该数据节点的子节点
3、READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内
容或子节点列表等
4、WRITE：数据节点更新权限，允许授权对象对该数据节点进行更新操作
5、ADMIN：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置
操作
11. Chroot 特性
3.2.0 版本后，添加了 Chroot 特性，该特性允许每个客户端为自己设置一个命名
空间。如果一个客户端设置了 Chroot，那么该客户端对服务器的任何操作，都将
会被限制在其自己的命名空间下。
通过设置 Chroot，能够将一个客户端应用于 Zookeeper 服务端的一颗子树相对
应，在那些多个应用公用一个 Zookeeper 进群的场景下，对实现不同应用间的相
互隔离非常有帮助。
12. 会话管理
分桶策略：将类似的会话放在同一区块中进行管理，以便于 Zookeeper 对会话进
行不同区块的隔离处理以及同一区块的统一处理。
分配原则：每个会话的“下次超时时间点”（ExpirationTime）
计算公式：
ExpirationTime_ = currentTime + sessionTimeout
第 58 页 共 485 页
ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *
ExpirationInterval , ExpirationInterval 是指 Zookeeper 会话超时检查时间
间隔，默认 tickTime
13. 服务器角色
Leader
1、事务请求的唯一调度和处理者，保证集群事务处理的顺序性
2、集群内部各服务的调度者
Follower
1、处理客户端的非事务请求，转发事务请求给 Leader 服务器
2、参与事务请求 Proposal 的投票
3、参与 Leader 选举投票
Observer
1、3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提
升集群的非事务处理能力
2、处理客户端的非事务请求，转发事务请求给 Leader 服务器
3、不参与任何形式的投票
14. Zookeeper 下 Server 工作状态
服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
第 59 页 共 485 页
1、LOOKING：寻找 Leader 状态。当服务器处于该状态时，它会认为当前集群中
没有 Leader，因此需要进入 Leader 选举状态。
2、FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
3、LEADING：领导者状态。表明当前服务器角色是 Leader。
4、OBSERVING：观察者状态。表明当前服务器角色是 Observer。
15. 数据同步
整个集群完成 Leader 选举之后，Learner（Follower 和 Observer 的统称）回向
Leader 服务器进行注册。当 Learner 服务器想 Leader 服务器完成注册后，进入
数据同步环节。
数据同步流程：（均以消息传递的方式进行）
Learner 向 Learder 注册
数据同步
同步确认
Zookeeper 的数据同步通常分为四类：
1、直接差异化同步（DIFF 同步）
2、先回滚再差异化同步（TRUNC+DIFF 同步）
3、仅回滚同步（TRUNC 同步）
4、全量同步（SNAP 同步）
在进行数据同步前，Leader 服务器会完成数据同步初始化：
peerLastZxid：
第 60 页 共 485 页
? 从 learner 服务器注册时发送的 ACKEPOCH 消息中提取 lastZxid（该
Learner 服务器最后处理的 ZXID）
minCommittedLog：
? Leader 服务器 Proposal 缓存队列 committedLog 中最小 ZXID
maxCommittedLog：
? Leader 服务器 Proposal 缓存队列 committedLog 中最大 ZXID
直接差异化同步（DIFF 同步）
? 场景：peerLastZxid 介于 minCommittedLog 和 maxCommittedLog
之间
先回滚再差异化同步（TRUNC+DIFF 同步）
? 场景：当新的 Leader 服务器发现某个 Learner 服务器包含了一条自己没
有的事务记录，那么就需要让该 Learner 服务器进行事务回滚--回滚到 Leader
服务器上存在的，同时也是最接近于 peerLastZxid 的 ZXID
仅回滚同步（TRUNC 同步）
第 61 页 共 485 页
? 场景：peerLastZxid 大于 maxCommittedLog
全量同步（SNAP 同步）
? 场景一：peerLastZxid 小于 minCommittedLog
? 场景二：Leader 服务器上没有 Proposal 缓存队列且 peerLastZxid 不等
于 lastProcessZxid
16. zookeeper 是如何保证事务的顺序一致性的？
zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被
提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch（时
期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch
会自增，低 32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两
阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能
执行并且能够成功，那么就会开始执行。
17. 分布式集群中为什么会有 Master？
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机
器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行
leader 选举。
18. zk 节点宕机如何处理？
第 62 页 共 485 页
Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保
证当一个节点宕机时，其他节点会继续提供服务。
如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数
据是有多个副本的，数据并不会丢失；
如果是一个 Leader 宕机，Zookeeper 会选举出新的 Leader。
ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在 ZK
节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
所以
3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)
2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)
19. zookeeper 负载均衡和 nginx 负载均衡区别
zk 的负载均衡是可以调控，nginx 只是能调权重，其他需要可控的都需要自己写
插件；但是 nginx 的吞吐量比 zk 大很多，应该说按业务选择用哪种方式。
20. Zookeeper 有哪几种几种部署模式？
部署模式：单机模式、伪集群模式、集群模式。
21. 集群最少要几台机器，集群规则是怎样的?
集群规则为 2N+1 台，N>0，即 3 台。
22. 集群支持动态添加机器吗？
其实就是水平扩容了，Zookeeper 在这方面不太好。两种方式：
第 63 页 共 485 页
全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的
会话。
逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供
服务。这是比较常用的方式。
3.5 版本开始支持动态扩容。
23. Zookeeper 对节点的 watch监听通知是永久的吗？为什么
不是永久的?
不是。官方声明：一个 Watch 事件是一个一次性的触发器，当被设置了 Watch
的数据发生了改变的时候，则服务器将这个改变发送给设置了 Watch 的客户端，
以便通知它们。
为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况
下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。
一般是客户端执行 getData(“/节点 A”,true)，如果节点 A 发生了变更或删除，
客户端会得到它的 watch 事件，但是在之后节点 A 又发生了变更，而客户端又没
有设置 watch 事件，就不再给客户端发送。
在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我
只要最新的数据即可。
24. Zookeeper 的 java 客户端都有哪些？
java 客户端：zk 自带的 zkclient 及 Apache 开源的 Curator。
第 64 页 共 485 页
25. chubby 是什么，和 zookeeper 比你怎么看？
chubby 是 google 的，完全实现 paxos 算法，不开源。zookeeper 是 chubby
的开源实现，使用 zab 协议，paxos 算法的变种。
26. 说几个 zookeeper 常用的命令。
常用命令：ls get set create delete 等。
27. ZAB 和 Paxos 算法的联系与区别？
相同点：
1、两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程
的运行
2、Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提
案进行提交
3、ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader
周期，Paxos 中名字为 Ballot
不同点：
ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建
分布式一致性状态机系统。
28. Zookeeper 的典型应用场景
第 65 页 共 485 页
Zookeeper 是一个典型的发布/订阅模式的分布式数据管理与协调框架，开发人员
可以使用它来进行分布式数据的发布和订阅。
通过对 Zookeeper 中丰富的数据节点进行交叉使用，配合 Watcher 事件通知机
制，可以非常方便的构建一系列分布式应用中年都会涉及的核心功能，如：
1、数据发布/订阅
2、负载均衡
3、命名服务
4、分布式协调/通知
5、集群管理
6、Master 选举
7、分布式锁
8、分布式队列
1. 数据发布/订阅
介绍
数据发布/订阅系统，即所谓的配置中心，顾名思义就是发布者发布数据供订阅者
进行数据订阅。
目的
动态获取数据（配置信息）
实现数据（配置信息）的集中式管理和数据的动态更新
设计模式
Push 模式
Pull 模式
第 66 页 共 485 页
数据（配置信息）特性
1、数据量通常比较小
2、数据内容在运行时会发生动态更新
3、集群中各机器共享，配置一致
如：机器列表信息、运行时开关配置、数据库配置信息等
基于 Zookeeper 的实现方式
? 数据存储：将数据（配置信息）存储到 Zookeeper 上的一个数据节点
? 数据获取：应用在启动初始化节点从 Zookeeper 数据节点读取数据，并
在该节点上注册一个数据变更 Watcher
? 数据变更：当变更数据时，更新 Zookeeper 对应节点数据，Zookeeper
会将数据变更通知发到各客户端，客户端接到通知后重新读取变更后的数据即
可。
2. 负载均衡
zk 的命名服务
命名服务是指通过指定的名字来获取资源或者服务的地址，利用 zk 创建一个全局
的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，
或者一个远程的对象等等。
分布式通知和协调
对于系统调度来说：操作人员发送通知实际是通过控制台改变某个节点的状态，
然后 zk 将这些变化发送给注册了这个节点的 watcher 的所有客户端。
第 67 页 共 485 页
对于执行情况汇报：每个工作进程都在某个目录下创建一个临时节点。并携带工
作的进度数据，这样汇总的进程可以监控目录子节点的变化获得工作进度的实时
的全局情况。
zk 的命名服务（文件系统）
命名服务是指通过指定的名字来获取资源或者服务的地址，利用 zk 创建一个全局
的路径，即是唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，
提供的服务的地址，或者一个远程的对象等等。
zk 的配置管理（文件系统、通知机制）
程序分布式的部署在不同的机器上，将程序的配置信息放在 zk 的 znode 下，当有
配置发生改变时，也就是 znode 发生变化时，可以通过改变 zk 中某个目录节点的
内容，利用 watcher 通知给各个客户端，从而更改配置。
Zookeeper 集群管理（文件系统、通知机制）
所谓集群管理无在乎两点：是否有机器退出和加入、选举 master。
对于第一点，所有机器约定在父目录下创建临时目录节点，然后监听父目录节点
的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper 的连接断开，其所创
建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于
是，所有人都知道：它上船了。
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount 又有了，
对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选
取编号最小的机器作为 master 就好。
Zookeeper 分布式锁（文件系统、通知机制）
有了 zookeeper 的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，
一个是保持独占，另一个是控制时序。
第 68 页 共 485 页
对于第一类，我们将 zookeeper 上的一个 znode 看作是一把锁，通过 createznode
的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那
个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放
出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺
序编号目录节点，和选 master 一样，编号最小的获得锁，用完删除，依次方便。
Zookeeper 队列管理（文件系统、通知机制）
两种类型的队列：
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有
成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按
编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL 节点，创建成功时
Watcher 通知等待的队列，队列删除序列号最小的节点用以消费。此场景下
Zookeeper 的 znode 用于消息存储，znode 存储的数据就是消息队列中的消息内
容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是持
久化的，所以不必担心队列消息的丢失问题。
Dubbo 面试题
1、为什么要用 Dubbo？
第 69 页 共 485 页
随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越
复杂，诞生了面向服务的架构体系(SOA)，
也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信
协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。
就这样为分布式系统的服务治理框架就出现了，Dubbo 也就这样产生了。
2、Dubbo 的整体架构设计有哪些分层?
接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的
业务设计对应的接口和实现
配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为
中心
服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端
的 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory
服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心，
扩展接口为 RegistryFactory、Registry、RegistryService
路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心，以
Invoker 为中心，扩展接口为 Cluster、Directory、Router 和 LoadBlancce
监控层（Monitor）：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩
展接口为 MonitorFactory、Monitor 和 MonitorService
远程调用层（Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心，
扩展接口为 Protocal、Invoker 和 Exporter
第 70 页 共 485 页
信息交换层（Exchange）：封装请求响应模式，同步转异步。以 Request 和
Response 为中心，扩展接口为 Exchanger、ExchangeChannel、
ExchangeClient 和 ExchangeServer
网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为
中心，扩展接口为 Channel、Transporter、Client、Server 和 Codec
数据序列化层（Serialize）：可复用的一些工具，扩展接口为 Serialization、
ObjectInput、ObjectOutput 和 ThreadPool
3、默认使用的是什么通信框架，还有别的选择吗?
默认也推荐使用 netty 框架，还有 mina。
4、服务调用是阻塞的吗？
默认是阻塞的，可以异步调用，没有返回值的可以这么做。
Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成
并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对
象。
5、一般使用什么注册中心？还有别的选择吗？
推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中
心，但不推荐。
第 71 页 共 485 页
6、默认使用什么序列化框架，你知道的还有哪些？
推荐使用 Hessian 序列化，还有 Duddo、FastJson、Java 自带序列化。
7、服务提供者能实现失效踢出是什么原理？
服务失效踢出基于 zookeeper 的临时节点原理。
8、服务上线怎么不影响旧版本？
采用多版本开发，不影响旧版本。
9、如何解决服务调用链过长的问题？
可以结合 zipkin 实现分布式服务追踪。
10、说说核心的配置有哪些？
配置 配置说明
dubbo:service 服务配置
dubbo:reference 引用配置
dubbo:protocol 协议配置
dubbo:applicatio
n
应用配置
第 72 页 共 485 页
dubbo:module 模块配置
dubbo:registry 注册中心配置
dubbo:monitor 监控中心配置
dubbo:provider 提供方配置
dubbo:consumer 消费方配置
dubbo:method 方法配置
dubbo:argument 参数配置
11、Dubbo 推荐用什么协议？
? dubbo://（推荐）
? rmi://
? hessian://
? http://
? webservice://
? thrift://
? memcached://
? redis://
? rest://
12、同一个服务多个注册的情况下可以直连某一个服务吗？
可以点对点直连，修改配置即可，也可以通过 telnet 直接某个服务。
第 73 页 共 485 页
13、画一画服务注册与发现的流程图？
14、Dubbo 集群容错有几种方案？
集群容错方案 说明
Failover Cluster 失败自动切换，自动重试其它服务器（默认）
Failfast Cluster 快速失败，立即报错，只发起一次调用
Failsafe Cluster 失败安全，出现异常时，直接忽略
Failback Cluster 失败自动恢复，记录失败请求，定时重发
Forking Cluster 并行调用多个服务器，只要一个成功即返回
第 74 页 共 485 页
Broadcast Cluster 广播逐个调用所有提供者，任意一个报错则报错
15、Dubbo 服务降级，失败重试怎么做？
可以通过 dubbo:reference 中设置 mock="return null"。mock 的值也可以修
改为 true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口
名称+Mock” 后缀。然后在 Mock 类里实现自己的降级逻辑
16、Dubbo 使用过程中都遇到了些什么问题？
在注册中心找不到对应的服务,检查 service 实现类是否添加了@service 注解
无法连接到注册中心,检查配置文件中的对应的测试 ip 是否正确
17、Dubbo Monitor 实现原理？
Consumer 端在发起调用之前会先走 filter 链；provider 端在接收到请求时也是
先走 filter 链，然后才进行真正的业务逻辑处理。
默认情况下，在 consumer 和 provider 的 filter 链中都会有 Monitorfilter。
1、MonitorFilter 向 DubboMonitor 发送数据
2、DubboMonitor 将数据进行聚合后（默认聚合 1min 中的统计数据）暂存到
ConcurrentMap statisticsMap，然后使用一个
含有 3 个线程（线程名字：DubboMonitorSendTimer）的线程池每隔 1min 钟，
调用 SimpleMonitorService 遍历发送 statisticsMap 中的统计数据，每发送完毕
一个，就重置当前的 Statistics 的 AtomicReference
3、SimpleMonitorService 将这些聚合数据塞入 BlockingQueue queue 中（队
列大写为 100000）
第 75 页 共 485 页
4、SimpleMonitorService 使用一个后台线程（线程名为：
DubboMonitorAsyncWriteLogThread）将 queue 中的数据写入文件（该线程以
死循环的形式来写）
5、SimpleMonitorService 还会使用一个含有 1 个线程（线程名字：
DubboMonitorTimer）的线程池每隔 5min 钟，将文件中的统计数据画成图表
18、Dubbo 用到哪些设计模式？
Dubbo 框架在初始化和通信过程中使用了多种设计模式，可灵活控制类加载、权
限控制等功能。
工厂模式
Provider 在 export 服务时，会调用 ServiceConfig 的 export 方法。ServiceConfig
中有个字段：
private static final Protocol protocol =
ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi
on();
Dubbo 里有很多这种代码。这也是一种工厂模式，只是实现类的获取采用了 JDK
SPI 的机制。这么实现的优点是可扩展性强，想要扩展实现，只需要在 classpath
下增加个文件就可以了，代码零侵入。另外，像上面的 Adaptive 实现，可以做到
调用时动态决定调用哪个实现，但是由于这种实现采用了动态代理，会造成代码
调试比较麻烦，需要分析出实际调用的实现类。
装饰器模式
Dubbo 在启动和调用阶段都大量使用了装饰器模式。以 Provider 提供的调用链为
例，具体的调用链代码是在 ProtocolFilterWrapper 的 buildInvokerChain 完成
的，具体是将注解中含有 group=provider 的 Filter 实现，按照 order 排序，最
后的调用顺序是：
第 76 页 共 485 页
EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->
ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->
ExceptionFilter
更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter 的作用是
判断是否是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像
ClassLoaderFilter 则只是在主功能上添加了功能，更改当前线程的 ClassLoader，
这是典型的装饰器模式。
观察者模式
Dubbo 的 Provider 启动时，需要与注册中心交互，先注册自己的服务，再订阅自
己的服务，订阅时，采用了观察者模式，开启一个 listener。注册中心会每 5 秒定
时检查是否有服务更新，如果有更新，向该服务的提供者发送一个 notify 消息，
provider 接受到 notify 消息后，即运行 NotifyListener 的 notify 方法，执行监
听器方法。
动态代理模式
Dubbo 扩展 JDK SPI 的类 ExtensionLoader 的 Adaptive 实现是典型的动态代理
实现。Dubbo 需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪
个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的
代码是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理类
的主要逻辑是，获取 URL 参数中指定参数的值作为获取实现类的 key。
19、Dubbo 配置文件是如何加载到 Spring 中的？
Spring 容器在启动的时候，会读取到 Spring 默认的一些 schema 以及 Dubbo 自
定义的 schema，每个 schema 都会对应一个自己的 NamespaceHandler，
NamespaceHandler 里面通过 BeanDefinitionParser 来解析配置信息并转化为
需要加载的 bean 对象！
第 77 页 共 485 页
20、Dubbo SPI 和 Java SPI 区别？
JDK SPI
JDK 标准的 SPI 会一次性加载所有的扩展实现，如果有的扩展吃实话很耗时，但
也没用上，很浪费资源。
所以只希望加载某个的实现，就不现实了
DUBBO SPI
1，对 Dubbo 进行扩展，不需要改动 Dubbo 的源码
2，延迟加载，可以一次只加载自己想要加载的扩展实现。
3，增加了对扩展点 IOC 和 AOP 的支持，一个扩展点可以直接 setter 注入其
它扩展点。
3，Dubbo 的扩展机制能很好的支持第三方 IoC 容器，默认支持 Spring Bean。
21、Dubbo 支持分布式事务吗？
目前暂时不支持，可与通过 tcc-transaction 框架实现
介绍：tcc-transaction 是开源的 TCC 补偿性分布式事务框架
Git 地址：https://github.com/changmingxie/tcc-transaction
TCC-Transaction 通过 Dubbo 隐式传参的功能，避免自己对业务代码的入侵。
22、Dubbo 可以对结果进行缓存吗？
第 78 页 共 485 页
为了提高数据访问的速度。Dubbo 提供了声明式缓存，以减少用户加缓存的工作
量

其实比普通的配置文件就多了一个标签 cache="true"
23、服务上线怎么兼容旧版本？
可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不
同的服务相互间不引用。这个和服务分组的概念有一点类似。
24、Dubbo 必须依赖的包有哪些？
Dubbo 必须依赖 JDK，其他为可选。
25、Dubbo telnet 命令能做什么？
dubbo 服务发布之后，我们可以利用 telnet 命令进行调试、管理。
Dubbo2.0.5 以上版本服务提供端口支持 telnet 命令
连接服务
telnet localhost 20880 //键入回车进入 Dubbo 命令模式。
查看服务列表
dubbo>ls
com.test.TestService
第 79 页 共 485 页
dubbo>ls com.test.TestService
create
delete
query
? ls (list services and methods)
? ls : 显示服务列表。
? ls -l : 显示服务详细信息列表。
? ls XxxService：显示服务的方法列表。
? ls -l XxxService：显示服务的方法详细信息列表。
26、Dubbo 支持服务降级吗？
以通过 dubbo:reference 中设置 mock="return null"。mock 的值也可以修改
为 true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口名
称+Mock” 后缀。然后在 Mock 类里实现自己的降级逻辑
27、Dubbo 如何优雅停机？
Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果使用
kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才
会执行。
28、Dubbo 和 Dubbox 之间的区别？
Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如
加了服务可 Restful 调用，更新了开源组件等。
第 80 页 共 485 页
29、Dubbo 和 Spring Cloud 的区别？
根据微服务架构在各方面的要素，看看 Spring Cloud 和 Dubbo 都提供了哪些支
持。
Dubbo Spring Cloud
服务注册中心 Zookeep
er
Spring Cloud Netflix Eureka
服务调用方式 RPC REST API
服务网关 无 Spring Cloud Netflix Zuul
断路器 不完善 Spring Cloud Netflix Hystrix
分布式配置 无 Spring Cloud Config
服务跟踪 无 Spring Cloud Sleuth
消息总线 无 Spring Cloud Bus
数据流 无 Spring Cloud Stream
批量任务 无 Spring Cloud Task
…… …… ……
使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但
是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，
但是如果你是一名高手，那这些都不是问题；而 Spring Cloud 就像品牌机，在
Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，
但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。
第 81 页 共 485 页
30、你还了解别的分布式框架吗？
别的还有 spring 的 spring cloud，facebook 的 thrift，twitter 的 finagle 等
Elasticsearch 面试题
1、elasticsearch 了解多少，说说你们公司 es 的集群架构，索
引数据大小，分片有多少，以及一些调优手段 。
面试官：想了解应聘者之前公司接触的 ES 使用场景、规模，有没有做过比较大
规模的索引设计、规划、调优。
解答：
如实结合自己的实践场景回答即可。
比如：ES 集群架构 13 个节点，索引根据通道不同共 20+索引，根据日期，每日
递增 20+，索引：10 分片，每日递增 1 亿+数据，
每个通道每天索引大小控制：150GB 之内。
仅索引层面调优手段：
1.1、设计阶段调优
1、根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索
引；
2、使用别名进行索引管理；
3、每天凌晨定时对索引做 force_merge 操作，以释放空间；
第 82 页 共 485 页
4、采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink
操作，以缩减存储；
5、采取 curator 进行索引的生命周期管理；
6、仅针对需要分词的字段，合理的设置分词器；
7、Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。……..
1.2、写入调优
1、写入前副本数设置为 0；
2、写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
3、写入过程中：采取 bulk 批量写入；
4、写入后恢复副本数和刷新间隔；
5、尽量使用自动生成的 id。
1.3、查询调优
1、禁用 wildcard；
2、禁用批量 terms（成百上千的场景）；
3、充分利用倒排索引机制，能 keyword 类型尽量 keyword；
4、数据量大时候，可以先基于时间敲定索引再检索；
第 83 页 共 485 页
5、设置合理的路由机制。
1.4、其他调优
部署调优，业务调优等。
上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。
2、elasticsearch 的倒排索引是什么
面试官：想了解你对基础概念的认知。
解答：通俗解释一下就可以。
传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。
而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表
即为倒排索引。
有了倒排索引，就能实现 o（1）时间复杂度的效率检索文章了，极大的提高了
检索效率。
第 84 页 共 485 页
学术的解答方式：
倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文
档中出现过，由两部分组成——词典和倒排表。
加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结
构。
lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：
1、空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
2、查询速度快。O(len(str))的查询时间复杂度。
3、elasticsearch 索引数据多了怎么办，如何调优，部署
面试官：想了解大数据量的运维能力。
解答：索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在后”，
这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户
检索或者其他业务受到影响。
如何调优，正如问题 1 所说，这里细化一下：
3.1 动态索引层面
基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索
引的模板格式为：blog_index_时间戳的形式，每天递增数据。
这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的
32 次幂-1，索引存储达到了 TB+甚至更大。
一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。
第 85 页 共 485 页
3.2 存储层面
冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。
对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，
节省存储空间和检索效率。
3.3 部署层面
一旦之前没有规划，这里就属于应急策略。
结合 ES 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注
意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的。
4、elasticsearch 是如何实现 master 选举的
面试官：想了解 ES 集群的底层原理，不再只关注业务层面了。
解答：
前置前提：
1、只有候选主节点（master：true）的节点才能成为主节点。
2、最小主节点数（min_master_nodes）的目的是防止脑裂。
这个我看了各种网上分析的版本和源码分析的书籍，云里雾里。
核对了一下代码，核心入口为 findMaster，选择主节点成功返回对应 Master，否
则返回 null。选举流程大致描述如下：
第一步：确认候选主节点数达标，elasticsearch.yml 设置的值
discovery.zen.minimum_master_nodes；
第 86 页 共 485 页
第二步：比较：先判定是否具备 master 资格，具备候选主节点资格的优先返回；
若两节点都为候选主节点，则 id 小的值会主节点。注意这里的 id 为 string 类型。
题外话：获取节点 id 的方法。
1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name
2ip port heapPercent heapMax id name
5、详细描述一下 Elasticsearch 索引文档的过程
面试官：想了解 ES 的底层原理，不再只关注业务层面了。
解答：
这里的索引文档应该理解为文档写入 ES，创建索引的过程。
文档写入包含：单文档写入和批量 bulk 写入，这里只解释一下：单文档写入流程。
记住官方文档中的这个图。
第一步：客户写集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，
请求的节点扮演路由节点的角色。）
第 87 页 共 485 页
第二步：节点 1 接受到请求后，使用文档_id 来确定文档属于分片 0。请求会被转
到另外的节点，假定节点 3。因此分片 0 的主分片分配到节点 3 上。
第三步：节点 3 在主分片上执行写操作，如果成功，则将请求并行转发到节点 1
和节点 2 的副本分片上，等待结果返回。所有的副本分片都报告成功，节点 3 将
向协调节点（节点 1）报告成功，节点 1 向请求客户端报告写入成功。
如果面试官再问：第二步中的文档获取分片的过程？
回答：借助路由算法获取，路由算法就是根据路由和文档 id 计算目标的分片 id 的
过程。
1shard = hash(_routing) % (num_of_primary_shards)
6、详细描述一下 Elasticsearch 搜索的过程？
面试官：想了解 ES 搜索的底层原理，不再只关注业务层面了。
解答：
搜索拆解为“query then fetch” 两个阶段。
query 阶段的目的：定位到位置，但不取。
步骤拆解如下：
1、假设一个索引数据有 5 主+1 副本 共 10 分片，一次请求会命中（主或者副本
分片中）的一个。
2、每个分片在本地进行查询，结果返回到本地有序的优先队列中。
3、第 2）步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。
fetch 阶段的目的：取数据。
路由节点获取所有文档，返回给客户端。
第 88 页 共 485 页
7、Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法
面试官：想了解对 ES 集群的运维能力。
解答：
1、关闭缓存 swap;
2、堆内存设置为：Min（节点内存/2, 32GB）;
3、设置最大文件句柄数；
4、线程池+队列大小根据业务需要做调整；
5、磁盘存储 raid 方式——存储有条件使用 RAID10，增加单节点性能以及避免单
节点存储故障。
8、lucence 内部结构是什么？
面试官：想了解你的知识面的广度和深度。
解答：
第 89 页 共 485 页
Lucene 是有索引和搜索的两个过程，包含索引创建，索引，搜索三个要点。可以
基于这个脉络展开一些。
最近面试一些公司，被问到的关于 Elasticsearch 和搜索引擎相关的问题，以及自
己总结的回答。
9、Elasticsearch 是如何实现 Master 选举的？
1、Elasticsearch 的选主是 ZenDiscovery 模块负责的，主要包含 Ping（节点之
间通过这个 RPC 来发现彼此）和 Unicast（单播模块包含一个主机列表以控制哪
些节点需要 ping 通）这两部分；
第 90 页 共 485 页
2、对所有可以成为 master 的节点（node.master: true）根据 nodeId 字典排
序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第 0 位）
节点，暂且认为它是 master 节点。
3、如果对某个节点的投票数达到一定的值（可以成为 master 节点数 n/2+1）并
且该节点自己也选举自己，那这个节点就是 master。否则重新选举一直到满足上
述条件。
4、补充：master 节点的职责主要包括集群、节点和索引的管理，不负责文档级
别的管理；data 节点可以关闭 http 功能*。
10、Elasticsearch 中的节点（比如共 20 个），其中的 10 个
选了一个 master，另外 10 个选了另一个 master，怎么办？
1、当集群 master 候选数量不小于 3 个时，可以通过设置最少投票通过数量
（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解
决脑裂问题；
2、当候选数量为两个时，只能修改为唯一的一个 master 候选，其他作为 data
节点，避免脑裂问题。
11、客户端在和集群连接时，如何选择特定的节点执行请求的？
1、TransportClient 利用 transport 模块远程连接一个 elasticsearch 集群。它并
不加入到集群中，只是简单的获得一个或者多个初始化的 transport 地址，并以 轮
询 的方式与这些地址进行通信。
12、详细描述一下 Elasticsearch 索引文档的过程。
第 91 页 共 485 页
协调节点默认使用文档 ID 参与计算（也支持通过 routing），以便为路由提供合
适的分片。
shard = hash(document_id) % (num_of_primary_shards)
1、当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 Memory
Buffer，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache，这个从 Momery
Buffer 到 Filesystem Cache 的过程就叫做 refresh；
2、当然在某些情况下，存在 Momery Buffer 和 Filesystem Cache 的数据可能会
丢失，ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请
求后，同时也会写入到 translog 中，当 Filesystem cache 中的数据写入到磁盘中
时，才会清除掉，这个过程叫做 flush；
3、在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync
将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一
个新的 translog。
4、flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认
为 512M）时；
第 92 页 共 485 页
补充：关于 Lucene 的 Segement：
1、Lucene 索引是由多个段组成，段本身是一个功能齐全的倒排索引。
2、段是不可变的，允许 Lucene 将新的文档增量地添加到索引中，而不用从头重
建索引。
3、对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗
CPU 的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。
4、为了解决这个问题，Elasticsearch 会合并小段到一个较大的段，提交新的合并
段到磁盘，并删除那些旧的小段。
13、详细描述一下 Elasticsearch 更新和删除文档的过程。
1、删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不
能被删除或者改动以展示其变更；
2、磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真
的被删除，而是在.del 文件中被标记为删除。该文档依然能匹配查询，但是会在
结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入
新段。
3、在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号，当执行更新
时，旧版本的文档在.del 文件中被标记为删除，新版本的文档被索引到一个新段。
旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
14、详细描述一下 Elasticsearch 搜索的过程。
第 93 页 共 485 页
1、搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
2、在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分
片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的
优先队列。
PS：在搜索的时候是会查询 Filesystem Cache 的，但是有部分数据还在 Memory
Buffer，所以搜索是近实时的。
3、每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并
这些值到自己的优先队列中来产生一个全局排序后的结果列表。
4、接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片
提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回
文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
5、补充：Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分
片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch 增
加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更准确，
但是性能会变差。*
第 94 页 共 485 页
15、在 Elasticsearch 中，是怎么根据一个词找到对应的倒排索
引的？
SEE：
? Lucene 的索引文件格式(1)
? Lucene 的索引文件格式(2)
16、Elasticsearch 在部署时，对 Linux 的设置有哪些优化方
法？
1、64 GB 内存的机器是非常理想的， 但是 32 GB 和 16 GB 机器也是很常见的。
少于 8 GB 会适得其反。
2、如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多
个内核提供的额外并发远胜过稍微快一点点的时钟频率。
3、如果你负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点，查
询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。
4、即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群
跨越大的地理距离。
5、请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。 在
Elasticsearch 的几个地方，使用 Java 的本地序列化。
第 95 页 共 485 页
6、通过设置 gateway.recover_after_nodes、gateway.expected_nodes、
gateway.recover_after_time 可以在集群重启的时候避免过多的分片交换，这可
能会让数据恢复从数个小时缩短为几秒钟。
7、Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只
有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。
8、不要随意修改垃圾回收器（CMS）和各个线程池的大小。
9、把你的内存的（少于）一半给 Lucene（但不要超过 32 GB！），通过
ES_HEAP_SIZE 环境变量设置。
10、内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个
100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起
来。 不难看出 swapping 对于性能是多么可怕。
11、Lucene 使用了大量 的文件。同时，Elasticsearch 在节点和 HTTP 客户端
之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。你
应该增加你的文件描述符，设置一个很大的值，如 64,000。
补充：索引阶段性能提升方法
1、使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。
2、存储：使用 SSD
3、段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设
置。如果你用的是 SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，
完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加
第 96 页 共 485 页
index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的
值，比如 1 GB，这可以在一次清空触发的时候在事务日志里积累出更大的段。
4、如果你的搜索结果不需要近实时的准确度，考虑把每个索引的
index.refresh_interval 改到 30s。
5、如果你在做大批量导入，考虑通过设置 index.number_of_replicas: 0 关闭副
本。
17、对于 GC 方面，在使用 Elasticsearch 时要注意什么？
1、SEE：https://elasticsearch.cn/article/32
2、倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segment
memory 增长趋势。
3、各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要
设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓
存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache
等“自欺欺人”的方式来释放内存。
4、避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用
scan & scroll api 来实现。
5、cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集
群通过 tribe node 连接。
6、想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做
持续的监控。
第 97 页 共 485 页
18、Elasticsearch 对于大数据量（上亿量级）的聚合如何实现？
Elasticsearch 提供的首个近似聚合是 cardinality 度量。它提供一个字段的基数，
即该字段的 distinct 或者 unique 值的数目。它是基于 HLL 算法的。HLL 会先对
我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到
基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；
小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内
存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。
19、在并发情况下，Elasticsearch 如果保证读写一致？
1、可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用
层来处理具体的冲突；
2、另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只
有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络
等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点
上重建。
3、对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副
本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜
索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。
20、如何监控 Elasticsearch 集群状态？
Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你
的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。
第 98 页 共 485 页
21、介绍下你们电商搜索的整体技术架构。
22、介绍一下你们的个性化搜索方案？
SEE 基于 word2vec 和 Elasticsearch 实现个性化搜索
23、是否了解字典树？
常用字典数据结构如下所示：
第 99 页 共 485 页
Trie 的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以
达到提高效率的目的。它有 3 个基本性质：
1、根节点不包含字符，除根节点外每一个节点都只包含一个字符。
2、从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。
3、每个节点的所有子节点包含的字符都不相同。
第 100 页 共 485 页
1、可以看到，trie 树每一层的节点数是 26^i 级别的。所以为了节省空间，我们
还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单
词长度。
2、实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿
子右兄弟表示法记录这棵树；
3、对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太
大的空间，而且查询速度上可以保留哈希的复杂度 O(1)。
24、拼写纠错是如何实现的？
1、拼写纠错是基于编辑距离来实现；编辑距离是一种标准的方法，它用来表示经
过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数；
2、编辑距离的计算过程：比如要计算 batyu 和 beauty 的编辑距离，先创建一个
7×8 的表（batyu 长度为 5，coffee 长度为 6，各加 2），接着，在如下位置填入
黑色数字。其他格的计算过程是取以下三个值的最小值：
如果最上方的字符等于最左方的字符，则为左上方的数字。否则为左上方的数字
+1。（对于 3,3 来说为 0）
左方数字+1（对于 3,3 格来说为 2）
上方数字+1（对于 3,3 格来说为 2）
最终取右下角的值即为编辑距离的值 3。
第 101 页 共 485 页
对于拼写纠错，我们考虑构造一个度量空间（Metric Space），该空间内任何关
系满足以下三条基本条件：
d(x,y) = 0 -- 假如 x 与 y 的距离为 0，则 x=y
d(x,y) = d(y,x) -- x 到 y 的距离等同于 y 到 x 的距离
d(x,y) + d(y,z) >= d(x,z) -- 三角不等式
1、根据三角不等式，则满足与 query 距离在 n 范围内的另一个字符转 B，其与 A
的距离最大为 d+n，最小为 d-n。
2、BK 树的构造就过程如下：每个节点有任意个子节点，每条边有个值表示编辑
距离。所有子节点到父节点的边上标注 n 表示编辑距离恰好为 n。比如，我们有棵
第 102 页 共 485 页
树父节点是”book”和两个子节点”cake”和”books”，”book”到”books”
的边标号 1，”book”到”cake”的边上标号 4。从字典里构造好树后，无论何
时你想插入新单词时，计算该单词与根节点的编辑距离，并且查找数值为
d(neweord, root)的边。递归得与各子节点进行比较，直到没有子节点，你就可
以创建新的子节点并将新单词保存在那。比如，插入”boo”到刚才上述例子的树
中，我们先检查根节点，查找 d(“book”, “boo”) = 1 的边，然后检查标号为
1 的边的子节点，得到单词”books”。我们再计算距离 d(“books”, “boo”)=2，
则将新单词插在”books”之后，边标号为 2。
3、查询相似词如下：计算单词与根节点的编辑距离 d，然后递归查找每个子节点
标号为 d-n 到 d+n（包含）的边。假如被检查的节点与搜索单词的距离 d 小于 n，
则返回该节点并继续查询。比如输入 cape 且最大容忍距离为 1，则先计算和根的
编辑距离 d(“book”, “cape”)=4，然后接着找和根节点之间编辑距离为 3 到
5 的，这个就找到了 cake 这个节点，计算 d(“cake”, “cape”)=1，满足条件
所以返回 cake，然后再找和 cake 节点编辑距离是 0 到 2 的，分别找到 cape 和
cart 节点，这样就得到 cape 这个满足条件的结果。
Memcached 面试题
1、Memcached 是什么，有什么作用？
第 103 页 共 485 页
Memcached 是一个开源的，高性能的内存绶存软件，从名称上看 Mem 就是内存
的意思，而 Cache 就是缓存的意思。Memcached 的作用：通过在事先规划好的
内存空间中临时绶存数据库中的各类数据，以达到减少业务对数据库的直接高并
发访问，从而达到提升数据库的访问性能，加速网站集群动态应用服务的能力。
memcached 服务在企业集群架构中有哪些应用场景？
一、作为数据库的前端缓存应用
a、完整缓存（易），静态缓存
例如：商品分类（京东），以及商品信息，可事先放在内存里，然后再对外提供
数据访问，这种先放到内存，我们称之为预热，（先把数据存缓存中），用户访
问时可以只读取 memcached 缓存，不读取数据库了。
b、执点缓存（难）
需要前端 web 程序配合，只缓存热点的数据，即缓存经常被访问的数据。
先预热数据库里的基础数据，然后在动态更新，选读取缓存，如果缓存里没有对
应的数据，程序再去读取数据库，然后程序把读取的新数据放入缓存存储。
特殊说明 ：
? 如果碰到电商秒杀等高并发的业务，一定要事先预热，或者其它思想实现，
例如：称杀只是获取资格，而不是瞬间秒杀到手商品。
那么什么是获取资格？_
? 就是在数据库中，把 0 标成 1.就有资格啦。再慢慢的去领取商品订单。
因为秒杀过程太长会占用服务器资源。
? 如果数据更新，同时触发缓存更新，防止给用户过期数据。
? 对于持久化缓存存储系统，例如：redis，可以替代一部分数据库的存储，
一些简单的数据业务，投票，统计，好友关注，商品分类等。nosql= not only
sql
第 104 页 共 485 页
二、作业集群的 session 会话共享存储。
? Memcached 服务在不同企业业务应用场景中的工作流程
? 当 web 程序需要访问后端数据库获取数据时会优先访问 Memcached 内
存缓存，如果缓存中有数据就直接获取返回前端服务及用户，如果没有数据（没
有命中），在由程序请求后端的数据库服务器，获取到对应的数据后，除了返回
给前端服务及用户数据外，还会把数据放到 Memcached 内存中进行缓存，等
待下次请求被访问，Memcache 内存始终是数据库的挡箭牌，从而大大的减轻
数据库的访问压力，提高整个网站架构的响应速度，提升了用户体验。
? 当程序更新，修改或删除数据库中已有的数据时，会同时发送请求通知
Memcached 已经缓存的同一个 ID 内容的旧数据失效，从而保证 Memcache
中数据和数据库中的数据一致。
? 如果在高并发场合，除了通知 Memcached 过程的缓存失效外，还会通
过相关机制，使得在用户访问新数据前，通过程序预先把更新过的数据推送到
memcache 中缓存起来，这样可以减少数据库的访问压力，提升 Memcached
中缓存命中率。
? 数据库插件可以再写入更新数据库后，自动抛给 MC 缓存起来，自身不
Cache.
2、Memcached 服务分布式集群如何实现？
特殊说明：Memcached 集群和 web 服务集群是不一样的，所有 Memcached 的
数据总和才是数据库的数据。每台 Memcached 都是部分数据。
（一台 memcached 的数据，就是一部分 mysql 数据库的数据）
a、程序端实现
程序加载所有 mc 的 ip 列表，通过对 key 做 hash (一致性哈希算法)
第 105 页 共 485 页
例如：web1 (key)===>对应 A,B,C,D,E,F,G…..若干台服务器。（通过哈希算法实
现）
b、负载均衡器
通过对 key 做 hash (一致性哈希算法)
一致哈希算法的目的是不但保证每个对象只请求一个对应的服务器，而且当节点
宕机，缓存服务器的更新重新分配比例降到最低。
3、Memcached 服务特点及工作原理是什么？
a、完全基于内存缓存的
b、节点之间相互独立
c、C/S 模式架构，C 语言编写，总共 2000 行代码。
d、异步Ｉ/O 模型，使用 libevent 作为事件通知机制。
e、被缓存的数据以 key/value 键值对形式存在的。
f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会
丢失。
g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用 LRU 算法
删除过期的缓存数据。
h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不
会监控过期，而是在访问的时候查看 key 的时间戳,判断是否过期。
j、memcache 会对设定的内存进行分块，再把块分组，然后再提供服务。
4、简述 Memcached 内存管理机制原理？
早期的 Memcached 内存管理方式是通过 malloc 的分配的内存，使用完后通过
free 来回收内存，这种方式容易产生内存碎片，并降低操作系统对内存的管理效
率。加重操作系统内存管理器的负担，最坏的情况下，会导致操作系统比
第 106 页 共 485 页
memcached 进程本身还慢，为了解决这个问题，Slab Allocation 内存分配机制
就延生了。
现在 Memcached 利用 Slab Allocation 机制来分配和管理内存。
Slab
Allocation 机制原理是按照预先规定的大小，将分配给 memcached 的内存分割
成特定长度的内存块（chunk)，再把尺寸相同的内存块，分成组
（chunks slab class),这些内存块不会释放，可以重复利用。
而且，slab allocator 还有重复使用已分配的内存的目的。 也就是说，分配到的
内存不会释放，而是重复利用。
Slab Allocation 的主要术语
Page
分配给 Slab 的内存空间，默认是 1MB。分配给 Slab 之后根据 slab 的大小切分成
chunk。
Chunk
用于缓存记录的内存空间。
SlabClass
特定大小的 chunk 的组。
集群架构方面的问题
第 107 页 共 485 页
5、memcached 是怎么工作的？
Memcached 的神奇来自两阶段哈希（two-stage hash）。Memcached 就像一
个巨大的、存储了很多对的哈希表。通过 key，可以存储或查询任意
的数据。
客户端可以把数据存储在多台 memcached 上。当查询数据时，客户端首先参考
节点列表计算出 key 的哈希值（阶段一哈希），进而选中一个节点；客户端将请
求发送给选中的节点，然后 memcached 节点通过一个内部的哈希算法（阶段二
哈希），查找真正的数据（item）。
6、memcached 最大的优势是什么？
Memcached 最大的好处就是它带来了极佳的水平可扩展性，特别是在一个巨大的
系统中。由于客户端自己做了一次哈希，那么我们很容易增加大量 memcached
到集群中。memcached 之间没有相互通信，因此不会增加 memcached 的负载；
没有多播协议，不会网络通信量爆炸（implode）。memcached 的集群很好用。
内存不够了？增加几台 memcached 吧；CPU 不够用了？再增加几台吧；有多余
的内存？在增加几台吧，不要浪费了。
基于 memcached 的基本原则，可以相当轻松地构建出不同类型的缓存架构。除
了这篇 FAQ，在其他地方很容易找到详细资料的。
7、memcached 和 MySQL 的 query
cache 相比，有什么优缺点？
第 108 页 共 485 页
把 memcached 引入应用中，还是需要不少工作量的。MySQL 有个使用方便的
query cache，可以自动地缓存 SQL 查询的结果，被缓存的 SQL 查询可以被反复
地快速执行。Memcached 与之相比，怎么样呢？MySQL 的 query cache 是集中
式的，连接到该 query cache 的 MySQL 服务器都会受益。
? 当您修改表时，MySQL 的 query cache 会立刻被刷新（flush）。存储
一个 memcached item 只需要很少的时间，但是当写操作很频繁时，MySQL
的 query cache 会经常让所有缓存数据都失效。
? 在多核 CPU 上，MySQL 的 query cache 会遇到扩展问题（scalability
issues）。在多核 CPU 上，query cache 会增加一个全局锁（global lock）, 由
于需要刷新更多的缓存数据，速度会变得更慢。
? 在 MySQL 的 query cache 中，我们是不能存储任意的数据的（只能是
SQL 查询结果）。而利用 memcached，我们可以搭建出各种高效的缓存。比
如，可以执行多个独立的查询，构建出一个用户对象（user object），然后将
用户对象缓存到 memcached 中。而 query cache 是 SQL 语句级别的，不可能
做到这一点。在小的网站中，query cache 会有所帮助，但随着网站规模的增加，
query cache 的弊将大于利。
? query cache能够利用的内存容量受到MySQL服务器空闲内存空间的限
制。给数据库服务器增加更多的内存来缓存数据，固然是很好的。但是，有了
memcached，只要您有空闲的内存，都可以用来增加 memcached 集群的规
模，然后您就可以缓存更多的数据。
8、memcached 和服务器的 local cache（比如 PHP 的 APC、
mmap 文件等）相比，有什么优缺点？
首先，local cache 有许多与上面(query cache)相同的问题。local cache 能够利
用的内存容量受到（单台）服务器空闲内存空间的限制。不过，local
第 109 页 共 485 页
cache 有一点比 memcached 和 query cache 都要好，那就是它不但可以存储任
意的数据，而且没有网络存取的延迟。
? local cache 的数据查询更快。考虑把 highly common 的数据放在 local
cache 中吧。如果每个页面都需要加载一些数量较少的数据，考虑把它们放在
local
cached 吧。
? local cache 缺少集体失效（group
invalidation）的特性。在 memcached 集群中，删除或更新一个 key 会让所有
的观察者觉察到。但是在local cache中, 我们只能通知所有的服务器刷新cache
（很慢，不具扩展性），或者仅仅依赖缓存超时失效机制。
? local cache 面临着严重的内存限制，这一点上面已经提到。
9、memcached 的 cache 机制是怎样的？
Memcached 主要的 cache 机制是 LRU（最近最少用）算法+超时失效。当您存
数据到 memcached 中，可以指定该数据在缓存中可以呆多久 Which is forever,
or some time in the future。如果 memcached 的内存不够用了，过期的 slabs
会优先被替换，接着就轮到最老的未被使用的 slabs。
10、memcached 如何实现冗余机制？
不实现！我们对这个问题感到很惊讶。Memcached 应该是应用的缓存层。它的设
计本身就不带有任何冗余机制。如果一个 memcached 节点失去了所有数据，您
应该可以从数据源（比如数据库）再次获取到数据。您应该特别注意，您的应用
应该可以容忍节点的失效。不要写一些糟糕的查询代码，寄希望于 memcached
第 110 页 共 485 页
来保证一切！如果您担心节点失效会大大加重数据库的负担，那么您可以采取一
些办法。比如您可以增加更多的节点（来减少丢失一个节点的影响），热备节点
（在其他节点 down 了的时候接管 IP），等等。
11、memcached 如何处理容错的？
不处理！ 在 memcached 节点失效的情况下，集群没有必要做任何容错处理。如
果发生了节点失效，应对的措施完全取决于用户。节点失效时，下面列出几种方
案供您选择：
? 忽略它！ 在失效节点被恢复或替换之前，还有很多其他节点可以应对节
点失效带来的影响。
? 把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下
（余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！
因为哈希参照的节点列表变化了，大部分 key 会因为哈希值的改变而被映射到
（与原来）不同的节点上。
? 启动热备节点，接管失效节点所占用的 IP。这样可以防止哈希紊乱
（hashing chaos）。
? 如果希望添加和移除节点，而不影响原先的哈希结果，可以使用一致性哈
希算法（consistent hashing）。您可以百度一下一致性哈希算法。支持一致性
哈希的客户端已经很成熟，而且被广泛使用。去尝试一下吧！
? 两次哈希（reshing）。当客户端存取数据时，如果发现一个节点 down
了，就再做一次哈希（哈希算法与前一次不同），重新选择另一个节点（需要注
意的时，客户端并没有把 down 的节点从节点列表中移除，下次还是有可能先
哈希到它）。如果某个节点时好时坏，两次哈希的方法就有风险了，好的节点和
坏的节点上都可能存在脏数据（stale data）。
12、如何将 memcached 中 item 批量导入导出？
第 111 页 共 485 页
您不应该这样做！Memcached 是一个非阻塞的服务器。任何可能导致
memcached 暂停或瞬时拒绝服务的操作都应该值得深思熟虑。向 memcached
中批量导入数据往往不是您真正想要的！想象看，如果缓存数据在导出导入之间
发生了变化，您就需要处理脏数据了；
13、如果缓存数据在导出导入之间过期了，您又怎么处理这些
数据呢？
因此，批量导出导入数据并不像您想象中的那么有用。不过在一个场景倒是很有
用。如果您有大量的从不变化的数据，并且希望缓存很快热（warm）起来，批量
导入缓存数据是很有帮助的。虽然这个场景并不典型，但却经常发生，因此我们
会考虑在将来实现批量导出导入的功能。
如果一个 memcached 节点 down 了让您很痛苦，那么您还会陷入其他很多麻烦。
您的系统太脆弱了。您需要做一些优化工作。比如处理”惊群”问题（比如
memcached 节点都失效了，反复的查询让您的数据库不堪重负…这个问题在 FAQ
的其他提到过），或者优化不好的查询。记住，Memcached 并不是您逃避优化
查询的借口。
14、memcached 是如何做身份验证的？
没有身份认证机制！memcached 是运行在应用下层的软件（身份验证应该是应用
上层的职责）。memcached 的客户端和服务器端之所以是轻量级的，部分原因就
是完全没有实现身份验证机制。这样，memcached 可以很快地创建新连接，服务
器端也无需任何配置。
第 112 页 共 485 页
如果您希望限制访问，您可以使用防火墙，或者让 memcached 监听 unix domain
socket。
15、memcached 的多线程是什么？如何使用它们？
线程就是定律（threads rule）！在 Steven Grimm 和 Facebook 的努力下，
memcached 1.2 及更高版本拥有了多线程模式。多线程模式允许 memcached 能
够充分利用多个 CPU，并在 CPU 之间共享所有的缓存数据。memcached 使用一
种简单的锁机制来保证数据更新操作的互斥。相比在同一个物理机器上运行多个
memcached 实例，这种方式能够更有效地处理 multi gets。
如果您的系统负载并不重，也许您不需要启用多线程工作模式。如果您在运行一
个拥有大规模硬件的、庞大的网站，您将会看到多线程的好处。
简单地总结一下：命令解析（memcached 在这里花了大部分时间）可以运行在多
线程模式下。memcached 内部对数据的操作是基于很多全局锁的（因此这部分工
作不是多线程的）。未来对多线程模式的改进，将移除大量的全局锁，提高
memcached 在负载极高的场景下的性能。
16、memcached 能接受的 key 的最大长度是多少？
key 的最大长度是 250 个字符。需要注意的是，250 是 memcached 服务器端内
部的限制，如果您使用的客户端支持”key 的前缀”或类似特性，那么 key（前缀
+原始 key）的最大长度是可以超过 250 个字符的。我们推荐使用使用较短的 key，
因为可以节省内存和带宽。
memcached 对 item 的过期时间有什么限制？
第 113 页 共 485 页
过期时间最大可以达到 30 天。memcached 把传入的过期时间（时间段）解释成
时间点后，一旦到了这个时间点，memcached 就把 item 置为失效状态。这是一
个简单但 obscure 的机制。
17、memcached 最大能存储多大的单个 item？
1MB。如果你的数据大于 1MB，可以考虑在客户端压缩或拆分到多个 key 中。
为什么单个 item 的大小被限制在 1M byte 之内？
啊…这是一个大家经常问的问题！
简单的回答：因为内存分配器的算法就是这样的。
详细的回答：Memcached 的内存存储引擎（引擎将来可插拔…），使用 slabs 来
管理内存。内存被分成大小不等的 slabs chunks（先分成大小相等的 slabs，然后
每个 slab 被分成大小相等 chunks，不同 slab 的 chunk 大小是不相等的）。chunk
的大小依次从一个最小数开始，按某个因子增长，直到达到最大的可能值。
18、memcached 能够更有效地使用内存吗？
Memcache 客户端仅根据哈希算法来决定将某个 key 存储在哪个节点上，而不考
虑节点的内存大小。因此，您可以在不同的节点上使用大小不等的缓存。但是一
般都是这样做的：拥有较多内存的节点上可以运行多个 memcached 实例，每个
实例使用的内存跟其他节点上的实例相同。
19、什么是二进制协议，我该关注吗？
第 114 页 共 485 页
关于二进制最好的信息当然是二进制协议规范：
二进制协议尝试为端提供一个更有效的、可靠的协议，减少客户端/服务器端因处
理协议而产生的 CPU 时间。
根据 Facebook 的测试，解析 ASCII 协议是 memcached 中消耗 CPU 时间最多的
环节。所以，我们为什么不改进 ASCII 协议呢？
20、memcached 的内存分配器是如何工作的？为什么不适用
malloc/free！？为何要使用 slabs？
实际上，这是一个编译时选项。默认会使用内部的 slab 分配器。您确实确实应该
使用内建的 slab 分配器。最早的时候，memcached 只使用 malloc/free 来管理
内存。然而，这种方式不能与 OS 的内存管理以前很好地工作。反复地 malloc/free
造成了内存碎片，OS 最终花费大量的时间去查找连续的内存块来满足 malloc 的
请求，而不是运行 memcached 进程。如果您不同意，当然可以使用 malloc！只
是不要在邮件列表中抱怨啊
slab 分配器就是为了解决这个问题而生的。内存被分配并划分成 chunks，一直被
重复使用。因为内存被划分成大小不等的 slabs，如果 item 的大小与被选择存放
它的 slab 不是很合适的话，就会浪费一些内存。Steven Grimm 正在这方面已经
做出了有效的改进。
21、memcached 是原子的吗？
第 115 页 共 485 页
所有的被发送到 memcached 的单个命令是完全原子的。如果您针对同一份数据
同时发送了一个 set 命令和一个 get 命令，它们不会影响对方。它们将被串行化、
先后执行。即使在多线程模式，所有的命令都是原子的，除非程序有 bug:)
命令序列不是原子的。如果您通过 get 命令获取了一个 item，修改了它，然后想
把它 set 回 memcached，我们不保证这个 item 没有被其他进程（process，未
必是操作系统中的进程）操作过。在并发的情况下，您也可能覆写了一个被其他
进程 set 的 item。
memcached 1.2.5 以及更高版本，提供了 gets 和 cas 命令，它们可以解决上面
的问题。如果您使用 gets 命令查询某个 key 的 item，memcached 会给您返回
该 item 当前值的唯一标识。如果您覆写了这个 item 并想把它写回到 memcached
中，您可以通过 cas 命令把那个唯一标识一起发送给 memcached。如果该 item
存放在 memcached 中的唯一标识与您提供的一致，您的写操作将会成功。如果
另一个进程在这期间也修改了这个 item，那么该 item 存放在 memcached 中的
唯一标识将会改变，您的写操作就会失败
22、如何实现集群中的 session 共享存储？
Session 是运行在一台服务器上的，所有的访问都会到达我们的唯一服务器上，这
样我们可以根据客户端传来的 sessionID，来获取 session，或在对应 Session 不
存在的情况下（session 生命周期到了/用户第一次登录），创建一个新的 Session；
但是，如果我们在集群环境下，假设我们有两台服务器 A，B，用户的请求会由
Nginx 服务器进行转发（别的方案也是同理），用户登录时，Nginx 将请求转发
至服务器 A 上，A 创建了新的 session，并将 SessionID 返回给客户端，用户在浏
览其他页面时，客户端验证登录状态，Nginx 将请求转发至服务器 B，由于 B 上
并没有对应客户端发来 sessionId 的 session，所以会重新创建一个新的 session，
并且再将这个新的 sessionID 返回给客户端，这样，我们可以想象一下，用户每
一次操作都有 1/2 的概率进行再次的登录，这样不仅对用户体验特别差，还会让
服务器上的 session 激增，加大服务器的运行压力。
第 116 页 共 485 页
为了解决集群环境下的 seesion 共享问题，共有 4 种解决方案：
1.粘性 session
粘性 session 是指 Ngnix 每次都将同一用户的所有请求转发至同一台服务器上，
即将用户与服务器绑定。
2.服务器 session 复制
即每次 session 发生变化时，创建或者修改，就广播给所有集群中的服务器，使
所有的服务器上的 session 相同。
3.session 共享
缓存 session，使用 redis， memcached。
4.session 持久化
将 session 存储至数据库中，像操作数据一样才做 session。
23、memcached 与 redis 的区别？
1、Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash
等数据结构的存储。而 memcache 只支持简单数据类型，需要客户端自己处理复
杂对象
2、Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可
以再次加载进行使用（PS：持久化在 rdb、aof）。
第 117 页 共 485 页
3、由于 Memcache 没有持久化机制，因此宕机所有缓存数据失效。Redis 配置
为持久化，宕机重启后，将自动加载宕机时刻的数据到缓存系统中。具有更好的
灾备机制。
4、Memcache 可以使用 Magent 在客户端进行一致性 hash 做分布式。Redis 支
持在服务器端做分布式（PS:Twemproxy/Codis/Redis-cluster 多种分布式实现方
式）
5、Memcached 的简单限制就是键（key）和 Value 的限制。最大键长为 250 个
字符。可以接受的储存数据不能超过 1MB（可修改配置文件变大），因为这是典
型 slab 的最大值，不适合虚拟机使用。而 Redis 的 Key 长度支持到 512k。
6、Redis 使用的是单线程模型，保证了数据按顺序提交。Memcache 需要使用
cas 保证数据一致性。CAS（Check and Set）是一个确保并发一致性的机制，属
于“乐观锁”范畴；原理很简单：拿版本号，操作，对比版本号，如果一致就操
作，不一致就放弃任何操作
cpu 利用。由于 Redis 只使用单核，而 Memcached 可以使用多核，所以平均每
一个核上 Redis 在存储小数据时比 Memcached 性能更 高。而在 100k 以上的数
据中，Memcached 性能要高于 Redis 。
7、memcache 内存管理：使用 Slab Allocation。原理相当简单，预先分配一系
列大小固定的组，然后根据数据大小选择最合适的块存储。避免了内存碎片。（缺
点：不能变长，浪费了一定空间）memcached 默认情况下下一个 slab 的最大值
为前一个的 1.25 倍。
8、redis 内存管理： Redis 通过定义一个数组来记录所有的内存分配情况， Redis
采用的是包装的 malloc/free，相较于 Memcached 的内存 管理方法来说，要简
单很多。由于 malloc 首先以链表的方式搜索已管理的内存中可用的空间分配，导
致内存碎片比较多
第 118 页 共 485 页
Redis 面试题
1、什么是 Redis?
Redis 是完全开源免费的，遵守 BSD 协议，是一个高性能的 key-value 数据库。
Redis 与其他 key - value 缓存产品有以下三个特点：
Redis 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再
次加载进行使用。
Redis 不仅仅支持简单的 key-value 类型的数据，同时还提供 list，set，zset，
hash 等数据结构的存储。
Redis 支持数据的备份，即 master-slave 模式的数据备份。
Redis 优势
性能极高 – Redis 能读的速度是 110000 次/s,写的速度是 81000 次/s 。
丰富的数据类型 – Redis 支持二进制案例的 Strings, Lists, Hashes, Sets 及
Ordered Sets 数据类型操作。
原子 – Redis 的所有操作都是原子性的，意思就是要么成功执行要么失败完全不
执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过 MULTI 和 EXEC
指令包起来。