steam膜上显示正在请求序列号一直加载不出来

steam膜上显示正在请求序列号一直加载不出来,第1张

1 第一步,查看steam客户端网络连接,是否正常。 强制启动端口80,443端口,禁用防火墙软件,重新请求序列号;
2 第二步,查看本地DNS设置,将正确的DNS服务器设置好,重新请求序列号;
3 第三步,重置内存缓存或重装steam客户端,重新请求序列号;
4 第四步,重置steam游戏缓存,重新请求序列号;
5 最后,如果以上任一步 *** 作后仍未有反应,建议你到steam官网咨询,以获取更加有效的帮助。

通俗来讲,哈希值就是文件的身份z,不过比身份z还严格。他是根据文件大小,时间,类型,创作者,机器等计算出来的,很容易就会发生变化,谁也不能预料下一个号码是多少,也没有更改他的软件。哈希算法将任意长度的二进制值映射为固定长度的较小二进制值,这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。如果散列一段明文而且哪怕只更改该段落的一个字母,随后的哈希都将产生不同的值。要找到散列为同一个值的两个不同的输入,在计算上是不可能的。

有这样一种情境,有三万张我们要均匀放置于三个缓存服务器上
简单的做法是对缓存的key进行哈希计算,得到的值进行取模计算,所得到的余数,便是缓存的服务器编号

hash % 机器数 = 余数
当机器数为3时无论值为多少,其余数永远只有0,1,2三种情况
那么根据余数,我们给服务器进行编号s0,s1,s2,余数为0的放置于s0服务器上,1,2同理。

这样我们就将三万张的缓存均分成三份存放与三台缓存服务器中
因为对同一张进行哈希计算时,所得到的哈希值是不变的,所以当需要访问时,只要再次进行哈希计算和取模计算,就能获取到存放于哪台服务器,便可以去该服务器中查找满足了我们的需求。而这种算法也称之为哈希算法

这其中有一个问题,那便是如果我增加一台服务器呢
可以预见的是,当增加一台服务器服务器数变成了4而余数也出现了4种情况

这时向s2的服务器查询时,无法读取到,这导致了程序无法从缓存服务器中读取数据,这时程序就会向后端服务器请求,而大量的缓存同时失效,会导致所有请求都指向后端服务器,这会引起后端服务器的崩溃。
这是就要引入一致性哈希算法

还是同样的三个缓存服务器,这次我们将哈希值对2 32取模,所得到的数一定是1到2 32之间的一个整数
然后我们想像一个圆环,其上的每一个点都代表1到2^32之间的一个整数,而这个圆环也被称为hash环
之后我们对服务器A进行取模计算,这样算出来的整数肯定在1到2^32之间,将这个整数代表为服务器A,并且我们可以将这个整数映射到哈希环上,同样的道理我们处理另外两个服务器,这时三个服务器都被映射到了哈希环上,对于我们也将他映射到哈希环上
那么我们只要从的哈希值开始,沿顺时针在哈希环上查找,遇到的第一个服务器便是缓存所在的服务器
这时哪怕新添加一个服务器在哈希环上,我门所丢失的缓存数据也只是新添加的服务器到逆时针方向遇到的第一个服务器这部分数据,而这样仍然有大部分缓存在缓存服务器中可以被查找到,这样可以帮助后端服务器分担大部分压力,不会使服务器崩溃,而这部分丢失的缓存数据,之后重新在后端加载便可以了

这又引入了另一个问题,哈希偏斜
我们无法确保三个服务器在哈希环上为均分的状态,很有可能其中一台服务器分到了很大部分而另两台分到了很少的部分,这样同样会有后端服务器崩溃的隐患
我们可以添加很多虚拟结点同一个服务器我们分出许多虚拟节点,映射在哈希环上,哈希环上的节点越多,缓存被均分的概率便越大,这样可以尽可能的保证缓存在服务器上是接近理想均分的状态,避免了哈希偏斜的问题

注:以下状态码大部分都是自己项目中遇到的,现记录方便日后查看。
通常前后端使用ajax交互时,客户端向服务器发送请求时,然后服务器向我们返回状态码。 状态码就是告诉我们服务器响应的状态 ,由3位数字组成,其中第一位数字表示响应类别,响应类别从1到5分为五种 。

表示请求被服务器正常处理 ,最常见的就是这个

表示请求已成功处理,但是没有内容返回
也就是返回的响应报文中没有报文实体
一般用在只是客户端向服务器发送信息,而服务器不用向客户端返回什么信息的情况

永久重定向,表示请求的资源已经永久的搬到了其他位置 ,资源已经被分配了新的URI

临时重定向,表示请求的资源临时搬到了其他位置 ,请求的资源暂时被配到到了新的URI,和301很像,只不过资源是临时移动

表示请求资源存在另一个URI,应使用GET定向获取请求资源
303功能与302一样,区别只是303明确客户端应该使用GET访问

表示客户端自从上次请求后,请求的网页未修改过。服务器返回此响应时,不会返回网页内容。
304通常在IE浏览器下多次请求同一个地址出现的。
场景:删除表格其中一条数据后重新请求列表数据渲染表格,第二次请求时状态码是304导致被删除的数据还是出现在前端。
原因:IE浏览器下同一地址的ajax请求优先读取本地缓存数据
解决方法:在请求地址后面加上时间戳,保证每次请求的地址都不一样,这样浏览器就无法读取缓存。

表示请求报文存在语法错误或参数错误,服务器不理解 ,需要修改请求内容后再次发送

表示发送的请求需要有>

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/10877088.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-12
下一篇 2023-05-12

发表评论

登录后才能评论

评论列表(0条)

保存