黑马头条知识点梳理以及面试题整理

黑马头条项目背景

一、项目介绍 1.1、项目背景 随着智能手机的普及，人们更加习惯于通过手机来看新闻。由于生活节奏的加快， 很多人只能利用碎片时间来获取信息，因此，对于移动资讯客户端的需求也越来越高。黑马头条项目正是在这样背景下开发出来。黑马头条项目采用当下火热的微服务+大数据技术架 构实现。本项目主要着手于获取最新最热新闻资讯，通过大数据分析用户喜好精确推送咨询新闻。

1.2、项目概述 黑马头条项目是对在线教育平台业务进行大数据统计分析的系统。碎片化、切换频繁、 社交化和个性化现如今成为人们阅读行为的标签。黑马头条对海量信息进行搜集，通过系统计算分类，分析用户的兴趣进行推送从而满足用户的需求。

1.3、需求说明 1.4、功能架构图

1.5、APP主要功能大纲 1、频道栏：用户可以通过此功能添加自己感兴趣的频道，在添加标签时，系统可依据用户喜好进行推荐； 2、文章列表：需要显示文章标题、文章图片、评论数等信息，且需要监控文章是否在APP端展现的行为；

3、搜索文章：联想用户想搜索的内容，并记录用户的历史搜索信息； 4、查看文章：用户点击文章进入查看文章页面，在此页面上可进行点赞、评论、不喜欢、分享等操作；除此之外还需要收集用户查看文章的时间，是否看我等行为信息； 5、注册登录：登录时，验证内容为手机号登录/注册，通过手机号验证码进行登录/注册，首次登录用户自动注册账号； 6、实名认证：用户可以进行身份证认证和实名认证，实名认证之后即可成为自媒体人，在平台上发布文章；

7、个人中心：用户可以在其个人中心查看收藏、关注的人、以及系统设置等功能。

1.6、自媒体端功能大纲 1、内容管理：自媒体用户管理文章页面，可以根据条件进行筛选，文章包含草稿、已发布、未通过、已撤回状态。用户可以对文章进行修改，上/下架操作、查看文章状态等操 作； 2、评论管理：管理文章评论页面，显示用户已发布的全部文章，可以查看文章总评论数和粉丝评论数，可以对文章进行关闭评论等操作； 3、素材管理：管理自媒体文章发布的图片，便于用户发布带有多张图片的文章图文数据：

4、自媒体人发布文章的数据：阅读数、评论数、收藏量、转发量，用户可以查看对应文章的阅读数据； 5、粉丝画像：内容包括：粉丝性别分布、粉丝年龄分布、粉丝终端分布、粉丝喜欢分类分布。

1.7、平台管理端功能大纲 1、用户管理：系统后台用来维护用户信息，可以对用户进行增删改查操作，对于违规用户可以进行冻结操作； 2、用户审核：管理员审核用户信息页面，用户审核分为身份审核和实名审核，身份审核是对用户的身份信息进行审核，包括但不限于工作信息、资质信息、经历信息等；实名认证是对用户实名身份进行认证；

3、内容管理：管理员查询现有文章，并对文章进行新增、删除、修改、置顶等操作； 4、内容审核：管理员审核自媒体人发布的内容，包括但不限于文章文字、图片、敏感信息等； 5、频道管理：管理频道分类界面，可以新增频道，查看频道，新增或修改频道关联的标签； 6、网站统计：统计内容包括：日活用户、访问量、新增用户、访问量趋势、热门搜索、用户地区分布等数据； 7、内容统计：统计内容包括：文章采集量、发布量、阅读量、阅读时间、评论量、转发量、图片量等数据； 8、权限管理：超级管理员对后台管理员账号进行新增或删除角色操作。 1.8、其它需求

1.9、交互需求

二．功能介绍 随着 Restful API、微服务的兴起，基于 Token 的认证现在已经越来越普遍。基于 token的用户认证是一种服务端无状态的认证方式，所谓服务端无状态指的 token本身包含登录用户所有的相关数据，而客户端在认证后的每次请求都会携带token，因此服务器端无需存放 token数据。 当用户认证后，服务端生成一个 token发给客户端，客户端可以放到 cookie 或 localStorage 等存储中，每次请求时带上 token，服务端收到 token通过验证后即可确认用户身份。

2.1、admin端 2.1.1、登录实现 根据用户名和密码登录，验证用户名和密码不能为空。首先查询该用户是否存在。根据名称查询，判断，如果用户是空，数据不存在。然后进行密码比对，与数据库里的信息比，如果不一致，返回密码错误，如果密码正确，返回 token，并且返回部分用户信息（隐藏敏感信息）给前端。 2.1.2、App端用户认证审核

用户审核功能

根据 ID查询用户，判断审核状态，如果是审核失败，修改用户状态，并且添加失败的原因，并保存并更新后的数据。审核通过，需要创建自媒体用户，构建自媒体用户，通过Feign远程调用接口，判断结果。如果创建自媒体用户成功，那么则继续创建作者，如果作者不为空，需要将authorId更新到自媒体账号中，修改apUserRealname 状态，修改apUser中的flag，构建作者信息，通过Feign远程调用接口，判断结果。

2.2、app端 2.2.1、APP 端用户认证 全局过滤器实现jwt 校验

通过网关进行授权验证

首先判断地址中是否包含登录的地址，如果是登陆的地址，不需要token，直接放行， 如果不是登陆地址，需要验证token。先获取 token（获取请求头对象），判断 token是否为空，如果为空返回 401，结束请求，不为空需要验证token，验证通过，需要将用户ID 放入到请求头中，供后面的微服务使用。

2.2.2、登录功能 app 端登录-需求分析

1、点击登录可以根据 app端的手机号和密码进行登录；

2、点击不登录，先看看可以在无登录状态下进入 app。

app端登录-思路分析

概念介绍：用户设备，即当前用户所使用的终端设备。

1、用户点击登录

1.1、用户输入手机号和密码到后端进行校验，校验成功生成 token返给前端；

1.2、其他请求需要带着 token到app网关去校验 jwt,校验成功，放行。

2，用户点击不登录，先看看

2.1、获取用户的设备id到后端根据设备 id生成token,设置 jwt 存储的id为 0；

2.2、其他请求需要带着 token到app网关去校验 jwt,校验成功，放行。

APP端登录-功能实现

用户登陆，查询用户，判断用户的密码是否与传递进来的密码一致，判断用户的密码是否与传递进来的密码一致，密码一致生成 token，发送 token给前端。

2.2.3、关注作者或取消关注 当前登录后的用户可以关注作者，也可以取消关注作者。

思路分析：

一个用户关注了作者，作者是由用户实名认证以后开通的作者权限，才有了作者信息， 作者肯定是app中的一个用户。

从用户的角度出发：一个用户可以关注其他多个作者；

从作者的角度出发：一个用户（同是作者）也可以拥有很多个粉丝(用户) 。

实现步骤：

1、前端传递作者 id获取作者信息，最终获取到作者在当前app端的账号 id；

2、如果是关注操作，需要保存数据，用户保存关注的作者，作者保存当前的粉丝；

2.1 异步记录关注行为（后面开发，为了推荐做准备）；

3、如果是取消关注，删除用户关注的作者，删除作者当前的粉丝。

app端关注信息表

记录了当前登录用户和关注人（作者）的关系，方便当前用户查看关注的作者。

1、app端用户粉丝表；

2、记录了作者与粉丝的关系，方便作者查看自己的粉丝，同时当前作者也是 app中的一个用户。

1、app用户表与 app作者表是一对一关系，只有在用户认证以后才会有作者出现；

2、app用户表与 app用户关注表是一对多的关系，一个用户可以关注多个作者；

3、app用户表与 app用户粉丝表是一对多的关系，一个用户可以拥有多个粉丝。 实现分析：

判断当前用户是否是正常登陆(不是设备ID)，发送消息，行为处理都是可以记录的，有登录用户,设置登录用户的ID，根据authorId 获取userId，获取关注的历史记录，查询该用户对应作者的粉丝信息，判断操作类型，0关注，1取消。

2.2.4、用户行为处理 实现分析 调用微服务查询当前用户点赞记录，更新点赞量时需要判断当前用户是否已经对这篇文章有过点赞数据,没有点赞记录，则更新文章库中文章表的点赞数,行为库中添加点赞记录， 如果有点赞记录，不再新增，但是可以修改（取消点赞），获取当前的点赞状态，判断点赞记录的类型与当前是否一致，不一致且操作为取消点赞，如果点赞记录为空,保存点赞记录， 取消点赞更新文章表中点赞数,更新行为库记录。

2.2.5、评论系统 文章详情页下方可以查看评论信息，按照点赞数量倒序排列，展示**评论内容、评论的作者、点赞数、回复数、时间**，默认查看20 条评论，如果想查看更多，可以点击加载更多进行分页。 评论概述：

登录用户可以进行评论，可以针对当前文章发布评论；

评论内容不为空且不超过 140 字，评论内容需要做文本反垃圾检测，评论内容需要做敏感词过滤，用户登录后才可以对文章发表评论。

评论话术：

每次用户要评论时，都会进行过滤，通过滤类，确保用户登陆后才能进行评论；

然后识别评论内容，字数判断，140 字以内。文本反垃圾检测、阿里云安全审核敏感词；

都通过后，保存用户评论，正式发布评论。

点赞话术：

同样通过过滤器，保证用户登录后才可以对评论点赞；

根据当前用户 id和评论id查询是否已有点赞记录，如果已有显示为已点赞；

如果没有点赞记录,新增点赞记录,更新评论的点赞数+1；

已有点赞记录,判断点赞记录中的点赞状态是否与当前操作一致 ；

不一致进行点赞数更新和点赞记录更新点赞操作, 根据点赞或取消点赞，评论数进行加减1。

评论列表话术：

根据文章 id查询评论列表，按照点赞的数量进行排序；

如果用户已经登录，需要判断当前登录用户，对评论列表中的哪些评论已点赞；

评论列表会进行分页查询。

回复话术：

回复功能包括，回复评论、回复列表展示、回复点赞；

当用户点击了评论中的回复时就可以查看所有评论回复的内容；

当用户针对当前评论回复时，需要更新回复数量；

当用户对回复点赞时，保存当前回复的点赞信息。

2.2.6、文章搜索 文章搜索话术：

在APP 端正上方有搜索框，可以输入搜索的关键字；

根据用户输入的关键字通过 es 分词查找文章列表；

文章列表的展示和 home 页展示一样，当用户点击某一篇文章时，可查看详情；

从es 的查询效率远比直接查数据库要快。所以需要把文章相关的数据存储到es 中；

搜索时查询es、展示列表，记录当前用户的搜索历史；

查询结果按照发布时间倒序排列。 搜索记录话术：

搜索历史记录会保存之前的 5调搜索关键词。用户可以选择手动删除；

在搜索时，会把搜索记录进行保存，存储的是用户实体信息和搜索关键词记录；

在用户再次点击到搜索框时，会查询当前用户的搜索记录列表，展示给用户；

当用户删除记录时，会将状态修改为 0，让历史记录无效，便不会展示。

关键词联想：

根据用户输入的关键字进行联想，默认展示5条联想词；

将用户搜索记录经过数据清洗后保存到联想词表，这是一个动态的数据，定时每天抓取搜索较高的1万条数据放到这里，之后根据关键字进行查询；

由于每次用户输入都会访问数据库，所以使用 redis 缓存进行缓解压力；

讲清晰的词分成词组，根据用户输入的在 redis 中查询出 5条，并展示；

数据结构为Trie树。

2.3、自媒体文章 2.3.1、自媒体文章列表查询 业务/需求:

所属：内容列表；

分页：需要进行分页；

条件：文章状态、关键字、频道列表、发布日期；

可以通过左侧的 “内容列表” 进入 文章查询页面。

筛选条件有：文章状态：全部、草稿、待审核、审核通过、审核失败；

关键字：用户输入；

频道列表：通过查询列表并展示；

发布日期：可选择区间；

默认查询当前用户的文章，状态：全部，不带有其他筛选信息，分页展示文章列表。

话术：

1.从本地线程获取到当前用户的 id，如果id为null 则用户未登录，给出”请登录” 提示。确保登陆后，通过用户 id查询出，用户的文章列表；

2.其他相关条件查询时，都会先判断是否为空， 确保用户有输入或选择后再加入对应的查询条件。条件包含: 关键字、所属频道 ID、文章状态、发布时间的开始和结束 其中所属频道 ID在 ad_channel 表中，因为该表id从1开始递增。如果 id值大于0，会根据所属 id 进行查询， （频道ID从 ad_channel表中查询出所有频道加载到页面即可）；

3.对查询的结果进行排序，我们选择根据发布时间倒序排列。根据实际业务需求可选创建时间、发布时间等进行排序；

4.封装好后将其返回，完成文章查询功能。

2.3.2、自媒体文章的发布、修改、保存功能 业务/需求：

文字内容：点击后可以手动输入需要添加的内容。可以多条；

图片内容：可以从素材库选择或本地上传，可以上传多个图片；

标签：用户自定义标签；

频道：可以从列表中选择；

定时：设置发布时间，到时间自动发布；

封面图片：无图、一张图、三张图；

跟前端布局有关。一般都是以上三种图片布局。

话术：

该功能为保存、修改、保存草稿的共有方法， 其中需要注意的是

修改：如果有那么是修改文章，先删除所有素材关联关系，再继续操作。点击修改按钮，携带文章id，进入编辑页面，可以修改文章的详细信息。修改的详细信息，都在文章发布功能中实现，如果有ID为修改，无 ID为新增。 封面图片：

如果选择是自动需要从内容中截取图片做为封面图片。

截取规则为：内容图片的个数小于等于2 则为单图截图一张图，内容图片大于等于3， 则为多图，截图三张图，内容中没有图片，则为无图。

设置发布和创建时间，通过当前线程获取当前用户，未登录给出提示。

通过dto对象获取封面图片，并提取内容中的图片，返回一个图片地址 url的 List 集合。

判断当前发布文章的封面类型 如果是-1为自动。

关于封面图片选择 “自动” 选项时，我们会提取内容中的图片。

通过判断 type 是image 统计数量并获取其值。

内容中图片数量 0为无图。小于等于 2 为1图 大于 2 为3图。

超过 3图会取前三个作为封面。

多张封面图片使用逗号分隔存入。

另外如果是保存草稿不需要添加素材和文章的关系。否则正常添加关系即可。

2.3.3、自媒体文章的修改 业务/需求：

通过点击现有文章进入编辑页面。可以对现有文章进行编辑修改。

话术：点击修改的时候，就是根据文章 id查询，跳转至编辑页面进行展示。这里只做一个页面跳转，具体修改功能的实现是由之前自媒体文章发布功能实现。

2.3.4、自媒体文章的删除功能 业务/需求：

点击现有文章的删除按钮，可以删除文章。

想要删除时，需要几个前提条件

1. 文章 id存在；

2. 文章存在；

3. 状态不是 9。

然后可以进行文章和素材关系的解除。之后再进行删除文章即可。

话术：

在做文章删除功能时，除了状态为9 已发布的文章不能删除外。

其他状态状态下都可以进行删除。

我们会先把文章和素材的关联关系删除掉，然后再进行对应文章的删除。

2.3.5、自媒体文章的上下架功能 业务/需求：

对已发布的文章进行上下架操作。

针对当前状态为 9(已发布)的文章进行上下架操作，并把数据同步到文章库中。使用 kafka 实现。

话术：

前台页面只有文章状态为9的会出现上下架选项， 先WmNewsdto 对象保证不为空，并且 id不为空。然后获取文章 确保文章存在，并且状态为 9 已发布时，就可以进行上下架操作了。我们只需要把 enable 修改一下即可。然后通过 Kafka 同步到App端直接发送一个包含上下架信息的主题（Topic），存的是map转换后的json包含 enable （上下架状态），和articleId(发布文章库 ID)。 2.3.6、自媒体文章审核 1.自媒体文章审核的流程

业务/需求：

自媒体文章可以自由发布，所以文章的内容是否符合规范、安全非常重要。所以我 们要细化内容审核的流程，来把控发布的文章。

文章审核分为 人工审核 和 自动审核。

人工审核：状态为4的进行人工审核。我们只需要把文章分配给审核工作人员即可。如果人工审核的文章发布时间大于当前时间，即可直接修改状态为8 审核通过(待 发布) 否则保存文章相关数据。

自动审核：状态为1的需要进行自动审核。我们会调用阿里云文本反垃圾服务，进行文章自动审核。如果审核不成功或需要人工审核，修改文章状态。如果当前文章有图片，调用阿里云图片审核服务，同样如果不成功，需要修改文章 状态。自动审核通过 如果文章发布时间大于当前时间，修改自媒体文章状态为8 审核通过(待发布) 否则保存文章相关数据。

2.文章审核

业务/需求：

自媒体和文章我们使用 Spring-Cloud的feign进行远程接口调用。

自媒体feign

1 根据文章 id查询自媒体文章的数据；

2 在审核的过程中,审核失败或者成功需要修改自媒体文章的状态；

3 在文章进行保存的时候需要查询作者信息，需要通过自媒体用户关联查询作者信息。

文章feign

1 保存文章信息 ap_article；

2 保存文章内容 ap_article_content；

3 在保存文章的时候需要关联作者，需要根据名称查询作者信息。

考虑到发表的文章会随时间增加，数据量巨大。所以使用分布式 id，分库进行保存。所以我们选择使用 雪花算法生成数据库id，Mybaits 逆向工程使用 ASSIGN_ID 生成。

雪花算法：

snowflake 是 Twitter 开源的分布式 ID 生成算法，结果是一个 long 型的 ID。其核心思想是：使用 41bit 作为毫秒数，10bit 作为机器的 ID（5 个 bit 是数据中心，5 个 bit 的 机器 ID），12bit 作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID）， 最后还有一个符号位，永远是0。

话术：

文章审核：我们的文章审核功能围绕着状态来实现。首先我们发布的文章初始状态肯定是 1(待审 核)，所以我们会根据文章状态进行如下操作：

状态 1

进行自动审核，通过阿里云安全的内容文本检测、图片审核， DFA敏感词过滤来完成审核。文本审核结果会有 1 审核通过 2 审核失败 3需要人工审核。

自动审核通过后，根据当前时间是否大于发布时间进行判断

是：直接保存到文章库

否：修改状态为8审核通过(待发布) 先保存数据，等发布时间到了再进行发布。

状态 8和状态4

8和4为人工审核通过或自动审核通待发布的文章， 所以只需要判断当前时间是否大于发布时间。

是：直接保存到文章库；

否：先保存数据，等发布时间到了再进行发布。

2.3.7、自媒体文章自动审核流程 作为内容类产品，内容安全非常重要，所以需要进行对自媒体用户发布的文 章进行审核以后才能到app端展示给用户。

审核的流程如下：

1.当自媒体用户提交发布文章之后，会发消息给kafka提交审核，平台运营 端监听消息；

2.根据自媒体文章id查询文章信息；

3.如果当前文章的状态为4（人工审核通过），则无需再进行自动审核，如 果发布时间大于当前时间,将状态修改为8,否则保存APP文章相关数据；

4.文章状态为8,发布时间小于等于当前时间,则直接保存app文章相关数据；

5.文章状态为1，则进行自动审核。

5.1 调用阿里云文本反垃圾服务，进行文本审核，如果审核不成功或需要人 工审核，修改自媒体文章状态；

5.2 如果文章中有图片,调用阿里云图片审核服务，如果审核不通过或需要 人工审核，修改自媒体文章状态；

5.3 文章内容中是否有自管理的敏感词，如果有则审核不通过，修改自媒体 文章状态；

5.4 自动审核通过,如果文章发布时间大于当前时间，修改自媒体文章状态为8（审核通过待发布状态） ；

5.5 自动审核通过,如果文章发布时间小于等于当前时间，保存app相关数据。

6.保存app相关数据,修改自媒体文章状态为 9 （已发布） ap_article 文章 ap_article_content 文章内容 ap_author 文章作者；

7.创建索引（为后续app端的搜索功能做数据准备） 表结构。

自媒体文章审核实现

当自媒体用户提交发布文章之后，会发消息给kafka提交审核，平台运营端 监听消息，根据自媒体文章id查询文章信息，判断当前文章的状态，丛自媒体 文章中提取文本和图片内容，调用阿里云文本反垃圾服务，进行文本审核，如果 审核不成功或需要人工审核，修改自媒体文章，调用阿里云图片审核服务，如果 审核不通过或需要人工审核，修改自媒体文章状态，文章内容中是否有自管理的 敏感词，如果有则审核不通过，修改自媒体文章状态，自媒体文章发布时间大于 当前时间，修改自媒体文章状态为8（审核通过待发布状态），审核通过，修改 自媒体文章状态为 9 （审核通过），保存app相关数据，如果当前文章的状态 为4（人工审核通过），则无需再进行自动审核审核，保存app文章相关数据 即可，文章状态为8,发布时间<=当前时间,则修改发布状态，文章状态为1，则进行自动审核。

2.3.8、定时任务扫描待发布文章 业务/需求:

定时任务的作用就是每分钟去扫描那些待发布的文章，如果当前文章的状态为8，并且发布时间小于当前时间的，立刻发布当前文章。

流程：

1. 文章数据准备，远程调用接口自媒体端文章查询功能，得到状态为 8 且发布时间 小于当前时间的文章。

2. 在任务调度中心创建调度任务，新建一个执行器，策略为轮询，每分钟执行一次。

3. 将扫描到符合条件的文章进行发布。

话术：

通过自媒体短的文章查询准备好数据后，我在项目中引入了 xxl-job调度任务中心，定义一个自媒体文章审核的执行器，路由策略采用轮询，每分钟执行一次扫描，如果发现有当 前文章的状态为8，并且发布时间小于当前时间的，立刻发布当前文章。

2.3.8、人工审核文章-admin端 业务/需求:

前提：自动审核失败，状态为3的。

自动审核使用的是阿里云和 DFA。某些情况自动审核会不通过，比如一些无法识别、无法分辨的信息等。会把文章从自动审核转到人工审核状态，并添加到人工审核列表。审核人员可以从列表中看到需要进行人工审核的文章，并且进行审核后选择 通过或不通过。

平台管理员可以查看待人工审核的文章信息，可以通过（状态改为 4）或驳回（状态改 为2）也可以通过点击查看按钮，查看文章详细信息，查看详情后可以根据内容判断是否需 要通过审核。

话术：我们在人工审核这里主要考虑的是列表的展示、并且增加一些搜索功能，方便找到对应 的文章。可以根据文章ID查看文章详情。对详情内容进行详细过审后，可以根据人工结果选择操作通过或不通过。

当审核通过后修改文章状态为 4，如果审核不通过 修改状态为 2，并添加审核不通过原因。

2.3.9、自媒体登陆 通过网关进行授权验证。

首先判断地址中是否包含登录的地址，如果是登陆的地址，不需要token, 直接放行，如果不是登陆地址，需要验证token。先获取token（获取请求头对 象），判断token是否为空，如果为空返回401，结束请求，不为空需要验证 token，验证通过，需要将用户ID 放入到请求头中，供后面的微服务使用。

2.4、新热文章计算 业务/需求:

筛选出文章列表中最近 5天热度较高的文章在每个频道的首页展示；

根据用户的行为（阅读、点赞、评论、收藏）实时计算热点文章。

话术：

新热文章计算分为三个部分

1.我们会定时计算热点文章，设置定时任务每日凌晨 1点开始，查询前 5天的文章。计算每个文章的分值，其中不同的行为设置不同的权重（阅读：1，点赞：3，评论：5， 收藏：8）

按照分值排序，给每个频道找出分值较高的30 条数据，存入缓存中；

2.实时计算热点文章

• 行为微服务，用户阅读或点赞了某一篇文章，发送消息给 kafka

• 文章微服务，接收行为消息，使用 kafkastream流式处理进行聚合，发消息给 kafka

• 文章微服务，接收聚合之后的消息，计算文章分值（当日分值计算方式，在原有权重的基础上再*3）

• 根据当前文章的频道 id查询缓存中的数据

• 当前文章分值与缓存中的数据比较，如果当前分值大于某一条缓存中的数据，则直接替换

• 新数据重新设置到缓存中；

1. 查询热点数据

• 判断是否是首页；

• 是首页，选择是推荐，channelId 值为0，从所有缓存中筛选出分值最高的 30 条数据返回；

• 是首页，选择是具体的频道，channelId 是具体的数字，从缓存中获取对应的频道中 的数据返回；

• 不是，则查询数据库中的数据。 三、技术点

1、Kafka 1.1、Kafka 是什么? Kafka 是一款分布式流处理框架，用于实时构建流处理应用。它有一个核心 的功 能广为人知，即作为企业级的消息引擎被广泛使用。 你一定要先明确它的流处理框架地位，这样能给面试官留 下一个很专业的印象。

1.2、Kafka 的特点？ 高吞吐量、低延迟：kafka 每秒可以处理几十万条消息，它的延迟最低只有几毫秒；

可扩展性：kafka 集群支持热扩展；

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；

容错性：允许集群中节点失败（若副本数量为 n,则允许n-1个节点失败）；

高并发：支持数千个客户端同时读写。

1.3、什么是消费者组？ 消费者组是 Kafka 独有的概念，如果面试官问这 ，就说明他对此是有一定了解的。我先给出标准答案：

1、定义：即消费者组是 Kafka 提供的可扩展且具有容错性的消费者机制。

2、原理：在 Kafka 中，消费者组是一个由多个消费者实例 构成的组。多个实例共同订阅若干个主题，实现共同消费。同一个组下的每个实例都配置有 相同的组 ID，被分配不同的订阅分区。当某个实例挂掉的时候，其他实例会自动地承担起 它负责消费的分区。 此时，又有一个小技巧给到你:消费者组的题目，能够帮你在某种程度上掌控下面的面试方向。 如果你擅长位移值原理，就不妨再提一下消费者组的位移提交机制; 如果你擅长 Kafka Broker，可以提一下消费者组与 Broker 之间的交互; 如果你擅长与消费者组完全不相关的 Producer，那么就可以这么说:“消费者组要消费的数据完全来自于 Producer 端生产的消息，我对 Producer 还是比较熟悉的。” 1.4、Kafka 中，ZooKeeper 的作用是什么? 这是一道能够帮助你脱颖而出的题目。碰到这个题目，请在心中暗笑三声。

目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后， Kafka 将完全不再依赖 于 ZooKeeper。

记住，一定要突出“目前”，以彰显你非常了解社区的演进计划。“存放元数据” 是指主题 分区的所有数据都保存在 ZooKeeper 中，且以它保存的数据为权威，其他“人” 都要与它 保持对齐。“成员管理”是指 Broker 节点的注册、注销以及属性变更，等等。“Controller 选举”是指选举集群 Controller，而其他管理类任务包括但不限于主题 删除、 参数配置等。

不过，抛出 KIP-500 也可能是个双刃剑。碰到非常资深的面试官，他可能会进一步 追问你 KIP-500 是做的。一言以蔽之:KIP-500 思想，是使用社区自研的基于 Raft 的共识算法，替代 ZooKeeper，实现 Controller 自选举。

1.5、如何估算 Kafka 集群的机器数量? 这道题目考查的是机器数量和所用资源之间的关联关系。所谓资源，也就是 CPU、 内存、磁盘和带宽。

通常来说，CPU 和内存资源的充足是比较容易保证的，因此，你需要从磁盘空间和带宽占用两个维度去评估机器数量。

在预估磁盘的占用时，你一定不要忘记计算副本同步的开销。如果一条消息占用 1KB 的磁盘空间，那么，在有 3 个副本的主题中，你就需要 3KB 的总空间来保存这条消息。显式地将这些考虑因素答出来，能够彰显你考虑问题的全面性，是一个难得的加分项。

对于评估带宽来说，常见的带宽有 1Gbps 和 10Gbps，但你要切记，这两个数字仅仅是最大值。因此，你最好和面试官确认一下给定的带宽是多少。然后，明确阐述出当带宽占用接近总带宽的 90% 时，丢包情形就会发生。这样能显示出你的网络基本功。

1.6、Kafka 为什么不支持读写分离? 这道题目考察的是你对 Leader/Follower 模型的思考。

Leader/Follower 模型并没有规定 Follower 副本不可以对外提供读服务。很多框架 都是允许这么做的，只是 Kafka 最初为了避免不一致性的问题，而采用了让 Leader 统一 提供服务的方式。

不过，在开始回答这道题时，你可以率先亮出观点:自 Kafka2.4 之后，Kafka 提供了有限度的读写分离，也就是说，Follower 副本能够对外提供读服务。

说完这些之后，你可以再给出之前的版本不支持读写分离的理由。

场景不适用：读写分离适用于那种读负载很大，而写操作相对不频繁的场景，可 Kafka 不属于这样的场景。

同步机制：Kafka 采用 PULL 方式实现 Follower 的同步，因此，Follower 与 Leader存在不一致性窗口。如果允许读 Follower 副本，就势必要处理消息滞后(Lagging)的问题。

黑马头条：

1、店铺查询那里，你是怎么存储店铺的信息？用什么数据结构？（应该是问 key 怎么设置的）

2、秒杀系统你是怎么设计的？

3、超卖问题你是怎么解决的？（黑马是用库存来当版本号，面试官问我这样会出现什么问题，我蒙了，虽然我也记得是有问题的，但是我不记得了，那集视频弹幕有弹出来，我记不得了）

4、还问了一个秒杀系统相关的，具体不记得了

5、前面问 redis 数据类型，还可以回答这个项目里使用的一些基于基础数据类型实现的特殊数据类型，例如 Geo 之类

6、秒杀具体流程，抢单如果每次扣减2件应该怎么做，你如何保证原子性？

7、List和Set的应用场景