分布式架构

一、前言 　　 在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。 二、集中式系统 　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。 三、分布式系统 　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点 　　 3.1 分布性 　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。 　 　3.2 对等性 　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的， 副本 指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。 数据副本 是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。 服务副本 是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。 　 　3.3 并发性 　　同一分布式系统中的多个节点

　　　 我的探索历程 　　 这一部分，与分布式不大相关，记录的是我是如何在分布式学习这条道路上摸索的，不感兴趣的读者请直接跳到下一章 。 　 　 过去的一年，我在分布式 学习 这条道路上苦苦徘徊，始终没有找到一个好的学习方法，一个能激励我持续学习的方法。 　　当然，我也在不停的反思，最先发现的问题是学习不系统，东看看，西看看，看过就忘。于是写了一篇文章《 带着问题学习分布式系统 》提出了一些问题，然后写了两篇文章来回带自己提出的问题。回过头看，其实这两篇文章都是基于分布式存储的。 　　然后接下来，又是一段时间的迷茫，不知道要学习啥（也是在学习Paxos的时候遇到了阻碍），偶然看到了关于SMART的一些文章，发现原来自己的学习一点都不SAMRT，所以坚持不下去。于是又写了一篇文章《 带着SMART原则重新出发 》，希望给自己设定SMART的目标，结果被博友打脸“一点都不smart”，而且也被结果打脸了，确实没有让我“重新出发”。 　　我也曾经在网上搜索，“如何学习分布式系统“，但并没有找到理想的、或者说适合我的学习方法。网上的答案，都是说，看这些论文，看这些系统的实现。。。或者很多大学的课程，都是罗列出一堆术语：概念、协议、组件。而我觉得，逐个去了解这些术语似乎很无聊，因为不知道为什么要这个协议，或者说这些协议、组件是如何组合起来的。 　　在没有得到适合自己的方案之后，我自己思考

　　很长一段时间，对分布式系统都比较感兴趣，也听说过、了解过其中一些相关的知识点，但都比较零碎。一直想系统的学习一下，但是一拖再拖，写下本文，也是希望能督促自己。 写在前面 　　听过很多道理，却依然过不好这一生。 　　看过很多关于学习的技巧、方法，却没应用到自己的学习中。 　　随着年纪变大，记忆力越来越差，整块的时间也越来越少，于是，越来越希望能够更高效的学习。学习是一种习惯也是一种能力，这种能力在上学期间养成是最好的，毕竟那个时候绝大部分时间都在学习。但很遗憾，我没有养成适合自己的、好的学习习惯。工作之后，除了在日常工作中用到的知识技术，很难通过自学掌握新的知识（偏向于专业知识，即技术）。而互联网行业的分支、知识点又是如此之多，于是会出现这样的情况，遇到一个新的知识，觉得很厉害很感兴趣，看两天，但很快就忘记了。另外，对于一些比较庞杂的技术，又无从下手，也很难坚持下去。 　　根本的问题在于学习不系统，没有把一个个的知识点连接起来，本来这些新的知识就很少在工作中实践，如果又是一个个的信息孤岛，很快就会被遗忘。另一个问题，没有良好的规划，今天看看这里，明天看看哪里，纠结于细枝末节，忘了从整体上把握。 　　幸好，差不多半年前开始意识到了这个问题，开始看书，看别人的博客，开始思考如何充分利用好有限的时间。自己也实践了一些想法，比如写博客，坚持写博客。也有很多没做好

根据阿里云《分布式文件存储系统技术及实现》整理而成。 1 分布式存储的客观需求 存储容量大 考虑对1PB数据进行排序，输入输出都需要1PB，算上中间临时数据，总共需要3-4PB。考虑多用户使用，则集群需要的总的存储空间大于100PB。 高吞吐量，如1PB数据排序需要在2小时内完成，每秒需要几十GB 数据可靠性，在数据规模增长时，降低数据丢失 服务高可用，99.95%意味着每年每年只有4-5小时不可用 高效运维，将日常硬件处理做成流程化，对监控报警要有完善支持 低成本，保证数据安全，正确服务稳定前提下，降低成本，才是分布式存储的核心竞争力 2 小概率事件对分布式系统挑战 单机系统下很少发生的事件，在大规模分布式系统中就会经常发生。 可能发生的小概率问题有： 1 磁盘错误 单机下运行稳定，集群下可能出现频繁。要考虑如何发现慢节点自动规避，发现机器宕机自动绕过。 2 Raid卡故障 发生在高可用节点上的事件。Raid卡是带有电池的缓存块，写入速度很快，能够在断电时保存数据。利用raid卡先缓存数据，之后再写入磁盘中。 3 网络故障 网络架构是一种树形结构，通过顶层交换机连接下层交换机，交换机下连接多台机器。 当上连交换机节点出错时，一部分主机将与其他主机分离，无法发挥作用。 可以将关键角色分布在不同的交换机下，将数据存储多份，某些机器失效时还可以访问到数据。 4 电源故障

一、亚马逊的架构规定 　　最早实践分布式服务化架构思想的公司应该是亚马逊，它早在 2002 年就颁布了下列架构规定，这应该就是 AWS（Amazon Web Service）出现的基础： 　　1. 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。 　　2. 团队间程序模块的信息通信，都要通过这些接口。 　　3. 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链接别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。 　　4. 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。 　　5. 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。 　　6. 不这样做的人会被炒鱿鱼。 　　前面提到过，分布式系统架构会带来很多问题，譬如： 　　1. 一个线上故障的工单会在不同服务和不同团队中转过来转过去； 　　2. 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都做好配额和限流； 　　3. 监控和查错变得更复杂

文章目录 一、Redis 集群结构以及设计理念 1. Redis 集群架构模式有哪几种？ 2. Redis 集群最大节点个数是多少？ 3. Redis 集群的主从复制模型是怎样的？ 4. 请介绍一下 Redis 集群实现方案 5. Redis 集群会有写操作丢失吗？为什么？ 6. Redis 慢查询是什么？通过什么配置？ 7. Redis 的慢查询修复经验有哪些？怎么修复的？ 8. 如何优化 Redis 服务的性能？ 9. Redis 的主从复制模式有什么优缺点? 10. Redis sentinel（哨兵）模式优缺点有哪些？ 11. 如何设置 Redis 的最大连接数？查看 Redis 的最大连接数？查看 Redis 的当前连接数？ 12. 介绍一些 Redis 常用的安全设置？ 二、Redis 缓存管理与持久化机制 1. Redis 持久化机制有哪些？ 2. Redis 持久化机制 AOF 和 RDB 有哪些不同之处？ 3. 请介绍一下 RDB 持久化机制的优缺点 4. 请介绍一下 AOF 持久化机制的优缺点 5. 如果 AOF 文件的数据出现异常， Redis 服务怎么处理？ 6. 常见的淘汰算法有哪些？ 7. Redis 淘汰策略有哪些？ 8. Redis 缓存失效策略有哪些？ 9. Redis 如何做内存优化？ 10. 什么是 bigkey？ 有什么影响？ 11.

实现分布式锁目前有三种流行方案，分别为基于数据库、Redis、Zookeeper的方案，其中前两种方案网络上有很多资料可以参考，本文不做展开。我们来看下使用Zookeeper如何实现分布式锁。 什么是Zookeeper? Zookeeper(业界简称zk)是一种提供配置管理、分布式协同以及命名的中心化服务，这些提供的功能都是分布式系统中非常底层且必不可少的基本功能，但是如果自己实现这些功能而且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上非常困难。因此zookeeper提供了这些功能，开发者在zookeeper之上构建自己的各种分布式系统。 虽然zookeeper的实现比较复杂，但是它提供的模型抽象却是非常简单的。Zookeeper提供一个多层级的节点命名空间(节点称为znode)，每个节点都用一个以斜杠(/)分隔的路径表示，而且每个节点都有父节点(根节点除外)，非常类似于文件系统。例如，/foo/doo这个表示一个znode，它的父节点为/foo，父父节点为/，而/为根节点没有父节点。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。 而为了保证高可用

处理实时的大数据流最常用的就是分布式计算系统，下面分别介绍Apache中处理大数据流的三大框架: Apache Storm 这是一个分布式实时大数据处理系统。Storm设计用于在容错和水平可扩展方法中处理大量数据。他是一个流数据框架，具有最高的社区率。虽然Storm是无状态的，它通过ApacheZooKeeper管理分布式环境和鸡群状态。使用起来非常简单，并且还支持并行地对实时数据执行各种操作。 Apache Storm继续成为实时数据分析的领导者是因为它的易于操作和设置，并且它保证每个消息将通过拓扑至少处理一次。使用storm时常常会设计一个用于实时计算的土状结构，称之为拓扑（topplogy）。将这个拓扑提交给集群之后，集群中的主控节点（master node）将分发代码，将任务分配给工作节点（worker node）。拓扑结构中履行职能的角色有两种：spout和bolt，其中spout发送消息，负责将数据流以tuple元组（不可变数组，固定的键值对）的形式发送出去；bolt则负责转换这些数据流，在bolt中可以完成计算、过滤等操作，bolt之间也可以随机互相发送消息。 下面是Storm的集群设计和其内部架构。 Twitter使用Storm框架处理流式大数据的应用场景： Twitter分析的输入来自Twitter Streaming API。Spout将使用Twitter

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着币价的一直下跌，有传言说，比特币价格此次崩盘，只是大 BOSS 吴忌寒为加速淘汰老旧矿机而祭出的绝招。 无论这个阴谋论真假与否，在整个区块链行业的凛冽寒冬中，价格的涨跌已经左右了太多的人头脑之中的理智。可是，众人之中，究竟有几个人真正理解了区块链技术的密码学机制与分布式计算？究竟有几个人还会关心区块链在技术上的创新？ 尘归尘，土归土。可能只有巨大的泡沫消散之后，区块链才能通过技术创新显示出真正的影响力。让区块链回归技术与应用的本质，这也是我们一直以来的定位。然而，传播这样的内容和话题，离不开货真价实的技术干货，以及有感染力的人物和故事。 我们今天的内容就来自于这样一个女生： 她是工业与系统工程专业出身，做过顶级投行高盛的分析师，做过著名风投 a16z 的合伙人——这都是许多人梦寐以求的工作。但是，功成名就的路上，她却发现编程才是自己想要的生活。 笨办法学会编程？她没学会。如何用 HTML/CSS 做一个网页？她开始上瘾了。所以，没有选择斯坦福、MIT 的编程学位，她更喜欢 Hack Reactor 的全栈动手实践。先学 JavaScript、React，后面的想法是机器学习、计算机视觉……这个女生就是 Preethi Kasireddy。 接触区块链之后，金融从业背景和全栈编程能力让 Preethi

突发奇想，对于数据库，想到了一些有意思的事情和功能，算是对未来数据库发展的一种畅想吧，期待未来有实力的公司或是科研机构能真正实现。 一：分布式操作系统---永动机型操作系统 聊数据库，先要说说操作系统，毕竟数据库要安装部署在操作系统上。 目前应用服务常见的硬故障分为电源、CPU、硬盘、内存、网络等，这些都是常见的、不可抗拒的故障。非分布式操作系统下，各个服务器资源不能最大化的得到合理利用，即使是现在的K8S容器时代，也是这样。目前在应用服务层面，存在读写性能、CPU、内存、网络等瓶颈，但在分布式操作系统下的数据库将突破这些瓶颈，将实现永动机型的应用，永不宕机，资源足够的情况下，各种资源自动弹性伸缩，性能永远没有瓶颈，整体的资源也得到合理的利用，应用服务不再关心硬件问题。 目前实现了文件存储的分布式(如ceph等文件系统),但是还没有实现CPU、内存、网络的分布式，即使只实现文件系统的分布式，也带来了数据库的巨大变革，代表Aurora、PolarDB等，实现存储与计算分离，在硬件上，基本上不用在关注硬盘故障的问题，安全、性能和弹性扩展能力得到极大提升。 如果最主要的CPU、硬盘、内存、网络全部实现了真正的分布式，不再区分单机CPU、硬盘、内存、网络，所有的资源都在一个大池子中，所有分布式集群中的CPU和内存等资源是集群共有的、可以共享的，既可以限定使用服务资源使用