zookeeper集群

Getting Start 下载 http://kafka.apache.org/ 优点和应用场景 Kafka消息驱动，符合发布-订阅模式，优点和应用范围都共通 发布-订阅模式优点 解耦合 ： 两个应用不需要相互调用 可扩展性 ： 消费者的个数可实时扩展 实时性 ： 消费者能实时的获取生产者发布的事件 高效 ：减少由于多个消费者请求数据造成的数据计算带来的资源消耗 异步通讯 ：发布-订阅模式是天生的异步通讯 Kafka其他优点 持久化 ： 消息丢失的可控性极高 高性能 ： 磁盘顺序读写性能比内存随机读写还高，每秒10万条消息 高吞吐量 ：每秒上百MB的吞吐量 顺序性 发布-订阅模式应用范围 适合数据一被生产，就需要被处理的情况 适合数据具有潜在消费者的情况 适合无论有没有消费者，数据都在生产的情况 不适合对数据的处理时间有特殊限定的情况 应用场景 最为消息中间件，实现消息队列和消息的发布-订阅，消息驱动的服务 数据总线，一对多的模式 日志收集，消息中间件的一种应用 数据库主从同步 核心概念 Broker 一个Kafka server就是一个Broker 一般情况下，一个Broker独占一台服务器，发挥微服务的优势 服务器资源有限的情况下，需要设计出Broker/Topic/Partition/Replica的最优分配策略，从而充分利用服务器资源 一个broker可以有多个topic

Kafka有两种模式： 点对点模式：消费者主动从Kafka中定时轮询的拉取数据，一条数据只会发送给customer group中的一个customer进行消费。 发布订阅者模式：kafka主动推送数据到所有订阅了该类信息的客户端。 Kafka中通过控制Customer的参数{group.id}来决定kafka是什么数据消费模式，如果所有消费者的该参数值是相同的，那么此时的kafka就是队列模式，数据只会发送到一个customer，此时Kafka类似于负载均衡；否则就是发布订阅模式； 在队列模式下，可能会触发Kafka的Consumer Rebalance kafka是依赖Zookeeper的，kafka中节点的状态信息和消费者的消费消息的状态信息会保存在zookeeper中，且zookeeper只保存这两点信息 kafka中存在几个概念：Broker、Topic、Partition Broker：为一个节点，每开启一个kafka服务就会有一个Broker Topic：为主题。kafka中消息是分类别的，kafka是通过topic来为消息分类的，每一个topic代表着一种消息类型。同一个topic可以存在于多个Broker中 Partition：为分区，分区存在于topic中，每个topic中会存在多个分区。在Kafka中分区是操作的最小单元

Kafka集群管理、状态保存是通过zookeeper实现，所以先要搭建zookeeper集群 zookeeper集群搭建 一、软件环境： zookeeper集群需要超过半数的的node存活才能对外服务，所以服务器的数量应该是2*N+1，这里使用3台node进行搭建zookeeper集群。 1. 3台linux服务器都使用docker容器创建，ip地址分别为 NodeA：172.17.0.10 NodeB：172.17.0.11 NodeC：172.17.0.12 2. zookeeper的docker镜像使用dockerfiles制作，内容如下： ################################################################### FROM docker.zifang.com/centos7-base MAINTAINER chicol "chicol@yeah.net" # copy install package files from localhost. ADD ./zookeeper-3.4.9.tar.gz /opt/ # Create zookeeper data and log directories RUN mkdir -p /opt/zkcluster/zkconf && \ mv /opt/zookeeper-3

Dubbo的使用及原理浅析. 前面几个博文中关于SSM 框架已经搭建完成, 这里来讲下项目中使用到的Dubbo以及自己了解到的关于Dubbo的一些知识. Dubbo是什么？ Dubbo是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。 Dubbo[]是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。 其核心部分包含: 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 Dubbo能做什么？ 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 Spring集成

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

一、单机环境部署 安装步骤 1、下载zookeeper包 官网下载地址： http://www.apache.org/dist/zookeeper/ 百度网盘： 链接： https://pan.baidu.com/s/1UdR3rLqx4mO7n2vkILfCHA 提取码：k8b5 2、上传linux系统，解压缩压缩包 #解压到 /usr/local/server 目录下 tar -zxvf zookeeper-3.4.14.tar.gz -C /usr/local/server 3、进入 zookeeper-3.4.14 目录，创建 data 文件夹 cd zookeeper-3.4.14/ mkdir data 4、修改zoo.cfg中的data属性 #进入conf目录 cd conf #修改 zoo_sample.cfg文件名为 zoo.cfg mv zoo_sample.cfg zoo.cfg ​ #修改zoo.cfg中的data属性 dataDir=/usr/local/server/zookeeper-3.4.14/data 5、zookeeper 服务启动 进入bin目录，启动服务输入命令 ./zkServer.sh start 输出以下内容表示启动成功 zkServer.sh常用命令 服务启动 ./zkServer.sh start 关闭服务输入命令 .

ZooKeeper的shell操作命令 使用 zkServer.sh 启动ZooKeeper服务器后，接下来就可以使用 zkCli.sh 脚本启动ZooKeeper客户端来连接ZooKeeper服务器；Windows对应的是 zkServer.cmd 和 zkCli.cmd 。 （1）使用 help 命令可查看ZooKeeper的shell操作可用的命令，如下： [ zk: localhost:2181 ( CONNECTED ) 4 ] help ZooKeeper -server host:port cmd args stat path [ watch ] set path data [ version ] ls path [ watch ] delquota [ -n | -b ] path ls2 path [ watch ] setAcl path acl setquota -n | -b val path history redo cmdno printwatches on | off delete path [ version ] sync path listquota path rmr path get path [ watch ] create [ -s ] [ -e ] path data acl addauth scheme auth quit getAcl

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

● 把zookeeper的tar包上传到虚拟机中, 解压 ● 在/usr/local/目录创建文件夹solr-cloud, 把上一步解压好的zookeeper-3.4.14拷贝三份到solr-cloud, 命名如下 配置zookeeper实例 ● 进入zookeeper01 创建一个data目录mkdir data, 放zookeeper的一些数据文件 ● 创建myid里面写上1(当前节点的编号) ● 查看, 内容是1 ● 切换到conf目录下, 把zoo_sample.cfg拷贝一份命名为zoo.cfg, 然后修改里面的配置信息 ● 把路径改成刚刚创建的data目录的路径, /usr/local/solr-cloud/zookeeper01/data/ 2181是客户端连接zookeeper,提供服务的端口号,这个先不改 ● 在最下面添加上下面这些, 2881是节点之间进行通信的端口号, 3881是节点之间投票选举的端口号 ● 保存之后, 参照上面的方法再去配置zookeeper02 创建data, 创建myid并写入2 ● 拷贝zoo_sample.cfg命名为zoo.cfg ● 修改zoo.cfg配置文件,注意文件路径和端口号 ● 最后面这个还是一样 ● 配置zookeeper03, 参照上面的zookeeper01,zookeeper02 ● 在solr

随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个 高可用、强一致性的服务发现存储仓库 ，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。 etcd 是一个高可用的 Key/Value 存储系统，主要用于分享配置和服务发现。etcd 的灵感来自于 ZooKeeper 和 Doozer，側重于： 简单 ：支持 curl 方式的用户 API (HTTP+JSON) 安全 ：可选 SSL client证书认证 高速 ：单实例可达每秒 1000 次写操作 可靠 ：使用 Raft 实现分布式 Etcd is written in Go and uses the raft consensus algorithm to manage a highly-available replicated log. 经典应用场景 要问etcd是什么？很多人第一反应可能是一个键值存储仓库，却没有重视官方定义的后半句，用于 配置共享和服务发现 。