nekolr's blog

连接有内连接和外连接之分，而外连接又分为左外连接和右外连接，这些我们都很熟悉。提到连接就不得不提到驱动表和被驱动表的概念，因为是多表联查，肯定需要先查询一张表，然后拿着查询到的记录分别到另一张表中去匹配，这个过程中，首先查询的那张表就是驱动表，而另一张表就是被驱动表。而内连接与外连接的区别，本质就是驱动表中的记录即使在被驱动表中没有与之相匹配的记录时，我们是否仍要将其加入到最终的结果集当中。

从最简单的单表查询开始，能够更加简单直接地接触到 MySQL 中最基础的一些访问方法，结合 MySQL 的行记录、数据页以及索引结构的知识，在出现性能问题时才可以更有底气地应对。

阅读和分析 GC 日志是处理 Java 虚拟机内存问题的一项基础手段，GC 日志是一些人为定义的规则，每一种收集器的日志形式可能都不太相同，但是虚拟机的设计者为了方便用户阅读，将各个收集器的日志都维持了一定的共性。本文是日志分析的一般流程描述。

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java 虚拟机规范中对于垃圾收集器应该如何实现并没有规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都有可能不同。

在程序运行期间，可能会因为某段代码大量占用 CPU 时间而拖累整个应用的执行，能够快速定位这类热点代码的性能分析工具有很多，这里介绍的火焰图比较特殊，它可以将很多性能分析工具的采样结果以一种更加直观的方式展现出来，从而快速定位热点问题。

Paxos 算法偏向于理论，对于如何应用到工程实践上较少提及，同时 Paxos 算法较难理解且复杂性很高，目前能够真正在生产环境中独立使用的成品很少，已知的基础库，比如 Tencent 的 phxpaxos 早在 2016 年开源，并在很久之前就停止维护了。阿里的 X-Paxos 只有文章介绍，并不开源。

共识算法的主要目的是屏蔽掉故障节点产生的噪音，从而让系统能够正常运行下去，常用于选举和状态机复制（state machine replication）。在保证 liveness 的同时，对 agreement 条件放宽了要求，它接受不一致是常态的事实，既然无法知道某些节点是 crash 还是消息延迟，那么只关心能够正确响应的节点，只要它们能够表决过半即可。过半表决意味着虽然没有达成完全一致，但是投票结果已经被过半的节点所继承，这样任何两个 quorum 一定会存在交集（比如 A、B、C 三个节点，两个 quorum 比如 AB 和 BC 一定会有交集 B），所以它们最终一定能通过消息交互而达成一致。

主要简单概括一下分布式系统中的网络和故障模型、共识问题、拜占庭将军问题、FLP 定理等等。

对于一致性模型的研究从共享内存的多核并行计算就开始了，然后又顺理成章的推广到了基于网络通信的多节点协同系统中。

分布式系统中，不同节点的物理时钟很难实现完全一致，即使我们给所有节点一个相同的起始时间，在经过一段时间后，节点之间的物理时钟也有很大可能会出现不一致。导致这种问题的根本原因是由于计算机的时钟是通过晶体振荡器实现的。晶体振荡器在通电后，内部的石英晶体会产生谐振，这种震荡的频率是稳定和精确的，比如为 10 MHz，处理器可以根据晶振的波形（震荡的次数）来计算时间。但是由于晶振的频率会受到温度变化的影响，因此机器工作时的温度变化会导致时钟过快或过慢，从而影响时钟的准确性。