Java“实战”问题三连
- Java“实战”面试题 1:如果用 mybatis 批量插入数据时需要返回主键,你是怎么做的?
- Java“实战”面试题 2:在微服务中你是如何实现不同服务间 session 共享的?
- Java“实战”面试题 3:你了解分库分表么?分库分表一般出现在哪些场景下?
面试题 1:如果用 mybatis 批量插入数据时需要返回主键,你是怎么做的?
需要在 Mapper.xml 的中标签中配置 useGeneratedKeys 和 keyProperty 两个属性,就可以在批量插入时返回主键。
比如有个表 t_user,里面有 user_id,user_name,sex 这三个字段,其中 user_id 是自增主键。
下面是批量插入的 Dao 层接口:
1 | List<String> insertUsers(@Param("list") List<UserInfo> users); |
xml 形式:
1234567 | <insert id="insertUsers"useGeneratedKeys="true"keyProperty="user_id"resultType="String"> insert into t_user (user_name,sex) values <foreach collection="list"item="c"separator=","> (#{c.user_name},#{c.sex}) </foreach></insert> |
注解形式:
1234 | @Insert("<script>insert into t_user (user_name,sex) values "+ "<foreach collection='list' item='c' separator=','>(#{c.user_name},#{c.sex})</foreach></script>")@Options(useGeneratedKeys = true, keyProperty = "user_id", resultType="String")List<String> insertUsers(@Param("list") List<UserInfo> users); |
注意:@Param 里和 foreach 的 collection 里都需要写成 list,其实是源码中写死了 key 为 list,否则批量插入后会报错说找不到 "user_id" 字段,而无法返回主键。
这种方式的前提是该表主键有序自增,它的原理其实就是拿到当前表中最大 ID,然后结合影响行数来返回相应数据。但这就需要固定的 insert 场景,如果是 insert ignore 这种可能和实际影响行数不同的情况,就会出现不准确的情况。
面试题 2:在微服务中你是如何实现不同服务间 session 共享的?
在微服务中,一个完整的项目被拆分成多个不相同的独立的服务,各个服务独立部署在不同的服务器上,各自的 session 被从物理空间上隔离开了,但是经常,我们需要在不同微服务之间共享 session。
常见的方案就是 Spring Session + Redis 来实现 session 共享。将所有微服务的 session 统一保存在 Redis 上,当各个微服务对 session 有相关的读写操作时,都去操作 Redis 上的 session。这样就实现了 session 共享,Spring Session 基于 Spring 中的代理过滤器实现,使得 session 的同步操作对开发人员而言是透明的,非常简便。
同时,Spring Session 已经集成了 redis,可以很方便的将 session 存到 redis 中从而实现单点登陆 / 登出的效果,但是从微服务的角度来说,为了降低系统间的耦合度,一般会单独建一个 Redis 服务来搞 session 共享。
1、pom 文件中引入以下包
12345678910 | <!–spring boot 与 redis 应用基本环境配置 –><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId></dependency><!–spring session 与 redis 应用基本环境配置 –><dependency> <groupId>org.springframework.session</groupId> <artifactId>spring-session-data-redis</artifactId></dependency> |
2、application.properties 配置好 redis
123456789 | spring.redis.database = 0spring.redis.host = 192.168.xx.xxspring.redis.port = 6379spring.redis.password = testspring.redis.pool.max-active = 200spring.redis.pool.max-wait = -1spring.redis.pool.max-idle = 10spring.redis.pool.min-idle = 0spring.redis.pool.timeout = 1000 |
在需要共享 session 的服务的启动类上,加上注解即可
123456789 | @EnableRedisHttpSession@SpringBootApplication(exclude= {DataSourceAutoConfiguration.class})publicclassPhoneApplication {publicstaticvoidmain(String[] args) {SpringApplication.run(PhoneApplication.class, args); } } |
面试题 3:你了解分库分表么?分库分表一般出现在哪些场景下?
分库:由单个数据库实例拆分成多个数据库实例,将数据分布到多个数据库实例中。
分表:由单张表拆分成多张表,将数据划分到多张表内。
随着业务数据量和网站 QPS 日益增高,对数据库压力也越来越大,单机版数据库很快会到达存储和并发瓶颈,就需要做数据库性能方面的优化,分库分表采取的是分而治之的策略,分库目的是减轻单台 MySQL 实例存储压力及可扩展性,而分表是解决单张表数据过大以后查询的瓶颈问题,坦白说,这些问题也是所有关系型数据库的“硬伤”。
常用策略包括:垂直分表、水平分表、垂直分库、水平分库。
一、朴实无华的 – 分表
1、垂直分表
垂直分表,或者叫竖着切表,是不是感受到该策略是以字段为依据的!主要按照字段的活跃性、字段长度,将表中字段拆分到不同的表(主表和扩展表)中。
特点:
- 每个表的结构都不一样;
- 每个表的数据也不一样;
- 有一个关联字段,一般是主键或外键,用于关联兄弟表数据;
- 所有兄弟表的并集是该表的全量数据;
场景:
- 有几个字段属于热点字段,更新频率很高,要把这些字段单独切到一张表里,不然 innodb 行锁很恶心的,锁死你呀~~ 如用户表里的余额字段?不,我的余额就很稳定,一直是 0。。
- 有大字段,如 text,存储压力很大,毕竟 innodb 数据和索引是同一个文件;同时,我又喜欢用 SELECT *,你懂得,这磁盘 IO 消耗的,跟玩儿似的,谁都扛不住的。
- 有明显的业务区分,或表结构设计时字段冗余;有些小伙伴看到第一点时,就发现陈哈哈是个菜鸡,用户表怎么会有余额字段?明显有问题啊!赶紧先到评论区喷陈哈哈一波~~ 然后笑嘻嘻地发现原来是个小尾巴,真不要脸是吧。。是的,因此不同业务我们要把具体字段拆开,这样才有利于业务后续扩展哦。
2、水平分表
水平分表,也叫“横着切”。。以行数据为依据进行切分,一般按照某列的内容进行切分。
如手机号表,我们可以通过前两位或前三位进行切分,如 131、132、133 → phone_131、phone_132、phone_133,手机号有 11 位(100 亿),量大是很正常的事儿,这年头谁家老头老太太每个手机呢是吧。这样切就把一张大表切成了好几十张小表,数据量不就下来了。有同学就问了那我怎么知道我这手机号查哪个表呢?一看你就没认真看前两行标红的点,为啥标红嘞?比如我查 13100001111,那我截取前三位,动态拼接到查询的表名上,就行了。
特点:
- 每个表的结构都一样;
- 每个表的数据都不一样,没有交集;
- 所有表的并集是该表的全量数据;
场景:单表的数据量过大或增长速度很快,已经影响或即将会影响 SQL 查询效率,加重了 CPU 负担,提前到达瓶颈。记得水平分表越早越好,别问我为什么。。
二、花里胡哨的 – 分库
需要你注意的是,传统的分库和我们熟悉的集群、主从复制可不是一个事儿;多节点集群是将一个库复制成 N 个库,从而通过读写分离实现多个 MySQL 服务的负载均衡,实际是围绕一个库来搞的,这个库称为 Master 主库。而分库就不同了,分库是将这个主库一分为 N,比如一分为二,然后针对这两个主库,再配置 2N 个从库节点。
3、垂直分库
纵向切库,太经典的切分方式,基于表进行切分,通常是把新的业务模块或集成公共模块拆分出去,比如我们最熟悉的单点登录、鉴权模块。熟悉的味道,记得有一次我把一些没用的表切到一个性能很好的服务器中,这服务器我专门用来学习,后来也不知被哪个狗腿子告密了~ 我 ** 你个 **,有种站出来,你个 ** 东西。
特点:
- 每个库的表都不一样;
- 表不一样,数据就更不一样了~ 没有任何交集;
- 每个库相对独立,模块化
场景:可以抽象出单独的业务模块时,可以抽象出公共区时(如字典、公共时间、公共配置等),或者想有一台属于自己的服务器时?
4、水平分库
以行数据为依据,将一个库中的数据拆分到多个库中。大型分表体验一下?坦白说这种策略并不实用,因为会对后台开发很不友好,有很多坑,不建议采用,理解即可。
特点:
- 每个库的结构都一样;
- 每个库的数据都不一样,没有交集;
- 所有库的并集是全量数据;
场景:系统绝对并发量上来了,CPU 内存压力大。分表难以根本上解决量的问题,并且还没有明显的业务归属来垂直分库,主库磁盘接近饱和。
其实,在实际工作中,我们在选择分库分表策略前,想到的应该是从缓存、读写分离、SQL 优化等方面,因为这些能够更直接、代价更小的解决问题。要记住动表就是动根本,你永远不知道这张表后面会连带多少历史遗留问题,如果是个很大型的项目,遇到些问题你就跟经理提议要分库分表,小心被呼死~
小结
今天我们复习了面试中常问的三个实战问题,你做到心中有数了么?
由于篇幅原因,今天就暂时展示到这里,对面试感兴趣且需要的朋友点赞 【点击此处】 即可免费获取哦~!!
原文链接:https://www.zhihu.com/question/312296981