英语时髦词汇有哪些
1. 时尚 英文：[ˈfæʃən] n. 时尚; 风格的改变……； 。时尚英语:[vəʊg]美容:[voʊg]n.Fashion; OK，时尚、流行的名字； （葡萄牙语）Vog [互联网]，流行； [ˈpre vələnt] 美式: [ˈprɛv ələnt] adj. 流行的； 广泛; 流行[农业科学] 流行 5. 流行英语：[ˈpɒpjələ(r)] 流行，流行；流行； 受欢迎的; 流行[专业]流行[艺术]]； 热门[机械工程]
消息队列原理及选型
消息队列（MessageQueue）是一种进程间通信或同一进程的不同序列间通信的方法。
Broker（消息服务器） Broker的概念来自于Apache ActiveMQ，通俗地说就是一个MQ服务器。
生产者业务发起者负责向broker发送生产消息
消费者业务处理器负责从broker获取消息并进行业务逻辑处理
发布主题（ topic）并订阅统一采集点下的Message模型，不同的生产者向该topic发送消息，MQ服务器分发到不同的客户端，实现消息广播
队列（queue）在PTP模式下，某些生产者将消息发送到特定队列 发送消息后，用户订阅特定的队列来接收指定的消息。
消息（消息体）是按照不同通信协议定义的固定格式编码的数据包，用于封装业务数据，实现消息传输
点对点模型用于消息生产者之间和消息消费者之间的点对点通信。
点对点模式包含三个角色：
每条消息被发送到特定的队列，接收者从队列中获取消息。
队列将消息保存在内存中或永久保存，直到消息用完或超时。
特点：
发布订阅模型包含三个角色：
多个发布者向一个Topic发送消息，系统将这些消息发送给多个订阅者。
特点：
AMQP，Advanced MessageQueuingProtocol，是应用层协议的开放标准，专为面向消息的中间件而设计。
消息中间件主要用于组件之间的解耦，消息的发送者不需要知道消息的消费者的存在，反之亦然。
AMQP的主要特点是面向消息、面向队列、路由（包括点对点和发布/订阅）、可靠性和安全性。
优点：可靠、通用
MQTT（消息队列遥测传输）是IBM开发的即时消息协议，可能成为物联网的重要组成部分。
该协议支持所有平台，几乎可以将任何联网物品连接到外界，它被用作传感器和执行器的通信协议（例如通过 Twitter 将家庭连接到互联网）。
优点：格式紧凑，工作带宽小，移动通信，PUSH，嵌入式系统
STOMP（StreamingTextOrientatedMessageProtocol）是一种面向流式文本的消息协议，它是一种MOM（ MessageOrientedMiddleware ），专为面向消息的中间件设计的纯文本协议）。
STOMP 提供了一种可互操作的连接格式，允许客户端与任何 STOMP 消息代理（Broker）进行交互。
优点：命令模式（不是主题\队列模式）
XMPP（Extensible Messaging and Presence Protocol）是一种基于可扩展标记语言（XML）的协议，主要用于消息传递即时（IM）和在线现场检测。
非常适合服务器之间近乎实时的操作。
该协议以 XML 流为核心，最终允许 Internet 用户向 Internet 上的其他人发送即时消息，即使他们的操作系统和浏览器不同。
优点：通用开放性、兼容性强、扩展性强、安全性高，但XML编码格式占用大量带宽
RabbitMQ是一个实现AMQP（高级消息队列协议）的消息中间件） 它是一种最初源自金融系统的软件，用于在分布式系统中存储和转发消息，在易用性、可扩展性和高可用性方面表现良好。
RabbitMQ的实现主要是为了实现系统之间的双向解耦。
当生产者产生大量数据而消费者无法快速使用时，就需要中间层。
保存此数据。
RabbitMQ是一个开源的AMQP实现，服务器是用Erlang语言编写的，支持各种客户端，例如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP。
、STOMP等等，支持AJAX。
它用于在分布式系统中存储和转发消息，在易用性、可扩展性和高可用性方面表现良好。
通道（channel）是两个管理器之间的单向点对点通信连接，如果需要双向通信，可以建立一对通道。
Exchange（消息交换） Exchange类似于数据通信网络中的交换机，提供消息路由策略。
在RabbitMq中，生产者不会通过通道直接将消息发送到队列，而是先将消息发送到Exchange。
一个Exchange可以绑定多个Queue，当生产者发送消息时，会发送一个ROUTING_KEY，Exchange会根据特定的路由算法，将消息路由到根据这个ROUTING_KEY确定的队列中。
与队列一样，交换器也可以设置为持久、临时或自动删除。
Exchange 有 4 种类型：direct（默认）、fanout、topic 和 header。
不同类型的Exchange有不同的消息转发策略：
绑定所谓绑定就是将特定的Exchange绑定到特定的Queue上。
Exchange和Queue之间的绑定可以是多对多的关系。
RoutingKey交换器（路由关键字）根据该关键字传递消息。
vhosts（虚拟主机）可以在RabbitMqserver上创建多个虚拟消息代理，也称为虚拟主机（vhosts）。
每个虚拟主机本质上都是一个迷你rabbitmqserver，每个虚拟主机管理自己的交换和绑定。
Vhost相当于物理服务器，可以为不同的应用程序提供边界隔离，使应用程序可以安全地运行在不同的vhost实例上，而不会互相干扰。
生产者和用户需要指定一个虚拟主机来连接到rabbit服务器。
假设P1和C1注册了相同的Broker、Exchange和Queue。
P1发送的消息最终会被C1使用。
基本通信流程大致如下：
当User收到消息时，需要显式地将基本消息发送给RabbitBroker。
当 ack 消息或用户订阅消息时，将 auto_ack 参数设置为 true。
在通信过程中，队列在以下几种情况下会处理ACK：
即确认机制消息确认为了保证消息不丢失，消息队列提供了确认机制，即ACK机制 当用户确认消息已被使用并处理时，向消息队列发送ACK。
如果一个用户宕机/关闭并且没有发送ACK，消息队列将假设该消息尚未被处理，并将该消息重新发送给另一个用户以供重用和处理。
发送和接收消息的处理支持事务例如：在任务中心场景中，一次处理可能涉及多条消息的接收和处理，这些消息应该在处理失败的同一个事务范围内，事务被回滚，消息被放回到队列中。
消息持久化对于一些关键核心业务非常重要，启用消息持久化后，消息队列关闭重启后，可以从持久化存储中恢复消息，而不会丢失消息继续获取和处理。
Fanout模式的特点：
任何以直接模式发送到DirectExchange的消息都会被转发到routing_key中指定的Queue。
如果exchange声明为direct，并且在bind中指定了routing_key，那么发送消息时需要同时指定exchange和routing_key。
简而言之：生产者生成消息并发送给Exchange根据Exchange类型和basic_publish中的routing_key发送消息消费者：订阅Exchange并根据Exchange类型和绑定中的BindingKey发送消息，如果生产者和消费者是相同的，Exchange 将创建一条到该队列的路径。
前面提到主题模式，直接类型的Exchange路由规则完全匹配Binding Key和Route Key，但是这种严格的匹配方式很多时候并不能满足实际的业务需求。
Exchange主题类型制定了匹配规则它与直接类型Exchange类似，它也会将消息路由到绑定键与路由键匹配的队列，但这里的匹配规则有很大不同。
它设置：
RabbitMQ，部署分为三种模式：单机模式、普通集群模式、镜像集群模式
多队列元数据机器上使用普通集群模式
如果另外一个实例使用时已连接，该实例将从 Instance at 开始 队列所在的实例拉取数据 这会造成拉取数据的开销 如果队列所在的实例，其他实例将无法从该实例拉取，即使开启了消息持久化。
允许rabbitmq保存消息 如果是这样，消息不一定会丢失，但必须等待实例恢复才能继续从队列中拉取数据。
据介绍，根本没有高可用性，它提供的是吞吐量，允许集群中的多个节点为特定队列p>queue传递读写操作。
元数据和消息会存储在多个实例中，每次写入消息时，都会自动同步到队列的多个实例中。
如上所述，但性能开销太高消息同步导致压力和网络带宽占用过大，而且没有队列可扩展性。
，没有办法线性增长你的队列目前，你需要启用镜像集群模式并在rabbitmq管理控制台中创建一个新的集群。
添加一个策略，将数据同步到指定数量的节点 然后当你再次创建队列时，使用这个策略，数据就会自动同步到其他节点
Kafka是Apache的子项目，该项目是一个派生消息队列系统/高性能跨语言订阅（不严格实现JMS规范的点对点模型）。
类型，但效果可以达到），在企业开发中被广泛使用高性能是它最大的优点，弱点是消息可靠性（丢失或者重复，为了换取高性能，开发者可以少用。
在降低性能方面换取消息可靠性
一个topic可以被认为是一种消息，每个topic会被分为若干个par。
每条消息在文件中的位置称为偏移量。
Kafka 不提供任何额外的索引机制来存储偏移量，因为 Kafka 不允许“随机读取”消息。
Kafka与JMS(JavaMessageService)(activeMQ)实现的区别在于，即使消息被消费，也不会立即删除。
日志文件会根据broker中的配置要求存储一定时间然后删除，例如日志文件存储2天，则无论是否存储，两天后该文件都会被清除； 里面的信息被吃掉了。
Kafka使用这种简单的方法来释放磁盘空间并减少消息消费后更改文件的磁盘IO开销。
对于用户来说，需要存储所使用的消息的偏移量，偏移量的存储和使用是由用户控制的，当用户正常使用消息时，偏移量会“线性”向前驱动。
也就是说，消息将被顺序使用。
事实上，用户可以按任意顺序使用该消息，只需将偏移量重置为任意值即可。
（offset会存储在zookeeper中，见下文）
kafka集群几乎不需要任何消费者和生产者的状态信息，因此，生产者和消费者的客户端实现非常轻量，他们可以随心所欲，无需任何操作。
对集群造成额外影响。
分区是为各种目的而设计的。
最基本的原因是kafka是基于文件存储的。
通过分区，可以将日志分散到多台服务器上，防止文件大小达到一台机器磁盘的上限。
每个分区都会由当前服务器存储（一个kafka实例可以分区为任意数量）； 分区到消息保护/使用效率。
另外，更多的区块意味着可以容纳更多的用户，有效提高并发使用能力。
（具体原则见下文）。
Topics的多个分区分布在Kafka集群中的多台服务器上，每个服务器（例如kafka）负责读写分区中的消息，另外，Kafka还可以配置要备份的分区； 最多副本数（replicas），每个分区都会备份到多台机器上以提高可用性。
基于复制的解决方案，这意味着需要安排多个备份； 每个分区都有一个服务器作为“领导者”； 它将有其他追随者接替（成为新的领导者）； 可见，作为Leader的服务器承担了所有的需求压力，因此，考虑到整个集群，分区的数量意味着有多少个“Leader”，将“Leader”平均分配，以保证整体性能稳定。
基本上Kafka用户只支持Topics。
每个用户都属于一个用户组，而不是每个组中有多个用户。
发送到某个主题的消息只能由订阅该主题的每个组中的一个用户使用。
如果所有用户都是同一个组，这种情况就差不多了，消息队列模式会在用户之间均匀加载。
如果所有用户都有不同的组，那么这就是“发布-订阅”；
在Kafka中，一个分区中的消息只会被一组中的一个用户使用，每组中的用户的消息消费是相互独立的； Topic 中的每个分区只会被“客户端”中的一个用户使用，但用户可以消费来自多个分区的消息。
Kafka只能保证分区中的消息被用户消费时是顺序的。
事实上，从Topic的角度来看，消息仍然是乱序的。
Kafka的设计原则规定，对于一个Topic，同一组内的用户同时使用的分区数量不能超过该数量，否则意味着部分用户将收不到消息。
保证
Kafka更适合高吞吐量的场景，并且允许数据丢失很少。
如果必须保证“可靠的消息传递”，可以使用JMS。
发送KafkaProducer消息有两种方式（Producer.type配置参数）：
对于同步模式（Producer.type=sync）？ 发送KafkaProducer消息的认证方式（acks配置参数）有3种：
Kafka最初的设计意图是作为一个统一的信息收集平台，能够实时收集反馈信息，需要能够支持大量数据，并具有良好的容错能力。
持久化Kafka使用文件来存储消息，这直接决定了Kafka的性能高度依赖于文件系统本身的特性。
而且无论任何操作系统，都几乎不可能优化文件系统本身。
文件缓存/直接内存映射等 是一种常用的方法。
由于Kafka增加了日志文件，同时磁盘检索的成本较小，为了减少磁盘写入次数，broker会在消息数量（或大小）达到一定阈值、时间时临时缓冲消息，然后刷新到磁盘，一次性减少磁盘IO调用次数。
需要考虑的性能点有很多除了磁盘IO之外，我们还需要考虑网络IO，这与Kafka的吞吐量有直接关系。
Kafka 并没有提供很多出色的技能； 在生产者端，可以对消息进行缓冲，当消息数量达到一定阈值时，将消息批量发送到broker。
消费者端也是如此，可以批量获取多条消息。
但是，消息卷大小可以通过配置文件指定。
在kafkabroker这边，似乎有一个sendfile系统调用有潜力提高网络IO性能：数据被映射到系统内存，socket可以继续读取相应的内存区域，而不需要进程再次复制和转换。
事实上，对于生产者/消费者/经纪人来说，CPU 支出应该不会很大，因此启用消息压缩机制是一个很好的策略，需要少量的 CPU 资源，但对于 Kafka 来说，需要考虑网络 IO。
通过网络发送的任何消息都可以被压缩。
卡夫卡支持多种压缩方法，例如 gzip/snappy。
生产者负载均衡： 生产者将与Topic下的所有分区头保持socket连接，消息直接从生产者通过socket发送到broker，中间不需要经过任何“路由层”； 事实上，发出客户端决定将消息路由到哪个分区。
例如，您可以使用“随机”、“密钥哈希”、“轮询”等。
如果一个topic中有多个分区，那么就需要在生产者端实现“均衡消息分发”。
分区头的位置（主机：端口）在zookeeper中注册。
发布者作为zookeeper客户端，注册了一个watch来监控分区头变化事件。
异步交付： 在客户端临时缓冲多条消息并将它们批量发送到代理太多的小数据IO会减慢整体网络延迟，实际上提高了网络效率。
不过这也存在一定的隐患，比如当生产者失败时，那些未投递的消息就会丢失。
用户向broker发送“fetch”请求，告诉broker平衡消息，之后用户会获取一定数量的消息也可以重置余额； 再次完成消息。
在JMS实现中，Topic模型是基于push方式的，即broker将消息推送给consumer。
然而，在Kafka中，采用的是pull方式，即用户与broker建立关系后，主动拉取（或检索）消息。
这种模式有几个优点：第一，用户可以在a中检索消息。
根据自己的消费能力适时地进行消费，并且可以控制消息消费的进度（均衡）。
此外，用户还可以控制消息消费的数量、batchfetch。
在其他JMS实现中，消息部署位置由提供者保留，以避免重复发送消息或重传部署不成功的消息等，同时必须控制消息状态。
这需要JMSbroker需要太多的额外工作。
在Kafka中，只有一个用户使用分区中的消息，并且没有消息状态控制，也没有复杂的消息认证机制，可见Kafka Broker是比较轻量的。
用户收到消息后，可以在本地存储上一条消息的偏移量，并间歇性地将偏移量注册到zookeeper。
可以看到用户客户端也很轻。
对于 JMS 实现，保证消息传递非常简单： 完全正确。
在kafka中有点不同：
atmostonce： 用户取出消息，然后保存偏移量，客户端保存偏移量后再处理消息，消息处理过程中出现异常，导致部分消息无法继续处理。
那么以后将不会检索到“未处理”的消息。
这就是“atmostonce”。
运动能力： 用户获取消息，然后处理消息，然后存储偏移量。
如果消息处理成功，但是在offset保存阶段zookeeper异常导致save操作失败，这会导致在检索时有可能得到最后处理的消息，这是“atleastonce”，原因是offset没有及时更新提交给zookeeper，zookeeper恢复正常或者之前的offset状态。
确切地说： Kafka没有严格实现（基于2阶段提交，事务我们认为Kafka中不需要这种策略。
通常“at-least-once”是我们的首选。
（相比之下）atmostonce，重复接收数据比丢失数据要好）。
高可用Kafka由多个broker组成，每个broker就是一个节点
创建一个topic，会被划分为多个partition，每个partition存在于不同的broker上，每个一; 分区放置部分数据。
Kafka是分布式消息队列，即上层Data ic分散在不同的机器上，每台机器存储一部分数据。
0.8版本之前，没有HA机制，如果任何broker宕机，该broker上的分区将无用，根本无法写入或读取。
0.8版本之后，提供了HA机制，即副本机制。
每个分区的数据都会同步到其他机器上，形成自己的多个副本。
那么所有的副本都会选择一个leader，然后生产和消费都会和这个leader打交道，其他的replica都是follower。
写入时，leader 会负责将数据同步给所有follower，读取时，只读取leader上的数据。
Kafka会将所有分区副本均匀分布在不同的机器上，以提高容错能力。
某个特定的broker上是否有分区drop，在另一台机器上是否有副本并不重要，如果其上有特定的分区leader，那么此时会重新选举一个新的leader退出，大家可以继续读写新的leader。
这称为高可用性。
写入数据时，生产者写入到leader，然后leader将数据写入本地磁盘，然后其他follower主动从leader那里拉取数据。
一旦所有follower都同步了数据，他们就会向leader发送ack。
leader收到所有follower的ack后，会向publisher返回写入成功的消息。
消息丢失会发生在三个环节，即生产者、mq中间件、消费者：
RabbitMQ
Kafka大体上和RabbitMQ是一样的。
Rabbitmq需要保证顺序消息发送到同一个队列，这个队列只能有一个用户如果需要提高性能，可以使用内存队列，然后分发给不同的基础worker进行处理。
Kafka写入分区的数据必须是有序的。
生产者写入时可以指定key，比如指定订单id作为key，订单相关的数据就会分发到分区中。
当用户从分区中取出数据时，必须按顺序将每一条数据插入到对应的内存队列线程处理的一个内存队列中。
