东东儿的博客

etcd备份恢复方案及原理介绍

linux内存监控指标

整篇文章在今天看来没有太新的东西，不过在当时，能用不高的代价，来解决遇到的问题，就很棒。简单记录一些要点。背景是facebook请求太多，数据库处理不过来，所以需要用缓存来解决。但是集群太大，使用单机的memcache搞不定，facebook借助开源的memcache，实现了缓存集群。使用了缓存删除策略，即修改数据库数据时，将缓存中的对应key删除，不使用更新策略的原因是容易出现并发问题，导致缓存和数据库最终不一致。降低延迟，使用udp来实现读请求（不怕丢），使用tcp来实现数据修改请求。客户端

工作中使用了raft用来做数据高可用，raft框架是使用百度开源的braft。1. 更有效的snapshot工作中使用了braft，数据状态机使用了rocksdb，是很常见的一种搭配形式。braft是定时会做一次snapshot，对于braft而言，snapshot就是将数据状态机中的全量数据backup一份到braft文件夹中管理起来，在follower需要时发送给远端，或者重启时使用。对于rocksdb而言将数据backup一份到其他文件夹中也非常方便，rocksdb会使用硬链接将当前的所有sst

阅读思路：分布式事务的一个研究型系统（不是已经落地的工程实现）与spanner不同之处在与 spanner可以跨数据中心，论文中的FaRM系统只能在单数据中心，但是性能非常高。首先高性能的原因来自于两个不同的硬件：非易失性的DRAMRDMA（remote direct memory access）非易失性内存的意思大概是普通的DRAM外挂了电源，在机器断电的情况下，外挂电源会生效（但是可能仅能支持很短一段时间，也许是几分钟），在外挂电源生效时，进程会停止工作，将DRAM中的数据全部落盘，然后

之前读过一些raft工程源码，如etcd，braft，Dragonboat中都对进行了相应的工程优化，如并行落盘，batch，pipeline等，witness节点等，实现了一些小论文中没有详细描述的功能，leader变更，成员节点变更等。这些功能及优化在raft作者的博士论文《CONSENSUS: BRIDGING THEORY AND PRACTICE》中都有提及，近期阅读了其中部分段落，记录一下。1. transfer leaderleader节点的变更在工程中还是一个比较重要的功能。按照论文中所

如何理解True Time外部一致性是什么？为什么需要时钟？为什么True Time可以保证外部一致性?True time的理论非常简单，具体介绍可以参考spanner论文，或者这篇博客：http://yang.observer/2020/11/02/true-time/1. 外部一致性是什么？这个词好像只在spa