当前位置:首页 > 问答 > 正文

多加点Redis虚拟节点,服务器才不容易崩溃啊,稳定性提升真不是吹的

开始)

“多加点Redis虚拟节点,服务器才不容易崩溃啊,稳定性提升真不是吹的”,这句话其实说的是一个特别实用的技术思路,尤其是在处理海量数据和高并发请求的时候,咱们可以把它想象成一个大型超市在节假日搞促销的场景,这样就好理解多了。

假设你开了一家超市,一开始生意一般,只有一个收银台,所有顾客都排这一条队等着结账,这时候虽然慢点,但还能应付,后来生意越来越火,一个收银台根本忙不过来,队伍排得老长,顾客怨声载道,有的等不及就直接走了,这就好比服务器因为压力太大,响应变慢,甚至直接“崩溃”宕机了。

为了解决这个问题,你很自然地会想到:多开几个收银台呗!于是你开了三个收银台,把顾客分成三队,这就是最简单的“分片”或者叫“分区”思想,把压力分摊开,在Redis里,这就是搭建一个Redis集群,把数据分散到三台不同的Redis服务器(我们叫它们节点)上,比如A、B、C三台,每台机器只存一部分数据,也只处理一部分请求,这样压力就小多了。

新的问题又来了,你怎么决定哪个顾客去哪个收银台排队呢?或者说,怎么决定一条商品数据该存到A、B、C哪台Redis服务器上呢?我们会用一个简单的规则,比如根据商品的编号(key)算一个哈希值,然后对这个哈希值取模(比如除以3看余数),余数是0的去A台,是1的去B台,是2的去C台,这个规则看起来很公平,一开始运行得也不错。

多加点Redis虚拟节点,服务器才不容易崩溃啊,稳定性提升真不是吹的

天有不测风云,突然有一天,B号收银台(也就是B服务器)的机器老化了,或者因为访问某个热门商品导致负载突然飙升,“崩溃”了,宕机了,这时候,原先所有该由B服务器处理的请求瞬间就没人管了,更麻烦的是,B服务器上存的所有数据暂时都访问不了了,这就相当于三个收银台坏了一个,原本排这个队的顾客一下子懵了,他们要么干等着修好(导致服务不可用),要么只能重新排队,但重新排队又会瞬间挤爆另外两个收银台,很可能导致连锁反应,让A和C也扛不住,整个系统就陷入了混乱。

这时候,超市经理(也就是系统运维人员)赶紧采取紧急措施:启用一台新的备用收银台D,让它顶替B的位置,麻烦事来了,因为之前的分队规则是“除以3取余数”,现在变成了A、C、D三台机器,规则得变成“除以3取余数”吗?不行啊,数据分布全乱了!原来在A和C上的数据位置可能不变,但原本在B上的数据,现在应该映射到D上吗?那其他数据要不要也跟着重新调整?这就意味着,几乎所有的数据都需要根据新的规则重新计算一遍应该放在哪台服务器上,然后进行大规模的数据迁移,这个过程非常耗时耗力,而且在迁移期间,系统会非常脆弱,很容易再次出现问题和数据不一致的情况,这次“崩溃”恢复的代价太大了。

怎么才能避免这种“一机崩溃,全网瘫痪”的尴尬局面呢?答案就是开头那句话:“多加点Redis虚拟节点”,这招真是太巧妙了,它引入了一个“虚拟层”的概念。

多加点Redis虚拟节点,服务器才不容易崩溃啊,稳定性提升真不是吹的

我们还用超市的例子打比方,这次,我们不直接设3个物理收银台,而是设想有成千上万个“虚拟收银窗口”,这些窗口是虚拟的,不是真实存在的,我们通过一种更复杂的哈希算法,把每一个商品(每一个key)均匀地映射到这成千上万个虚拟窗口中的一个,我们再把这大量的虚拟窗口,尽可能地平均分配给当前实际存在的3台物理收银台(A、B、C服务器)。

这样一来,每台物理服务器就不再是只负责一个连续的“数据段”,而是负责着大量分散的、不连续的虚拟窗口所对应的数据,就像把一大把芝麻均匀地撒在三块面包上,而不是把一整瓶花生酱涂在一块面包上。

神奇的事情发生了,假设B服务器又崩溃了,当B宕机时,它负责的那几千个虚拟窗口瞬间失效了,由于这些虚拟窗口是均匀分布在所有数据中的,所以这次失效导致的数据丢失和请求失败,也是均匀地分散在所有的数据范围上的,而不是像之前那样,一整块连续的数据都完蛋。

这时,我们迅速启用新的备用服务器D,我们不需要改变那个“数据key -> 虚拟窗口”的映射规则,这个规则是固定的,我们只需要把原来由B服务器负责的那些虚拟窗口,重新分配给幸存的A、C和新加入的D这三台服务器就可以了,由于虚拟节点的数量非常多,这次重新分配会非常平滑,对于大多数数据来说,它们原来在哪个虚拟窗口,现在还在哪个虚拟窗口,只是这个虚拟窗口可能从B服务器移交给了A或C或D来管理,只有原先落在B服务器负责的那些虚拟窗口上的数据,才需要迁移到新的服务器上。

这样一来,数据的移动量被降到了最低,通常只涉及整个集群数据量的 1/节点总数(比如原来是3个节点,就大约迁移三分之一的数据),这相比于之前那种推倒重来式的全部数据重新分布,无论是迁移速度、对系统资源的占用,还是对正常服务的影响,都小了不止一个数量级,系统的恢复速度极快,稳定性自然就得到了巨大的提升,这就是“多加点虚拟节点”的精髓所在,它通过引入一个抽象的中间层,将物理节点的变化所带来的冲击稀释、打散,从而极大地增强了整个系统应对故障的能力,说“服务器不容易崩溃”真不是吹的。 结束)