程序猿阿朗

> 现在的仓库绑定域名可以展示README.md的内容。但排版有些问题。希望作者能针对性优化一下。谢谢啦 这个我是知道的，后面我可以搞个 github pages 的网页或者直接注册个域名来发布一下。貌似挺多人喜欢这些壁纸。

> 感谢作者，github仓库页面的排版形式非常棒，只不过发布成网页后有一些兼容错误，希望形式还是不变只是兼容一下单网页，看到这个项目后我特别喜欢，我有些等不及了我想自己修改一下网页排版，但是不知道怎么手动触发Actions 任务，而且好像当天修改时间(UTC+0)也不会触发任务 上个周末抽出时间对项目进行了优化，并简单做了个在线网站 。 可以通过地址：https://bing.wdbyte.com/ 访问浏览。 源码也已经开源，欢迎讨论交流。

好想法，后续来看看下载功能放到哪里比较好。🌹🌹🌹

> 过了一遍，基本包括了我们常见限流策略方案，但是如果把各个限流策略 **递进关系** 和 **相关性** 这类核心概念补充一下，文章会让读者更加便于接受和总结。 > > 首先计数器方式也有人说 **固定窗口** 的，实现简单，精确度不够，临界超QPS，简而言之就是有 **流量突刺**，所以引出 **滑动窗口**，好处在于能够一定程度上解决了精确度，但是又不稳定，不能完全消除这种超qps的概率，不是绝对的精确，并且随着你追求精确度去不断窗口细分，成本代价也不断增加，还是没有达到绝对精确，那有没有绝对精确的呢？ > > 有，**滑动日志**，它解决了精确度问题，达到了完全精确，但是空间复杂度O(N)和时间复杂度O(logN)的问题，又使得滑动日志虽然达到了绝对精确但是牺牲了很大的成本，计算复杂度很高。并且还有一个问题，就是你虽然精确度完全精确了，但是你流量不够 **平滑**，在极小极限的时间窗口情况下，你流量平滑度还是不够，就算你通过计算复杂度去换取平滑度，但是做不到绝对平滑。简而言之就是你没法很好的去控制 **速率**，于是又有了 **令牌桶** 和 **漏桶**，设计思路基本都是控制平均访问速率，像 v ≤ N / T。区别就在于漏桶能保护下游服务，但是牺牲了响应性能，就是匀速流出肯定需要流量等待嘛，而令牌桶虽然没有很好保护了下游服务但是能应对突刺流量，也提升了响应体验。 > > 另外，往细了说，令牌桶和漏桶就是滑动窗口的变种，无非加了速率控制和应对不同的流量模型和响应场景。 >...