ITPub博客

InnoDB 和大部分的存储引擎一样, 都是采用WAL 的方式进行写入数据,所有的数据都先写入到redo log, 然后后续再从buffer pool 刷脏到数据页又或者是备份恢复的时候从redo log 恢复到buffer poll, 然后在刷脏到数据页,WAL很重要的一点是将随机写转换成了顺序写,

分布式存储系统中面临着的首要问题就是如何将大量的数据分布在不同的存储节点上，无论上层接口是KV存储、对象存储、块存储、亦或是列存储，在这个问题上大体是一致的。本文将介绍在分布式存储系统中做数据分布目标及可选的方案，并试着总结他们之间的关系及权衡。

​从Zeppelin：一个分布式KV存储平台之概述的介绍中我们知道元信息节点Meta以集群的形式向整个Zeppelin提供元信息的维护和提供服务。可以说Meta集群是Zeppelin的大脑，是所有元信息变化的发起者。每个Meta节点包含一个Floyd实例，从而也是Floyd的一个节点，Meta集群依赖Floyd提供一致性的内容读写。本文将从角色、线程模型、数据结构、选主与分布式锁、集群扩容缩容及成员变化几个方面详细介绍，最后总结在Meta节点的设计开发过程中带来的启发。

通过上一篇Zeppelin：一个分布式KV存储平台之概述的介绍，相信读者已经对Zeppelin有了大致的了解，这篇就将详细介绍其中的存储节点集群（Node Server）。存储节点负责最终的数据存储，每个Node Server会负责多个分片副本，每个分片副本对应一个DB和一个Binlog。同一分片的不同副本之间会建立主从关系，进行数据同步，并在主节点异常时自动切换。本文将从请求处理、线程模型、元信息变化、副本同步及故障检测来展开介绍，最后总结在存储节点的设计开发过程中的两点启发。

过去的一年多的时间中，大部分的工作都围绕着Zeppelin这个项目展开，经历了Zeppelin的从无到有，再到逐步完善稳定。见证了Zeppelin的成长的同时，Zeppelin也见证了我的积累进步。对我而言，Zeppelin就像是孩提时代一同长大的朋友，在无数次的游戏和谈话中，交换对未知世界的感知，碰撞对未来的憧憬，然后刻画出更好的彼此。这篇博客中就向大家介绍下我的这位老朋友。

线性一致性（Linearizability）是分布式系统中常见的一致性保证。那么如何验证系统是否正确地提供了线性一致性服务呢？本文希望从‘什么是线性一致性’，‘如何验证线性一致性’，问题复杂度，常见的通用算法，以及工程实现五个部分，直观、易懂地回答这个问题。

数据库事务隔离发展标准一文中，从标准制定的角度介绍了数据库的隔离级别，介绍了Read Uncommitted、Read Committed、Repeatable Read、Serializable等隔离级别的定义。本文就来看看究竟有哪些常见的实现事务隔离的机制，称之为并发控制（Concurrency Control）。