Java后端工程师学习之路

以下是学习资料：
MySQL基础原理:MySQL的学习，整体是follow极客时间的《MySQL实战45讲》，大家可以去订阅，建议还是去看原版，有很多例子讲解，支持正版，作者非常良心（但是部分内容是DBA需要学习的，对于专注于业务开发的我，目前只总结了部分开发需要的了解的，深度也不足）。

ElasticSearch学习:现在常用的Google、Baidu，都是非常强大的搜索工具，那么是如何搜索的呢？肯定不能是在Mysql这种传统的关系型数据库。在全文搜索中，关系型数据库完全派不上用场，因此就有了ES，正常的数据库使用的是正排索引，而ES使用的是倒排索引。这一点很重要，是进行高效的全文搜索的基础。

MYSQL系列–IN到底走不走索引

ThreadLocal源码学习:ThreadLocal是开发中非常实用的工具，比如用户个人信息等数据可以存储在ThreadLocal中，今天来解析一下源码，至于Java虚拟机层面，ThreadLocal数据的实际内存存储等待后续学习更新。

Logback实用技巧:Logback的详细介绍在# Java日志框架：logback详解 中已经有了，这边就不再重复造轮子。就讲一下日常使用中，如何更好的使用log。

来了一个需求，是需要捞线上数据按某些规则统计下有多少脏数据。很简单嘛，写个脚本任务，打点log看看就行了，快速写完代码完事，但是查log的时候发现，因为数据量很大，打印了太多的日志，而公司的任务平台只保留100M左右的日志文件，导致打印的都是Mybatis的SQL日志，后面的正经日志都被截断了。处理方案大致就是两种，分别从Mybatis和Logback入手。

作者：lbh1995
链接：https://juejin.cn/post/7076826377034563621
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Redis学习总结:网络上有很多相关blog对Redis进行非常全面的介绍，本文档只记录一些个人的思考总结。

Q1：主从复制中，为什么不是RDB全量复制，AOF增量复制，而是维护了一个新的环结构数据？
A1:RDB和AOF是备份手段，第一次同步的时候，全量复制使用RDB没有问题，因为这是一个初始化操作，并且这时候「从节点」其实是未就绪的，不需要“迎客”。当第一次同步完后，「从节点」需要相应读操作了；首先这时对节点的性能要求很高；其次AOF是需要写数据到文件中较慢，没有直接使用在内存中的repl_back_buffer快，因此增量复制不用AOF同步。
Q2：集群模式中，故障恢复怎么又是slave节点又是其余主节点的，不能直接由其余主节点或者全都由故障主节点的slave节点完成吗？
A2：先描述一下整体流程：
1. 集群其余「主节点」判断某个「主节点」故障，标记下线
2. 故障「主节点」的「从节点」发现「主节点」下线，进入主从替换流程，向集群广播消息，进行拉票
3. 其余「主节点」进行投票，获得票数过半的故障「主节点」的「从节点」晋升，若没过半则反复进行拉票-投票
4. 选出新「主节点」，接手原「主节点」资产
其实如果只由「主节点」的「从节点」们独立进行选举也能做到，就类似哨兵模式那样，但是问题就在于，“集群模式是master节点们的集群模式”，如果光由「从节点」们过家家，是无法保证新「主节点」在集群中的通信顺畅的，因此应该“从集群模式角度进行主从切换”，而不是“从主从模式的角度进行主从切换”。

MQ理论知识归纳:参考了不少文章资料，沉淀一份个人学习总结，主要介绍下RocketMQ和Kafka的相关特性。

RocketMQ与Kafka的异同
共同点: (1) 一条消息会被订阅了同一个Topic的ConsumerGroup都消费一次，但是只会由同一个ConsumerGroup钟的一个Consumer消费；一个Consumer可以消费多个Queue或者Partition；一个Queue或者Partition只能被一个Consumer消费。(2) Queue和Partition在不同Broker上都有副本，并且都有master/leader节点，从节点的数据都由主节点同步。
不同点: (1) 对于commitlog/log文件，在一个Broker上RocketMQ的全部Topic都存到同一个文件中，而kafka不同Topic则分文件存储。(2) RocketMQ这么设计主要是为了能够进行顺序写，提高IO效率，时延更低。但是consumequeue文件还是分开存储的，以consumequeue文件的顺序和定长保证消息读取的效率，以及允许commitlog可无序且不定长存储。
Kafka的分文件存储后，局部是顺序写，全局是随机写，时延会比RocketMQ要高，但是易扩展，整体的吞吐量会更大。(3) kafka的集群由Zookeeper管理，可以自动进行主从切换，RocketMQ由NameServer管理，不能进行主从切换。
总结就是，RocketMQ更适合在线场景（订单系统），Kafka更适合离线场景（log收集）