东哥和系统设计开荒小分队的基地
我们在分析各种分布式系统场景时不可避免地会讨论到数据的读写，很多时候我们会对数据的读写做很多的优化和特殊处理，而这些操作的背后根源都离不开数据存储的硬件，本文就来和大家谈一谈这其中设计的各种硬件和相应的技术。 Cache和读写 我们都知道把数据放到内存中，这样有读请求过来的时候就可以直接从内存中读取到相关数据（hit cache的情况），而不需要去访问具体的物理磁盘，从而减少了disk I/O的操作。同样地，写也可以写到内存中，只是和读不同的是，内存写终究只是一个中间状态，你最终还是要写到磁盘中才行，所以内存到写操作来说只起到一个delay的作用（当然假如你没有persist保存的情况下，可能也不需要写到磁盘，但我们讨论正常的需要persist保存的情况）。...
本周讨论话题由Stephen Zhao以及Morgan Wu主讲，相关内容总结如下： Stephen的Slides：K8s Introduction。...
我们在研究分布式文件系统的实现时，不可避免要讨论MapReduce技术。比较常见的使用这一技术的有HDFS (Hadoop Distributed File System)，它是Google文件系统GFS的开源实现。当然很多别的分布式文件系统，比如GlusterFS，QFS（Quantcast...
本周我们完成了关于监控系统metric实现的讨论，相关资料总结如下： 晓东使用的架构图：《我经历过的监控系统演进史》 一篇很好的讨论监控系统实现的文章：《A Tricky System...
在我们详细深入介绍MySQL的方方面面之前，让我们首先来看一下MySQL的总体架构，从总体上对MySQL有所了解，这样我们在后面的具体介绍部分的时候才能够知道这些部分属于哪个模块，大概有什么样的作用。 MySQL的逻辑架构 首先我们来看一下MySQL的逻辑架构，如下图所示。 我们可以看到大概可以分成三层： Connection/thread...
工作几年，曾经青涩的你也脱去了稚嫩，写代码（Bug）的水平与日俱增，渐渐成为了组里面的顶梁柱。有时看着镜子里日益稀少的头发，你也许会告诉自己是时候该考虑转一下Manager了。于是你和你老板多次提起，是否有转管理的机会。皇天不负有心人，在一个风和日丽的早晨，老板把你喊进办公室，让你当一个新人的Mentor，磨炼一下管理的能力。一下子接到任务的你，是否真的掌握了作为一个Mentor该具有的技能了呢？本文就来唠叨唠叨该怎么做一个Mentor以及可能遇到的问题和解决方法。 成为一个Mentor 假如你有机会成为一个Mentor，首先恭喜你，这是一个表现的好机会，一般来说只要你不去打你的Mentee，基本不会因为这件事做得不好而被解雇，所以可以说这是一个只赚不亏的买卖。尽管如此，显然我们还是希望能够很好地做好一个Mentor。 一般来说会有两种Mentor，一个是Intern的Mentor，一个是新人的Mentor。这两者稍有差别，我们一个一个为你慢慢道来。 Intern的Mentor...
我们现实工作中很多时候想知道当前服务器的各项性能指标，比如说CPU的使用率是多少，还有多少内存，各个磁盘的IO是什么样的情况等等。假如我们使用的是windows操作系统，那么它其实已经内置了一个很强的性能监控系统，本文就来介绍一下我们如何使用这个性能监控系统。 Windows Performance counter系统介绍 总得来说Windows...
我们在前面《分布式系统中的Linearizability一致性的概念介绍》介绍了Linearizability的基本概念，本文就来详细介绍一下我们如何来实现Linearizability。 我们再来简单回忆一下Linearizability的介绍，他其实就是说所有的replica都像只有一个一样，那么我们是否有个暴力解，就是真的只有一个拷贝，没有replica，这样不就是Linearizable的了？你是对的，哈哈，不过这个显然不是我们想要的答案，毕竟这样一来，如果这个节点出了任何问题，你整个读写就都不能继续了。 那么我们先来看看各种分布式的模型，看看他们能不能Linearizability： 单leader的replication 在单leader的系统中，假如读都是从leader来的话，或者你使用同步更新replica，那是有可能实现Linearizability的，但是注意也只是有可能，毕竟有可能leader出问题，比如leader自己还认为自己是leader，但事实上已经不是了，这种情况就有可能不是linearizability了。...
分布式系统中一致性一直是一个大家热衷讨论的话题，这里的一致性是指假如你同时到两个节点读取数据，你很可能看到的是不同的数据。毕竟发生在一个节点上的写操作同步到另外一个节点总是需要时间的。 我们最常见的说法就是“最终一致性”，也就是说假如没有写操作，所有的节点在一段时间之后就会一致了。目前大多数的数据库都是支持这种一致性的，但是这个一致性非常弱。你仔细想想它其实什么都没有保证，比如你写了一个数，你再去读，读到什么值根本就没有任何保证，只是说你最终能读到一致的值，这个最终是多长时间之后谁也不知道。所以说这样的“最终一致性”其实给应用开发带来了很多困难，也有可能导致很多Bug。 那么有没有什么更强的一致性保证呢?答案是当然有，但是需要注意的是一致性越强，它的性能或者错误容忍度就会越差，毕竟十全十美总是很难。本文就来介绍一种强一致性技术：Linearizability。 概述 我们上面提到在一个“最终一致性”的系统中，你同时访问不同的数据replica，得到的值可能是不同的。那么能否有一种机制保证我们任何时候访问同一个数据replica得到的值一直都是相同的呢？这种保证的就是Linearizability背后的思想：任何时候整个系统就像只有一个拷贝一样，不管你访问哪一个replica，得到的结果都是一样的。...
我们知道分布式系统中各个服务器都是通过网路进行连接的，这样导致的结果就是你很难知道各个服务器的真实状况，比如你判断另外一台服务器是否有问题的唯一办法就是发送一个请求给他，只有收到了回应，你就认为它是好的，假如没有收到回应，你就很难判断对面的服务器是否有问题，因为这个没有回应很可能是发生了网络故障，也可能是对端机器真的出问题了。因此，在分布式系统中我们如何来准确判断这些问题呢？本文就来详细介绍相关的方法。 基于多数的（Majority）事实 很多时候我们一个节点可能不是真的有问题，比如说它正在进行GC，那么在GC的这段时间内它就不能回应任何请求，这个时候从节点本身的来看，它自己是很ok的，没有任何问题。然而从别的节点来看，这个GC的节点就和出问题的节点一模一样，发请求它不回，重试也没有反应。所以别的节点就会认为它是有问题的。从这个角度来看，节点本身其实也是很难知道自己是否问题的。 现在比较流行判断节点是否有问题的算法都是基于多数的决策，比如说我有5个节点，那么大家一起来投票，假如有超过一定数量的节点（一般来说超过半数，这里就是有三个节点）认为它有问题，那么我们就认为这个节点是真的有问题。哪怕这个节点本身是没有问题的，但是只要有多数认为有问题，我们就认为它有问题。这里使用多数来决定是因为多数就意味着不会有冲突，因为一个系统中不可能存在两个多数，只可能有一个。 Leader和Lock...
Follow:
More
Recent Comments