运维面试必问的中间件高频面试题

1. redis是单线程还是多线程？

这个问题已经被问过很多次了，从redis4.0开始引入多线程，redis 6.0 中，多线程主要用于网络 I/O 阶段，也就是接收命令和写回结果阶段，而在执行命令阶段，还是由单线程串行执行。由于执行时还是串行，因此无需考虑并发安全问题。
redis 中的多线程组不会同时存在“读”和“写”，这个多线程组只会同时“读”或者同时“写”
在 redis 6.0 之前，redis 的核心操作是单线程的。

因为 redis 是完全基于内存操作的，通常情况下CPU不会是redis的瓶颈，redis 的瓶颈最有可能是机器内存的大小或者网络带宽。

既然CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了，因为如果使用多线程的话会更复杂，同时需要引入上下文切换、加锁等等，会带来额外的性能消耗。

而随着近些年互联网的不断发展，大家对于缓存的性能要求也越来越高了，因此 redis 也开始在逐渐往多线程方向发展。

2. redis常用的版本是？

redis5.0，redis6.0

3. redis 的使用场景？

缓存、分布式锁、排行榜（zset）、计数（incrby）、消息队列（stream）、地理位置（geo）、访客统计（hyperloglog）

4. redis常见的数据结构

常见的5种：

String：字符串，最基础的数据类型。

List：列表。

Hash：哈希对象。

Set：集合。

Sorted Set：有序集合，Set 的基础上加了个分值。

高级的2 种：

HyperLogLog：通常用于基数统计。使用少量固定大小的内存，来统计集合中唯一元素的数量。统计结果不是精确值，而是一个带有0.81%标准差（standard error）的近似值。所以，HyperLogLog适用于一些对于统计结果精确度要求不是特别高的场景，例如网站的UV统计。
Stream：主要用于消息队列，类似于 kafka，可以认为是 pub/sub 的改进版。提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。

5. redis持久化你们怎么做的？

redis持久化主要有两种 ROD和AOF，当先现在还有混合的，从reids4.0后引入的

RDB实现原理：
RDB类似于快照，在某个时间点，将 Redis 在内存中的数据库状态（数据库的键值对等信息）保存到磁盘里面。RDB 持久化功能生成的 RDB 文件是经过压缩的二进制文件。

RDB的优点：

RDB文件是经过压缩的，占用空间很小，它保存了某个时间点的数据集，很适合做备份。 比如你可以在24小时内，每个小时备份一次RDB文件，并且每个月的每一天备份一个RDB文件。
RDB非常适合用来做灾备恢复，可以加密后传送到数据中心
RDB可以最大化redis的性能
从恢复速度来看，RDB明显要比AOF要快
但是RDB也有一定的缺点：
RDB在服务器故障的时候，容易造成数据损失。 我们通常设置每5分钟保存一次快照，这样数据丢失也只有5分钟的数据。
RDB保存时使用fork子进程数据的持久化，如果数据量大的话，会非常耗时，造成redis停止处理服务N毫秒。
AOF：
保存 Redis 服务器所执行的所有写操作命令来记录数据库状态，并在服务器启动时，通过重新执行这些命令来还原数据集。

AOF默认是关闭的，可以通过appendonley yes 开启

AOF 持久化功能的实现可以分为三个步骤：命令追加、文件写入、文件同步。

AOF的优点：
1）AOF 比 RDB可靠。你可以设置不同的 fsync 策略：no、everysec 和 always。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

2）AOF文件是一个纯追加的日志文件。即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等）， 我们也可以使用 redis-check-aof 工具也可以轻易地修复这种问题。

3）当 AOF文件太大时，Redis 会自动在后台进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写是绝对安全，因为重写是在一个新的文件上进行，同时 Redis 会继续往旧的文件追加数据。当新文件重写完毕，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上。

4） AOF 文件有序地保存了对数据库执行的所有写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。如果你不小心执行了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF 文件没有被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF缺点：
1） 对于相同的数据集，AOF的文件一般会比RDB大
2） AOF所使用的fsync策略，备份速度也会比RDB曼

如何使用：
如果想尽量保证数据安全性， 你应该同时使用 RDB 和 AOF 持久化功能，同时可以开启混合持久化。
如果想尽量保证数据安全性， 你应该同时使用 RDB 和 AOF 持久化功能，同时可以开启混合持久化。
如果你的数据是可以丢失的，则可以关闭持久化功能，在这种情况下，Redis 的性能是最高的。

6. 主从复制实现的原理

Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况，为分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步

7. redis哨兵模式原理

哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过 sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且哨兵会早主从模式的从节点中重新选出来一个新的master，并且将新的master信息通知给client端。

这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。Redis服务是通过配置文件启动的，比如上面的从节点设置了只读模式，它被选举成了master之后就是可读写的了，感觉很奇怪，后来看了下重新选举之后的各redis服务的配置文件，发现文件里面的内容会被哨兵修改。要想真的高可用，我们的哨兵也要集群模式。

 

8. memcache和redis的区别

1、 Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等。
2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
3、虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘
4、过期策略–memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10
5、分布式–设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从
6、存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）
7、灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复
8、Redis支持数据的备份，即master-slave模式的数据备份。

redis和memecache的不同在于[2]：
1、存储方式：
memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小
redis有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（笔者注：有快照和AOF日志两种持久化方式，在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做dump）。
2、数据支持类型：
redis在数据支持上要比memecache多的多。
3、使用底层模型不同：
新版本的redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4、运行环境不同：
redis目前官方只支持LINUX 上去行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统 环境上的优化，虽然后来微软有一个小组为其写了补丁。但是没有放到主干上

个人总结一下，有持久化需求或者对数据结构和处理有高级要求的应用，选择redis，其他简单的key/value存储，选择memcache。

9. redis有哪些架构模式？

 

存在问题： 内容容量有限，处理能力有限，无法高可用

Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。 只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从服务器的数据相同。

特点：

        1、master/slave 角色

        2、master/slave 数据相同

        3、降低 master 读压力在转交从库

问题：

        无法保证高可用

        没有解决 master 写的压力

 

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

特点：

        1、保证高可用

        2、监控各个节点

        3、自动故障迁移

缺点：

        主从模式，切换需要时间丢数据

        没有解决 master 写的压力

Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。

特点：

1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

2、支持失败节点自动删除

3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

缺点：

增加了新的 proxy，需要维护其高可用。

failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预

10. 缓存雪崩？

在前面学习我们都知道Redis不可能把所有的数据都缓存起来(内存昂贵且有限)，所以Redis需要对数据设置过期时间，并采用的是惰性删除+定期删除两种策略对过期键删除。Redis对过期键的策略+持久化

如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中

什么是缓存雪崩？
Redis挂掉了，请求全部走数据库。

对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。

缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！

解决方法：

解决方法：在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。

对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：

事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。

事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)

事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。

11. 缓存穿透

什么是缓存穿透
缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义
请求的数据在缓存大量不命中，导致请求走数据库。
缓存穿透如果发生了，也可能把我们的数据库搞垮，导致整个服务瘫痪！

如何解决缓存穿透
由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！

当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。

这种情况我们一般会将空对象设置一个较短的过期时间。

12. 缓存击穿

某一个热点key，在不停地扛着高并发，当这个热点key在失效的一瞬间，持续的高并发访问就击破缓存直接访问数据库，导致数据库宕机。

设置热点数据"永不过期" 加上互斥锁：上面的现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它 其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后将数据放到redis缓存起来。
后面的线程进来发现已经有缓存了，就直接走缓存

总结：
雪崩是大面积的key缓存失效；穿透是redis里不存在这个缓存key；击穿是redis某一个热点key突然失效，最终的受害者都是数据库。

13. redis为什么这么快

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

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

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

4、使用多路 I/O 复用模型，非阻塞 IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

14. memcache有哪些应用场景

作为数据库的前端缓存应用： 完整缓存，静态缓存。
比如 商品分类，商品信息

15. memcache 服务特点及工作原理

a. 完全基于内存缓存的
b、节点之间相互独立
c、C/S模式架构，C语言编写，总共2000行代码。
d、异步Ｉ/O 模型，使用libevent作为事件通知机制。
e、被缓存的数据以key/value键值对形式存在的。
f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会丢失。
g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用LRU算法删除过期的缓存数据。
h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不会监控过期，而是在访问的时候查看key的时间戳,判断是否过期。
j、memcache会对设定的内存进行分块，再把块分组，然后再提供服务

16. memcached是如何做身份验证的？

没有身份认证机制，如果你想限制访问，可以使用防火墙

17. mongoDB是什么？

MongoDB是一个文档数据库，提供好的性能，领先的非关系型数据库。采用BSON存储文档数据。
BSON（）是一种类json的一种二进制形式的存储格式，简称Binary JSON.
相对于json多了date类型和二进制数组。

18. mongodb的优势

面向文档的存储：以 JSON 格式的文档保存数据。
任何属性都可以建立索引。
复制以及高可扩展性。
自动分片。
丰富的查询功能。
快速的即时更新。

19. mongodb使用场景

大数据
内容管理系统
移动端Apps
数据管理

20. kafka 中的ISR，AR代表什么，ISR伸缩又代表什么

ISR:In-Sync Replicas 副本同步队列
AR:Assigned Replicas 所有副本
ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

21.kafka中的broker 是干什么的

broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

22. kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，

但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等

23. kafka follower如何与leader同步数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。

而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

24. kafka 为什么那么快

Cache Filesystem Cache PageCache缓存

顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。

Zero-copy 零拷技术减少拷贝次数

Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。

Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

25. Kafka中的消息是否会丢失和重复消费？

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1、消息发送

     Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：
1
0—表示不进行消息接收是否成功的确认；
1—表示当Leader接收成功时确认；
-1—表示Leader和Follower都接收成功时确认；
综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；

（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

2、消息消费

Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；

High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

解决办法：

    针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；

    针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。

26. 为什么Kafka不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型
Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

(1)数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。

(2)延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

27. 什么是消费者组?

消费者组是 Kafka 独有的概念，如果面试官问这 个，就说明他对此是有一定了解的。我先给出标准答案：
1、定义：即消费者组是 Kafka 提供的可扩展且具有容错性的消费者机制。
2、原理：在 Kafka 中，消费者组是一个由多个消费者实例 构成的组。多个实例共同订阅若干个主题，实现共同消费。同一个组下的每个实例都配置有 相同的组 ID，被分配不同的订阅分区。当某个实例挂掉的时候，其他实例会自动地承担起 它负责消费的分区。

此时，又有一个小技巧给到你:消费者组的题目，能够帮你在某种程度上掌控下面的面试方
向。

如果你擅长位移值原理，就不妨再提一下消费者组的位移提交机制;
如果你擅长 Kafka Broker，可以提一下消费者组与 Broker 之间的交互;
如果你擅长与消费者组完全不相关的 Producer，那么就可以这么说:“消费者组要消 费的数据完全来自于 Producer 端生产的消息，我对 Producer 还是比较熟悉的。”

28. Kafka 中的术语

代理（borker）: 一个kafka进程（kafka进程又被称为实例），被称为一个代理broker节点。

生产者（producer）

Producer将消息记录发送到Kafka集群指定的主题（Topic）中进行存储，同时生产者（Producer）也能通过自定义算法决定将消息记录发送到哪个分区（Partition）。
例如，通过获取消息记录主键（Key）的哈希值，然后使用该值对分区数取模运算，得到分区索引。

消费者Consumer
消费者（Consumer）从Kafka集群指定的主题（Topic）中读取消息记录。在读取主题数据时，需要设置消费组名（GroupId）。如果不设置，则Kafka消费者会默认生成一个消费组名称。

消费者组： Consumer Group
消费者程序在读取Kafka系统主题（Topic）中的数据时，通常会使用多个线程来执行。一个消费者组可以包含一个或多个消费者程序，使用多分区和多线程模式可以极大提高读取数据的效率。

一般而言，一个消费者对应一个线程

主题Topic
Kafka系统通过主题来区分不同业务类型的消息记录。例如，用户登录数据存储在主题A中，用户充值记录存储在主题B中，则如果应用程序只订阅了主题A，而没有订阅主题B，那该应用程序只能读取主题A中的数据
分区（Partition）
每一个主题（Topic）中可以有一个或者多个分区（Partition）。在Kafka系统的设计思想中，分区是基于物理层面上的，不同的分区对应着不同的数据文件。Kafka通过分区（Partition）来支持物理层面上的并发读写，以提高Kafka集群的吞吐量。
一个分区只对应一个代理节点（Broker），一个代理节点可以管理多个分区。

副本（replication）
在Kafka系统中，每个主题（Topic）在创建时会要求指定它的副本数，默认是1。通过副本（Replication）机制来保证Kafka分布式集群数据的高可用性
在创建主题时，主题的副本系数值应如下设置：（1）若集群数量大于等于3，则主题的副本系数值可以设置为3；（2）若集群数量小于3，则主题的副本系数值可以设置为小于等于集群数量值。例如，集群数为2，则副本系数可以设置为1或者2；集群数为1，则副本系数只能设置为1。

记录（Record）
被实际写入到Kafka集群并且可以被消费者应用程序读取的数据，被称为记录（Record）。每条记录包含一个键（Key）、值（Value）和时间戳（Timestamp）。

replica：
partition 的副本，保障 partition 的高可用。

leader：
replica 中的一个角色， producer 和 consumer 只跟 leader 交互。

follower：
replica 中的一个角色，从 leader 中复制数据。

controller：
kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。

zookeeper：
kafka 通过 zookeeper 来存储集群的 meta 信息。

 

生产者（Producer）负责写入消息数据。将审计日志、服务日志、数据库、移动App日志，以及其他类型的日志主动推送到Kafka集群进行存储。·

消费者（Consumer）负责读取消息数据。例如，通过Hadoop的应用接口、Spark的应用接口、Storm的应用接口、ElasticSearch的应用接口，以及其他自定义服务的应用接口，主动拉取Kafka集群中的消息数据。

29. kafka适用于哪些场景

日志收集
消息系统
用户轨迹（记录浏览器用户或者app用户产生的各种记录，点击和搜索浏览等）
记录运营监控数据
实现流处理

30. Kafka写入流程：

1.producer 先从 zookeeper 的 “/brokers/…/state” 节点找到该 partition 的 leader

producer 将消息发送给该 leader

leader 将消息写入本地 log

followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK

leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK