一、沉默王二-JVM
1、栈虚拟机和寄存器虚拟机
1.1 栈与寄存器
寄存器（Register）是中央处理器（CPU）内用来暂存指令、数据和地址的存储器，也是 CPU 中读写最快的存储器。
从硬件层面来说，栈位于内存当中，而寄存器位于 CPU 当中，这也是为什么，我们通常会说，基于寄存器架构的虚拟机会比基于栈的虚拟机快的原因。
1.2 基于栈的虚拟机
HotSpot VM 是基于栈的一种虚拟机，当 Java 程序运行时，HotSpot VM 加载编译后的字节码文件（也就是.class 文件），其解释器或JIT编译器会读取文件中的字节码指令，将它们解释（或编译）为机器码。
方法调用和执行过程中的数据（如局部变量和中间结果）会存储在栈（操作数栈）中，字节码指令操作这些数据，然后执行程序逻辑。
main 方法被执行的时候，JVM 会创建一个栈帧（Stack Frame），通过存储局部变量表、操作数栈、动态链接、方法出口等信息来支撑和完成方法的执行，栈帧就是虚拟机栈中的子单位。
栈帧本身也是一种栈结构，用于支持虚拟机进行方法调用和方法执行，遵循 LIFO 的原则，每个栈帧都包含了一个方法的运行信息，每个方法从调用到执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈和出栈的过程。
虚拟机栈是线程私有的，每个线程都有自己的 Java 虚拟机栈。方法调用时都会创建一个新的栈帧，该栈帧被推入虚拟机栈，成为当前活动栈帧。
- 入栈：方法调用时，虚拟机栈会为这个方法分配一个栈帧，这个栈帧被压入虚拟机栈，成为当前的活动栈帧。PC 寄存器指向当前栈帧的指令，执行方法的指令序列从该地址开始。
- 出栈：方法执行完成后，对应的栈帧会被移除，控制权回到前一个栈帧，前一个栈帧中的返回值成为当前活动栈帧的一个操作数，继续执行。
其中的操作数栈（Operand Stack）也是一种栈结构，用于保存方法执行时的中间结果、参数和返回值。当一个方法刚刚开始执行的时候，这个方法的操作数栈是空的。
在方法执行的过程中，操作数栈被用于执行各种字节码指令。例如，将两个数字相加的指令会从操作数栈中弹出两个数字，将它们相加，然后将结果压入操作数栈中。
另外，操作数栈的内容是临时的，它的生命周期和方法的生命周期是一样的，当方法执行结束后，操作数栈也会被销毁。
1.3 基于寄存器的虚拟机
那除了有基于栈的虚拟机实现，当然也有基于寄存器的虚拟机实现，比如 LuaVM，负责执行 Lua 语言，一门轻量级的脚本语言。
基于寄存器的虚拟机是一种计算机程序的执行环境，它使用寄存器来存储变量的值，而不是使用堆栈。在基于堆栈的虚拟机中，操作数通常存储在堆栈上，指令通过弹出和推入堆栈来操作这些操作数。相比之下，基于寄存器的虚拟机直接在寄存器之间进行操作，这通常可以提供更高效的性能。 以下是基于寄存器的虚拟机的一些关键特点：
- 寄存器使用：每个变量都存储在一个寄存器中，而不是堆栈上。这减少了内存访问的次数，因为寄存器通常比主存储器快得多。
- 指令格式：指令通常包含操作码和指定源寄存器和目标寄存器的字段。例如，一个加法指令可能会指定两个源寄存器，其内容将被相加，并将结果存储在一个目标寄存器中。
- 寄存器分配：编译器或虚拟机需要决定哪些变量应该存储在哪个寄存器中。这个过程称为寄存器分配，它可以是一个复杂的优化问题，尤其是在寄存器数量有限的情况下。
- 性能：由于减少了内存访问和优化的寄存器使用，基于寄存器的虚拟机通常比基于堆栈的虚拟机性能更好，尤其是在执行大量计算密集型任务时。
- 代码密度：基于寄存器的指令可能比基于堆栈的指令更紧凑，因为它们不需要显式地推入和弹出堆栈。
- 复杂性：基于寄存器的虚拟机通常比基于堆栈的虚拟机复杂，因为它们需要处理寄存器分配和优化问题。
基于寄存器的虚拟机在性能敏感的应用中非常流行，例如，Java HotSpot VM就使用了一种混合模式，其中包含基于寄存器的编译策略以提高性能。
1.4 总结
基于栈的优点是可移植性更好、指令更短、实现起来简单，但不能随机访问栈中的元素，完成相同功能所需要的指令数也比寄存器的要多，需要频繁的入栈和出栈。
基于寄存器的优点是速度快，有利于程序运行速度的优化，但操作数需要显式指定，指令也比较长。
二、小林-图解系统-网络系统-一致性哈希
1、如何分配请求？
大多数网站背后肯定不是只有一台服务器提供服务，因为单机的并发量和数据量都是有限的，所以都会用多台服务器构成集群来对外提供服务。
但是问题来了，现在有那么多个节点（后面统称服务器为节点，因为少一个字），要如何分配客户端的请求呢？
其实这个问题就是「负载均衡问题」。解决负载均衡问题的算法很多，不同的负载均衡算法，对应的就是不同的分配策略，适应的业务场景也不同。
最简单的方式，引入一个中间的负载均衡层，让它将外界的请求「轮流」的转发给内部的集群。比如集群有 3 个节点，外界请求有 3 个，那么每个节点都会处理 1 个请求，达到了分配请求的目的。
考虑到每个节点的硬件配置有所区别，我们可以引入权重值，将硬件配置更好的节点的权重值设高，然后根据各个节点的权重值，按照一定比重分配在不同的节点上，让硬件配置更好的节点承担更多的请求，这种算法叫做加权轮询。
加权轮询算法使用场景是建立在每个节点存储的数据都是相同的前提。所以，每次读数据的请求，访问任意一个节点都能得到结果。
但是，加权轮询算法是无法应对「分布式系统（数据分片的系统）」的，因为分布式系统中，每个节点存储的数据是不同的。
当我们想提高系统的容量，就会将数据水平切分到不同的节点来存储，也就是将数据分布到了不同的节点。比如一个分布式 KV（key-valu） 缓存系统，某个 key 应该到哪个或者哪些节点上获得，应该是确定的，不是说任意访问一个节点都可以得到缓存结果的。
因此，我们要想一个能应对分布式系统的负载均衡算法。
2、使用哈希算法有什么问题？
有的同学可能很快就想到了：哈希算法。因为对同一个关键字进行哈希计算，每次计算都是相同的值，这样就可以将某个 key 确定到一个节点了，可以满足分布式系统的负载均衡需求。
哈希算法最简单的做法就是进行取模运算，比如分布式系统中有 3 个节点，基于 hash(key) % 3 公式对数据进行了映射。
如果客户端要获取指定 key 的数据，通过下面的公式可以定位节点：
hash(key) % 3
如果经过上面这个公式计算后得到的值是 0，就说明该 key 需要去第一个节点获取。
但是有一个很致命的问题，如果节点数量发生了变化，也就是在对系统做扩容或者缩容时，必须迁移改变了映射关系的数据，否则会出现查询不到数据的问题。
举个例子，假设我们有一个由 A、B、C 三个节点组成分布式 KV 缓存系统，基于计算公式 hash(key) % 3 将数据进行了映射，每个节点存储了不同的数据：
现在有 3 个查询 key 的请求，分别查询 key-01，key-02，key-03 的数据，这三个 key 分别经过 hash() 函数计算后的值为 hash( key-01) = 6、hash( key-02) = 7、hash(key-03) = 8，然后再对这些值进行取模运算。
通过这样的哈希算法，每个 key 都可以定位到对应的节点。
当 3 个节点不能满足业务需求了，这时我们增加了一个节点，节点的数量从 3 变化为 4，意味取模哈希函数中基数的变化，这样会导致大部分映射关系改变，如下图：
比如，之前的 hash(key-01) % 3 = 0，就变成了 hash(key-01) % 4 = 2，查询 key-01 数据时，寻址到了节点 C，而 key-01 的数据是存储在节点 A 上的，不是在节点 C，所以会查询不到数据。
同样的道理，如果我们对分布式系统进行缩容，比如移除一个节点，也会因为取模哈希函数中基数的变化，可能出现查询不到数据的问题。
要解决这个问题的办法，就需要我们进行迁移数据，比如节点的数量从 3 变化为 4 时，要基于新的计算公式 hash(key) % 4 ，重新对数据和节点做映射。
假设总数据条数为 M，哈希算法在面对节点数量变化时，最坏情况下所有数据都需要迁移，所以它的数据迁移规模是 O(M) ，这样数据的迁移成本太高了。
所以，我们应该要重新想一个新的算法，来避免分布式系统在扩容或者缩容时，发生过多的数据迁移。
3、使用一致性哈希算法有什么问题？
一致性哈希算法就很好地解决了分布式系统在扩容或者缩容时，发生过多的数据迁移的问题。
一致哈希算法也用了取模运算，但与哈希算法不同的是，哈希算法是对节点的数量进行取模运算，而一致哈希算法是对 2^32 进行取模运算，是一个固定的值。
我们可以把一致哈希算法是对 2^32 进行取模运算的结果值组织成一个圆环，就像钟表一样，钟表的圆可以理解成由 60 个点组成的圆，而此处我们把这个圆想象成由 2^32 个点组成的圆，这个圆环被称为哈希环，如下图：
一致性哈希要进行两步哈希：
- 第一步：对存储节点进行哈希计算，也就是对存储节点做哈希映射，比如根据节点的 IP 地址进行哈希；
- 第二步：当对数据进行存储或访问时，对数据进行哈希映射；
所以，一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上。
问题来了，对「数据」进行哈希映射得到一个结果要怎么找到存储该数据的节点呢？
答案是，映射的结果值往顺时针的方向的找到第一个节点，就是存储该数据的节点。
举个例子，有 3 个节点经过哈希计算，映射到了如下图的位置：
接着，对要查询的 key-01 进行哈希计算，确定此 key-01 映射在哈希环的位置，然后从这个位置往顺时针的方向找到第一个节点，就是存储该 key-01 数据的节点。
比如，下图中的 key-01 映射的位置，往顺时针的方向找到第一个节点就是节点 A。
所以，当需要对指定 key 的值进行读写的时候，要通过下面 2 步进行寻址：
- 首先，对 key 进行哈希计算，确定此 key 在环上的位置；
- 然后，从这个位置沿着顺时针方向走，遇到的第一节点就是存储 key 的节点。
知道了一致哈希寻址的方式，我们来看看，如果增加一个节点或者减少一个节点会发生大量的数据迁移吗？
假设节点数量从 3 增加到了 4，新的节点 D 经过哈希计算后映射到了下图中的位置：
你可以看到，key-01、key-03 都不受影响，只有 key-02 需要被迁移节点 D。
假设节点数量从 3 减少到了 2，比如将节点 A 移除：
你可以看到，key-02 和 key-03 不会受到影响，只有 key-01 需要被迁移节点 B。
因此，在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。
上面这些图中 3 个节点映射在哈希环还是比较分散的，所以看起来请求都会「均衡」到每个节点。
但是一致性哈希算法并不保证节点能够在哈希环上分布均匀，这样就会带来一个问题，会有大量的请求集中在一个节点上。
比如，下图中 3 个节点的映射位置都在哈希环的右半边：
这时候有一半以上的数据的寻址都会找节点 A，也就是访问请求主要集中的节点 A 上，这肯定不行的呀，说好的负载均衡呢，这种情况一点都不均衡。
另外，在这种节点分布不均匀的情况下，进行容灾与扩容时，哈希环上的相邻节点容易受到过大影响，容易发生雪崩式的连锁反应。
比如，上图中如果节点 A 被移除了，当节点 A 宕机后，根据一致性哈希算法的规则，其上数据应该全部迁移到相邻的节点 B 上，这样，节点 B 的数据量、访问量都会迅速增加很多倍，一旦新增的压力超过了节点 B 的处理能力上限，就会导致节点 B 崩溃，进而形成雪崩式的连锁反应。
所以，一致性哈希算法虽然减少了数据迁移量，但是存在节点分布不均匀的问题。
4、如何通过虚拟节点提高均衡度？
要想解决节点能在哈希环上分配不均匀的问题，就是要有大量的节点，节点数越多，哈希环上的节点分布的就越均匀。
但问题是，实际中我们没有那么多节点。所以这个时候我们就加入虚拟节点，也就是对一个真实节点做多个副本。
具体做法是，不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。
比如对每个节点分别设置 3 个虚拟节点：
- 对节点 A 加上编号来作为虚拟节点：A-01、A-02、A-03
- 对节点 B 加上编号来作为虚拟节点：B-01、B-02、B-03
- 对节点 C 加上编号来作为虚拟节点：C-01、C-02、C-03
引入虚拟节点后，原本哈希环上只有 3 个节点的情况，就会变成有 9 个虚拟节点映射到哈希环上，哈希环上的节点数量多了 3 倍。
你可以看到，节点数量多了后，节点在哈希环上的分布就相对均匀了。这时候，如果有访问请求寻址到「A-01」这个虚拟节点，接着再通过「A-01」虚拟节点找到真实节点 A，这样请求就能访问到真实节点 A 了。
上面为了方便你理解，每个真实节点仅包含 3 个虚拟节点，这样能起到的均衡效果其实很有限。而在实际的工程中，虚拟节点的数量会大很多，比如 Nginx 的一致性哈希算法，每个权重为 1 的真实节点就含有160 个虚拟节点。
另外，虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高。
比如，当某个节点被移除时，对应该节点的多个虚拟节点均会移除，而这些虚拟节点按顺时针方向的下一个虚拟节点，可能会对应不同的真实节点，即这些不同的真实节点共同分担了节点变化导致的压力。
而且，有了虚拟节点后，还可以为硬件配置更好的节点增加权重，比如对权重更高的节点增加更多的虚拟机节点即可。
因此，带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。
4、总结
不同的负载均衡算法适用的业务场景也不同的。
轮询这类的策略只能适用与每个节点的数据都是相同的场景，访问任意节点都能请求到数据。但是不适用分布式系统，因为分布式系统意味着数据水平切分到了不同的节点上，访问数据的时候，一定要寻址存储该数据的节点。
哈希算法虽然能建立数据和节点的映射关系，但是每次在节点数量发生变化的时候，最坏情况下所有数据都需要迁移，这样太麻烦了，所以不适用节点数量变化的场景。
为了减少迁移的数据量，就出现了一致性哈希算法。
一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。
但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应。
为了解决一致性哈希算法不能够均匀的分布节点的问题，就需要引入虚拟节点，对一个真实节点做多个副本。不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。
引入虚拟节点后，可以会提高节点的均衡度，还会提高系统的稳定性。所以，带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。
