神技圈子的博客

对GlusterFS如何实现最终一致性进行了源码讲解

未提交读是一种禁止脏写（dirty writes）的一致性模型，即两个事务在提交之前同时修改同一个对象。在 ANSI SQL 规范中，未提交读被认为是默认的、最宽松的一致性模型，允许所有行为；然而，等人 认为 ，它实际上应该禁止脏写。未提交读是一种事务模型：操作（通常称为“事务”）可能涉及按顺序执行的多个基本子操作。它还具有属性：操作可以作用于系统中的多个对象。读取未提交可以完全可用：在存在网络分区的情况下，每个节点都可以取得进展。

读已提交是一种一致性模型，它通过防止脏读来加强读未提交：事务不允许看到未提交的事务的写操作。已提交读取是一种事务模型：操作（通常称为“事务”）可以涉及按顺序执行的几个基本子操作。它还具有属性：操作可以作用于系统中的多个对象。已提交读可以完全可用：在存在网络分区的情况下，每个节点都可以取得进展。在不牺牲可用性的情况下，你还可以通过选择更强的单调原子视图来确保事务效果一起被观察到。为了提高性能，您可能希望允许脏读，并放宽到未提交读。请注意，已提交读取不会施加任何实时约束。

单调原子视图是一种一致性模型，它通过阻止事务观察先前提交的事务的部分（但不是全部）影响来增强已提交的读取。它表达了 ACID 中的原子约束，即事务的所有（或全部）影响都应发生。一旦事务 T2 观察到事务 T1 的写入，那么T1的所有影响都应该对 T2可见。这在强制执行外键约束和确保索引和物化视图反映其底层对象时特别有用。单调原子视图是一种事务模型：操作（通常称为“事务”）可以涉及按顺序执行的几个基本子操作。它还具有属性：操作可以作用于系统中的多个对象。

是一种一致性模型，它通过防止丢失更新来增强读取提交。它引入了游标的概念，游标指的是事务正在访问的特定对象。事务可能有多个游标。当事务使用游标读取对象时，该对象不能被任何其他事务修改，直到游标被释放或事务提交。游标稳定性是一种事务模型：操作（通常称为“事务”）可以涉及按顺序执行的多个基本子操作。它也是一个多对象属性：操作可以作用于系统中的多个对象。游标稳定性无法完全实现；在存在网络分区的情况下，部分或所有节点可能无法继续工作。若要实现完全可用性，则以允许丢失更新为代价，请考虑使用已提交读取。

详细讲解了Redis分布式锁的使用和底层源码逻辑

详细讲解了Double Write和Buffer Pool之间的关系和MySQL写入流程

详细讲解MinIO 数据写入流程与分片存储原理

源码讲解minion核心模块（开篇）

分析了redsync的结构定义以及如何使用

基于两类对象的文件类型存储，一类是“对象文件网关型”文件存储，另一类是分布式文件系统存储的区别

详细讲解了leveldb写操作流程

leveldbleveldb是一个写性能十分优秀的存储引擎，是典型的LSM-tree的实现。LSM的核心思想是为了换取最大的写性能而放弃掉部分读性能。那么，为什么leveldb写性能高？简单来说它就是尽量减少随机写的次数。leveldb首先将数据更新到内存中。当内存中的数据量达到一定阈值，将这部分数据再真正刷新到磁盘文件中。一般来说，顺序写60MB/s，随机写45MB/s.整体架构leveldb主要由以下几个重要的部件构成：1.memtable2.immutable memtable3.sst

前言介绍了进程如何基于面向对象的封装，本章我们基于封装好的Process类来实现一种无锁版的生产者和消费者框架，用它实现了高性能文件拷贝功能。读这篇文章之前大家可以想一下如果是你，你会怎么设计这样的框架？在这个模型中作为每个生产者，如何把读取到内容发送给消费者。而作为消费者，如何把接收到的内容写入文件，并且最终保证文件内容是一致的。好了，废话不多说，我们来通过代码看下是怎么设计的吧？生产者消费者模型我们回顾一下什么是生产者消费者模型。这个模型是为了解决在整个程序过程中既要不断产生数据，又要处理数据的

前言阿里云今年春招校招面试题，面试官问Redis在是如何使用跳表的？让很多同学赶到很头疼。今天我们就来讲一讲吧。Sorted Set的结构redis的数据类型中有序集合（sorted set）使用非常广泛，本身具有集合的功能，同时又可以支持集合带权重，并且按权重排序。它可以通过ZRANGEBYSCORE按照元素权重返回一个范围内的元素，或者通过ZSCORE返回某个元素的权重值。它能以常数复杂度返回元素的权重，相信很多童鞋都能想到是采用了哈希表索引。而能支持范围查询如何做到的呢？那就得说到今天的重点跳表

一文搞懂MySQL XA如何实现分布式事务前言XA 协议如何通过MySQL XA实现分布式事务前言MySQL支持单机事务的良好表现毋庸置疑，那么在分布式系统中，涉及多个节点，MySQL又是如何实现分布式事务的呢？比如开发一个业务系统，它接受外部的请求，然后访问多个内部其它系统才能执行该请求。执行时我们需要同时更新多个数据库的值（D1,D2,D3)。由于系统必须处于一个一致性，也就是这三个数据库的值要么同时更新成功，要么全部不更新。不然会造成子系统有些指令成功了，有些指令尚未执行。导致对结果理解混乱。那

这里写自定义目录标题前言前言为什么不用char*前言这里写自定义目录标题前言前言为什么不用char*前言字符串在日常开发中应用得比较普遍，对于Redis来说，键值对中的键是字符串，值也是字符串。比如在Redis中写入一条客户信息记录姓名、性别、爱好等。在Redis这种内存数据库中，由于字符串被广泛的应用，在设计字符串时基于以下几点来设计：1.支持丰富高效的字符串操作，比如追加、拷贝、比较等2.能保存二进制数据3.能尽可能的节省内存开销可能会有人问了，既然C语言库提供了char*这样的字符

文章目录前言三种优化过的数据结构SDS 设计**redisObject 结构体****嵌入式字符串**ziplist 设计intset 设计共享对象前言Redis 作为内存数据库，如何高效地使用内存非常重要。为了提升内存的使用率，主要采取数据结构优化设计及使用以及内存数据按照规则淘汰。内存数据按照淘汰规则主要通过 Redis 的内存替换策略实现的，也就是将很少使用的内存数据淘汰，这样就可以更好地把内存空间给频繁使用的数据使用。下面，我们就通过源码讲解下 Redis 中内存友好的数据结构是如何设计的以及R

面试还原技面第二轮面试题问到了LSM-Tree是如何实现加速随机写的。不是存储研发方向的童鞋们一看这个题可能会一脸懵逼，可能会疑惑什么是LSM-Tree啊，以前只听过红黑树、B+树。那么，这个数据结构又有什么特点，为什么能用来对随机写进行加速的。什么是LSM TreeLSM树（英文全程Log-Structured Merge Tree）它是一种分层、有序、面向磁盘的存储结构。先看Log Structured表示日志结构的，日志是软件或者系统打出来的，就像平时写日记一样，一页页往下写，系统写日志不会写错

背景一面在考查技术基础首先被问到过raft协议如何选主？主挂了选出的新主如何重新进行日志复制？raft协议一直都是分布式系统一致性的难点，能讲清楚很不容易，下面我们就通过现场还原的方式讲讲该如何回答这两个问题的。现场还原Q1面试官：那你先说一下raft协议是如何选主吧？A1 我：为了保证数据一致性，最好的方式是唯一节点去读，唯一节点去写。这样的数据肯定是一致的。但是分布式架构显然不可能一个节点处理。因此raft提出在集群的所有节点中需要有一个节点来充当这个唯一节点，在一段时间内，只有这一个节点负

实现分布式事务原子性的协议一说到事务，一般就会想到ACID特性，其中A（atomic）其实就是指事务的原子性。那么什么是原子性呢，简单来说原子性就是要求事务只有两个状态：一是成功，也就是所有操作全部成功二是失败，任何操作没有被执行，即使过程中已经执行了部分操作，也要保证回滚这些操作。其实要做到原子性并不容易，因为多数情况下事务是由多个操作构成的序列。而分布式事务原子性的表现与普通的事务原子性一致。分布式事务要涉及多个物理节点，而且还增加了网络这个不确定因素，使得要满足分布式事务的原子性问题更加复

强一致性和最终一致性如果部门想做一个业务数据的实时分析系统，希望数据写入成功后就能马上读取到最新的数据，其实就是要实现一个强一致性系统，数据更新后能立即查询到。那么，在这里面首先要搞清楚强一致性和最终一致性有什么区别。强一致性：保证写操作完成后，任何后续访问都能读取到最近更新成功后的数据最终一致性：如果对某个对象没有新的写操作了，最终所有后续访问经过一段时间后都能读到相同的最近更新的值。也就是说，写操作完成后，后续访问可能会读到旧的数据。什么是Quorum NWR如果为了这么一个临时需求重新

前言Redis具有高可靠性，一般来说，其实指两层意思。一个数据尽量少丢失，二是服务尽量少中断。AOF和RDB保证了前者，而对于后者，Redis的做法是增加副本冗余量，将一份数据同时保存在多个不同的实例上，即使有一个实例出现了故障，需要过一段时间才能恢复，其他实例也可以对外提供服务，这样就不会影响业务使用。这么多实例保存同一份数据，听起来挺好。但是我们必须考虑一个问题，这么多副本，它们之间的数据如何保持一致呢？数据读写操作可以发给所有的实例吗？主从库模式实际上，Redis提供了主从库模式，以保证数据副

前言通常来说redis是单线程，主要是指redis的网络IO和读写键值对是由一个线程完成的。这也是redis对外提供键值存储服务的主要流程。但是其它功能，比如持久化，集群数据同步等，其实是由额外的线程执行的。所以，redis并不是完全意义上的单线程，只是一般把它成为单线程高性能的典型代表。那么，很多小伙伴会提问，为什么用单线程？为什么单线程能这么快。redis为什么用单线程首先我们要得了解下多线程的开销问题平时写程序很多人都觉得使用多线程，可以增加系统吞吐率，或者增加系统扩展性。的确，对于一个多线

前言为了提升系统的高并发情况下的性能和吞吐率，一般采用IO多路复用模型。IO多路复用包括Select，Poll和Epoll三种方式，Epoll是目前使用较为频繁的机制。Epoll是Linux内核为处理大批文件描述符而改进的poll，相对于select和poll，Epoll有以下两个优势：支持理论上无限大的socket描述符select限制了每个进程打开的socket描述符，例如Linux系统在linux/include/linux/posix_types.h中定义了_FD_SETSIZE为1024，

大厂面经分享——来聊聊我的阿里云P7面试经历背景一面：简历面试二面：基础技术面三面：交叉面四面：Boss面总结背景  这篇文章为了记录下自己工作历程里面的一些面试经验，同时对于那些想了解大厂情况的童鞋希望也能有个借鉴。本文来自于个人经历，有些地方可能同你以前获取的经验有所出入，请权当参考。  我面的阿里云后端存储开发岗，职级P7。大概花了三周时间，一共经历了三轮技术面，一次笔试，一次BOSS面。下面就根据面试先后顺序，分享下我的面试经历。一面：简历面试  面试觉得简历还合适的话，就会先找你大

背景大多数分布式KV存储作为存储引擎的时候，在对数据分片的时，为了实现每个分片的高可靠性、高可用和强一致性，一般采用Raft协议来实现，这个Raft协议，它是一个理论基础，实现了集群的自我控制和自我选举来解决高可用的问题。它是一个被广泛采用的，非常成熟的一致性协议。比如etcd就是基于Raft来实现的。掌握了这个算法，可以得心应手地处理绝大部分场景的容错和一致性需求。比如分布式配置系统，分布式NoSQL存储等等，轻松地突破系统的单机限制。下面的章节中，不仅会介绍Raft的原理，还会通过基于Raft算法的

背景该系列的前面章节介绍了分布式存储的数据如何完成分布式存储，而本章将聚焦于分布式存储后是如何保证数据可靠性的。可靠性是存储的重要指标之一，如果数据丢失所造成的损失是无法想象的。常规情况下，我们一般使用多副本技术来提高存储系统的可靠性，多副本就是把数据复制成多份并分别存储到不同地方以实现冗余备份。理论上来说数据存的份数越多，可靠性也越高，但是可用空间也在随之减少。举个例子，100T的空间如果按2副本来存数据，那么只能存50T的数据（50T2=100T），现在副本数加大，改为存5副本，那么久只能存20T的数

背景作为k-v存储的开山鼻祖，Dynamo从亚马逊研发出来之后就在存储领域引起了轰动。理论上说Dynamo可以无限扩容，且性能是无限线性递增的(后面会将为啥理论上讲是无限线性增长)。Dynamo的动态伸缩让系统的scale-out能力极强。Dynamo延伸出dynamoDB作为nosql 领域的代表DB。Dynamo保证系统无限扩展且同时性能不下降的关键，是让整个存储集群没有中心节点，扩容的所有的节点都能负载均衡，跟集群里面的其他节点对等。要实现这样的能力，需要依赖一种数据的均匀分布的算法，该算法够随机并

前言之前写了篇Basic Paxos的文章，大家阅读了后应该就知道了Basic Paxos只能就单个值（Value）。假设需要对一系列值达成共识的话

什么是Paxos算法一致性就是数据保持一致，在分布式系统中，理解为多个节点中数据值的一致。而一致性又分为以下两种强一致性弱一致性Paxos算法就是著名的强一致性算法。它有一个假设前提，在分布式系统中进程间通信会出现延迟、丢失、重复等现象，但是不会出现传错的现象。而Paxos就是为了保证在这样的系统中进程间基于消息传递就某个值达成一致。其实在过去很长一段时间，Paxos算法可以说是分布式共识的代名词，当前最常用的一批共识算法，比如，Fast Paxos算法，Cheap Paxos算法，R

随着数据库应用的不断发展，数据规模逐渐升级，为了提高效率，往往会将多个事务并发的执行。而多个事务并发可能会同时存取同一数据，产生数据不一致的情况：读“脏”数据，不可重复读等。所以数据库管理系统（Database Management System，DBMS）必须提供并发控制机制，使得并发的事务在冲突的时候被串行化执行。这种调度称为可串行化调度。 通过时间戳的调度规则通过比较时间戳来判定读写请求是否被允许。与封锁相比，时间戳规则采取一种乐观的方式，假设事务所有操作都是可串行的，只有操作确实导致了非可串行化行

性能分析运行环境CPU： Intel® Xeon® CPU E5-2603 0 @ 1.80GHz内存：2049316 kBLinux版本：25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/LinuxReed_Sol_Van基于原始范德蒙矩阵的rs纠删码，生成矩阵由范德蒙矩阵构造，将原...

Bigtable作为一个分布式存储平台，能够可靠的扩展存储PB级的数据，并分布到上千台服务器上。适合多种应用，从需要高吞吐量的批处理工作到延时敏感的实时性服务（Bigtable是如何达到这些目的的？在架构上是如何体现的？），具有良好的可伸缩性、高效性、高可用性、高性能（如何达到这些目的？如何设计的？）。一致性、可靠性的问题，论文中没有提到（如何做到这些？依靠底层GFS，还是依靠上层应用的设计？...

整体架构及流程fuse为多线程并发模型，每个worker线程都在读取/dev/fuse中的请求，这样就保证线程之间的同步，当读取到一个请求之后，线程就开始处理该请求，但如果监听线程为0，则继续创建新的线程进行监听，处理完请求之后，如果线程的数量超过限制(10个)，就退出该线程。整个框架如下： worker线程通过请求派发函数fuse_ll_process派发请求之后，根据opcod...