$a = (10) ? "zhen" : 'jia'; // 三目运算符 与下边if 语句 意思一样if( 1 0 ){$a = "zhen";}else{$a = "jia";}
用这个源码包试试
应该就是这样解释的了,建议楼主去后盾人那学习,因为他们最近搞什么活动学费九折还包住宿
消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式.
Broker（消息服务器）
Broker的概念来自与Apache ActiveMQ,通俗的讲就是MQ的服务器.
Producer（生产者）
业务的发起方,负责生产消息传输给broker
Consumer（消费者）
业务的处理方,负责从broker获取消息并进行业务逻辑处理
Topic（主题）
发布订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅 者,实现消息的广播
Queue（队列）
PTP模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收.
Message（消息体）
根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输
点对点模型用于消息生产者和消息消费者之间点到点的通信.
点对点模式包含三个角色：
每个消息都被发送到一个特定的队列,接收者从队列中获取消息.队列保留着消息,可以放在内存 中也可以持久化,直到他们被消费或超时.
特点：
发布订阅模型包含三个角色：
多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者.
AMQP即Advanced Message Queuing Protocol,是应用层协议的一个开放标准,为面向消息的中间件设计.消息中间件主要用于组件之间的解耦,消息的发送者无需知道消息使用者的存在,反之亦然.AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全.
优点：可靠、通用
MQTT（Message Queuing Telemetry Transport,消息队列遥测传输）是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分.该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议.
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
优点：命令模式（非topic\queue模式）
XMPP（可扩展消息处理现场协议,Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议,多用于即时消息（IM）以及在线现场探测.适用于服务器之间的准即时操作.核心是基于XML流传输,这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息,即使其操作系统和浏览器不同.
优点：通用公开、兼容性强、可扩展、安全性高,但XML编码格式占用带宽大
RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种,最初起源于金融系统,用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗. RabbitMQ 主要是为了实现系统之间的双向解耦而实现的.当生产者大量产生数据时,消费者无法快速消费,那么需要一个中间层.保存这个数据.
Channel（通道）
道是两个管理器之间的一种单向点对点的的通信连接,如果需要双向交流,可以建立一对通道.
Exchange（消息交换机）
Exchange类似于数据通信网络中的交换机,提供消息路由策略.
RabbitMq中,producer不是通过信道直接将消息发送给queue,而是先发送给Exchange.一个Exchange可以和多个Queue进行绑定,producer在传递消息的时候,会传递一个ROUTING_KEY,Exchange会根据这个ROUTING_KEY按照特定的路由算法,将消息路由给指定的queue.和Queue一样,Exchange也可设置为持久化,临时或者自动删除.
不同类型的Exchange转发消息的策略有所区别：
Binding（绑定）
所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来.Exchange 和Queue的绑定可以是多对多的关系.
Routing Key（路由关键字）
exchange根据这个关键字进行消息投递.
vhost（虚拟主机）
在RabbitMq server上可以创建多个虚拟的message broker,又叫做virtual hosts (vhosts).每一个vhost本质上是一个mini-rabbitmq server,分别管理各自的exchange,和bindings.vhost相当于物理的server,可以为不同app提供边界隔离,使得应用安全的运行在不同的vhost实例上,相互之间不会干扰.producer和consumer连接rabbit server需要指定一个vhost.
假设P1和C1注册了相同的Broker,Exchange和Queue.P1发送的消息最终会被C1消费.
基本的通信流程大概如下所示：
Consumer收到消息时需要显式的向rabbit broker发送basic.ack消息或者consumer订阅消息时设置auto_ack参数为true.
在通信过程中,队列对ACK的处理有以下几种情况：
即消息的Ackownledge确认机制,为了保证消息不丢失,消息队列提供了消息Acknowledge机制,即ACK机制,当Consumer确认消息已经被消费处理,发送一个ACK给消息队列,此时消息队列便可以删除这个消息了.如果Consumer宕机/关闭,没有发送ACK,消息队列将认为这个消息没有被处理,会将这个消息重新发送给其他的Consumer重新消费处理.
消息的收发处理支持事务,例如：在任务中心场景中,一次处理可能涉及多个消息的接收、处理,这应该处于同一个事务范围内,如果一个消息处理失败,事务回滚,消息重新回到队列中.
消息的持久化,对于一些关键的核心业务来说是非常重要的,启用消息持久化后,消息队列宕机重启后,消息可以从持久化存储恢复,消息不丢失,可以继续消费处理.
fanout 模式
模式特点：
direct 模式
任何发送到Direct Exchange的消息都会被转发到routing_key中指定的Queue.
如果一个exchange 声明为direct,并且bind中指定了routing_key,那么发送消息时需要同时指明该exchange和routing_key.
简而言之就是：生产者生成消息发送给Exchange, Exchange根据Exchange类型和basic_publish中的routing_key进行消息发送 消费者：订阅Exchange并根据Exchange类型和binding key(bindings 中的routing key) ,如果生产者和订阅者的routing_key相同,Exchange就会路由到那个队列.
topic 模式
前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key,但这种严格的匹配方式在很多情况下不能满足实际业务需求.
topic类型的Exchange在匹配规则上进行了扩展,它与direct类型的Exchage相似,也是将消息路由到binding key与routing key相匹配的Queue中,但这里的匹配规则有些不同.
它约定：
RabbitMQ,部署分三种模式：单机模式,普通集群模式,镜像集群模式.
普通集群模式
多台机器部署,每个机器放一个rabbitmq实例,但是创建的queue只会放在一个rabbitmq实例上,每个实例同步queue的元数据.
如果消费时连的是其他实例,那个实例会从queue所在实例拉取数据.这就会导致拉取数据的开销,如果那个放queue的实例宕机了,那么其他实例就无法从那个实例拉取,即便开启了消息持久化,让rabbitmq落地存储消息的话,消息不一定会丢,但得等这个实例恢复了,然后才可以继续从这个queue拉取数据, 这就没什么高可用可言,主要是提供吞吐量 ,让集群中多个节点来服务某个queue的读写操作.
镜像集群模式
queue的元数据和消息都会存放在多个实例,每次写消息就自动同步到多个queue实例里.这样任何一个机器宕机,其他机器都可以顶上,但是性能开销太大,消息同步导致网络带宽压力和消耗很重,另外,没有扩展性可言,如果queue负载很重,加机器,新增的机器也包含了这个queue的所有数据,并没有办法线性扩展你的queue.此时,需要开启镜像集群模式,在rabbitmq管理控制台新增一个策略,将数据同步到指定数量的节点,然后你再次创建queue的时候,应用这个策略,就会自动将数据同步到其他的节点上去了.
Kafka 是 Apache 的子项目,是一个高性能跨语言的分布式发布/订阅消息队列系统（没有严格实现 JMS 规范的点对点模型,但可以实现其效果）,在企业开发中有广泛的应用.高性能是其最大优势,劣势是消息的可靠性（丢失或重复）,这个劣势是为了换取高性能,开发者可以以稍降低性能,来换取消息的可靠性.
一个Topic可以认为是一类消息,每个topic将被分成多个partition(区),每个partition在存储层面是append log文件.任何发布到此partition的消息都会被直接追加到log文件的尾部,每条消息在文件中的位置称为offset（偏移量）,offset为一个long型数字,它是唯一标记一条消息.它唯一的标记一条消息.kafka并没有提供其他额外的索引机制来存储offset,因为在kafka中几乎不允许对消息进行"随机读写".
对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,有consumer来控制；当consumer正常消费消息时,offset将会"线性"的向前驱动,即消息将依次顺序被消费.事实上consumer可以使用任意顺序消费消息,它只需要将offset重置为任意值.(offset将会保存在zookeeper中,参见下文)
partitions的设计目的有多个.最根本原因是kafka基于文件存储.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存；可以将一个topic切分多任意多个partitions,来消息保存/消费的效率.此外越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.(具体原理参见下文).
一个Topic的多个partitions,被分布在kafka集群中的多个server上；每个server(kafka实例)负责partitions中消息的读写操作；此外kafka还可以配置partitions需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性.
基于replicated方案,那么就意味着需要对多个备份进行调度；每个partition都有一个server为"leader"；leader负责所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进,同步消息即可.由此可见作为leader的server承载了全部的请求压力,所以呢从集群的整体考虑,有多少个partitions就意味着有多少个"leader",kafka会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定.
Producers
Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition；比如基于"round-robin"方式或者通过其他的一些算法等.
Consumers
本质上kafka只支持Topic.每个consumer属于一个consumer group；反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.
如果所有的consumer都具有相同的group,这种情况和queue模式很像；消息将会在consumers之间负载均衡.
如果所有的consumer都具有不同的group,那这就是"发布-订阅"；消息将会广播给所有的消费者.
在kafka中,一个partition中的消息只会被group中的一个consumer消费；每个group中consumer消息消费互相独立；我们可以认为一个group是一个"订阅"者,一个Topic中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费时,消息是顺序的.事实上,从Topic角度来说,消息仍不是有序的.
Kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息.
Guarantees
Kafka就比较适合高吞吐量并且允许少量数据丢失的场景,如果非要保证"消息可靠传输",可以使用JMS.
Kafka Producer 消息发送有两种方式(配置参数 producer.type)：
对于同步方式(producer.type=sync)?Kafka Producer 消息发送有三种确认方式(配置参数 acks)：
kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力.
持久性
kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,所以呢磁盘检索的开支是较小的；同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数.
性能
需要考虑的影响性能点很多,除磁盘IO之外,我们还需要考虑网络IO,这直接关系到kafka的吞吐量问题.kafka并没有提供太多高超的技巧；对于producer端,可以将消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker；对于consumer端也是一样,批量fetch多条消息.不过消息量的大小可以通过配置文件来指定.对于kafka broker端,似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次copy和交换. 其实对于producer/consumer/broker三者而言,CPU的开支应该都不大,所以呢启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑.可以将任何在网络上传输的消息都经过压缩.kafka支持gzip/snappy等多种压缩方式.
需要考虑的影响性能点很多,除磁盘IO之外,我们还需要考虑网络IO,这直接关系到kafka的吞吐量问题.kafka并没有提供太多高超的技巧；对于producer端,可以将消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker；对于consumer端也是一样,批量fetch多条消息.不过消息量的大小可以通过配置文件来指定.对于kafka broker端,似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次copy和交换. 其实对于producer/consumer/broker三者而言,CPU的开支应该都不大,所以呢启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑.可以将任何在网络上传输的消息都经过压缩.kafka支持gzip/snappy等多种压缩方式.
需要考虑的影响性能点很多,除磁盘IO之外,我们还需要考虑网络IO,这直接关系到kafka的吞吐量问题.kafka并没有提供太多高超的技巧；对于producer端,可以将消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker；对于consumer端也是一样,批量fetch多条消息.不过消息量的大小可以通过配置文件来指定.对于kafka broker端,似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次copy和交换. 其实对于producer/consumer/broker三者而言,CPU的开支应该都不大,所以呢启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑.可以将任何在网络上传输的消息都经过压缩.kafka支持gzip/snappy等多种压缩方式.
生产者
其中partition leader的位置(host:port)注册在zookeeper中,producer作为zookeeper client,已经注册了watch用来监听partition leader的变更事件.
消费者
consumer端向broker发送"fetch"请求,并告知其获取消息的offset；此后consumer将会获得一定条数的消息；consumer端也可以重置offset来重新消费消息.
在JMS实现中,Topic模型基于push方式,即broker将消息推送给consumer端.不过在kafka中,采用了pull方式,即consumer在和broker建立连接之后,主动去pull(或者说fetch)消息；这中模式有些优点,首先consumer端可以根据自己的消费能力适时的去fetch消息并处理,且可以控制消息消费的进度(offset)；此外,消费者可以良好的控制消息消费的数量,batch fetch.
对于JMS实现,消息传输担保非常直接:有且只有一次(exactly once).
在kafka中稍有不同:
at most once: 消费者fetch消息,然后保存offset,然后处理消息；当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后"未处理"的消息将不能被fetch到,这就是"at most once".
at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致此时此刻呢再次fetch时可能获得上次已经处理过的消息,这就是"at least once",原因offset没有及时的提交给zookeeper,zookeeper恢复正常还是之前offset状态.
通常情况下"at-least-once"是我们首选.(相比at most once而言,重复接收数据总比丢失数据要好).
kafka高可用由多个broker组成,每个broker是一个节点；
创建一个topic,这个topic会划分为多个partition,每个partition存在于不同的broker上,每个partition就放一部分数据.
kafka是一个分布式消息队列,就是说一个topic的数据,是分散放在不同的机器上,每个机器就放一部分数据.
写的时候,leader会负责把数据同步到所有follower上去,读的时候就直接读leader上数据即可.
kafka会均匀的将一个partition的所有replica分布在不同的机器上,从而提高容错性.
如果某个broker宕机了也没事,它上面的partition在其他机器上都有副本的,如果这上面有某个partition的leader,那么此时会重新选举一个新的leader出来,大家继续读写那个新的leader即可.这就有所谓的高可用性了.
写数据的时候,生产者就写leader,然后leader将数据落地写本地磁盘,接着其他follower自己主动从leader来pull数据.一旦所有follower同步好数据了,就会发送ack给leader,leader收到所有follower的ack之后,就会返回写成功的消息给生产者.
消息丢失会出现在三个环节,分别是生产者、mq中间件、消费者：
RabbitMQ
Kafka
大体和RabbitMQ相同.
Rabbitmq
需要保证顺序的消息投递到同一个queue中,这个queue只能有一个consumer,如果需要提升性能,可以用内存队列做排队,然后分发给底层不同的worker来处理.
写入一个partition中的数据一定是有序的.生产者在写的时候 ,可以指定一个key,比如指定订单id作为key,这个订单相关数据一定会被分发到一个partition中去.消费者从partition中取出数据的时候也一定是有序的,把每个数据放入对应的一个内存队列,一个partition中有几条相关数据就用几个内存队列,消费者开启多个线程,每个线程处理一个内存队列.
以上就是土嘎嘎小编大虾米为大家整理的相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用，就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！