上海小公司面经-复盘版
公司介绍
上海小厂,200一天,随便面了面发了offer邮件,主要练习了自我介绍和部分项目介绍经验。
讲讲Java 的抽象类和接口
语法层面上的区别:
抽象类可以提供成员方法的实现细节,而接口中只能存在public abstract 方法;
抽象类中的成员变量可以是各种类型的,而接口中的成员变量只能是public static final类型的;
接口中不能含有静态代码块以及静态方法,而抽象类可以有静态代码块和静态方法;
一个类只能继承一个抽象类,而一个类却可以实现多个接口。
设计层面上的区别:
抽象类是对一种事物的抽象,即对类抽象,而接口是对行为的抽象。
抽象类是对整个类整体进行抽象,包括属性、行为,但是接口却是对类局部(行为)进行抽象。
设计层面不同,抽象类作为很多子类的父类,它是一种模板式设计。而接口是一种行为规范,它是一种辐射式设计。
@Restcontroller 了解不
Spring4之后新加入的注解,原来返回json需要@ResponseBody和@Controller配合。
即@RestController是@ResponseBody和@Controller的组合注解。
—》拓展restful 风格---〉自己项目就是restful的
@autowrited 和 @ resource
一般没什么区别,用idea的话,autowrited会报警告
spring建议用set注入和构造器注入,不建议在成员变量上加注解
autowrited是spring提供的,resource是java jre提供的
IOC 和 AOP
ioc 基本概念--》ioc 实现(工厂+反射)
aop 基本概念(面向切面编程,在不修改原代码的基础上对功能坐增强)--〉aop 实现(代理)
——〉静态代理、动态代理
——〉aop通知、aop在项目的应用(日志收集、鉴权、响应统计)
AOF 和 RDB
AOF(Append Only File)
AOF持久化功能,是一种保存写操作命令到日志的持久化方式
只会记录写操作命令,读操作命令是不会被记录的,因为没意义。
有三种写回策略
Always,每次写操作命令执行完后,同步将 AOF 日志数据写回硬盘;
Everysec,每次写操作命令执行完后,先将命令写入到 AOF 文件的内核缓冲区,然后每隔一秒将缓冲区里的内容写回到硬盘;
No,意味着不由 Redis 控制写回硬盘的时机,转交给操作系统控制写回的时机,也就是每次写操作命令执行完后,先将命令写入到 AOF 文件的内核缓冲区,再由操作系统决定何时将缓冲区内容写回硬盘。
根据自己的业务场景进行选择:
- 如果要高性能,就选择 No 策略;
- 如果要高可靠,就选择 Always 策略;
- 如果允许数据丢失一点,但又想性能高,就选择 Everysec 策略。
RDB 快照
也是用日志文件记录信息,RDB 文件的内容是二进制数据
Redis 提供了两个命令来生成 RDB 文件,分别是 save
和 bgsave
,他们的区别就在于是否在「主线程」里执行:
- 执行了 save 命令,就会在主线程生成 RDB 文件,由于和执行操作命令在同一个线程,所以如果写入 RDB 文件的时间太长,会阻塞主线程;
- 执行了 bgsave 命令,会创建一个子进程来生成 RDB 文件,这样可以避免主线程的阻塞;
执行 bgsave 过程中,Redis 依然可以继续处理操作命令的,也就是数据是能被修改的。
---》拓展写时复制技术(Copy-On-Write, COW)
RDB 和 AOF 合体
RDB 和 AOF 合体使用,这个方法是在 Redis 4.0 提出的,该方法叫混合使用 AOF 日志和内存快照,也叫混合持久化。
当开启了混合持久化时,在 AOF 重写日志时,fork
出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件,然后主线程处理的操作命令会被记录在重写缓冲区里,重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件,写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。
也就是说,使用了混合持久化,AOF 文件的前半部分是 RDB 格式的全量数据,后半部分是 AOF 格式的增量数据。
这样的好处在于,重启 Redis 加载数据的时候,由于前半部分是 RDB 内容,这样加载的时候速度会很快。
加载完 RDB 的内容后,才会加载后半部分的 AOF 内容,这里的内容是 Redis 后台子进程重写 AOF 期间,主线程处理的操作命令,可以使得数据更少的丢失。
微服务了解么
从单体架构的缺点聊到微服务的优点以及缺点
然后以自己做的项目为例讲了讲服务的拆分、调用
写个sql
总结
sql基础薄弱,语法快忘了,要加强
spring偏业务的忘差不多了,要回忆一下
redis部分继续融合八股
微服务部分
从单体优缺点--》微服务架构优缺点
然后可以讲服务拆分、服务注册--〉分布式---》共识算法
也可以讲网关,从基础的getway--〉南北向网关、东西向网关
记录个人的面试