个人专属
# 待总结知识点
1、UBT 的整个流程以及难点
2、上云的整个流程以及难点
集群类型共有四种：普通集群(单机房缓存)、本机房缓存、XPipe单向同步、XPipe双向同步。
XPipe单向同步：部署机房只能选一个，且必须是上海的机房，此机房为Master节点所在机房。备机房可选择多个，支持AWS公有云。备机房数据从部署机房同步而来。
3、性能优化、JVM参数调优、OOM问题解决、CPU飙升、慢SQL优化、Redis 连接超时问题解决、Kafka数据同步、UBT埋点、上云 案例
# 一、Java/JVM/Dump
# 1、GC的种类及其特性
# 2、什么是Minor GC，Major GC 和Full GC？分别发生的时机？
# 3、如何抓Dump 步骤（登录服务器，工具）
# 4、Dump分析工具的使用
# 5、dump分析哪些方面
# 6、JVM参数及涵义。如何查看线上JVM各参数值？
【参考答案】：链接
# 7、非阻塞编程
# 8、NIO
【参考答案】：链接
# 10、Reactive Programming
同11
# 11、Java 9 Reactive Streams都有哪些标准接口
【参考答案】：链接
# 12、用一句话描述任意一个你了解的Reactive Streams的实现，比如Spring Reactor，RxJava，Akka Streams
同13
# 13、基本的Stream operators，比如onNext, onError, onComplete, onCancel, map, flatMap的使用场景。
【参考答案】：链接
# 14、Lock vs lock-free - 概念理解
【参考答案】：链接
# 15、Mutex/Lock
# 16、Semaphore
【参考答案】：链接
# 17、Signal
# 18、Atomic
# 19、while 循环条件
【1】最大值太大，导致出现假死循环的场景。CPU增大，甚至会出现 OOM
【2】死锁（并发场景）
【3】while 循环内对判断条件里的变量进行了二次操作，导致死循环。
【4】while 条件使用函数表达式（增加系统编译，运行成本）
【5】变量没有保证原子性（并发场景）
【6】CAS中的while变量存在 ABA问题（并发场景）
# 二、监控&报警设置
# 1、Hickwall、Cat、BigEyes show小组面板
# 2、系统核心指标及异常分析方法：
【1】CPU Util、Load、Thread等（threaddump、arthas）
【2】Memory、Off-heap memory、 GC等（top、memory tracking）
【3】网络(netstat)
【4】性能分析（arthas）
带着问题通过上述指标来诊断
# 三、Linux基础知识
# 1、SSH - 怎么登录到机器
# 2、Linux Commands
【1】cpu利用率
【2】内存使用情况
【3】磁盘IO
【4】日志
【5】网络状况
# 四、Production Access
# 1、WebInfo、PAAS、Group
# 2、QConfig灰度
# 3、灰度流量切换
# 4、发布灰度
# 5、重启
拉入拉出
# 五、数据库
# 1、如果一个linux上的Mysql数据库系统突然变慢，如何查找原因
# 2、携程DBA不建议使用读写分离的架构，而更多的使用主备架构。如何看待这个问题?
# 3、与OPSDBA相比开发DBA和具体项目结合更紧密，对业务更了解对数据库性能优化的作用是什么？
# 4、MySQL数据库CPU飙升到100%怎么处理？
【参考答案】：链接
# 5、MySQL中InnoDB引擎的行锁是通过加在什么上实现的？
【参考答案】：链接
# 6、有种说法，MySQL单表不能超过5000万，怎么看这个问题？如果需要拆分是分表还是分库？
曾经在中国互联网技术圈广为流传着这么一个说法：MySQL 单表数据量大于 2000 万行 32G，性能会明显下降。事实上，这个传闻据说最早起源于百度。具体情况大概是这样的，当年的 DBA 测试 MySQL性能时发现，当单表的量在 2000 万行量级的时候，SQL 操作的性能急剧下降，因此，结论由此而来。然后又据说百度的工程师流动到业界的其它公司，也带去了这个信息，所以，就在业界流传开这么一个说法。
再后来，阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。对此，有阿里的黄金铁律支撑，所以，很多人设计大数据存储时，多会以此为标准，进行分表操作。
那么，你觉得这个数值多少才合适呢？为什么不是 300 万行，或者是 800 万行，而是 500 万行？也许你会说这个可能就是阿里的最佳实战的数值吧？那么，问题又来了，这个数值是如何评估出来的呢？稍等片刻，请你小小思考一会儿。
事实上，这个数值和实际记录的条数无关，而与 MySQL 的配置以及机器的硬件有关。因为，MySQL 为了提高性能，会将表的索引装载到内存中。InnoDB buffer size 足够的情况下，其能完成全加载进内存，查询不会有问题。但是，当单表数据库到达某个量级的上限时，导致内存无法存储其索引，使得之后的 SQL 查询会产生磁盘 IO，从而导致性能下降。当然，这个还有具体的表结构的设计有关，最终导致的问题都是内存限制。这里，增加硬件配置，可能会带来立竿见影的性能提升哈。
那么，我对于分库分表的观点是，需要结合实际需求，不宜过度设计，在项目一开始不采用分库与分表设计，而是随着业务的增长，在无法继续优化的情况下，再考虑分库与分表提高系统的性能。
# 六、PMO
# 1、项目具有哪些特性
# 2、项目管理五大过程组分别是什么
# 3、项目质量受哪些方面制约
# 4、基于问题3，各维度优先顺序是怎样的
# 七、SM
# 1、在敏捷开发的过程中， 是由哪个角色完成工作任务的分配？
# 2、Scrum的三大支柱是什么？在团队工作中如何体现这三大支柱？
# 3、Scrum每日站会的主要目的是什么？
# 4、优化交付周期的途径有哪些？
# 5、如何设计团队的可视化看板？
# 八、必须会的知识
# 特殊时间配置检查
在日期格式化时，大写的YYYY和小写的yyyy有什么区别，大写的HH和小写的hh有什么区别？ yyyy 表示当天所在的年，而大写的 YYYY 代表的是当天所在的周属于的年份，一周从周日开始，周六结束，只要本周跨年，返回的 YYYY 就是下一年 表示月份是大写的 M；表示分钟则是小写的 m； 24 小时制的是大写的 H； 12 小时制的则是小写的 h; 常见错误格式：YYYY-MM-dd HH:mm:ss；正确格式：yyyy-MM-dd HH:mm:ss
# 数据清理
第一部分是由于系统技术改造和需求迭代中动态规则所产生的配置项
第二部分是业务处理流程中产生的持久化过程记录数据
# 全链路性能测试
# 缓存穿透
缓存初始化和填充预热
Redis Key
容量预估
避免数据膨胀
更优雅的代码
超时设置与处理
失败重试
Java异常
服务降级
日志处理
大数据量处理
篡改缓存
# 数据变更与空值处理
1、依赖的服务正常情况下不会返回空值，但是当依赖的服务出现问题时，就会返回空值，这种情况往往时容易忽略的，所以要做好校验，或者使用历史数据，或者使用默认数据。因为为空的话，可能业务就执行不下去了，给客户的反馈也不好。需要根据依赖服务的重要性来决定。有时候可能也必须停止使用。
多线程和死循环
# 数据库发布
1.为什么在MySQL数据库中不建议使用text/blob等数据类型？对于大字段的数据存储有什么好的方案？
Mysql的优化准则里面，多次提到尽量避免使用Blob/Text等字段，会造成数据库的大量分页，占用空间，之前一直不以为然，果然还是尝到苦头了。
性能很差，排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。
TEXT或BLOB类型只能使用前缀索引，MySQL对索引字段长度是有限制的。
2.如果新增DB表中字段，导致已有查询SQL报"Ambiguous column name"错误，是什么原因，如何避免这样的报错？
故障快速恢复的通用操作
问题排查
# 待整理知识点
一、性能优化
# 二、JVM参数调优
-XX:-OmitStackTraceInFastThrow 关闭“省略异常栈信息从而快速抛出”。默认打开，必须关闭，否则会导致异常信息打印不全。例如：只有java.lang.NullPointerException信息，没有完整的具体信息，展示什么地方为空的堆栈信息。
# 三、OOM问题解决
# 四、CPU飙升
# 五、慢SQL优化
# 六、数据库分库分表
ShardingSphere提供了如哈希取模、范围划分、标签分类、时间范围以及复合分片等多种切分策略。
挑战性： 尽管分片解决了性能，可用性以及单节点备份和恢复等问题，但其分布式体系结构还带来了一些新问题。一个问题是，面对如此分散的数据库和表时，应用程序开发工程师和数据库管理员的操作变得格外费力。他们应该确切地知道从哪个数据库表中获取数据。另一个挑战是，在单节点数据库中正确运行的 SQL在分片数据库中可能不合适。分片后表名称的更改，或由分页，排序依据或聚合分组依据等操作引起的不当行为就是这种情况。
跨数据库事务处理也是分布式数据库需要处理的棘手事情。当单表数据量减少时，合理使用分片表还可以充分利用本地事务。通过明智地使用同一数据库中的不同表，可以避免分布式事务带来的麻烦。当无法避免跨数据库事务时，某些企业仍然需要保持事务一致。互联网巨头尚未大规模采用基于XA的分布式事务，因为它们无法确保其在高并发情况下的性能。它们通常用最终一致的软状态代替强一致的事务。
1、IO瓶颈
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。
第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。
2、CPU瓶颈
第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。
第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。
# 七、Redis 连接超时问题解决
# 八、Kafka数据同步
# CompletableFuture和响应式编程的区别是什么呢
【参考答案】：链接