消息队列和kafka，zookeeper集群搭建

基本的概念

参考基本的概念文献
我们可以把消息队列比作是一个存放消息的容器，当我们需要使用消息的时候可以取出消息供自己使用
消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。目前使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ

为什么叫队列？？？？？？？？？？？？？？？？
我们知道队列 Queue 是一种先进先出的数据结构，所以消费消息时也是按照顺序来消费的。比如生产者发送消息1,2,3…对于消费者就会按照1,2,3…的顺序来消费。但是偶尔也会出现消息被消费的顺序不对的情况，比如某个消息消费失败又或者一个 queue 多个consumer 也会导致消息被消费的顺序不对，我们一定要保证消息被消费的顺序正确
看图就知道消息队列服务器是什么

在数据库与网站服务器之间加入了消息队列服务器，用户的请求数据发送给消息队列之后立即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。

消息队列和发布-订阅模式的关系

除了发布-订阅模式，还有点对点订阅模式（一个消息只有一个消费者），我们比较常用的是发布-订阅模式
消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。 从上图可以看到消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。


在发布-订阅的模式里面又分两种，一种是生产者主动从队列中推送给消费者，第二种是消费者主动从队列中拉取消息，kafka是属于第二种的主动拉取消息。这种有个缺点：消费者要不断地去询问消息队列是不是有消息。

kafka和消息队列的关系

RabbitMQ:分布式，支持多种MQ协议，重量级
ActiveMQ：与RabbitMQ类似
ZeroMQ：以库的形式提供，使用复杂，无持久化
Redis：单机、纯内存性好，持久化较差
*Kafka：分布式，消息不是使用完就丢失【较长时间持久化】，吞吐量高【高性能】，轻量灵活
RabbitMQ 也是常见的消息对列，它支持多种MQ的协议，JMS，等多种协议等等，它的缺点比较重
ActiveMQ 也和 RabbitMQ 类似，支持的协议比较多
ZeroMQ 是一个socket的通信库，它是以库的形式提供的，所以说你需要写程序来实现消息系统，它只管内存和通信那一块，持久化也得自己写，还是那句话它是用来实现消息队列的一个库，其实在storm里面呢，storm0.9之前，那些spout和bolt，bolt和bolt之间那些底层的通信就是由ZeroMQ来通信的，它并不是一个消息队列，就是一个通信库，在0.9之后呢，因为license的原因，ZeroMQ就由Netty取代了，Netty本身就是一个网络通信库嘛，所以说更合适是在通信库这一层，不应该是MessageQueue这一层
Redis 本身是一个内存的KV系统，但是它也有队列的一些数据结构，能够实现一些消息队列的功能，当然它在单机纯内存的情况下，性能会比较好，持久化做的稍差，当持久化的时候性能下降的会比较厉害
Kafka 的亮点，天生是分布式的，不需要你在上层做分布式的工作，另外有较长时间持久化，前面的几个MQ基本消费就干掉了，另外在长时间持久化下性能还比较高，顺序读和顺序写，另外还通过sendFile这样0拷贝的技术直接从文件拷贝到网络，减少内存的拷贝，还有批量读批量写来提高网络读取文件的性能
框架图：

Broker指的是一台主机，Topic指的是消息的主题用于分类,每台主机存储一个主题的分块partition,每个topic是有一个leader负责与comsumer进行连接的，每个broker还存储了另一个broker的备份follower,如果leader挂了，就用它来取代。。
kafka存储的信息是在磁盘的，默认存储7天。
Kafka是依赖zookeeper的。

kafka的启动

kafka和zookeeper的安装的教程参考文献
要启动kafka必须先启动zookeeper:
[root@localhost local]# cd /usr/local/zookeeper-3.4.13/bin
[root@localhost bin]# ./zkServer.sh start
[root@localhost bin]# ./zkCli.sh

最后启动kafka(在Kafka安装目录下执行下面语句)
root@localhost kafka_2.10-0.10.2.1]# bin/kafka-server-start.sh config/server.properties

zookeeper伪集群搭建

参考
它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
简单来说zookeeper=文件系统+监听通知机制。

集群和分布式的区别

将一套系统拆分成不同子系统部署在不同服务器上（这叫分布式），
然后部署多个相同的子系统在不同的服务器上（这叫集群），部署在不同服务器上的同一个子系统应做负载均衡。 （zookeeper集群，redis集群，等等，都是一模一样的几台服务器，是一类人，共同完成系统中的某一块功能）

分布式：一个业务拆分为多个子业务，部署在多个服务器上 。

集群：同一个业务，部署在多个服务器上 。
相同点：

分布式和集群都是需要有很多节点服务器通过网络协同工作完成整体的任务目标。

不同点：

分布式是指将业务系统进行拆分，即分布式的每一个节点都是实现不同的功能。而集群每个节点做的是同一件事情。

集群的三种模式

集群模式
1、单机模式
在zoo.cfg中只配置一个server.id就是单机模式了。

这种模式下，如果当前主机宕机，那么所有依赖于当前zookeeper服务工作的其他服务器都不能在进行正常工作，这种事件称为单节点故b障。所以这种模式一般用在测试环境。

2、伪分布式
在zoo.cfg中配置多个server.id，其中ip都是当前机器，而端口各不相同，启动时就是伪集群模式了。

这种模式和单机模式产生的问题是一样的。这种模式也是用在测试环境中。

3、完全分布式
多台机器各自配置zoo.cfg文件，将各自互相加入服务器列表，上面搭建的集群就是这种完全分布式。

这种模式是真实生产环境中使用的zookeeper集群模式。

启动zookeeper(不能进入bin目录启动)
#启动ZK服务:
bin/zkServer.sh start
#停止ZK服务:
bin/zkServer.sh stop
#重启ZK服务:
bin/zkServer.sh restart
#查看ZK服务状态:
bin/zkServer.sh status
分别在三个虚拟机分别装三个zookeeper服务器的教程参考

因为有一个服务器忘记增加了后面的2888:3888折腾了一个晚上的
错误Error contacting service. It is probably not running.以后要小心了！！！！！！！！！！！！！最好是用scp复制文件，不要一台服务器一台服务器的写

zookeeper入门指令参考
一台机器的节点值改变了，另外一台机器上的这个节点也变了

zookeeper监听的原理

redis集群和zookeeper集群的区别

redis集群中所有的节点都是有备份的，也就是说有两个节点是一模一样的，相互备份，但是集群中的节点不像zookeeper那样子超过半数挂了就挂了，而是当一个节点和它的备份都挂了那么整个redis集群都挂了。集群存储数据时要经过一个算法决定这个数据到底存在哪一个节点上，也就是存在哪一台服务器上。
这个算法叫做crc16算法，Redis集群理论上最多可以有16384个节点。。
搭建redis集群参考文献