整理印象笔记，印象笔记的数据得搬走了。

唉，整理印象笔记中剪藏的网页，发现有些已经变成黄网了

一种能高速查找的自适应哈希表

感觉见过这个点子 SIMD加速

这个场景主要面向的是key有特征的

Redis 高负载下的中断优化

防止跨numa 亲和性绑定/中断划分

页错误引发的 Redis 延迟

pagecache不够？pagecache没用上？IO影响pagecache？

FloatInfo在线演示

https://mserdarsanli.github.io/FloatInfo/

Explaining The Postgres Meme

fsync使用错误这个比较经典 https://www.postgresql.org/message-id/flat/CAMsr%2BYHh%2B5Oq4xziwwoEfhoTZgr07vdGG%2Bhu%3D1adXx59aTeaoQ%40mail.gmail.com

fsync失败就应该退出，不能重试，重试不代表上次失败的fsync是成功的

当然后面其他数据库也正确的处理了 https://github.com/wiredtiger/wiredtiger/commit/ae8bccce3d8a8248afa0e4e0cf67674a43dede96

MySQL · 引擎特性 · B+树并发控制机制的前世今生

写的真好

又见CLOSE_WAIT

浅谈CLOSE_WAIT

简单说就是业务写的有问题，请求使用的连接没及时释放，都卡在close wait了。

回忆一下

Source file: mmd/tcp-flow.mmd:

stateDiagram-v2 Closed --> Listen Listen --> SYN_RCVD SYN_RCVD --> Established Closed --> SYN_SENT SYN_SENT --> Established Established --> FIN_WAIT_1 FIN_WAIT_1 --> FIN_WAIT_2 FIN_WAIT_2 --> TIME_WAIT TIME_WAIT --> Closed Established --> CLOST_WAIT CLOST_WAIT --> LAST_ACK LAST_ACK --> Closed

Source file: mmd/tcp-flow2.mmd:

sequenceDiagram client->>+server: syn Note over client: SYN_SENT server->>+client: syn+ack Note over server: SYN_RCVD Note over client: Established client->>+server: ack Note over server: Established Note over client,server: Session client->>+server: fin Note over client: FIN_WAIT_1 server->>+client: ack Note over server: CLOSE_WAIT Note over client: FIN_WAIT_2 server->>+client: fin Note over server: LAST_ACK Note over client: TIME_WAIT client->>+server: ack Note over client,server: Closed

这种是对端主动关闭，对端挂了，对端超时主动断开 ->响应太慢

但close wait是转瞬即逝的，只要主调调用close，为什么能剩这么多？

大批量的连接被断开，但是主调卡住了，没close，现象就是一堆close_wait

还有一种可能是消费不过来 -> BACKLOG 太大

此处的 backlog 不是 syn backlog，而是 accept 的 backlog，如果 backlog 太大的话，设想突然遭遇大访问量的话，即便响应速度不慢，也可能出现来不及消费的情况，导致多余的请求还在​ ​队列​​里就被对方关闭了。

netstat -ant

ss -ant

观察CLOSE_WAIT Recv-Q Local Address
Recv-Q不为空，它表示应用还没来得及接收数据
Local Address 表示哪个地址和端口有问题

lsof -i:<PORT>

FoundationDB论文解读 A Distributed Unbundled Transactional Key Value Store

  • 总体的架构是松耦合的，分为control plane + data plane
    • control plane负责系统的管理和监控，使用active disk paxos 来存储系统metadata。
    • data plane负责用户+系统数据的存储，其中事务管理系统负责写路径，storage系统负责读路径，是解耦的，可以各自独立扩展。
  • 利用OCC + MVCC的策略来实现串行化事务。
  • 使用failure -> restart -> recovery的策略来处理failure，即快速失败快速恢复。
  • 采用了类似Aurora的log is database的思路，对log进行多副本同步复制，是一种特例的quorum，所有副本都同步落盘，才认为提交成功，才能返回客户端！因此f+1个副本，最多可允许f个失效。

打造千亿文件量级的大规模分布式文件系统

看看取舍

感觉cephfs还是利用不好

Google Percolator事务

看起来不难

Source file: mmd/precolater.mmd:

sequenceDiagram client->>+timer: get start_ts timer-->>+client: ok Note over client: 从提交的key中选取pk sk client->>+servers: prewrite alt 写写冲突检查 key的commit_ts < start_ts servers-->>+client: WriteConflict else key已经锁上了 servers-->>+client: KeyIsLock else Note over servers: 锁key 写lock cf{start_ts,key,pk_ref}
pk_ref pk存pk sk存pk的指向信息 Note over servers: 写data {key,start_ts,value} servers-->>+client: ok end client->>+timer: get commit_ts timer-->>+client: ok client->>+servers: commit 先发给pk节点 alt 检查keylock合法性 servers-->>+client: KeyLockError else Note over servers: 写 write cf {key,commit_ts,start_ts}
写写冲突使用 Note over servers: 释放锁, 删除lock cf servers-->>+client: ok end client->>+servers: commit 异步发给其他sk节点 client->>+servers: read key Note over servers: 从 write cf拿到最近的start_ts
拼成新key去data cf里捞 opt 冲突事务的锁是否存在？ alt 当前节点是冲突事务的pk节点 Note over servers: 冲突事务的锁存在
冲突事务已经失败则清理锁
不存在就不冲突 else Note over servers: 找到冲突事务的pk节点，判断锁是否存在 alt 冲突事务的pk锁不存在 Note over servers: 说明事务已经成功
需要在当前节点继续事务
写data cf {key,start_ts,value} else 冲突事务的pk锁存在 Note over servers: 说明事务已经失败
清理锁 end end end alt 检查key在start_ts之前是否有锁 Note over client: 等待 end servers-->>+client: key + start_ts => value

Redis 高负载下的中断优化 - 美团技术团队

简单来说，CPU0负载太高了，调度不均匀，绑核解决

一个epoll惊群导致的性能问题

SO_REUSEPORT/EPOLLEXCLUSIVE

用 redis 实现分布式幂等服务中间件

TCC

关于TCP 半连接队列和全连接队列

ss -s
netstat -s
ss -lnt

scheduling domain

在NUMA系统上，如果一个node利用率非常高，比如高于90%，而另一个node利用率可能只有60%~70%，这时可以尝试disable wakeup affinity。

分布式快照算法: Chandy-Lamport 算法

Source file: mmd/lamport-snapshot.mmd:

sequenceDiagram NOte over Pi: Initiating a snapshot Pi->>Pi: 创建snapshot Pi->>Pj: 发送marker Pi->>Pi: 记录收到的信息 Pj-->>Pi: 收到marker alt Pj还没创建snapshot NOte over Pj: 创建snapshot
清空接收channel的信息
已经保存了 Pj-->>Pi: 发送marker else NOte over Pj: 记录收到marker前信息
便于崩溃回放 Pj-->>Pi: ok end NOte over Pi,Pj: Terminating a snapshot
所有节点都收到了marker
且记录好了信息

flink用的这个方案，保存进度

这玩意会有单节点问题。又没有好的挽救方案，重试可能会夹杂一大堆需要重放的记录

MongoDB 存储引擎 WiredTiger 原理解析

PPT不错

MySQL · 引擎特性 · B+树并发控制机制的前世今生

写的不错

哈希表总结及其高级话题讨论

写的不错，完美hash和 Extendible Hashing 都提到了

Extendible Hashing 其实可以可以借鉴dragonfly的经验

从HashMap的rehash到分布式KV数据库

这个讨论了多阶hash

MySQL · 引擎特性 · InnoDB 文件系统之文件物理结构

『浅入浅出』MySQL 和 InnoDB

innodb

linux-network-performance-parameters

以C++为核心语言的高频交易系统是如何做到低延迟的？

其实就是降低内存动态分配，尽可能缩短路径

两阶段提交的工程实践

写的好啊