京东网站的建设情况,wordpress文章中加入代码段,晋中工商局网站开发区分局,那些网站可以做淘宝店铺推广目录
引入 OCC
添加退避机制
添加抖动机制
小结 引入 OCC 乐观并发控制#xff08;Optimistic Concurrency Control#xff0c;OCC#xff09;是一种既能保证多个写入者安全地修改单个对象又能避免丢失写入的古老方法OCC具有三个优点#xff1a;只要底层存储可用#…目录
引入 OCC
添加退避机制
添加抖动机制
小结 引入 OCC 乐观并发控制Optimistic Concurrency ControlOCC是一种既能保证多个写入者安全地修改单个对象又能避免丢失写入的古老方法OCC具有三个优点只要底层存储可用它总能取得进展易于理解易于实现DynamoDB 的条件写入使OCC成为DynamoDB 用户的自然选择并且DynamoDBMapper 客户端原生支持OCC尽管OCC可以保证有进展但在高争用情况下它的表现仍然很差所谓高争用(是指在多个线程或进程同时访问或修改共享资源时的情况这可能导致竞争条件和性能问题它与高并发有一定的关联但并不完全相同(高并发强调的是系统同时处理多个并发请求的能力通常表示系统在单位时间内可以处理的并发请求数量非常大而高争用则强调的是在共享资源上的竞争程度即多个并发操作对同一个资源的竞争情况)(因此高争用更专注于资源竞争的概念而高并发更关注系统整体的并发处理能力当存在高争用情况时可能会出现性能瓶颈和竞争条件需要采取合适的并发控制和优化策略来解决这些问题))这些争用情况中最简单的是当大量客户端同时启动并尝试更新同一数据库行时由于每轮保证有一个客户端成功因此完成所有更新所需的时间与争用程度呈线性增长在本文的图表中使用了一个小型模拟器来模拟 OCC 在带有延迟以及延迟方差的网络中对远程数据库的行为在这个模拟中网络引入了平均 10ms 的延迟和 4ms 的方差第一个模拟展示了随着争用程度增加完成时间如何呈线性增长这种线性增长是因为每轮只有一个客户端成功所以需要N轮才能让所有N个客户端都成功 不幸的是这还不是全部当有N个客户端竞争时系统所完成的总工作量将以N的平方增加 添加退避机制 这里的问题是有 N 个客户端在第一轮中竞争N-1 个客户端在第二轮中竞争依次类推让每个客户端在每一轮中都竞争是浪费的减缓客户端的速度可能有所帮助而经典的减缓客户端的速度的方法是采用有上限的指数退避(限制指数退避)有上限的指数退避意味着客户端在每次尝试后都会将退避时间乘以一个常数直到达到某个最大值在我们的例子中每次尝试失败后客户端会睡眠一段时间 重新运行模拟显示退避机制在一定程度上有所帮助但并不能解决问题客户端的工作量仅有轻微减少 查看问题的最佳方法是查看指数退避调用发生的时间 很明显指数退避起到了作用因为调用发生的频率越来越低然而问题也显而易见仍然存在调用的集群我们并没有减少每轮竞争的客户端数量只是引入了一些没有任何客户端竞争的时间段尽管网络延迟的自然变化导致了一些分散但竞争并没有得到很大程度的减少 添加抖动机制 解决方案并不是移除退避机制而是添加抖动机制最初抖动似乎是一个违反直觉的想法试图通过添加随机性来提高系统的性能然而上述时间序列提供了使用抖动的充分理由——我们希望将峰值分散到相对恒定的速率添加抖动只需要对睡眠函数进行微小修改即可 那个时间序列看起来好很多间隔不再存在除了最初的峰值外呼叫的速率大致保持恒定这对于总呼叫次数也产生了很好的效果 在有100个竞争客户端的情况下我们将呼叫次数减少了一半以上与不使用抖动的指数退避相比我们还大幅改善了完成时间 有几种方法可以实现这些定时退避循环我们将上述算法称为“完全抖动”并考虑两种替代方案第一种替代方案是“相等抖动”它总是将一些退避和抖动保持较小的量 这种方法的原理是它防止了非常短的延迟始终保留一部分退避的减速效果第二种替代方案是“去关联抖动”与“完全抖动”类似但是我们还会根据上一个随机值来增加最大抖动范围 小结 在计算机网络中指数退避和抖动是一种常见的错误恢复和重试策略当发生网络传输错误或拥塞时指数退避和抖动策略可以帮助减少冲突和重试的负载提高系统的稳定性和效率指数退避是指在发生错误后(竞争失败后)等待一段时间然后重试的操作并且在每次重试时增加等待时间的策略具体来说等待时间是根据指数函数逐渐增加的通常是当前重试次数的指数幂这样做可以在网络拥塞的情况下给予网络更多时间来恢复并避免短时间内的连续冲突抖动是指在等待时间的基础上引入一个随机因素使得重试的时间间隔稍微有所变化这样做的目的是避免在网络中出现周期性的重试避免网络拥塞或错误引起的冲突通过结合指数退避和抖动策略可以在网络中更有效地处理错误和重试操作提高系统的可靠性和性能哪种方法最好从客户端工作量的角度来看无论是“完全抖动”还是“相等抖动”调用次数都大致相同而“去关联抖动”的调用次数更高相对于无抖动方法这两种方法都大大减少了工作量 没有抖动的指数退避方法显然是失败者它不仅需要更多的工作量而且比带有抖动的方法需要更长的时间实际上它需要更多的时间我们不得不将其从图表中删除以便更好地比较其他方法 在带有抖动的方法中“相等抖动”是失败者它的工作量略高于“完全抖动”而且耗时更长而在“去关联抖动”和“完全抖动”之间的选择则不那么明确“完全抖动”方法的工作量更少但需要稍微更长的时间但两种方法都大大减少了客户端工作量和服务器负载值得注意的是这些方法都没有从根本上改变要完成的工作的N2特性但在适度的竞争水平下它们显著减少了工作量使用抖动的指数退避的实施复杂度回报是巨大的因此应该被视为远程客户端的标准方法
