大家好，大家好，我是一栋小建筑。
最近，当我感到无聊（触摸）漫步（鱼）github时，我找到了一个Ali开源项目可以贡献代码的地方。
它不是单个测试和更改代码格式，但更具挑战性。最重要的事情并不困难。仔细阅读本文后，可以写出基本基础。没什么可说的，离开！
我相信，当您在每日写作代码中编写时间戳时，您将编写以下代码：
读者中有一些地鼠，我们还用GO写下它：
总的来说，写这篇文章或99％的情况没有问题，但是一个大哥哥研究了爪哇的时间邮票以获取：
http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemellis.html
他得出结论：并发越高，时间戳就慢了！
我们不了解细节的细节。这可能是因为只有一个全局时钟源。高纠正或频繁访问将引起严重的争议。
我首先与缓存时间戳的方法接触以在Cobar项目中进行优化：
https://github.com/alibaba/cobar
由于Cobar是数据库中间件，因此其QP可能很高，因此我们进行了优化。我们看一眼他的意识：
https://github.com/alibaba/cobar/blob/master/src/main/server/alibaba/cobar/cobar/timeutil.java
https://github.com/alibaba/cobar/blob/master/src/main/server/alibaba/cobarserver.java
Cobar这样做的原因是因为他的QP通常很高，这可以减少CPU消耗或时间消耗的时间 - 戳记；其次，该时间戳仅用于cobar用于统计使用，即使它不准确，这也不是很大。从实现的角度来看，确实是。
后来，我还看到了其他代码中的类似实现，例如Sentinel（不是Redis的前哨，而是Ali开源Sentinel的开源）。
作为当前流的工具，Sentinel自然是支出越小，越好，因此Ali Sentinel的前哨也使用类似于Cobar的实现：
原因也很简单，尽可能最大程度地减少系统资源的消耗，时间戳的性能更好，但是它不能与柯巴尔保持弱精度，因为Sentinel获得的时间戳很可能会确定一次，它将一旦确定请求是限制和融合的。
因此，解决方案也非常简单，直接将缓存时间戳的间隔更改为
去年，我还写了一篇文章“低执行时间戳记”，其中包含《哨兵守则》：
甚至后来的哨兵也采用了相同的逻辑：
我以前没有考虑过太多，我认为这没错。
直到两个晚上，我还可以在哨兵社区周围漫步并看到一个问题，这令人震惊：
https://github.com/alibaba/sentinel-golang/issues/441
在第一段中，大个子给出了一个非常有见地的观点：
什么是委婉语，什么是“负收入”？
我再次搜索并找到了这个问题：
https://github.com/alibaba/sentinel/issues/1702
Timeutil吃了50％的CPU，即“负收入”或令人震惊的！
看到这个问题，我简短地思考：
但这只是我们的想法，如果有数据支持，那就说服力。
读完它后，我跪在适当的地方，我无法长时间起床。
班级代表摘要：
在此手术之后，即使是哨兵社区中的大个子也感觉很好，并用拇指大拇指：
但是，经过如此多的测试，最终修改只是将真实的变化更改为false：
最初，我认为这个大个子的考验已经获得了很大的收获。我没想到下一次流浪会让我发现一些更难以置信的东西。
由于分析了上述分析，因此当QP相对较高时，收入可以被抵消，因此可以实现自适应算法。当QPS较低时，将直接从系统获得。当QPS较高时，从缓存获得。
果然，已实现了Sentinel（Java版本，版本> = 1.8.2）！
发行参考：https：//github.com/alibaba/sentinel/pull/1746
让我们看一下其实施：
让我们首先看一下核心缓存时间戳（每毫秒一次执行一次）。在此周期中，它将缓存时间戳分为三个状态：
如何流通这三个状态？答案是在开始时打电话的方法：
首先，检查逻辑具有一个间隔，即每隔时间（3秒）进行状态转换；
其次，如果当前状态为，并且QP大于（1200），则切换到。
如果当前状态小于（800），请切换。
似乎丢失了开关分支。在上面的周期中，第三个分支切换到状态一次。
为什么这是？如果未直接切换过渡，则切换后的时间戳可能是错误的。
文本可能不是直观的，我们将状态流到地图上：
最后，这些已经准备好了。获得时需要做两件事：一个是计算时间戳的QPS，另一件是获得时间戳；如果是或直接获得系统时间返回，则是缓存，请使用时间戳。
当程序相对免费时，它不会缓存时间戳，请减少CPU消耗。当Qps高时，时间戳也可以减少CPU消耗，并且可以减少时间戳的延迟。
但是我在中间有一个问题。我不知道如何在这里获得QPS边界。它并不一定是绝对准确的，但是该值不一定与机器的配置有关。可以将其配置而不是在代码中写入死亡。关于这一点，本守则的作者还解释了以下原因：
最后，您可能会问，此QPS统计信息如何？
这是哨兵的力量。使用统计信息，因为这不是本文的重点，因此不会扩展。如果您感兴趣，那么算法和Java是完全一样的，甚至实现了。
有没有测试数据支持？另一个大个子在评论区域发布了他的测试数据。让我们来看看：
在低负载下，CPU的消耗特别明显，高负负载没有改变，这也符合我们的期望。
您认为您认为这一点在这里吗？是的，Sentinel-Go尚未实现上述自适应算法。这是一个绝佳的机会。有技术内容和参考（Java版本）。令人兴奋吗？
社区中还有一个问题：
https://github.com/alibaba/sentinel-golang/issues/419
这个问题已于2021年8月提出，但截至目前，他尚未贡献该守则。这四座房屋和五座等同于他放弃的条目，所以你理解我的意思吗？
如果您认为文章还可以，请移动您的手，单击，您的鼓励是我连续创作的动力！
顺便说一句，如果您认为这不有趣，则可以再次查看这些相关文章：
谢谢您的阅读，我们下次会见您?
搜索微信公共帐户“捕获主”，后端技术共享，体系结构设计，绩效优化，来源阅读，问题调查和坑。
原始：https：//juejin.cn/post/7101520653442318366