Java牛客网社区项目——知识点&面试题

请简要介绍一下你的项目？

这个项目的整体结构来源于牛客网，主要使用了Springboot、Mybatis、MySQL、Redis、Kafka等工具。主要实现了用户的注册、登录、发帖、点赞、系统通知、按热度排序、搜索等功能。另外引入了redis数据库来提升网站的整体性能，实现了用户凭证的存取、点赞关注的功能。基于 Kafka 实现了系统通知：当用户获得点赞、评论后得到通知。利用定时任务定期计算帖子的分数，并在页面上展现热帖排行榜。

什么是Spring框架？

有很多模块组成，利用这些模块可以方便开发工作。这些模块是：核心容器（spring core)/数据访问和集成(Spring JDBC)/Web(Spring Web/MVC)/AOP(Spring Aop)/消息模块/测试模块(Spring Test)等。

对Spring IoC的理解

IoC的意思是控制反转，是一种设计思想，把需要在程序中手动创建对象的控制权交给了Spring框架。IoC的载体是IoC容器，本质是一个工厂，数据结构上来看是一个Map，用来存放着各种对象。当我们创建一个对象时，只需要配置好配置文件/注解，而不用担心对象是怎么被创建出来的。

IoC的优点：降低耦合，对象被容器管理需要两份数据：你的对象定义 + 配置文件，对象间的关系体现在配置文件，不会直接产生耦合。

什么是DAO

data access object，存放数据库访问对象。

Spring中关于Bean的注解

四种常见Bean
@Controller @Repository @Service @Component一般来说Bean只会被容器初始化一次，

@PostConstruct：初始化前调用 @PreDestroy：销毁之前

如何使用Bean
bean通过容器管理，不需要我们实例化，如果要使用某个bean，使用依赖注入 @Autowired

Spring MVC是什么，是怎样的工作流程

服务器分为表现层/业务层/数据层，其中Spring MVC是工作在表现层，作用是接收/解析用户发送的请求，调用对应的业务类，根据业务类返回的结果（ModelAndView)，调用view进行视图渲染，并将渲染后的View返回给请求者。具体分为以下8步。

1. 客户端（浏览器）发送请求给前端处理器（DispatcherServlet)(发送请求，响应结果)；
2. DispatcherServlet根据请求信息调用HandlerMapping，查找到对应的Handler；
3. 查找到对应的Handler(也就是Controller)后，由HandlerAdapter适配器处理；
4. HandlerAdapter根据Handler来调用真正的Controller；
5. Controller进行业务处理，返回ModelAndView对象，Model是数据对象，View是逻辑上的View；
6. ViewResolver根据逻辑view找到实际view；
7. DispatcherServlet把Model传给view进行视图渲染，然后返回给请求者。

C - Controller：控制器。接受用户请求，调用 Model 处理，然后选择合适的View给客户。
M - Model：模型。业务处理模型，接受Controller的调遣，处理业务，处理数据。
V - View：视图。返回给客户看的结果。

DispatcherServlet处理流程？

DispatcherServlet 处理流程：
在整个 Spring MVC 框架中，DispatcherServlet 处于核心位置，它负责协调和组织不同组件完成请求处理并返回响应工作。DispatcherServlet 是 SpringMVC统一的入口，所有的请求都通过它。DispatcherServlet 是前端控制器，配置在web.xml文件中，Servlet依自已定义的具体规则拦截匹配的请求，分发到目标Controller来处理。 初始化 DispatcherServlet时，该框架在web应用程序WEB-INF目录中寻找一个名为[servlet-名称]-servlet.xml的文件，并在那里定义相关的Beans，重写在全局中定义的任何Beans。在看DispatcherServlet 类之前，我们先来看一下请求处理的大致流程：

1. Tomcat 启动，对 DispatcherServlet 进行实例化，然后调用它的 init() 方法进行初始化，在这个初始化过程中完成了：对 web.xml 中初始化参数的加载；建立 WebApplicationContext(SpringMVC的IOC容器)；进行组件的初始化；
2. 客户端发出请求，由 Tomcat 接收到这个请求，如果匹配 DispatcherServlet 在 web.xml中配置的映射路径，Tomcat 就将请求转交给 DispatcherServlet 处理；
3. DispatcherServlet 从容器中取出所有 HandlerMapping 实例（每个实例对应一个 HandlerMapping接口的实现类）并遍历，每个 HandlerMapping 会根据请求信息，通过自己实现类中的方式去找到处理该请求的 Handler(执行程序，如Controller中的方法)，并且将这个 Handler 与一堆 HandlerInterceptor (拦截器)封装成一个 HandlerExecutionChain 对象，一旦有一个 HandlerMapping 可以找到 Handler则退出循环；
4. DispatcherServlet 取出 HandlerAdapter 组件，根据已经找到的 Handler，再从所有HandlerAdapter 中找到可以处理该 Handler 的 HandlerAdapter 对象；
5. 执行 HandlerExecutionChain 中所有拦截器的 preHandler() 方法，然后再利用
   HandlerAdapter 执行 Handler ，执行完成得到 ModelAndView，再依次调用拦截器的
   postHandler() 方法；
6. 利用 ViewResolver 将 ModelAndView 或是 Exception（可解析成 ModelAndView）解析成View，然后 View 会调用 render() 方法再根据 ModelAndView 中的数据渲染出页面；
7. 最后再依次调用拦截器的 afterCompletion() 方法，这一次请求就结束了。

拦截器的作用

目的：让未登录用户不能访问某些页面
原理：在方法前标注自定义注解，拦截所有的请求，只处理带有该注解的方法。

什么是SSM框架？

包括Spring + Spring MVC(和Spring天生集成) + MyBatis（帮你和数据库打交道的框架，简单的设置，你就可以像Java一样，操作数据库了）

怎么实现注册功能的？

根据请求来拆解功能
1，打开注册网页
2，把注册的信息发送给服务器（点注册）
3，把激活邮件发送给邮箱
4，利用激活链接打开网页

每一次请求都是先开发数据访问层，在开发业务层，最后开发视图层（三层架构），但是每一次请求不一定要用到这三层

什么是Interceptor，在项目的哪里使用到了Interceptor

Interceptor是SpringMVC的处理器（handler)拦截器，用于对处理器进行预处理和后处理。本项目中，每次请求都会检查request中的login_ticket，把找到的user信息存放在协程中，并在完成处理后，自动释放。（方便的进行用户信息取用）

使用什么技术生成验证码

使用Kaptcha包，可随机生成字符和图片。

如何检查登陆状态

加拦截器注解。

如何实现敏感词过滤

使用前缀树（字典树）存储敏感词，对text中的敏感词实现替换。

什么是Ajax，应用在项目哪些地方？

ajax指异步的json和xml技术，不是一门新的语言，而是使用现有技术的新方法。最大的特点是：不重新加载整个页面的基础上，可以与服务器交换数据，并更新部分网页数据。
项目中：帖子发布成功/失败的提示，使用到ajax

什么是事务，事务的四大特性。

定义：事务是逻辑上的一组操作，要么都执行，要么都不执行。
事物的四大特性-ACID：
A：原子性，事务是最小的执行单位，不允许被分割，事务的全部操作要么全部提交成功，要么全部失败回滚。
C：一致性，数据库在事务执行前后保持一致性状态，在一致性状态下，所有事务对同一个数据的读取结果相同。
I ：隔离性，一个事务所作的修改在最终提交前，对其他事务是不可见的。避免多个事物交叉执行所导致的数据不一致问题。
D（Duability）：持久性，一旦事务提交，所做的修改将被永远保存到数据库中。即使系统发生崩溃，事务执行的结构也不能丢失。

怎么利用Spring实现事务管理

Spring管理事务忽略了底层数据库的结构，非常方便。有两种方式：注解（类型，传播方式）/编程式事务（override)。

是怎样实现统一捕获异常的？

在SpringBoot的项目某一路径下，加上对应的错误页面，发生错误时自动会跳转。服务器的三层结构中，错误会层层向上传递，所以只需要在表现层（controller)统一处理错误即可。
方法：在controller中加上advice包，并通过注解@ControllerAdvice和@ExceptionHandler，统一捕获异常。

是怎样实现统一记录日志的？

使用了AOP技术（面向切面编程），这里使用到的是SpringAOP。 AOP技术能够将哪些与业务，但是为业务模块共同调用的逻辑或责任（比如事务处理，日志记录，权限控制等），封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的扩展性和维护性。 SpringAOP本质上基于动态代理，当要代理的对象实现了某接口，会使用JDK动态代理，在运行时通过创建接口的代理实例，织入代码。当要代理的对象没有实现接口，则使用Cglib技术（编译时增强），通过子类代理织入代码。

什么是Redis，Redis有哪些优点？

概念：redis是一个非关系型数据库，数据存储在内存中，读写速度快。可以存储键和五种不同类型值的映射。只能以字符串为键，值支持：字符串，列表，无序集合，有序集合，hash散列表。
优点：由于数据存储在内存中，读写速度非常快，满足高性能，高并发的系统要求。与Java原生的map/guava相比，支持分布式缓存。与memcached相比，支持更丰富的数据类型，且支持数据持久化。

Redis分布式集群架构

典型的分片+复制

怎么往Spring框架中配置Redis，介绍常见的Redis操作

如何配置：
1，导入jar包
2，配置端口，以及配置类redisTemplate（注入连接工厂/设置序列化方式（json））
常见操作
Value类型：redisTemplate.opsForValue().set(redisKey, 1)，redisTemplate.opsForValue().get(redisKey)， redisTemplate.opsForValue().increment(redisKey)，
Hash类型：redisTemplate.opsForHash().put(redisKey, “id”, 1)， 还有get等操作
List类型：redisTemplate.opsForList().leftPush(redisKey, 101)， 还有size, index, range， leftPop等操作
Set类型：add, size, pop, members等操作
Zset类型：redisTemplate.opsForZSet().add(redisKey, “Linda”, 92), 有socre，rank，reverseRank， range等操作
操作key：可以delete，以及设置过期时间
同时支持绑定操作，支持事务（编程式事务，在事务中一般不包含查询）
为什么不包含查询：redis事务就是一系列命令的批量操作，批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。

项目中Redis的作用

1、事务操作：redisTemplate直接调用opfor…来操作redis数据库，每执行一条命令是要重新拿一个连接，因此很耗资源，让一个连接直接执行多条语句的方法就是使用SessionCallback，同样作用的还有RedisCallback，但不常用。
2、使用redis存储验证码：

1. 因为验证码需要频繁的进行访问与刷新，因此对性能的要求较高；
2. 验证码不需要永久保存，通常在很短的时间后就会失效；
3. 分布式部署的时候，存在session共享的问题。

3、使用redis存储登录凭证：
因为后台在每次处理请求的时候都要查询用户的登录凭证，访问的频率非常高，因此需要使用redis存储。
4、使用redis缓存用户信息：
因为后台在每次处理请求的时候都要根据用户的凭证用户信息，访问的频率非常高。
5、Redis可以使用zset对需要排序的数据进行自定义的排序。

怎样存储的点赞/关注/缓存用户数据

点赞使用set类型存储，key为点赞对象，set中保存点赞人的ID
关注使用zSet类型存储，key为被关注者，set保存关注者以及关注时间为score
缓存用户数据使用Value类型，key为用userID得到的key，value为user对象（设置过期时间，且数据修改时需要清除缓存）

什么是消息队列

消息队列是一个存放消息的容器，生产者把消息放在队列中，消费者从消息队列中取出数据。消息队列的主要功能（优点）在于：

1. 解耦：生产者只负责把消息放在队列中，而不用关心谁去使用它。
2. 异步：生产者把消息放在队列中后即可返回，而不用一个个的通知消费者去执行，消费者是异步的获取消息的。
3. 限流：生产者一次性产生大量的数据时，不会给消费者造成压力，消费者可以根据自身的能力，去消息队列中取数据。

消息队列作为信息传递的中间件，需要注意哪些问题？

1、高可用：因为消息队列如果宕机，会导致整个系统不可用。（分布式/集群的现成支持）
2、数据持久化：防止数据丢失
3、如何取数据：消息队列主动通知或者消费者轮询。

Java中的blockingqueue，可以提供线程间的消息队列

BQ也是生产者与消费者模式，属于点对点式消息队列？（一个消息只会被消费一次）Blocking Queue构建了一个桥梁，能够解决生产速度/消费速度不匹配问题。阻塞的时候只是在那里等着，但是不会占用CPU资源，对性能不会有影响。

什么是Kafka，有哪些功能和应用场景？

Kafka为分布式流处理平台。流处理是指对不断产生的动态数据流实时处理，基于分布式内存，具有数据处理快速，高效，低延迟的特性。

Kafka简介：Kafka是一种消息队列，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景
特点：

• 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
• 可扩展性：kafka集群支持热扩展
• 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
• 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
• 高并发：支持数千个客户端同时读写

Kafka主要提供的功能包括：消息系统，日志收集，用户行为跟踪，流式数据处理。

Kafka的基础架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1Mw9pX6K-1685417762438)(C:\Users\DoubleC\Desktop\小白要找工作\images\image-20230530103047397.png)]
Producer：消息生产者，向Kafka中发布消息的角色。
Consumer：消息消费者，即从Kafka中拉取消息消费的客户端。
Consumer Group：消费者组，消费者组则是一组中存在多个消费者，消费者消费Broker中当前Topic的不同分区中的消息，消费者组之间互不影响，所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。某一个分区中的消息只能够一个消费者组中的一个消费者所消费
Broker：经纪人，一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳多个Topic。
Topic：主题，可以理解为一个队列，生产者和消费者都是面向一个Topic
Partition：分区，为了实现扩展性，一个非常大的Topic可以分布到多个Broker上，一个Topic可以分为多个Partition，每个Partition是一个有序的队列(分区有序，不能保证全局有序)
Replica：副本Replication，为保证集群中某个节点发生故障，节点上的Partition数据不丢失，Kafka可以正常的工作，Kafka提供了副本机制，一个Topic的每个分区有若干个副本，一个Leader和多个Follower
Leader：每个分区多个副本的主角色，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。
Follower：每个分区多个副本的从角色，实时的从Leader中同步数据，保持和Leader数据的同步，Leader发生故障的时候，某个Follower会成为新的Leader。

Kafka的消息模型，以及常见术语

消息模型：发布-订阅模型，消费者订阅了某一主题（topic）后，生产者采用类似广播的方式，将消息通过主题传递给所有的订阅者。
Topic：主题，类似于文件夹，用来存放不同的数据。
Partition：主题分区，同一主题的不同分区可以存放在不同的Broker上面，保证并发能力和负载均衡。
Offset：消息在Partition中的存放位置。
Broker：可以理解为kafka集群里面的一台或多台服务器，它本身是没有复制的，上面可能运行着topic1的leader， topic2的follower等等。

在项目哪里用到了Kafka？

当有点赞，评论，关注请求时，会发送系统通知点赞，评论，关注的对象。在处理系统信息时，使用到了Kafka，具体来说，先定义了生产者类和消费者类，其中生产者被点赞/评论/关注功能对应的Controller使用，产生消息。而消费者负责消息（message）到来时，把消息存到数据库内。

什么是ElasticSearch，存储原理，功能，特点

概念：ES是一个基于lucene构建的，分布式的，RESTful的开源全文搜索引擎。
存储原理：数据按照Index – Type – Document – 字段四级存储，其中Index对应数据库，Type对应表，Document为搜索的原子单位，包含一个或多个容器，基于JSON表示。字段是指JSON中的每一项组成，类似于数据库中的行/列。Mapping是文档分析过滤后的结果，根据用户自定义，将某些文字过滤掉，类似于表结构定义DDL？？。同时ES也和分布式数据库一样，支持shard的replication。
功能：
1、分布式的搜索引擎和数据分析引擎
2、全文检索，结构化检索，数据分析。
3、对海量数据进行近实时的处理
特点：
1、可以作为分布式集群处理PB级别的数据，也可单机使用。
2、不是特有技术，而是将分布式+全文搜索（lucene) + 数据分析合并在一起。
3、操作简单，作为传统数据库的补充，提供了数据库所不具备的很多功能。

项目中哪里使用到了ES,如何使用

在进行帖子搜索时，使用到了ES。可用Repository和Template两种方式，由于Repository搜索到的结果（直接返回的post类，方便）没有高亮标签（why），所以使用了template方式重写了mapResults函数，获得了带有高亮标签的post。
使用消息队列（kafka）的方式，实现发帖/删帖后ES数据库的自动更新。
搜索：定义SearchQuery，确定搜素内容，排序方式，高亮等。接着使用elasticTemplate.queryForPage方法，需要重写mapResults函数，得到高亮数据。

项目中使用到了SpringSecurity在哪些地方？

重构了用户权限控制（之前用的拦截器）

怎样统计网站UA和DAU

使用Redis的高级数据结构：
HyperLogLog：超级日志，统计独立整数个数。统计UA（独立访问）时，以日期为 rediskey ，将客户端IP　add 到HyperLogLog中（redisTemplate.opsForHyperLogLog().add(redisKey, i);）
Bitmap：位图，比如365天的签到，只需要３６５／８个字节的大小。统计DAU（日活跃用户）时，以日期为 rediskey ，以用户ID作为位（在数据中的位置），用 or 操作，既可以方便的统计一段时间内的注册用户访问人数。

什么是Quartz，特点，专业术语，项目应用

概念：quartz是一个开源项目，完全基于java实现。是一个优秀的开源调度框架。
特点：
1，强大的调度功能，例如支持丰富多样的调度方法
2，灵活的应用方式，例如支持任务和调度的多种组合方式
3，分布式和集群能力
专业术语：
scheduler：任务调度器 ， scheduler是一个计划调度器容器，容器里面有众多的JobDetail和trigger，当容器启动后，里面的每个JobDetail都会根据trigger按部就班自动去执行
trigger：触发器，用于定义任务调度时间规则
job：任务，即被调度的任务， 主要有两种类型的 job：无状态的（stateless）和有状态的（stateful）。一个 job 可以被多个 trigger 关联，但是一个 trigger 只能关联一个 job
misfire：本来应该被执行但实际没有被执行的任务调度
项目应用：定时的统计帖子分数（如何设置定时任务和trigger）

什么是Caffeine，如何缓存，项目应用

概念：Caffeine 是一个基于Java 8的高性能本地缓存框架
初始化cache：缓存保存的对象，使用Caffeine.newBuilder()创建，创建时设置缓存大小，过期时间，缓存未命中时的加载方式。
为什么只缓存热度帖子？答：因为不会经常变。

在SpringBoot上的，其他技术是依托于SpringBoot之上的。SpringBoot只是起到辅助的作用，降低其他技术的使用难度。整个技术的核心是Spring框架，在Spring之上使用了SpringMvc（解决了前后端请求处理交互的问题）、SpringMybatis（可以访问数据库）、SpringSecurity（用于管理项目中的登录权限等）。SpringMvc、SpringMybatis、SpringSecurity构成了项目的基石，项目中几乎所有请求是由他们完成的。…

1.如何实现项目的注册问题

用户注册对于开发人员来说就是在数据库表中插入一条新的用户数据。在我们这个项目中就是在user表中插入一条新数据，我们可以按照注册功能实现的以下三个请求来进行开发

我们对每一个请求的开发都是由Dao——>sevice——controller层

我们在插入数据前，会对数据进行空值验证，对账号邮箱进行重复性验证，使用map来存储错误信息，如果controller层拿到的map为空就说明注册成果，进行后续的激活处理。在插入数据时，会对密码进行加盐处理后，在使用MD5算法进行加密，然后存储到数据库，最开始的数据Status设为0，表示无效，需要进行激活处理。

激活逻辑：

2.项目如何实现用户唯一性检验

在创建MySQL表时，使用unqiue关键字保证用户名username字段的唯一性。另外，在注册用户时进行重复性验证，如果已经用户已经存在，不能进行注册。

3.项目的部署

4.项目中为什么要选用SpringBoot

用SpringBoot来简化项目的开发，Springboot具备以下优势：

一、独立运行

Spring Boot而且内嵌了各种servlet容器，Tomcat、Jetty等，现在不再需要打成war包部署到容器中，Spring Boot只要打成一个可执行的jar包就能独立运行，所有的依赖包都在一个jar包内。

二、简化依赖

spring-boot-starter-web启动器自动依赖其他组件，简少了maven的配置。

三、自动配置

Spring Boot能根据当前类路径下的类、jar包来自动配置bean，如添加一个spring-boot-starter-web启动器就能拥有web的功能，无需其他配置。

四、无代码生成和XML配置

Spring Boot配置过程中无代码生成，也无需XML配置文件就能完成所有配置工作，这一切都是借助于条件注解完成的，这也是Spring4.x的核心功能之一。

5.登录状态保存在哪

最开始考虑保存在数据库中

保存在用户凭证表，包括用户id，用户凭证，用户状态和过期时间，对于用户凭证表是0有效1无效。在登录时验证账号密码是否为空，或者密码是否错误等，如果没有错误就生成登录凭证，代码如下

后面用redis进行优化，将用户的登录凭证存入redis，如下：

6.用户登陆上之后怎么显示登录页面

根据登录与否，主页显示的信息会有不同。显示登录信息这个功能是一个共有的功能，对每一个请求都需要处理，所以采用拦截器来实现，集中统一的，以一个低耦合度的方式来处理。拦截器能够拦截浏览器访问过来的请求，然后处理每个请求共有的业务。

用户在登录后会以ticket为key，以及实际的ticket为value创建一个cookie存入浏览器，之后服务端根据用户凭证在用户凭证表中查询user信息封装在模板中然后返回给浏览器（后面用redis优化了，不是根据ticket在表中取，而是ticke是一个对象，它含有userId的成员属性！！，然后根据userId取user表中取user信息。redis将ticket序列化为字符串后存入。）。代码和流程如下图所示

这个过程是每一个用户登录都会存在的，所以我们需要拦截器来处理。同时对于服务端来说，同时可能会有大量的浏览器请求，所以这里还涉及到线程安全问题。

redis优化！！！！ 将用户信息缓存到redis中，优先从缓存中取值：

拦截器：1.自定义拦截器 2.配置拦截器

首先验证用户

经过controller后，返回到拦截器，拦截器再将用户信息存入model

自定义拦截器需要实现HandlerInterceptor，然后重写preHandle（controller前执行）,postHandle（controller后执行）,以及afterCompletion（模板解析后执行）

配置拦截器：需要实现WebMvcConfigurer接口，然后重写addInterceptors方法，排除拦截静态页面。

采用ThreadLocal来保存用户信息，保证线程安全性

ThreadLocal源码：

从上面的代码可以看出，ThreadLocal set赋值的时候首先会获取当前线程thread,并获取thread线程中的ThreadLocalMap属性。如果map属性不为空，则直接更新value值，如果map为空，则实例化threadLocalMap,并将value值初始化

ThreadLocalMap是ThreadLocal的内部静态类，而它的构成主要是用Entry来保存数据 ，而且还是继承的弱引用。在Entry内部使用ThreadLocal作为key，使用****我们设置的value作为value****。

通过当前线程对象的getMap()方法获取ThreadMap对象 然后将当前ThreadLocal对象作为key值存入map 这能保证线程内的资源共享而不同线程之间独立

7.md5原理知道吗？安全吗？可逆吗？

可以将MD5算法看作一台机器，计算机的任何内容（字符串，图片，视频等）被丢进去都将输出一个长度为128比特的MD5值。

输入消息相同，结果也会始终相同，不同的消息，结果则不同。MD5原理简述：MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过了一系列的处理后，算法的输出由四个32位分组组成，将这四个32位分组级联后将生成一个128位散列值。

MD5的安全性：普遍认为MD5是很安全，因为暴力破解的时间是一般人无法接受的。实际上如果把用户的密码MD5处理后再存储到数据库，其实是很不安全的。因为用户的密码是比较短的，而且很多用户的密码都使用生日，手机号码，身份证号码，电话号码等等。或者使用常用的一些吉利的数字，或者某个英文单词。如果我把常用的密码先MD5处理，把数据存储起来，然后再跟你的MD5结果匹配，这时我就有可能得到明文。因此在我们这个项目中，会将用户密码进行加盐处理（密码末尾加随机的字符串）然后再进行MD5加密存入数据库。

**MD5是否可逆：不可逆，**原因是MD5是一种散列函数，使用的是hash算法，在计算过程中原文的部分信息是丢失了的。

8.项目里哪块用到aop了

项目中统一处理日志时，用到了AOP。

如果我们在每个业务组件中都记录日志，那么会产生非常多的重复代码。如果我们采用OOP的思想，将记录日志的功能封装成一个bean去调用，那么会产生耦合度高等问题。因为记录日志本身不属于业务需求，它属于系统需求，所以我们不应该将业务需求和系统需求耦合在一起，这个时候我们就需要用AOP来处理。

Target是我们已经开发好的业务逻辑的一个一个bean，我们称之为目标对象，目标对象上有很多地方可以被织入代码，可以被织入代码的地方我们统称为连接点joinpoint。AOP解决统一处理系统需求的方式是将代码定义到一个额外的bean，叫切面组件Aspect，这个组件在程序运行之前就需要被框架织入到某些连接点。切面组件的pointcut声明织入到哪个位置，通知Advice方法声明切面要处理什么样的逻辑。

具体使用：

before代码前置通知，在开头织入程序。

9.项目中redis怎么用的

缓存点赞和关注：

1、Redis缓存用户点赞数用String类型，以用户ID为key，点赞时，自增，取消赞时，自减；

缓存实体点赞数，set类型，用户给实体点赞时添加进列表，取消赞时则移除，最后用size统计；

2、缓存粉丝列表，使用zset，存入粉丝的id和关注的时间戳，使用zCard获得粉丝数量。利用reverseRange的时间戳反向排序，按关注时间加载粉丝列表。

优化登录：

1、使用Redis缓存用户信息。将user缓存到Redis中，获取user时，先从Redis获取。取不到时，则从数据库中查询，再缓存到Redis中。因为很多界面都要用到user信息，并发时，频繁的访问数据库，会导致数据库崩溃。变更数据库时，先更新数据库，再清空缓存；

2、使用Redis缓存验证码 。原本添加到session中，减轻服务器压力。将验证码存到Redis中，方便查询检验；

-验证码需要频繁的访问与刷新，对性能要求很高；

-验证码不需要永久存储，通常在很短的时间内就会失效；

-分布式部署时，存在session共享问题；

3、登录凭证：原本添加到MySQL中，为减轻每次登录都去查询数据库的压力，将登录凭证ticket缓存在Redis中，防止每次都要进行数据库的查询，提高并发能力。退出登录时，原本要修改数据库中的登录凭证，现在只需要修改Redis即可。

10.redis的key怎么设计？

redis的key是String类型的，编写了一个工具类来生成redis的key。key由多个单词拼接而成，中间采用冒号隔开，有的单词是固定的，有些单词是动态的，设计方法如下所示：

这里如某个实体的赞采用了set来存入，存的是userId，这样的话能够得到每个点赞的人，以及数量。

这里用户的赞用int存，它等于该用户实体（帖子+评论）收到的赞的总和。

关注的实体和实体拥有的粉丝都用zset存。set保存关注者以及关注时间为score

缓存用户数据使用Value类型，key为用userID得到的key，value为user对象（设置过期时间，且数据修改时需要清除缓存）

验证码是与user相关的，但是这里我们不能直接传入userId,因为还未登录，我们不知道用户是谁。这里传入了一个字符串owner，这是在用户访问登录页面的时候，给他发一个凭证（随机字符串），存到cookie里，如下图所示。

用的时候从cookie内将这个owner取出来，在得到rediskey，然后获取验证码，与输入的验证码进行对比。

11.缓存点赞数如何实现

帖子和评论的赞一起存，统称为实体的赞。还需要统计用户的赞（用户的帖子和评论收到的赞的总和）如下图所示。因为如果统计用户所有帖子和评论的赞得到用户获得的赞太麻烦，所以这里以用户ID采用rediskey工具拼接为key记录点赞数量（这就会涉及到事务操作。用户的帖子或者评论的点赞数增加了对应的用户的赞要增加）

具体实现：使用redis来存储点赞数，首先需要构造redis的key，如下图拼接

主要考虑到这个entityType（帖子还是评论）和 entityId（这个类型下的目标）确定实体类型和id

而redis的值使用set类型而不是一个简单的整数，这主要是为了可能需求发生变化，比如说想看到谁给我点赞了。集合里面存userid。用户的赞的值就采用value

点赞使用set类型存储，key为点赞对象，set中保存点赞人的ID

点赞的时候需要判断用户是否已经点赞：通过redistemplate.opsforSet().ismember方法 如果已经点过赞了就要把点赞记录删除 否则添加数据。 这里用到了事务操作 重写了execute方法

还需要查询某实体的点赞数量和点赞状态：

这里点赞状态没有用布尔值是为了之后开发新功能，比如踩就能使用-1；

12 如何保证redis和数据库一致性？

项目中只有redis保存用户信息那里才会出现这个问题！！ 因为redis对于点赞、关注、用户凭证和验证码等功能来说都是当作数据库来用的，所以没有这个问题。

只要我们使用 Redis 缓存，就必然会面对缓存和数据库间的一致性保证问题，这也算是 Redis 缓存应用中的“必答题”了。最重要的是，如果数据不一致，那么业务应用从缓存中读取的数据就不是最新数据，这会导致严重的错误。比如说，我们把电商商品的库存信息缓存在 Redis 中，如果库存信息不对，那么业务层下单操作就可能出错，这当然是不能接受的。

**缓存和数据库的数据不一致是如何发生的？**首先，我们得清楚“数据的一致性”具体是啥意思。其实，这里的“一致性”包含了两种情况：

• 1. 缓存中有数据，那么，缓存的数据值需要和数据库中的值相同；
• 2. 缓存中本身没有数据，那么，数据库中的值必须是最新值。

1. 不符合这两种情况的，就属于缓存和数据库的数据不一致问题了。不过，当缓存的读写模式不同时，缓存数据不一致的发生情况不一样，我们的应对方法也会有所不同，所以，我们先按照缓存读写模式，来分别了解下不同模式下的缓存不一致情况。

对于读写缓存来说，如果要对数据进行增删改，就需要在缓存中进行，同时还要根据采取的写回策略，决定是否同步写回到数据库中。

1. 1. 同步直写策略：写缓存时，也同步写数据库，缓存和数据库中的数据一致；
2. 2. 异步写回策略：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库。使用这种策略时，如果数据还没有写回数据库，缓存就发生了故障，那么，此时，数据库就没有最新的数据了。

所以，对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用同步直写策略。不过，需要注意的是，如果采用这种策略，就需要同时更新缓存和数据库。所以，我们要在业务应用中使用事务机制，来保证缓存和数据库的更新具有原子性，也就是说，两者要不一起更新，要不都不更新，返回错误信息，进行重试。否则，我们就无法实现同步直写。当然，在有些场景下，我们对数据一致性的要求可能不是那么高，比如说缓存的是电商商品的非关键属性或者短视频的创建或修改时间等，那么，我们可以使用异步写回策略。

下面我们再来说说只读缓存。对于只读缓存来说，如果有数据新增，会直接写入数据库；而有数据删改时，就需要把只读缓存中的数据标记为无效。这样一来，应用后续再访问这些增删改的数据时，因为缓存中没有相应的数据，就会发生缓存缺失。此时，应用再从数据库中把数据读入缓存，这样后续再访问数据时，就能够直接从缓存中读取了。

项目中的redis在存储用户信息时，是只读模式，看代码：

首先从缓存中取，如果有则直接返回，没有则初始化（从数据库取后存入缓存），然后返回。

那么只读情况下，这个过程中会不会出现数据不一致的情况呢？考虑到新增数据和删改数据的情况不一样，所以我们分开来看。

如果是新增数据，数据会直接写到数据库中，不用对缓存做任何操作，此时，缓存中本身就没有新增数据，而数据库中是最新值，此时，缓存和数据库的数据是一致的。

如果发生删改操作，应用既要更新数据库，也要在缓存中删除数据。会出现以下两种问题（前一个要素成果的前提下）

我们在项目中用的是第二种情况，即先更新数据库值，然后删除缓存，如图：

为什么不选择先删除缓存的主要原因是有可能导致请求因缓存缺失而访问数据库，给数据库带来压力

如何解决数据不一致问题？

缓存和数据库的数据不一致一般是由两个原因导致的，提供了相应的解决方案。

1. 删除缓存值或更新数据库失败而导致数据不一致，可以使用重试机制确保删除或更新操作成功。
2. 在删除缓存值、更新数据库的这两步操作中，有其他线程的并发读操作，导致其他线程读取到旧值，应对方案是延迟双删。

重试机制：具体来说，可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中。当应用没有能够成功地删除缓存值或者是更新数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或更新。如果能够成功地删除或更新，我们就要把这些值从消息队列中去除，以免重复操作，此时，我们也可以保证数据库和缓存的数据一致了。否则的话，我们还需要再次进行重试。如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了 。

延迟双删： 一般应用于先删除缓存，再更新数据库的多线程并发访问的情况。这是因为，先更新数据库值，再删除缓存值的情况下，如果线程 A 删除了数据库中的值，但还没来得及删除缓存值，线程 B 就开始读取数据了，那么此时，线程 B 查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。不过，在这种情况下，如果其他线程并发读缓存的请求不多，那么，就不会有很多请求读取到旧值。而且，线程 A 一般也会很快删除缓存值，这样一来，其他线程再次读取时，就会发生缓存缺失，进而从数据库中读取最新值。所以，这种情况对业务的影响较小。

而假设线程 A 删除缓存值后，还没有来得及更新数据库（比如说有网络延迟），线程 B 就开始读取数据了，那么这个时候，线程 B 会发现缓存缺失，就只能去数据库读取。这会带来两个问题：

1. 线程 B 读取到了旧值；
2. 线程 B 是在缓存缺失的情况下读取的数据库，所以，它还会把旧值写入缓存，这可能会导致其他线程从缓存中读到旧值。

等到线程 B 从数据库读取完数据、更新了缓存后，线程 A 才开始更新数据库，此时，缓存中的数据是旧值，而数据库中的是最新值，两者就不一致了。

这种情况我们就用延迟双删来解决： 在线程 A 更新完数据库值以后，我们可以让它先 sleep 一小段时间，再进行一次缓存删除操作。之所以要加上 sleep 的这段时间，就是为了让线程 B 能够先从数据库读取数据，再把缺失的数据写入缓存，然后，线程 A 再进行删除，这样再有线程来读取，就不会出现我们上面所说的，线程A更新了数据库，却发现缓存值于数据库不一致的情况了。

总结如图：

13 项目中的kafka是怎么用的？

kafka入门

Apache Kafka是一个分布式流平台。一个分布式的流平台应该包含3点关键的能力：

1. 发布和订阅流数据流，类似于消息队列或者是企业消息传递系统
2. 以容错的持久化方式存储数据流
3. 处理数据流

-应用：消息系统、日志收集、用户行为跟踪、流式处理

kafka特点

-高吞吐量：处理TB级的海量数据

-消息持久化：持久化，将数据存储到硬盘上，而不仅仅存储在内存中，长久保存消息，存到硬盘中的读取速度远远小于内存，读写硬盘的效率高低取决于读取硬盘的方式，硬盘的顺序读写的效率是很高的，kafka保证对硬盘消息的读写都是顺序的；

-高可靠性：kafka是分布式部署，一台服务器挂了，还有别的，有容错机制

-高拓展性：集群的服务器不够时，可以扩展服务器，只需简单的配置

·kafka术语

-Broker：卡夫卡的服务器，卡夫卡集群中的每一台服务器称为一个Broker

-Zookeeper：管理集群的软件，在使用卡夫卡时可以单独安装zookeeper或是内置zookeeper

消息队列的实现方式：

*点对点的实现方式*：BlockingQueue，生产者将消息放入队列中，消费者从队列中取出数据，每个消息只会被一个消费者消费；

消息发送者生产消息发送到消息队列中，然后消息接收者从消息队列中取出并且消费消息。消息被消费以后，消息队列中不再有存储，所以消息接收者不可能消费到已经被消费的消息。

发布订阅模式：生产者将消息发布到某个位置，多个消费者可以同时订阅这个位置，该消息可以被多个消费者读取，

卡夫卡使用的就是发布订阅模式：生产者将消息发布到的区域就叫做topic，可以理解为一个文件夹

-Partition：对主题的分区

-Offset：消息在分区内存放的索引

-Leader Replica：副本，卡夫卡是分布式的，所以会对分区进行多个副本的重复

主副本：可以处理获取消息的请求

-Follower Replica：从副本只是备份数据，不会产生响应，当主副本挂了时，分布式会在所有的从副本中选择一个作为新的主副本

发送系统通知： —操作非常频繁，用户群体很多，需要考虑性能问题

·触发事件

定义三种不同的主题，将不同的触发事件包装成不同的消息，发布到对应的主题中，这样生产者线程可以继续发布消息，

此时消费者线程可以并发的读取消息，进行存储

-评论后，发布通知

-点赞后，发布通知

-关注后，发布通知

·处理事件

-封装事件对象

-开发事件的生产者

-开发事件的消费者

生产者：触发Event，封装了Topic以及userId、Entity等信息，调用sendMsg时，提取出event.Topic和JSONObject.toJSONString(Event)以content形式发送，进行调用即可； （主动触发，*在添加评论、关注和点赞时触发）*

消费者：监听Topic，如果有新消息，就读取，record中获得到的是event里的json串，再恢复成event即可JSONObject.paresObject(record.value().toString,Event.class)；然后将相关属性，封装成message私信的形式，保存到数据库中，供给前端页面调用并显示。（*这里的消费就是将数据从消息队列存入数据库，被动触发，**kafka**监听主题，有消息就自动消费*）

14 消息队列放到内存还是磁盘？放磁盘为什么还这么快？

Kafka的消息是保存或缓存在磁盘上的，一般认为在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间，但是实际上，Kafka的特性之一就是高吞吐率。

从数据写入和读取两方面分析，为什么Kafka速度这么快

写入数据：磁盘读写的快慢取决于你怎么使用它，也就是顺序读写或者随机读写。在顺序读写的情况下，磁盘的顺序读写速度和内存持平。因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最讨厌随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。

即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以Kafka的数据并不是实时的写入硬盘 ，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。

读取数据：实现了零拷贝

15 TrieTree前缀树介绍一下

前缀树 是一种多叉树的树形数据结构，在项目中用于对敏感词进行过滤。

构造前缀树：第一层就存所有敏感词的第一个字符

前缀树特点是：1.根节点不包含任何信息 除了根节点的每个节点只包含一个字符，2.从根节点到某一个节点经过的路径，字符所连接的字符串就是这个节点所对应的字符串 3.每个节点的所有子节点包含的字符不同

如下图：

过滤敏感词算法：

三个指针，一个指向树根（node），另两个指针（begin和position），都指向文本首，其中一个一直向后移动（begin），另一个跟着动，发现不是敏感词，就说明以begin开头的字符不可能组成敏感词，将其存入StringBuilder，begin后移，然后再返回至begin。若是敏感词，则替换，并另两个指针都后移，树指针指向根节点。

 public String filter(String text) {
        if (StringUtils.isBlank(text)) {
            return null;
        }
        // 指针1
        TrieNode tempNode = rootNode;
        // 指针2
        int begin = 0;
        // 指针3
        int position = 0;
        // 结果
        StringBuilder sb = new StringBuilder();
        while (position < text.length()) {
            char c = text.charAt(position);
            // 跳过符号
            if (isSymbol(c)) {
                // 若指针1处于根节点,将此符号计入结果,让指针2向下走一步
                if (tempNode == rootNode) {
                    sb.append(c);
                    begin++;
                }
                // 无论符号在开头或中间,指针3都向下走一步
                position++;
                continue;
            }
            // 检查下级节点
            tempNode = tempNode.getSubNode(c);
            if (tempNode == null) {
                // 以begin开头的字符串不是敏感词
                sb.append(text.charAt(begin));
                // 进入下一个位置
                position = ++begin;
                // 重新指向根节点
                tempNode = rootNode;
            } else if (tempNode.isKeywordEnd()) {
                // 发现敏感词,将begin~position字符串替换掉
                sb.append(REPLACEMENT);
                // 进入下一个位置
                begin = ++position;
                // 重新指向根节点
                tempNode = rootNode;
            } else {
                // 检查下一个字符
                position++;
            }
        }
        // 将最后一批字符计入结果
        sb.append(text.substring(begin));
        return sb.toString();
    }