兴业 + 民生上岸面试经验分享

今天这一篇兴业+民生的分享，后续的小伙伴可以参考。

民生简介

民生银行是一家民营性质的股份制商业银行，总部在北京。今年 5 月，民生银行在北京各大高校举行金融科技宣讲会，并宣布开展暑期提前批招聘：通过笔试筛选的同学在暑期前往北京顺义的民生银行总部参加夏令营活动，在夏令营期间通过选拔后方可拿到正式 Offer。关于民生具体招聘，笔试面试信息后续会写。

招聘面试流程

由于我是参加的夏令营活动，所以流程和正式批的有点不大一样。这里的流程是简历投递-通用类线上测评--专业技术线上笔试-金融科技夏令营选拔(5 天)---随后发放正式入职 OFFER---人才保温计划及签订三方协议---入职。

此次暑期招聘共有民生银行总行科技部和民生科技（民生银行科技子公司）两家企业进行招聘，总行科技部工作地点位于北京，而民生科技工作地点为：北京、深圳、成都、西安等地，其中成都的工作地点位于高新区天府国际金融中心 6 号楼民生银行成都分行内；

总行科技部涉及产品经理、大数据开发、信息安全、技术研发等岗位；民生科技只有技术研发岗位，笔者报名的是民生科技位于成都的技术研发岗；

笔试情况

笔试时间：

• 6 月 25 日 上午进行测评，2.5 小时，内容：（行测题+英语阅读 3 篇+心理测试）；

• 6 月 26 日 晚上进行笔试，2 小时，内容：（题型：30 道选择，两道编程，两道简答 ）；

选择题涵盖广泛：对称密钥算法、读程序写结果、cookie、RAID5、排序算法比较、决策树、SQL 语句、Hive5 等内容；

编程：两道编程题都很简单，一个是对学生成绩排序，写一个结构体的 cmp 函数就可以，另一个题是测试菜单程序：统计空行数，getline 读入（可以读空格），需要注意的是在输入完指令字符后，需要先用 getchar 接受一下末尾的空格。

简答题：第一个题设计分布式系统，第二题多张表写 mysql 语句，5 个小问，需要用到嵌套子查询。

7 月 7 日 收到笔试通过的消息，随后通过邮件确认参加夏令营的时间，暑期计划举行 3-4 期，选择其中一期参加即可，笔者选择的是八月下旬的那一期，随后 7 月份那批夏令营正式举行了，根据参加同学的反馈流程大概是：

• 破冰团建活动

• 金融科技授课

• 分组并分配研究题目

• 组内讨论并做课题研究

• 以 PPT 的形式汇报并评优

分享下前方同学返回来的民生总部的食宿情况：

面试情况

**8 月全国疫情反弹，后续批次的夏令营取消。**无福消受~~~~

参加 7 月份夏令营的同学在 8 月 23 日 收到 Offer，粗略估计拿到 Offer 比率大约为 3/4。随后报名后面批次的同学改为线上两轮面试的形式进行选拔：

**一轮技术面：**20 分钟左右

两位面试官+1 位 HR 共同在腾讯会议室内等着你，3-5 分钟自我介绍+项目介绍+挑一个项目深挖（比如项目里登录怎么实现的，点赞怎么实现的？）

• Redis 存储结构 持久化

Redis 是一个支持持久化的内存数据库，也就是说 redis 需要经常将内存中的数据同步到磁盘来保证持久化。redis 支持四种持久化方式，一是 Snapshotting（快照）也是默认方式；二是 Append-only file（缩写 aof）的方式；三是虚拟内存方式；四是 diskstore 方式

先来看 RDB 快照

快照嘛，快速拍照，即在某个时间点将内存中的数据写入一个磁盘的临时文件，持久化结束后，用这个临时文件替换上次持久化的文件。再看看配置文件

save 900 1                              # 在900秒内如果键值修改过1次就快照save 300 10                             # 在300秒内如果键值修改过10次就快照save 60 10000                           # 在60秒内键值修改过10000次就快照 stop-writes-on-bgsave-error yes         # 后台备份出错时，是否禁止新的写入操作？如果不禁止容易造成数据不一致rdbcompression yes                      # 导出的rdb文件是否压缩rdbchecksum yes                         # 恢复时导入rdb文件是否检验完整性、是否检验版本是否一致dbfilename dump.rdb                     # 导出来得rdb文件名dir /var/lib/redis                      # rdb的存放路径

AOF

通过将发送到服务器的写操作命令记录下来，形成 AOF 文件，此文件只许追加不能修改，Redis 启动时会读取 AOF 文件后重构数据(重新执行一遍)。文件默认名称是 appendonly.aof

appendonly no                           # 是否开启aof功能appendfilename "appendonly.aof"         # 文件名 appendfsync always                      # 只要一修改就同步至缓冲区，并同步至磁盘appendfsync everysec                    # 每秒将数据同步至缓冲区，并同步至磁盘appendfsync no                          # redis不设定同步策略，由内核设定的参数决定是否同步 no-appendfsync-on-rewrite no            # appendfsync设定为always或everysec的话，还要不要同步磁盘 auto-aof-rewrite-percentage 100         # 每隔多久重构aof文件，单位秒auto-aof-rewrite-min-size 64mb          # aof文件最小为多少时重构一次aof文件。搭配上一条使用 aof-load-truncated yes                  # 崩溃修复后自动进行全备

AOF 对比 RDB

AOF 更加安全，可以将数据即时同步到文件中，但是消耗磁盘 I/O，效率低 Snapshot 更高效，它是服务器在正常运行情况下数据同步最佳手段，文件尺寸小，效率高，安全性低

• 缓存击穿 缓存穿透 缓存雪崩

我在学校就这么点小项目，上来就问我这些玩意，我可

又有什么办法，也得硬抗哇。

缓存穿透

访问缓存的时候，没有找到 key，就直接访问了后方的数据库，而且还没查到数据，就没办法写缓存，所以下一次查询还是会打在数据库中。

这样看来，缓存就没有起到作用，流量大了就容易把数据库打垮求，此时的缓存就感觉被 走光了，没啥作用。

如何解决

1、**接口校验。**在正常业务流程中可能会存在少量访问不存在 key 的情况，但是一般不会出现大量的情况，所以这种场景最大的可能性是遭受了非法攻击。可以在最外层先做一层校验：用户鉴权、数据合法性校验等，例如商品查询中，商品的 ID 是正整数，则可以直接对非正整数直接过滤等等。

2、缓存空值。当访问缓存和 DB 都没有查询到值时，可以将空值写进缓存，但是设置较短的过期时间，该时间需要根据产品业务特性来设置。

3、布隆过滤器。使用布隆过滤器存储所有可能访问的 key，不存在的 key 直接被过滤，存在的 key 则再进一步查询缓存和数据库。

缓存击穿

描述：某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。

解决方案：

1、加互斥锁。在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。

关于互斥锁的选择，网上看到的大部分文章都是选择 Redis 分布式锁（可以参考我之前的文章：面试必问的分布式锁，你懂了吗？），因为这个可以保证只有一个请求会走到数据库，这是一种思路。

但是其实仔细想想的话，这边其实没有必要保证只有一个请求走到数据库，只要保证走到数据库的请求能大大降低即可，所以还有另一个思路是 JVM 锁。

JVM 锁保证了在单台服务器上只有一个请求走到数据库，通常来说已经足够保证数据库的压力大大降低，同时在性能上比分布式锁更好。

需要注意的是，无论是使用“分布式锁”，还是“JVM 锁”，加锁时要按 key 维度去加锁。

我看网上很多文章都是使用一个“固定的 key”加锁，这样会导致不同的 key 之间也会互相阻塞，造成性能严重损耗。

缓存雪崩

描述：大量的热点 key 设置了相同的过期时间，导在缓存在同一时刻全部失效，造成瞬时数据库请求量大、压力骤增，引起雪崩，甚至导致数据库被打挂。

缓存雪崩其实有点像“升级版的缓存击穿”，缓存击穿是一个热点 key，缓存雪崩是一组热点 key。

解决方案：

1、过期时间打散。既然是大量缓存集中失效，那最容易想到就是让他们不集中生效。可以给缓存的过期时间时加上一个随机值时间，使得每个 key 的过期时间分布开来，不会集中在同一时刻失效。

2、热点数据不过期。该方式和缓存击穿一样，也是要着重考虑刷新的时间间隔和数据异常如何处理的情况。

3、加互斥锁。该方式和缓存击穿一样，按 key 维度加锁，对于同一个 key，只允许一个线程去计算，其他线程原地阻塞等待第一个线程的计算结果，然后直接走缓存即可。

• Redis 集群了解么？

Redis 集群三种方式，主从复制模式，Sentinel 模式，Cluster 模式。但是你可以只需要说一种就行了，这里也就只给出主从复制模式哦。

主从复制模式

通过持久化功能，Redis 保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。 但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。

为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。

为此， Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。

在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库(slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

总结：引入主从复制机制的目的有两个

一个是读写分离，分担 “master” 的读写压力

一个是方便做容灾恢复

• 说一下 SpringAOP

• 项目中用哪些地方用到了 AOP

• 雪花算法和 UUID 的对比

• 常用的 Linux 命令说几个

• SpringCloud 优缺点

这个也是挺常见的问题，尤其是大家简历有相关的 Web 系统。会问你的项目选型，为什么会选这个。

优点

1. 耦合度比较低。不会影响其他模块的开发。

2. 配置比较简单，基本用注解就能实现，不用使用过多的配置文件。

3. 微服务跨平台的，可以用任何一种语言开发。

4. 轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发。

缺点

1. 部署比较麻烦，给运维工程师带来一定的麻烦。

2. 2.针对数据的管理比麻烦，因为微服务可以每个微服务使用一个数据库，集成度较高，使用过程中不太容易了解底层。

3. 3.系统集成测试比较麻烦

4. 4.性能的监控比较麻烦。【最好开发一个大屏监控系统】

每个微服务可以有自己的独立的数据库也有用公共的数据库。

• HR 提了 2 个问题：能不能来实习、为什么选择成都？

没有反问

**二轮主管面（一个大 Boss+一个小 Boss+一个 HR 主管）相隔一周:**10-15 分钟

• 自我介绍 1-2 分钟，聊天：

• 了解民生么？偏向前端还是后端？为什么选择成都？学习成绩怎么样？

• 大学研究生的经历依次问问？你经历最大困难是什么？怎么克服的？

• 没有反问 X2

总结

整体来看，无论是民生还是其他行，夏令营通常是对技术有一定要求的，也是让大家尽早熟悉银行开发流程的一次机会。之前写过一次 Fintech，也是金融科技相关的活动，活动开展比较早，也需要大家多多关注，才能把握机会的哟。

​