上篇文章中我们探索了同步 IO 的来龙去脉。本篇文章将踏入异步 IO 王国,研究磁盘 IO 的异步编程。
在扩展到分布式之前,我们先来弄明白单机 IO 的手段。同步/异步/Poller/线程池,眼花缭乱的名词,是否在故弄玄虚?
本文翻译自 https://lwn.net/Articles/457667/ 原文标题: Ensuring data reaches disk 理想情况下,不会发生操作系统的崩溃和断电,磁盘也不会发生故障。但不幸的是,故障比预期更为常见。本文描述了从应用程序到数据存储的路径。重点介绍数据缓冲部分,提供最佳实践,以确保数据被提交到稳定的持久化存储中,避免发生问题时中途丢失。
使用 raft + 单机 KV 引擎构建分布式 KV 存储,是一种常见的方式。比如 TiKV, CockroachDB 等。本文重点讨论如何进行 raft snapshot。
braft 是一个较多人使用的 C++ raft 框架。开发者基于其抽象接口实现自己的业务逻辑,方便实现 raft 高可用的服务。本文从 metrics 入手,梳理开发者应该持续关注哪些监控变量。以其为线索,阅读源码探究其实现原理。力争做到心里有谱,不惧异常。
项目使用 tikv 作为分布式 KV 引擎构建了元数据服务。随着业务增长,P99 延迟急剧升高。在调优 tikv server 收获甚微后,我们把目光转回 tikv-client,结合源码和线上 metrics 分析可能的瓶颈和优化手段。
我们思考了很久,如何筹备一场新人和宾客都能沉浸其中的婚礼。“简单、自由、快乐、分享” 成为了主题。我们找到了生活的答案,并邀请朋友们一同见证。
作为 go 开发者,我们可能忽略了一名英雄:在内存垃圾标记之后,拾荒器 (scavenging) 最终负责把无用内存归还给操作系统。本文结合例子和源码,分析 go scavenging 的策略,为内存关键型程序提供一些小建议。
Stream Layer 扮演 WAS 数据存储的角色。本文阅读论文,思考并学习 stream/extent 的实现机制。
本系列文章是笔者阅读微软存储系统论文 《Windows Azure Storage: a highly available cloud storage service with strong consistency》的笔记和思考。
本文中,我们将探究 Linux 中 cpu 使用率 iowait 定义和计算方式。iowait 很高的系统,一定存在 IO 瓶颈吗?通过实验验证和讨论了综合观测系统的 IO 压力的方式。
限流器是服务治理的重要一环。但常见的讨论集中于对 频率 的限制。本文结合笔者最近的需求,分析 Go 官方限流器 time/rate 的实现原理,结合实践对 带宽/流量限制 可能遇到的问题进行讨论。
近一个月从底层翻阅了 Apache Traffic Server 的磁盘缓存引擎,俞发觉得精妙。另外自己在开发的 web 代理缓存 hitori 中,也确实需要一款大容量磁盘缓存引擎。便实现了一个磁盘缓存引擎库,名字叫做 bakemono。