分布式架构

一.Kafka架构 producer:生产馒头 consumer:吃馒头 broker:篮子来装馒头 topic:馒头的标签 馒头A，馒头B 二.安装zookeeper 配置环境变量 zoo.cfg 配置tmp路径（自己定义位置） 默认端口2181 启动：./zkServer.sh start 三.安装Kafka 配置环境变量 server.properties 配置： broker.id(要唯一，一个Kafka相当于一个篮子) 接听端口默认 9092 log.dirs(配置tmp路径,自己定义位置) hostname=hadoop000 zookeeper.connection=hadoop000:2181 启动：kafka-server-start.sh $KAFKA_HOME/config/server.properties 创建topic：kafka-topics.sh --create --zookeeper hadoop000:2181 --replication-factor 1 --partitions 1 --topic test 查看topic：kafka-topics.sh --list --zookeeper hadoop000:2181 发送消息：kafka-console-producer.sh --broker-list hadoop000:9092

第一部分：Dubbo的背景分析及工作原理 1. Dubbo是什么？ Dubbo是一个来自阿里巴巴的开源分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。 简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架 其核心部分包含: 1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 2. Dubbo能做什么？ 1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 Dubbo采用全Spring配置方式，透明化接入应用

前言 众所周知，阿里巴巴是 apache基金会成员、Linux基金会成员，同时是Xen顾问委员会成员。上述身份可见阿里在开源方面的重视程度，阿里通过开源贡献更多技术、分享更多理念。其开源的很多项目大受欢迎，今日就来盘点阿里 29 个开源项目，你用过几个，哪个最好用，欢迎在留言区告诉我。 如果你一直以来都对java抱有强烈的学习兴趣。却不知道如何系统的进行学习。学习有困难或者想领取java小白学习路线资料的 这里有互相学习交流的小伙伴，可以进来一起学习，有什么不懂得也可以互相解答：点击我加入吧，即可直达。 。 1. 分布式应用服务开发的一站式解决方案 Spring Cloud Alibaba Spring Cloud Alibaba 致力于提供分布式应用服务开发的一站式解决方案。此项目包含开发分布式应用服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。 地址： https://github.com/spring-cloud-incubator/spring-cloud-alibaba 2. 设计语言 & 前端框架 Ant Design Ant

官网文档地址： https://zookeeper.apache.org/doc/r3.5.4-beta/zookeeperOver.html 概述 Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架， 它负责存储和管理大家都关心的数据， 然后接受观察者的注册， 一旦这些数据的状态发生变化， Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应 ， 从而实现集群中类似Master/Slave管理模式。 Zookeeper 是一个分布式的服务框架，主要用来 解决分布式集群中应用系统的协调和一致性问题 ，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。如：统一命名服务、状态同步服务、集群管理、分布式应用配置管理等。 它能够为分布式应用提供高性能和可靠地协调服务，使用ZooKeeper可以大大简化分布式协调服务的实现，为开发分布式应用极大地降低了成本。协同服务很难正确运行，经常出现竞争危害和死锁。ZooKeeper 的目的就是降低协同服务实现与维护的成本。 架构及原理 集群架构 Zookeeper集群是由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点

1.高并发和大流量 大型互联网需要面对高并发的访问用户，比如在天猫“双11”的时候，一分钟之内，有超过一千万的独立用户访问整个天猫系统，大规模的并发用户访问会对系统的处理能力造成巨大的冲击，系统必须要有足够强的处理能力才能够满足。同时有这么多用户来访问，产生了巨大的访问流量，对系统的抗压能力形成了考验。 高可用 大型互联网系统必须要 7×24 小时不间断地提供服务，和传统软件系统不同，银行或者是电信甚至零售业，它们都有下班时间，下了班以后可以对系统进行停机维护和升级发布，但是互联网没有下班时间，所以一直要保持高可用，7×24 小时永不间断。为了保证系统的高可用，必须要进行特别的系统架构设计。 海量的数据存储 因为互联网需要满足大量的用户使用，所以这些用户会产生很多的数据，需要对这些数据进行重组和管理。除了用户提交的数据，互联网还会采集很多其它的数据，包括一些用户行为的数据、第三方的数据以及网络爬虫获取的数据，通过大数据技术对这些数据做进一步分析，对用户进行更精准的营销和服务，以发现新的业务增长点。 用户分布广泛，网络情况复杂 互联网是为全球用户提供服务的，用户分布范围广，各地的网络情况千差万别，为了使所有用户能够得到统一的良好的体验，需要对系统架构进行相关的设计。 安全环境恶劣 因为互联网是开放的，所以互联网站很容易就会受到攻击。 需求变化快，发布频繁 和传统的软件版本发布频率比

Elasticsearch简介 * Elasticsearch是一个实时的分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。 它可以用于全文搜索，结构化搜索以及分析，当然你也可以将这三者进行组合。 Elasticsearch是一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。 但是Lucene只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的学习了解，才能明白它是如何运行的，Lucene确实非常复杂。 Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。 当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作: 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流。 Elasticsearch的上手是非常简单的。它附带了很多非常合理的默认值

传统的存储 ，一般是指用 商用硬盘构建稳固的存储系统，通常会用到RAID技术 ，这是一种被研究的很透彻的存储技术，有大量的相关软硬件，成本已降低到可接受的程度。 分布式存储 ，一般是指用大量廉价的磁盘，通过软件层实现一定的高级功能，如高数据持久性，不停机扩容，异地分布，多租户架构等，往往也可以通过中间件的形式做扩容。 简要介绍下这两种方式的异同。 RAID技术 RAID，通常是硬件实现，也可以软件实现，RAID存储的时候，会有大量的异或运算，软RAID会降蛮多机器性能，不推荐，而实现硬RAID所需的RAID卡，价格也不高，速度和本地硬盘一致。 总结优点： RAID卡比较便宜，成本低 技术成熟，实施方便 运维方便 本地传输，速度快，不存在小文件的问题 总结缺点： 扩展性差，RAID在系统看来，就是磁盘，并不是以接口提供，没法儿做很好的扩展，比如要坐文件杀毒功能，RAID几乎无法支持 扩容难，空间不够用了，必须停机扩容，而这对有7*24要求的单位，几乎是硬伤 对于分布式存储 优势在于： 扩展方便，可以通过软件层，添加需要的功能 容错性强，对于no-share架构的分布式系统，任何一个节点的crash都不会影响其它节点的工作 扩展方便，对于大部分分布式系统，都可以在线扩容 缺点在于： 速度比本地硬盘慢，特别是存储大量小文件的时候，速度巨慢 实施麻烦，需要专业的计算机工程师协助部署

Solr2004年诞生 ElasticSearch 2010年诞生 ES更新 ElasticSearch简介: 　　ElasticSearch是一个实时的分布式的搜索引擎和分析引擎.它可以帮助你用前所未有的速度去处理大规模数据. 　　它可以用于全文检索,结构化以及分析.当然你也可以将这三者进行组合. 　　ElasticSearch是一个建立在全文搜索引擎Apache Lucene基础上的搜索引擎,可以说Lucene是当今最先进,最高效的全共鞥开源搜索引擎框架. 　　但是Lucene只是一个框架,要充分利用它的功能,需要使用JAVA,并且在程序中集成Lucene.需要很多的学习了解,才能明白它是如何运行的,Lucene确实非常复杂. 　　ElasticSearch使用Lucene作为内部引擎,但是在使用它做全文检索时,只需要使用统一开发好的API即可,而不需要了解其背后复杂的Lucene的运行原理. 　　当然Elasticsearch并不仅仅是Lucene这么简单,它不但包括了全文搜索功能,还可以进行一下工作: 　　　　分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索. 　　　　实时分析的分布式搜索引擎. 　　　　可以拓展到上百台服务器上,处理PB级别的结构化和非结构化数据 这么多的功能都被继承到一台服务器上

Ceph基础知识和基础架构 0、Ceph分为三部分：RADOS关于数据存储分布，CRUSH关于伪随机算法，Ceph系统 1、Ceph是一个可靠的、自动中均衡、自动恢复的分布式存储系统，根据场景划分可以将Ceph划分为三大块，分别是对象存储、块设备存储和文件系统存储。在虚拟化中，常常用到的时Ceph的块设备存储，比如在Openstack项目中，Ceph的块设备存储可以对接Openstack的cinder后端存储，Glance的镜像存储和虚拟机的数据存储，比较直观的时Ceph集群可以提供一个raw格式的快存储来作为虚拟机的硬盘。 Ceph相比其他存储的优势点在于它不单单时存储，同时还充分利用存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡，同时由于Ceph的良好设计，采用了CRUSH算法，HASH算法，使得它不存在传统的单点故障问题，且随着规模的扩大性能并不会受到影响。 2、Ceph核心组件 Ceph的核心组件包括Ceph OSD、Ceph Monitor和Ceph MDS。 Ceph OSD：全称是Ceph Object Storage Device，他的主要功能是存储数据，复制数据，平衡数据，恢复数据等。与其他OSD之间进行心跳检测等，并将一些变化情况上报给Ceph Monitor。一般情况下 一块硬盘对应一个OSD

1. ceph 简介 　　Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统()。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。 Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。 　　官网：https://ceph.com/ 　　官方文档：http://docs.ceph.com/docs/master/# 2. Ceph特点 高性能 ： 　　1) 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。 　　2) 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。 　　3) 能够支持上千个存储节点的规模，支持TB到PB级的数据。 高可用性： 　　1) 副本数可以灵活控制。 　　2) 支持故障域分隔，数据强一致性。 　　3) 多种故障场景自动进行修复自愈。 　　4) 没有单点故障，自动管理。 高可扩展性： 　　1) 去中心化。 　　2) 扩展灵活。 　　3)