ITPub博客

1.背景今天刚开始接触paxos（basicpaxos）的时候，真的是觉得其超级晦涩，总感觉不解其意，其实主要还是对其核心解决的问题本身理解不够到位。也就是要很好的理解Paxos，首先需要理解Paxos解决的是什么问题。在描述之前，我们先统一一个词汇，那就是共识（consensus）和一致性（con

ClosingPerformanceGapBetweenVolatileandPersistentMemory

1.背景阅读USENIXATC2018《RedesigningLSMsforNonvolatileMemorywithNoveLSM》[1]笔记Non-volatilememories（NVM）特点（例如Intel的3DXPoint技术）随机read/writelatency很低throughput

1.背景以LevelDB和RocksDB为代表的LSM-treekey-value存储，被广泛的应用，所以当前针对其优化的研究非常多，在最近几年的顶会上都有，这里将介绍USENIXATC2018的一篇文章HashKV[2]，其是对FAST2016中WiscKey[1]的优化。那么首先来介绍下LSM-

1.背景在共识算法之Multi-Paxos（一）中翻译了multi-paxos详细算法流程和细节，本篇作为（二）篇将通过图文来分析multi-paxos其各个模块的细节，Leadelection，CommitIndexAdvance，LogReplication等。主要还是参考文献[1、2、3]。为

1.算法描述当前multi-paxos没有权威的文献参考，目前大多采用的参考文献[1]的描述，这里首先给出其翻译版，然后分析其各个模块的细节，Leadelection，CommitIndexAdvance，LogReplication等。（背景图片来自[2]）1.1.服务器状态所有acceptor上

1.背景以LevelDB和RocksDB为代表的LSM-treekey-value存储，被广泛的应用，所以当前针对其优化的研究非常多，在最近几年的顶会上也是常有的话题，这里将介绍USENIXFAST2016的一篇文章《WiscKey:SeparatingKeysfromValuesinSSD-Con

1.背景这是阅读微软在ICDE2013的论文《TheBw-Tree:AB-treeforNewHardwarePlatforms》的笔记。论文主要阐述了一个高性能的atomicrecordstores(ARSs)系统的实现，也就是提供原子key-value访问接口的系统。主要是提出了Bw-tree，

1.Background以LevelDB和RocksDB为代表的LSM-treekey-value存储引擎在生产环境中被广泛应用，所以当前针对其优化的研究也非常多，在最近几年的顶级会议上也是热门的话题，本篇就是阅读sosp2017《PebblesDB:buildingkey-valuestoresu

好久之前为解决一个LevelDB数据膨胀的问题（也就是垃圾数据得不到回收），梳理过一遍LevelDB的源码，探究其Compaction的机制，以便分析出LevelDB垃圾数据不能得以回收的原因，也参考过很多网上的资料，但是都不够系统，所以决定再抽点时间把LevelDBCompaction的机制单独梳

0.概述好久前读过@郁白老师写的Paxos三部曲[1]，当时也是似懂非懂的，其中描述了Paxos一个经典的问题就是幽灵复现。后来在实际接触了一些一致性协议的东西，又看到了文献[2]，@陈宗志重新梳理了这个问题，分析了raft解决“幽灵复现”其实就是解决分布式系统中常见的第三态问题。自己也打算“新瓶装

原题目：Write-OptimizedandHigh-PerformanceHashingIndexSchemeforPersistentMemory文章概况：这篇文章主要研究Persistentmemory上高性能的hashing索引技术这篇文章是来自华中科技大学，好像实现了零突破。上交IPADS

阅读OSDI2018《Fault-Tolerance,FastandSlow:ExploitingFailureAsynchronyinDistributedSystems》觉得有点意思，所以在这里分享给大家，可以加深自己对共识算法的理解。1.Introduce在分布式系统中，通常会将数据复制到2n

1.IntroducePacifica是微软2008年发表的一个通用的复制框架，早于raft（2014），其具有简单、实用和强一致（strongconsistency）的特点。Pacifica的出现主要就是为了解决一致性复制协议（Paxos）理论和工程实践之间的gap，也就是基于Paxos的一致性复

IntroduceEtcd是一个建立在分布式kv基础之上的分布式配置管理服务软件，其分布式数据一致性复制是采用的raft。今天将和大家一起学习下Etcd对ReadOnly请求是如何处理的，鉴于其他的博文中已经有关于ReadIndex的实现介绍，这里将只为大家介绍Leaseread。首先回顾下raft

来自NSDI2019《ExploitingCommutativityForPracticalFastReplication》的idea，主要工作是对数据多副本一致性复制协议latency的优化，觉得有点意思，在这里分享给大家，*压压惊*，毕竟最近江湖腥风血雨，不太平。1.Introduce为了保证分

0.前言条件变量（conditionvariable）和互斥锁（mutex），这两个寻常百姓人家常用的同步工具，想必大家都不陌生。但是在最近遇到的关于条件变量和互斥锁错误使用的bug，才发现自己之前对条件变量的理解不够深入，可以尝试问自己这个问题：为什么条件变量和互斥锁总是搭配着使用？互斥锁的作用是

1.背景面对海量数据的时候，单个节点存放不下，自然需要将数据切成分片Partations，存放到多个节点上（这里的Partation在MongoDB中被称为分片(shard),在HBase中称之为区域(Region)，Bigtable中则是表块（tablet），Cassandra中是虚节点（vnod

1.介绍对于通常的互联网应用来说，read、write比例通常在8:2，所以提升read的性能是至关重要的，通常的做法是采用更快的介质作为更慢介质的Cache，在计算机系统中Cache的应用非常常见，例如：CPU有L1、L2、L3级缓存作为内存的Cache，文件系统有PageCache，使用内存作为

1.介绍常见的Loadbalance算法想必大家都不陌生，Random、Round-robin、Leastconnection、Consistenthash等应该都耳熟能详，这些算法都在实践中有广泛的应用，例如Nginx、Haproxy等负载均衡模块都有相应算法的实现。本文将和大家分享一种全新的Lo