项目源码可以在 https://gitee.com/ShayneC/community获取
项目发布与总结
1. 单元测试
-
Spring Boot Testing
- 依赖:spring-boot-starter-test
- 包括:Junit、Spring Test 、AssertJ、…
-
Test Case
- 要求:保证测试方法的独立性。
- 步骤:初始化数据、执行测试代码、验证测试结果、清理测试数据。
- 常用注解:@BeforeClass、@AfterClass、@Before、@After。
2. 项目监控
- Spring Boot Actuator
- Endpoints: 监控应用的入口,Spring Boot内置了很多端点,也支持自定义端点。
- 监控方式:HTTP或JMX。
- 访问路径:例如“/actuator/health”。
- 注意事项:按需配置暴露的端点,并对所有端点进行权限控制。
在application.properties中配置actuator
# actuator
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=info,caches
在src/main/java/com/nowcoder/community下新建actuator包并新建DatabaseEndpoint类
@Component
@Endpoint(id = "database")
public class DatabaseEndpoint {
private static final Logger logger = LoggerFactory.getLogger(DatabaseEndpoint.class);
@Autowired
private DataSource dataSource;
@ReadOperation
public String checkConnection() {
try (
Connection connection = dataSource.getConnection();
){
return CommunityUtil.getJSONString(200, "获取连接成功");
} catch (SQLException e) {
logger.error("获取连接失败: " + e.getMessage());
return CommunityUtil.getJSONString(500, "获取连接失败");
}
}
}
在浏览器中访问http://localhost:8888/community/actuator/database即可返回数据库连接结果
最后在SecurityConfig中配置只有管理员才能访问监控页面。
3. 项目部署
- 浏览器访问Nginx(负责分发请求,反向代理)
- Tomcat服务器(装JRE和Maven)
- MySQL、Redis、Kafka、Elasticsearch、Wkhtmltopdf
- Putty(访问服务器的客户端)
4. 项目总结
- Spring Boot
- Spring
- Spring MVC、Spring Mybatis、Spring Security
- 权限@会话管理
- 注册、登录、退出、状态、设置、授权
- Spring Email、Interceptor
- 核心@敏感词、@事务
- 首页、帖子、评论、私信、异常、日志
- Advice、AOP、Transaction
- 性能@数据结构
- 点赞、关注、统计、缓存
- Redis
- 通知@模式
- 系统通知
- Kafka
- 搜索@索引
- 全文搜索
- Elasticsearch
- 其他@线程池、@缓存
- 排行、上传、服务器缓存
- Quartz、Caffeine
动态请求:客户端–>Nginx主(从)–>Sever(community->本地缓存)–>Redis、DB、Kafka、Elasticsearch、文件服务器(七牛云)
静态资源:客户端–> 部署到CDN缓存服务(全国都有服务器,就近加载)
1.核心功能:
- 发帖、评论、私信、转发;
- 点赞、关注、通知、搜索;
- 权限、统计、调度、监控;
2.核心技术:
- Spring Boot、SSM
- Redis、Kafka、ElasticSearch
- Spring Security、Quatz、Caffeine
3.项目亮点:
- 项目构建在Spring Boot+SSM框架之上,并统一的进行了状态管理、事务管理、异常处理;
- 利用Redis实现了点赞和关注功能,单机可达5000TPS;
- 利用Kafka实现了异步的站内通知,单机可达7000TPS;
- 利用ElasticSearch实现了全文搜索功能,可准确匹配搜索结果,并高亮显示关键词;
- 利用Caffeine+Redis实现了两级缓存,并优化了热门帖子的访问,单机可达8000QPS。
- 利用Spring Security实现了权限控制,实现了多重角色、URL级别的权限管理;
- 利用HyperLogLog、Bitmap分别实现了UV、DAU的统计功能,100万用户数据只需*M内存空间;
- 利用Quartz实现了任务调度功能,并实现了定时计算帖子分数、定时清理垃圾文件等功能;
- 利用Actuator对应用的Bean、缓存、日志、路径等多个维度进行了监控,并通过自定义的端点对数据库连接进行了控。
5. 常见面试题
MySQL
- 存储引擎
- InnoDB支持事务(Transations)
- 事务
- 事务的特性:原子性、一致性、隔离性、持久性
- 事务的隔离
- 并发异常:第一类丢失更新、第二类丢失更新、脏读、不可重复读、幻读
- 隔离级别:Read Uncommited、Read Committed、Repeatable Read、Serializable
- Spring事务管理:声明式事务、编程式事务
- 锁
- 范围
- 表级锁:开销小、加锁快,发生锁冲突的概率高、并发度低,不会出现死锁。
- 行级锁:开销大、加锁慢,发生锁冲突的概率低、并发度高,会出现死锁。
- 范围
- 索引(InnoDB)
- 共享锁(S):行级,读取一行;
- 排他锁(X):表级,更新一行;
- 意向共享锁(IS):表级,准备加共享锁;
- 意向排他锁(IX):表级,准备加排他锁;
- 间隙锁(NK):行级,使用范围条件时,对范围内不存在的记录加锁。一是为了防止幻读,二是为了满足恢复和复制的需要。
IS | IX | S | X | |
---|---|---|---|---|
IS | x | |||
IX | x | x | ||
S | x | x | ||
X | x | x | x | x |
-
加锁
- 增加行级锁之前,InnoDB会自动给表加意向锁;
- 执行DML语句时,InnoDB会自动给数据加排他锁;
- 执行DQL语句时
- 共享锁(S):SELECT…FROM…WHERE…LOCK IN SHARE MODE;
- 排他锁(X):SELECT…FROM…WHERE…FOR UPDATE;
- 间隙锁(NK):上述SQL采用范围条件时,InnoDB对不存在的记录自动增加间隙锁。
-
死锁
- 场景
- 事务1:UPDATE T SET…WHERE ID=1;UPDATE T SET…WHERE ID=2;
- 事务2:UPDATE T SET…WHERE ID=2;UPDATE T SET…WHERE ID=1;
- 解决方案
- 一般InnoDB会自动检测到,并使一个事务回滚,另一个事务继续;
- 设置超时等参数 innodb_lock_wait_timeout;
- 避免死锁
- 不同的业务并发访问多个表时,应约定以相同的顺序来访问这些表;
- 以批量的方式处理数据时,应事先对数据排序,保证线程按固定的顺序来处理数据;
- 在事务中,如果要更新记录,应直接申请足够级别的锁,即排他锁;
- 场景
-
悲观锁(数据库)
-
乐观锁(自定义)
-
版本号机制
- UPDATE…SET…,VERSION=#{version+1} WHERE … AND … VERSION=#{version}
-
CAS算法(Compare and swap)
是一种无锁的算法,该算法涉及3个操作数(内存值V、旧值A、新值B),当V等于A时,采用原子方式用B的值更新V的值。该算法通常采用自旋操作,也叫自旋锁。它的缺点是:
- ABA问题:某线程将A改为B,再改回A,则CAS会误认为A没被修改过。
- 自旋操作采用循环的方式实现,若加锁时间长,则会给CPU带来巨大的开销。
- CAS只能保证一个共享变量的原子操作。
-
-
B+Tree(InnoDB)
- 数据分块存储,每一块称为一页;
- 所有值都是按顺序存储的,并且每一个叶子到根的距离相同;
- 非叶子节点存储数据的边界,叶子节点存储指向数据行的指针;
- 通过边界缩小数据的范围,从而避免全表扫描,加快了查找的速度。
Redis
- 数据类型
数据类型 | 最大存储数据量 |
---|---|
key | 512M |
string | 512M |
hash | 2^32-1 |
list | 2^32-1 |
set | 2^32-1 |
sorted set | 官方没给 |
bitmap | 512M |
hyperloglog | 12K |
-
过期策略
Redis会把设置了过期时间的key放入一个独立的字典里,在key过期时并不会立刻删除它。
Redis会通过如下两种策略,来删除过期的key:
-
惰性删除
客户端访问某个key时,Redis会检查该key是否过期,若过期则删除。
-
定期扫描
Redis默认每秒执行10次过期扫描(配置hz选项),扫描策略如下:
- 从过期字典中随机选择20个key;
- 删除这20个key中已过期的key;
- 如果过期的key的比例超过25%,则重复步骤1;
-
-
淘汰策略
当Redis占用内存超出最大限制(maxmemory)时,可采用如下策略(maxmemory-policy),让Redis淘汰一些数据,以腾出空间继续提供读写服务:
- noeviction:对可能导致增大内存的命令返回错误(大多数写命令,DEL除外);
- volatile-ttl:在设置了过期时间的key中,选择剩余寿命(TTL)最短的key,将其淘汰;
- volatile-lru:在设置了过期时间的key中,选择最少使用的key(LRU),将其淘汰;
- volatile-random:在设置了过期时间的key中,随机选择一些key,将其淘汰;
- allkeys-lru:在所有的key中,选择最少使用的key(LRU),将其淘汰;
- allkeys-random:在所有的key中,随机选择一些key,将其淘汰;
LRU算法:
- 维护一个链表,用于顺序存储被访问过的key。在访问数据时,最新访问过的key将被移动到表头,即最近访问的key在表头,最少访问的key在表尾。
近似LRU算法(Redis)
- 给每个key维护一个时间戳,淘汰时随机采样5个key,从中淘汰掉最旧的key。如果还是超出内存限制,则继续随机采样淘汰。
- 优点:比LRU算法节约内存,却可以取得非常近似的效果。
-
缓存穿透
-
场景
查询根本不存在的数据,使得请求直达存储层,导致其负载过大,甚至宕机。
-
解决方案:
- 缓存空对象:存储层未命中后,仍然将空值存入缓存层。再次访问该数据时,缓存层会直接返回空值。
- 布隆过滤器:将所有存在的key提前存入布隆过滤器,在访问缓存层之前,先通过过滤器拦截,若请求的是不存在的key,则直接返回空值。
-
-
缓存击穿
-
场景
一份热点数据,它的访问量非常大。在其缓存失效瞬间,大量请求直达存储层,导致服务崩溃。
-
解决方案:
- 加互斥锁:对数据的访问加互斥锁,当一个线程访问该数据时,其他线程只能等待。这个线程访问过后,缓存中的数据将被 重建,届时其他线程就可以直接从缓存取值。
- 永不过期:不设置过期时间,所以不会出现上述问题,这是“物理“上的不过期。为每个value设置逻辑过期时间,当发现该值逻辑过期时,使用单独的线程重建缓存。
-
-
缓存雪崩
-
场景
由于某些原因,缓存层不能提供服务,导致所有请求直达存储层,造成存储层宕机。
-
解决方案:
- 避免同时过期:设置过期时间时,附加一个随机数,避免大量的key同时过期。
- 构建高可用的Redis缓存:部署多个Redis实例,个别节点宕机,依然可以保持服务的整体可用。
- 构建多级缓存:增加本地缓存,在存储层前面多加一级屏障,降低请求直达存储层的几率。
- 启用限流和降级措施:对存储层增加限流措施,当请求超出限制时,对其提供降级服务。
-
-
分布式锁
-
场景
修改时,经常需要将数据读取到内存,在内存中修改后再存回去。在分布式应用中,可能多个进程同时执行上述操作,而读取和修改非原子操作,所以会产生冲突。增加分布式锁,可以解决此类问题。
-
基本原理
- 同步锁:在多个线程都能访问到的地方,做一个标记,标识该数据的访问权限。
- 分布式锁:在多个进程都能访问到的地方,做一个标记,标识该数据的访问权限。
-
实现方式
- 基于数据库实现分布式锁;
- 基于Redis实现分布式锁;
- 基于Zookeeper实现分布式锁;
-
Redis实现分布式锁的原则
- 安全属性:独享。在任一时刻,只有一个客户端持有锁。
- 活性A:无死锁。即便持有锁的客户端崩溃或者网络被分裂,锁仍然可以被获取。
- 活性B:容错。只要大部分Redis节点都活着,客户端就可以获取和释放锁。
-
单Redis实例实现分布式锁
-
获取锁使用命令:
SET resource_name my_random_value NX PX 30000
NX:仅在key不存在时才执行成功。PX:设置锁的自动过期时间。
-
通过Lua脚本释放锁:
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
可以避免删除别的客户端获取成功的锁:
A加锁 --> A阻塞 --> 因超时释放锁 --> B加锁 --> A恢复 --> 释放锁
-
-
多Redis实例实现分布式锁
Redlock算法,该算法有现成的实现,其Java版本的库为Redisson。
- 获取当前Unix时间,以毫秒为单位。
- 依次尝试从N个实例,使用相同的key和随机值获取锁,并设置响应超时时间。如果服务器没有在规定时间内响应,客户端应该尽快尝试另外一个Redis实例。
- 客户端使用当前时间减去开始获取锁的时间,得到获取锁使用的时间。当且仅当大多数的Redis节点都取到锁,并且使用的时间小于锁失效的时间时,锁才算取得成功。
- 如果取到了锁,key的真正有效时间等于有效时间减去获取锁使用的时间。
- 如果获取锁失败,客户端应该在所有的Redis实例上进行解锁。
-
Spring
- Spring IOC
- Bean的作用域
作用域 | 使用范围 | 描述 |
---|---|---|
singleton | 所有Spring应用 | 在容器中只存在一个实例,默认值。 |
prototype | 所有Spring应用 | 在容器中存在多个实例,即每次获取该Bean时,都会创建一个新实例。 |
request | SpringWeb应用 | 为每个请求创建一个新的实例。 |
session | SpringWeb应用 | 为每个会话创建一个新的实例。 |
globalSession | SpringWeb应用 | 为全局的session创建一个实例,只在Portlet上下文中有效。 |
application | SpringWeb应用 | 为整个Web应用创建一个新的实例。 |
-
Spring AOP
-
AOP的术语
Target(Joinpoint)<-- Weaving <-- Aspect(Pointcut(s.find*(…))、Advice(q前、后、返回、异常))
- 编译时织入,需使用特殊的编译器。
- 装载时织入,需使用特殊的类装载器。
- 运行时织入,需为目标生成代理对象。
-
-
Spring MVC
-
客户端发出请求访问服务器时,由DispatcherServlet处理。
-
DispatcherServlet调用HandlerMapping(根据访问路径找到对应Controller)。
-
HandlerMapping给DispatcherServlet返回HandlerExecutionChain对象(封装了Controller和拦截器)。
-
DispatcherServlet调用拦截器的preHandle()方法,接着调用HandlerAdapter(内部调了Controller)。
-
HandlerAdapter返回ModelAndView给DispatcherServlet,返回后调用postHandle()方法。
-
DispatcherServlet调用ViewResolver(视图解析器)。
-
ViewResolver解析View,由模板引擎渲染,(拦截器的afterCompletion()方法)返回客户端。
-
HandlerMapping给DispatcherServlet返回HandlerExecutionChain对象(封装了Controller和拦截器)。
-
DispatcherServlet调用拦截器的preHandle()方法,接着调用HandlerAdapter(内部调了Controller)。
-
HandlerAdapter返回ModelAndView给DispatcherServlet,返回后调用postHandle()方法。
-
DispatcherServlet调用ViewResolver(视图解析器)。
-
ViewResolver解析View,由模板引擎渲染,(拦截器的afterCompletion()方法)返回客户端。
-