分布式架构

一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（ http header 中包含 Expires/Cache of Control ， last modified(304 ， server 不返回 body ，客户端可以继续用 cache ，减少流量 ) ， ETag ） 反向代理缓存 应用端的缓存 (memcache) 内存数据库 Buffer 、 cache 机制（数据库，中间件等） 2) 索引 哈希、 B 树、倒排、 bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B 树索引适合于查询为主导的场景，避免多次的 IO ，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap 是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之 (MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR 模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理 (map) ，将处理后的数据进行合并 (combine) 、排序 (shuffle and sort) 后再分发 ( 至 reduce

1.测试MySQL连接 bin/sqoop list-databases --connect jdbc: mysql://192.168.1.187:3306/trade_dev --username 'mysql' --password '111111' 2.检验SQL语句 bin/sqoop eval --connect jdbc: mysql://192.168.1.187:3306/trade_dev --username 'mysql' --password '111111' --query "SELECT * FROM TB_REGION WHERE REGION_ID = '00A1719A489D4F49906A8CA9661CCBE8'" 3.导入hdfs 3.1 导入 bin/sqoop import --connect jdbc: mysql://192.168.1.187:3306/trade_dev --username 'mysql' --password '111111' --table TB_REGION --target-dir /sqoop/mysql/trade_dev/tb_region -m 5 --columns "code,name,category,farthercode,visible,regionlevel,region_id"

摘要：消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka等。 消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 1.异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。 （1）串行方式：将注册信息持久化后，发送注册邮件，再发送注册短信。三个业务全部完成后，返回给客户端。 （2）并行方式：将注册信息持久化后，发送注册邮件的同时，发送注册短信。三个业务全部完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。 假设三个业务节点每个使用100毫秒钟，不考虑其他开销，则串行方式的时间是300ms，并行的时间可能是200毫秒。则串行的方式1秒内可处理3次请求，并行方式1秒内可处理5次请求，综上所述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？ 引入消息队列，将不是必须的业务逻辑，异步处理。如下图所示 按照上图，用户的响应时间相当于是注册信息写入数据库的时间和将消息插入消息队列，也就是105毫秒。注册邮件，发送短信消息写入队列后，直接返回

hdfs解决物理计算机存储能力不能满足数据集的要求时遇到的问题，这个系统架构于网络之上，会引入网络编程的复杂性，因此分布式文件系统比普通完成磁盘文件系统更为复杂。 hdfs基于流数据模式访问和处理超大文件的需求而开发的，它可以运行于廉价的商用服务器上，总的来说，可以将 hdfs的主要特点概括为以下几点： （1）处理超大文件 这里指的超大文件通常指数百GB，甚至是数百TB大小的文件。目前在实际应用中，hdfs已经能用来存储管理PB级的数据了。 （2）流式的访问数据 hdfs的设计建立在更多的响应“一次写入，多次读取”任务的基础之上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说对hdfs来说，请求读取整个数据集要比读取一个记录更加高效。 （3）运行在廉价的商用机器集群上 hadoop设计对硬件需求比较低，只需运行在廉价的商用硬件集群上，但廉价商用机也意味着大型集群出现节点故障情况概率高，这就要求在设计hdfs时要充分考虑数据的可靠性，安全性及高可用性。 hdfs在一些方面有一定的局限性，主要在以下几个方面。 （1）不适合低延迟数据访问 如果要处理一些用户要求时间比较短的低延迟应用请求，则hdfs不适合。hdfs是为了处理大型数据集分析任务的

首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后，每次用户的请求都可以发到集群中任意一台服务器上处理，任何一台服务器的处理结果都是相同的； 　　（2）HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态

原创作者：张磊、邓洪超 如果我问你，如何把一个 etcd 集群部署在 Google Cloud 或者阿里云上，你一定会不假思索的给出答案：当然是用 etcd Operator！ 实际上，几乎在一夜之间，Kubernetes Operator 这个新生事物，就成了开发和部署分布式应用的一项事实标准。时至今日，无论是 etcd、TiDB、Redis，还是 Kafka、RocketMQ、Spark、TensorFlow，几乎每一个你能叫上名字来的分布式项目，都由官方维护着各自的 Kubernetes Operator。而 Operator 官方库里，也一直维护着一个知名分布式项目的 Operator 汇总。 https://github.com/operator-framework/awesome-operators 短短一年多时间，这个列表的长度已经增长了几十倍。 而且更有意思的是，如果你仔细翻阅这个 Operator 列表，你就不难发现这样一个有趣的事实：现今 Kubernetes Operator 的意义，恐怕已经远远超过了“分布式应用部署”的这个原始的范畴，而已然成为了容器化时代应用开发与发布的一个全新途径。所以，你才会在这个列表里看到，Android SDK 的开发者们，正在使用 Operator “一键”生成和更新 Android 开发环境；而 Linux 系统工程师们

作者：刘超 转自【刘超的通俗云计算】 什么是云计算 早在十年前，市场上就出现了很多和云计算相关的岗位，当时正是云计算技术最火热的时代，不管是BAT还是华为等企业都开始布局云计算，于是OpenStack研发、容器研发、底层开发等相关岗位相应地也越来越多，虽然这几年大数据和AI的风头已经完全压过了云计算，但是这一门技术仍然在现如今的技术体系中占有很重要的位置。那么，到底什么是云计算，就是我们每一个要学习云计算技术的朋友要了解的事情了，根据百度百科的介绍 大数据（big data），IT行业术语，是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。 在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 [1] 中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理。大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。 [2] 思维导图 云计算的发展史 物理机时代 云计算的整个过程，用一个词来讲就是“分久必合，合久必分”。 云计算其实主要解决了四个方面的内容：计算，网络，存储，应用。前三者是资源层面的，最后是应用层面的。 计算是CPU和内存，为啥

作者：网易云 链接： https://www.zhihu.com/question/27696290/answer/381993207 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 什么是大数据 近几年，市场上出现了很多和大数据相关的岗位，不管是数据分析、数据挖掘，或者是数据研发，都是围绕着大数据来做事情，那么，到底什么是大数据，就是我们每一个要学习大数据技术的朋友要了解的事情了，根据百度百科的介绍 大数据（big data），IT行业术语，是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。 在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 [1] 中大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理。大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。 [2] 思维导图 大数据方面核心技术有哪些？ 大数据的概念比较抽象，而大数据技术栈的庞大程度将让你叹为观止。 大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算

转载自 https://www.cnblogs.com/wetest/p/6806506.html 和 https://www.cnblogs.com/dudu0614/p/8821811.html 什么是分布式系统 分布式这一概念，一直都是后端工程师绕不过去的一个坎，今天，我们就一起来看看到底什么是分布式系统，又有哪些分布式技术世我们需要学习的。 根据百度百科的介绍，分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。 从分布式系统的诞生说起 我们常常会听说，某个互联网应用的服务器端系统多么牛逼，比如QQ、微信、淘宝。那么，一个互联网应用的服务器端系统，到底牛逼在什么地方？为什么海量的用户访问，会让一个服务器端系统变得更复杂？本文就是想从最基本的地方开始，探寻服务器端系统技术的基础概念。 承载量是分布式系统存在的原因 当一个互联网业务获得大众欢迎的时候，最显著碰到的技术问题，就是服务器非常繁忙。当每天有1000万个用户访问你的网站时，无论你使用什么样的服务器硬件，都不可能只用一台机器就承载的了。因此，在互联网程序员解决服务器端问题的时候，必须要考虑如何使用多台服务器，为同一种互联网应用提供服务，这就是所谓

Zookeeper常用的应用场景 分布式协调： 简单来说就是有人对Zookeeper中的数据做了监听，如果修改了Zookeeper中被监听的数据，Zookeeper反过来就会告诉发起监听的人数据变更。比如在kafka的设计中，kafka的一个节点在Zookeeper中创建了一个数据，kafka的策略是谁创建了这个数据谁就是kafka集群的主节点，其余的节点都会去监听这个数据。如果主节点宕机了，这Zookeeper对应的数据就会发送变更，即而监听这个数据的其余节点就会感知到主节点宕机，然后重新进行选举。 元数据管理： 很多分布式的程序需要集中式管理自己的元数据，这个时候Zookeeper就是一个很好的选择。比如kafka、Storm等分布式的工具就会把集群里核心的元数据存放在Zookeeper中。 高可用： 很多分布式项目都是主从架构（一个主节点+多个从节点）。如果只有一个主节点的话，程序就会有单点故障问题，那么这个时候就需要部署多个从节点实现高可用。如HDFS就是靠Zookeeper实现高可用的 分布式锁： 注意的是Zookeeper不支持高并发，在高并发的情况建议使用Redis实现分布式锁，并发不太高的情况下使用Zookeeper实现分布式锁比较方便。 Zookeeper架构 在Zookeeper集群中，集群的服务角色分为leader和learner