原名： PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database
PolarFS是 PolarDB 的底层分布式文件系统。
极低延迟和高可用， 充分利用用户态网络/IO栈，激进使用新技术（现在看来都是平常的技术了），包括RDMA、NVMe和SPDK等。 写延迟接近本地SSD。
为了提高io吞吐，PolarFS还开发了ParallelRaft，打破Raft只能顺序提交的约束。
笔者注：整体来看，本篇都是一些当年的新技术的应用，如RDMA，SPKD，核心可以说是os-bypass和zero-copy等工程优化。 架构上没有什么特别的亮点。 当然开发的ParallelRaft笔者没关注，不予评价。
原名： Socrates: The New SQL Server in the Cloud
用户期望： 高可用、安全、scalability、弹性。但传统架构无法满足这些要求。
答案是上云。
笔者注：虽然上云似乎越来越被证明是伪需求了。
原文名: We Ain’t Afraid of No File Fragmentation: Causes and Prevention of Its Performance Impact on Modern Flash SSDs
原文名: What’s the Story in EBS Glory: Evolutions and Lessons in Building Cloud Block Store
对应c++的各种同步和锁语义，flare实现了协程的同步和锁语义。这也是个人比较关心的，比如mutex可能造成thread睡眠，那么flare是如何实现mutex，不让thread睡眠，只让协程睡眠。
除了协程的上下文切换外，个人对flare协程库最感兴趣的地方就是协程调度算法了。本文简单分析fiber的调度算法。
最好先阅读下官方文档：https://github.com/Tencent/flare/blob/master/flare/doc/fiber-scheduling.md
本文分析 flare中，fiber是如何构造析构以及如何它的两种launch策略。
一些名词解释：
标题起得有点唬人，但问题出自公司内的一个陈年老bug，表象是"atomic 不原子"。根本原因是在给原子变量分配内存时出现了跨cacheline分配。具体见下面的例子：
公司内项目为了提升性能，做的其中一个优化是上了协程+io uring。 我们选择的协程库为 腾讯开源的flare。 本文分析flare的fiber是如何做上下文切换的，即用户态的context switch。
在flare中，一个用户态线程命名为fiber，所以本文也即分析fiber是如何做context switch的。
RDB 是redis持久化方式的一种。 本文介绍其实现原理，内容包括：