一. 问题背景
在公司实习，了解到并学到很多新方向的东西，这里做一下超级简单的整理，后期再深入学习
二. 整理
-
swagger、YAPI，两者的作用相似，前后端分离开发使用的对接工具
-
前后联调的过程中，先定位问题，再动手改代码。修改原方法的时候要兼容其他调用者，否则另写一个方法来实现
-
项目开发的过程中，要定好时间以及目标。每个阶段都定一个目标，以此推进项目进度
-
优先处理500错误，优先查看服务器日志的报错信息（因此开发过程中需要适当加上日志打印）。一般是sql语句多/少了逗号，或者少了个字段，或者resultType和resultMap使用不合理
-
前后联调定位问题，直接按F12查看发的请求，根据请求去找对应的controller
-
前后联调时，不可一味相信前端开发者的话，不合理的东西可以驳回，要相信计算机，利用一切计算机手段验证事实
-
定边界版本，怎么迭代，先上普通版本后迭代还是做完美再发布
-
对各种类型的数字，可以使用Number类型去兼容
-
OFS媒体中心，阿里OSS
-
OAUTH2.0， JWT
-
K8S
-
脱敏
-
HTTPS
-
token、session、cookie
-
referer防盗链
-
MD5
-
Websocket：服务器逆推，能干socket的事情，但重型，低成本
-
不要返回null给安卓，安卓遇到null会有大问题，原因是反序列化时类型找不到
-
面试一般问：设计流程的思路、对场景的问题
-
需要有求知欲，工作中学习，学习中工作
-
传统IT公司问解决方案、设计思想
-
Java设计模式
-
《大型网站技术架构：核心原理与案例分析》阿里写的
-
中间件，广度+深度+思维
-
问场景问题，要往前想有什么风险，往后想会怎么样
-
快乐学习：广度->深度（适合传统IT行业）
-
倍速看视频->官方文档
-
高并发解决方案：从软件、硬件考虑。前期从sql语句拆分，比如不超过3张多表关联。一步步扩展、微服务（侧重业务解耦）、熔断等技术
-
在性能、快速开发以及后期维护之间权衡
-
测试用例，测试覆盖率80%
-
postman发请求，请求参数等的使用
-
有任何问题，都优先看服务器日志，开发过程中适当加日志打印
-
spring事务机制
-
通过代码层面了解业务
-
带着目的学习
-
nginx算法
-
@RequestBody接收复杂结构体
-
sonar-q插件、find-bug插件
-
工作流引擎
-
spring cloud 和 spring cloud alibaba
-
毕设可以做搜索引擎、分布式运算、语言处理、AI象棋、IM即时通讯
-
HttpClient、OkHttp
-
面试题：从URL输入地址后，浏览器发生了什么？
-
加密方式
-
通过CDN、负载均衡，使得前端加速
-
ThreadLocal、epoll、poll
-
拆分几个简单的sql执行，降并发提性能，占用db的资源会更少
-
文件上传：（1）本地缓存（2）开一个临时表，事务结束后再提交
-
尽量不去银行外包
-
mysql8.0对json做了优化
-
BusiCode：与业务有关的状态；Code：与业务无关的状态；鉴权可以直接在网关过滤，不符合的全都不给进入网关
-
mq、es
-
学技术->了解是什么，突破从0到1-> 干了什么->配置-> 整合springboot->事务->高可用->英文文档->部署小集群->kafka、k8s
-
阿里云按量收费挺可以的
-
可以看看Gson、gava等项目的代码
-
伙伴云
-
jmeter
-
json串转换
-
restemplate、feign、springboot
-
开发过程中不要被卡在某个地方，假设那个地方已经完成，然后继续开发
-
乐观锁、并发更新、版本号更新
-
数据迁移、分表分库、主键id雪花算法、UUID
-
一个主任务可以派生n个子任务
-
报错“data too long”，只需修改表字段的长度
-
做多几个字段用来备份，不建议这么做，后期维护会很难
-
设计了一个manager层，rest->service->manager->mapper
-
备份机制
-
如何改写nacos
-
etl工具。数据挖掘的过程
-
MapReduce
-
报文体的contentType会影响结果
-
poll、epoll
-
vmware网络搭建NAT、桥接，集群搭建
-
yapi的mock
-
TCP的反向代理与HTTP有什么不同
-
分布式session
-
逻辑删除
-
数据防篡改
-
事务机制
-
CAP准则
-
网络编程
-
定时任务
-
redis底层使用netty。缓存是：先update数据库再update缓存。缓存雪崩、击穿、穿透（用布隆过滤器解决）。redis持久化服务会定时写数据造成阻塞。redis内存溢出机制？redis假死？redis高可用？用redis5.0.4或者5.0.6版本，比较稳定
-
并发不高的情况下，可维护性优于性能优化
-
maven私有库
-
FastDFS媒体中心
-
百万级表如何更新
-
导入导出很耗时，用异步方式解决，比如异步任务中心、消息队列
-
电商模型：skuspu
-
消息队列，流量削峰，解决并发
-
BPM标准
-
若查询条件不是主键，必须用list接收
-
MQ队列：分片技术；cache；ACK确认机制
-
定义接口时，看界面需要发多少个请求
-
报表调优，查询几万条数据
-
JUC、线程池实现原理，对象头，这些都是加分项；MySQL的MVVC问题；算法；研究github项目，开源经验
-
所有子任务完成了，主任务才完成，可以使用类似CAS的方式update表字段，其实就是加上一个版本号