场景题目记录
场景题
- CPU 100% 问题怎么排查
- 为何mysql要分库分表
- 分库分表的常见方式
- QPS过大优化措施
- redis内存淘汰策略
- redis过期删除策略
- 接口请求变慢定位思路
- binlog、redolog、undolog
- MVCC
- jvm调优
CPU 100% 问题怎么排查
cpu排查经验
为何mysql要分库分表
- 数据量过大导致的性能问题
- 高并发下的数据库压力
- 水平扩展需求突破单机限制
分库分表的常见方式
- 水平分表:按规则(如哈希、范围)将数据拆分到多个表中。每个表字段相同
- 垂直分表:按业务模块拆分数据库(渠道、用户)、按字段拆分表(如将大字段或不常用字段单独存储),每个表字段不同
- 数据量超过1000万可考虑分库
QPS过大优化措施
- 缓存层
热点数据缓存、 缓存穿透 / 击穿 / 雪崩处理 - 数据库层
索引优化、读写分离、分库分表 - 代码业务层
缓存序列化结果,避免重复操作 - 监控与压测
通过 JMeter模拟高并发场景,找出系统短板
redis内存淘汰策略
- LRU:淘汰最久未被访问的数据
- TTL:从设置过期时间的key中随机淘汰
redis过期删除策略
- 惰性删除:当客户端请求一个键时,Redis 先检查该键是否过期。若已过期,删除该键并返回 nil;若未过期,正常返回值
- 定期删除:随机从数据库中选择 20 个键,检查是否过期。删除其中所有过期的键。若过期键的比例超过 25%,重复步骤 ,直到比例低于 25% 或执行时间超过阈值(默认 25ms)
接口请求变慢定位思路
- 检查代码避免出现循环调用外部接口和循环调用数据库接口,检查 InputStream、Connection 等资源是否正确关闭
- redis mysql慢查询相关
binlog、redolog、undolog
- binlog:MySQL 主从复制依赖 binlog,主库将写操作记录到 binlog,从库读取并重放这些日志,实现数据同步
- redolog(重做日志):当数据库崩溃或重启时,通过 redo log 恢复未写入磁盘的数据页,确保已提交的事务不会丢失。
- undolog:当事务需要回滚时,通过 undo log 反向应用修改(如将 INSERT 变为 DELETE)
MVCC
- MVCC(Multi-Version Concurrency Control,多版本并发控制)是一种数据库并发控制技术
- 实现方式主要有乐观锁和悲观锁
jvm调优
- jvm首先在工作中很少去操作,原因有下:首先当JVM出现了GC的压力时,首先要从代码层面去优化,其次调整JVM会面临不可维护(调整完下一个人看不懂),不可扩展(不同的场景参数会失效)
- jvm调优主要是GC参数的调优,可以回答GC相关的问题
- 以G1回收器为例:共分为四个区域(Eden、Surrivor、Old、大对象区)
- 启动JVM时候可以使用
-XX:+UserG1GC
,指定回收器,目前jdk版本默认是G1 - 固定堆大小:
-Xms 2048M -XMx 2048M
(参数表示堆内存的上下限,一般设置为相同的值) 固定堆的大小可以避免堆的扩缩容,堆内存的扩缩容会影响GC的时间,带来更多的停顿时间
- 设置region的大小。堆被划分为不同的region,设置region的大小就可以控制region的个数,个数太多遍历的时间会更久
-XX:G1GHeapRegionSize=4M
- 设置GC最大停顿时间,对于延迟比较敏感的接口可以适当减小这个时间
-XX:MaxGCPauseMillis=100ms