傻逼的共识也是共识，共识引发冲突

谈谈网络拥塞的根源

这也是我一直反对严格最短路径优先的原因，反而松散的 ecmp 更有效率，系统应该在所有可达的路径上分发流量，路径度量顶多作为一个不那么重要的权重。最短路径优先算法就是一个精确的钟摆，当网络共识把大家引导到同一条路径时，这条路径就成了最劣路径。最短路径优先算法让网络工作在 active-standby 模式，而不是 active-active 负载均衡模式。那么多路径简直就是在最短路径上的路由器坏了重收敛时用的。

这就引入了允不允许乱序的问题，应该是 tcp 给网络惯的毛病，要向大自然学习，婚礼车队都不是完全不能乱序。 综合一下本文的三个点之间的互相影响，最短路径优先算法让网络在极短的时间内产生了共识，而该共识把流量引入所谓枢纽节点，于是在枢纽节点产生拥塞。

让共识达成的慢一点，或干脆不要有共识，就解除了拥塞的根源。

但随着最短路径优先的互联网感染了社会生活的几乎每个方面，它的病也感染了生活的每个方面，无论是旅游还是导航，可以说互联网是现实生活中各种拥塞的主因，主因的背后还是最短路径优先算法。

你家门口就能买到好吃的猪头肉，若不是你在网络上查到距离你 10 公里开外的一家老字号名店，你也不会去买，信息是共享的，共识让所有人都知道了这家店，于是店家过载，开始排队，即使开分店，也还是在分店间排序评分，最高分那家还是会排队。

哈尔滨热度也一样，如果你也相信 “最短路径优先” 不靠谱，相信退而求其次，去趟长春你会发现同样好玩，就算在长春，也没必要非要去冰雪新天地和净月潭，冰雪项目，南湖公园就够了，接地气。

MySQL 8.0新特性和性能数据

分布式QoS算法解析

令牌桶算法中，系统以指定策略（比如匀速）往桶中放入令牌，业务请求被处理时，需要先从桶中获取令牌。当桶中没有令牌时，业务请求将不被处理。这样能通过控制令牌生成的速率，来控制业务请求被处理的速率。

漏桶算法中，设想一个漏桶接水，桶里的水将匀速流出。不管业务请求到来有多快，这些请求被处理（即从漏桶流出）的速率都是恒定的。

二者的区别是，漏桶算法能强行限制业务请求速率，而令牌桶除了能限速之外，还能允许一定的突发请求处理。一般在实现中会结合漏桶和令牌桶算法

mClock的算法思想

  • 指定权重（Weight, W）、预留（Reservation, R）和上限（Limit, L）：给定一组分布在不同服务器上的VM，根据业务需求，为每个VM指定一组参数，参数有三类，分别是Weight、Reservation和Limit。如果VM更重要，可以为之指定更大的Weight。Reservation表示必须满足的最低需求。如果指定了Limit，则表示该业务所得资源最多不会超过指定值。
  • 在共享存储侧，每个VM的IO请求到来时，mClock算法根据Weight、Reservation和Limit配置给请求打上三个独立的标签。

mClock算法结合处理Weight, Reservation, Limit三个队列后的效果是：

  • 如果系统资源不够所有人分，则优先满足Reservation和Limit。
  • 如果系统资源足够分，则按Weight去分配。

dmClock 流程上类似mClock，仍是先为不同业务指定(W, R, L)，据此在client侧为不同业务请求打标签，比如打Weight标签时，不再是+1/w，而是+delta/w。关键是理解这里的delta

感觉不是特别清晰

Introducing DoorDash’s In-House Search Engine

FAST’22 Hydra https://zhuanlan.zhihu.com/p/613948599

https://github.com/scylladb/seastar/blob/7fe1a04211dece31e1b0612fe38d3bc8de1c3ac0/doc/lambda-coroutine-fiasco.md?plain=1#L9

    co_await seastar::yield().then(seastar::coroutine::lambda([captures] () -> future<> {
        co_await seastar::coroutine::maybe_yield();
        // 在这里安全地使用 `captures`。
    }));

IAM

•Version：定义策略语言的版本 •Effect：指定语句是允许还是拒绝访问 •Action：描述应该允许或拒绝的操作的类型 •Resource：指定策略语句涵盖的对象

aws设计挺切面的