原名： 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策略。

一些名词解释：

• Fiber： flare对外的有栈协程调度实体
• FiberDesc： flare内部，用于描述一个fiber任务的元数据结构，该结构不包含fiber运行起来时的stack
• FiberEntity：flare内部，用于表示一个真正运行的Fiber的实体，可以理解为linux中的task struct。包含运行时的stack。

标题起得有点唬人，但问题出自公司内的一个陈年老bug，表象是"atomic 不原子"。根本原因是在给原子变量分配内存时出现了跨cacheline分配。具体见下面的例子：

背景·

公司内项目为了提升性能，做的其中一个优化是上了协程+io uring。 我们选择的协程库为 腾讯开源的flare。 本文分析flare的fiber是如何做上下文切换的，即用户态的context switch。

在flare中，一个用户态线程命名为fiber，所以本文也即分析fiber是如何做context switch的。

RDB 是redis持久化方式的一种。 本文介绍其实现原理，内容包括：

• redis 保存 RDB和 加载RDB的方式，SAVE和BGSAVE的实现原理
• RDB自动保存原理
• RDB文件的组成部分

最近在给公司项目做编译优化，因为编译时间实在是太长了，导致合代码ci效率太低。本文主要是给整改中遇到的一个坑的总结。考虑以下编译case:

其中 liba, libb, libc 均可能是static lib , shared lib。不同的排列组合，可以有不同的结果。有些导致无法编译，有些可以编译但是不能运行。