想做个网站 在哪买域名和空间河南网站seo费用

当前位置： 首页 > news >正文

想做个网站 在哪买域名和空间,河南网站seo费用,做微信网站,seo推广系统文章部分内容来源#xff1a;小林coding 问题场景#xff1a;我们需要用Lua脚本#xff0c;并且这个Lua脚本需要用到两个Key#xff0c;但这两个Key必须命中同一台机器才可以#xff0c;不然Lua脚本就会执行失败。如果集群扩容可能会导致两个Key落到不同的节点上导致Lua脚…文章部分内容来源小林coding 问题场景我们需要用Lua脚本并且这个Lua脚本需要用到两个Key但这两个Key必须命中同一台机器才可以不然Lua脚本就会执行失败。如果集群扩容可能会导致两个Key落到不同的节点上导致Lua脚本执行失败 我们文章内容先讲清楚一致性Hash然后我们再讲实战场景Redis分片扩容导致Lua脚本失效 如何分配请求 负载均衡 大多数网站背后肯定不是只有一台服务器提供服务因为单机的并发量和数据量都是有限的所以都会用多台服务器构成集群来对外提供服务。 但是问题来了现在有那么多个节点后面统称服务器为节点因为少一个字要如何分配客户端的请求呢 其实这个问题就是「负载均衡问题」 解决负载均衡问题的算法很多不同的负载均衡算法对应的就是不同的分配策略适应的业务场景也不同 轮询算法 普通轮询 引入一个中间的负载均衡层让它将外界的请求「轮流」的转发给内部的集群。 比如集群有 3 个节点外界请求有 3 个那么每个节点都会处理 1 个请求达到了分配请求的目的 加权轮询 考虑到每个节点的硬件配置有所区别我们可以引入权重值 将硬件配置更好的节点的权重值设高然后根据各个节点的权重值按照一定比重分配在不同的节点上让硬件配置更好的节点承担更多的请求这种算法叫做加权轮询。 加权轮询算法使用场景是建立在每个节点存储的数据都是相同的前提。 所以每次读数据的请求访问任意一个节点都能得到结果。 但是加权轮询算法是无法应对「分布式系统数据分片的系统」的 因为分布式系统中每个节点存储的数据是不同的 当我们想提高系统的容量就会将数据水平切分到不同的节点来存储也就是将数据分布到了不同的节点。 比如一个分布式 KVkey - valu缓存系统 某个 key 应该到哪个或者哪些节点上获得应该是确定的不是说任意访问一个节点都可以得到缓存结果的 普通哈希算法有什么问题 哈希算法对同一个关键字进行哈希计算每次计算都是相同的值这样就可以将某个 key 确定到一个节点了可以满足分布式系统的负载均衡需求。 取模运算 哈希算法最简单的做法就是进行取模运算比如分布式系统中有 3 个节点基于 hash (key) % 3 公式对数据进行了映射。 如果客户端要获取指定 key 的数据通过下面的公式可以定位节点 hash(key) % 3 如果经过上面这个公式计算后得到的值是 0就说明该 key 需要去第一个节点获取。 但是有一个很致命的问题如果节点数量发生了变化也就是在对系统做扩容或者缩容时必须迁移改变了映射关系的数据否则会出现查询不到数据的问题。 举个例子假设我们有一个由 A、B、C 三个节点组成分布式 KV 缓存系统基于计算公式 hash (key) % 3 将数据进行了映射每个节点存储了不同的数据 现在有 3 个查询 key 的请求分别查询 key - 01key - 02key - 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)这样的数据的迁移成本太高了。 所以我们应该要重新想一个新的算法来避免分布式系统在扩容或者缩容时发生过多的数据迁移 一致性哈希算法有什么问题 什么是一致性哈希 一致性哈希算法就很好地解决了分布式系统在扩容或者缩容时发生过多的数据迁移的问题。 一致哈希算法也用了取模运算 但与哈希算法不同的是哈希算法是对节点的数量进行取模运算 而一致哈希算法是对 2^32 进行取模运算是一个固定的值 我们可以把一致哈希算法是对 2^32 进行取模运算的结果值组织成一个圆环就像钟表一样 钟表的圆可以理解成由 60 个点组成的圆 而此处我们把这个圆想象成由 2^32 个点组成的圆这个圆环被称为哈希环如下图 一致性哈希中的两步哈希 一致性哈希要进行两步哈希 第一步对存储节点进行哈希计算也就是对存储节点做哈希映射比如根据节点的 IP 地址进行哈希第二步当对数据进行存储或访问时对数据进行哈希映射 所以一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上 对「数据」进行哈希映射得到一个结果要怎么找到存储该数据的节点呢 答案是映射的结果值往顺时针的方向的找到第一个节点 就是存储该数据的节点 例子 3个节点进行哈希映射 举个例子有 3 个节点经过哈希计算映射到了如下图的位置 3个key进行哈希映射 接着要对查询的 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 崩溃进而形成雪崩式的连锁反应。 所以一致性哈希算法虽然减少了数据迁移量但是存在节点分布不均匀的问题 如何通过虚拟几点提高均衡度 要想解决节点能在哈希环上分配不均匀的问题就是要有大量的节点节点数越多哈希环上的节点分布的就越均匀。 但问题是实际中我们没有那么多节点。 所以这个时候我们就加入虚拟节点也就是对一个真实节点做多个副本 具体做法 不再将真实节点映射到哈希环上而是将虚拟节点映射到哈希环上并将虚拟节点映射到实际节点 所以这里有「两层」映射关系 比如对每个节点分别设置 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 个虚拟节点。 另外虚拟节点除了会提高节点的均衡度还会提高系统的稳定性 当节点变化时会有不同的节点共同分担系统的变化因此稳定性更高。 比如当某个节点被移除时对应该节点的多个虚拟节点均会移除 而这些虚拟节点按顺时针方向的下一个虚拟节点可能会对应不同的真实节点 即这些不同的真实节点共同分担了节点变化导致的压力 而且有了虚拟节点后还可以为硬件配置更好的节点增加权重 比如对权重更高的节点增加更多的虚拟机节点即可 因此带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景 而且适合节点规模会发生变化的场景 实战场景Redis分片扩容使Lua脚本失效 场景介绍 我们需要用Lua脚本并且这个Lua脚本需要用到两个Key但这两个Key必须命中同一台机器才可以不然Lua脚本就会执行失败。如果集群扩容可能会导致两个Key落到不同的节点上导致Lua脚本执行失败 无论是单机还是集群模式对于Key的操作都必须通过参数列表显示的传进去不能依赖脚本或者是随机逻辑 对于Cluster模式中要求所有的keys所在的slot必须在同一个shard内 解决方案 1.使用HashTag Redis集群通过{}来定义Hash Tag确保多个Key落在同一个slot。你可以在Key中使用{}来强制让两个Key落在同一个slot local key1 user:{123}:profile local key2 user:{123}:settings 在这个例子中{123}是Hash TagRedis会根据123来计算slot确保key1和key2落在同一个节点上 2.确保key在同一个slot中 在Redis集群中Key的slot是通过CRC16算法计算的。你可以通过以下方式确保两个Key落在同一个slot 使用相同的Hash Tag如上所述。确保Key的CRC16计算结果相同 什么是Slot槽 在 Redis 集群中数据被分散存储在多个节点上。为了实现数据的分布式存储Redis 将所有可能的 Key 分配到 16384 个 Slot 中。每个 Slot 是一个逻辑分区Redis 集群中的每个节点负责管理一部分 Slot。 Slot 的计算方式 Redis 使用 CRC16 算法对 Key 进行计算然后将结果对 16384 取模得到 Key 对应的 Slot 编号。公式如下 slot CRC16(key) % 16384 例如Key 为 user:123Redis 会计算 CRC16(user:123) % 16384得到一个 0 到 16383 之间的 Slot 编号。 Slot 的作用 数据分片Redis 集群通过 Slot 将数据分布到不同的节点上。动态扩容当集群扩容或缩容时Redis 可以通过迁移 Slot 来重新分配数据 什么是Hash Tag哈希标签 Hash Tag 是 Redis 提供的一种机制用于强制将多个 Key 分配到同一个 Slot 中 它的核心思想是通过在 Key 中指定一个特殊的标记{}让 Redis 只对标记内的内容计算 Slot而不是对整个 Key 计算。 Hash Tag 的语法 在 Key 中使用 {} 包裹一部分内容Redis 只会对 {} 内的部分计算 Slot。例如 user:{123}:profile user:{123}:settings 在这两个 Key 中{123} 是 Hash Tag。Redis 会忽略 user: 和 :profile 或 :settings只对 123 计算 Slot。 Hash Tag 的作用 确保多个 Key 落在同一个 Slot 中。在 Redis 集群中Lua 脚本要求所有操作的 Key 必须在同一个 Slot 中Hash Tag 可以满足这一需求 Hash Tag和Slot的关系 如果没有 Hash TagRedis 会对整个 Key 计算 Slot。如果有 Hash TagRedis 只会对 {} 内的内容计算 Slot。通过 Hash Tag可以让多个 Key 共享同一个 Slot即使它们的 Key 名称不同