鞋网站建设方案,多个链接的网站怎么做的,网页设计与制作心得体会1500字,湛江网站建设的详细过程RabbitMQ
RabbitMQ是实现AMQP协议(0.9.1) 的消息中间件的一种#xff0c;由RabbitMQ Technologies Ltd开发并且提供商业支持的#xff0c;最初起源于金融系统#xff0c;服务器端用Erlang语言编写#xff0c;用于在分布式系统中存储转发消息#xff0c;在易用性、扩展性、…RabbitMQ
RabbitMQ是实现AMQP协议(0.9.1) 的消息中间件的一种由RabbitMQ Technologies Ltd开发并且提供商业支持的最初起源于金融系统服务器端用Erlang语言编写用于在分布式系统中存储转发消息在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ基本概念
Broker 简单来说就是消息队列服务器实体Exchange 消息交换机它指定消息按什么规则路由到哪个队列Queue 消息队列载体每个消息都会被投入到一个或多个队列Binding 绑定它的作用就是把exchange和queue按照路由规则绑定起来Routing Key 路由关键字exchange根据这个关键字进行消息投递VHost vhost 可以理解为虚拟 broker 即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等但最最重要的是其拥有独立的权限系统可以做到 vhost 范围的用户控制。当然从 RabbitMQ 的全局角度vhost 可以作为不同权限隔离的手段一个典型的例子就是不同的应用可以跑在不同的 vhost 中。Producer 消息生产者就是投递消息的程序Consumer 消息消费者就是接受消息的程序Channel 消息通道在客户端的每个连接里可建立多个channel每个channel代表一个会话任务
由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。
RabbitMQ处理流程
1.Producer会先建立Channel建立到Broker上Virtual Host的连接接下来就可以向这个Virtual Host中的Exchange发送消息。
2.Producer把消息发布到Exchange上消息最终到达队列并被消费者接收而Binding决定交换器的消息应该发送到那个队列。Exchange能够处理消息的前提是它至少已经和某个Queue或者另外的Exchange形成了绑定关系并设置好了到这些Queue和Excahnge的路由规则。在Exchange收到消息后会根据设置的路由规则将消息发送到符合要求的Queue或者Exchange中路由规则与Message中的Routing Key属性配合使用。
3.当Queue收到消息后会进行如下处理
如果当前没有Consumer的Channel连接到这个Queue那么Queue将会把这条消息进行存储直到有Channel被创建。如果已经有Channel连接到这个Queue那么消息将会按顺序发送给这个Channel。
4.当Consumer收到消息后就可以进行消息的处理
Consumer在完成某一条消息的处理后将需要手动的发送一条ACK消息到对应的Queue也可以设置为自动发送或者无需发送。Queue在接收到这条ACK信息后才认为这条消息处理成功并将这条消息从Queue中移除。如果在对应的Channel断开后Queue都没有这条消息的ACK信息这条消息将会重新被发送给另外的Channel。也可以直接发送NACK信息这样这条消息将会立即归队并发送给另外的Channel。
RabbitMQ的工作模式
simple模式即最简单的收发模式 1.消息产生消息将消息放入队列
2.消息的消费者(consumer) 监听 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失这里可以设置成手动的ack,但如果设置成手动ack处理完后要及时发送ack消息给队列否则会造成内存溢出)。
work工作模式(资源的竞争) 1.消息产生者将消息放入队列。
2.消费者可以有多个,消费者1,消费者2同时监听同一个队列,消息被消费。C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize) 保证一条消息只能被一个消费者使用)。
publish/subscribe发布订阅(共享资源) 1、每个消费者监听自己的队列
2、生产者将消息发给broker由交换机将消息转发到绑定此交换机的每个队列每个绑定交换机的队列都将接收到消息。
routing路由模式 1.消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息;
2.根据业务功能定义路由字符串
3.从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。
4.业务场景:error 通知;EXCEPTION;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;
topic 主题模式(路由模式的一种) 1.星号(*)井号(#)代表通配符
2.星号(*)代表多个单词,井号(#)代表一个单词
3.路由功能添加模糊匹配
4.消息产生者产生消息,把消息交给交换机
5.交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费
RabbitMQ优点
由于erlang语言的特性mq 性能较好高并发健壮、稳定、易用、跨平台、支持多种语言、文档齐全有消息确认机制和持久化机制可靠性高高度可定制的路由管理界面较丰富在互联网公司也有较大规模的应用社区活跃度高
RabbitMQ缺点
尽管结合erlang语言本身的并发优势性能较好但是不利于做二次开发和维护实现了代理架构意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署但是使得其运行速度较慢因为中央节点增加了延迟消息封装后也比较大需要学习比较复杂的接口和协议学习和维护成本较高
Kafka
Kafka是由Apache软件基金会开发的一个开源流处理平台由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统它可以处理消费者规模的网站中的所有动作流数据。 这种动作网页浏览搜索和其他用户的行动是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统但又要求实时处理的限制这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理也是为了通过集群来提供实时的消息。 Kafka基本概念 Broker 消息中间件处理节点一个Kafka节点就是一个Broker一个或者多个Broker可以组成一个Kafka集群 Topic 每条发布到Kafka集群的消息都有一个类别这个类别被称为Topic。物理上不同Topic的消息分开存储逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处 Partition 用于存放消息的队列存放的消息都是有序的同一主题可以分多个Partition如分多个Partiton时同样会以如partition1存放1、3、5消息partition2存放2、4、6消息 Producer 消息生产者向Broker发送消息的客户端 Consumer 消息消费者从Broker读取消息的客户端Consumer是通过offset进行标识消息被消费的位置 Consumer Group 每个Consumer属于一个特定的Consumer Group一条消息可以发送到多个不同的Consumer Group但是同一个Consumer Group中只能有一个Consumer能够消费该消息
Kafka数据处理步骤
Producer产生消息发送到Broker中Leader状态的Broker接收消息写入到相应topic中Leader状态的Broker接收完毕以后传给Follow状态的Broker作为副本备份Consumer消费Broker中的消息
Kafka优点
客户端语言丰富支持java、.net、php、ruby、python、go等多种语言性能卓越单机写入TPS约在百万条/秒消息大小10个字节提供完全分布式架构, 并有replica机制, 拥有较高的可用性和可靠性, 理论上支持消息无限堆积支持批量操作消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方Kafka Web管理界面Kafka-Manager在日志领域比较成熟被多家公司和多个开源项目使用
Kafka缺点
Kafka单机超过64个队列/分区Load会发生明显的飙高现象队列越多load越高发送消息响应时间变长使用短轮询方式实时性取决于轮询间隔时间消费失败不支持重试支持消息顺序但是一台代理宕机后就会产生消息乱序社区更新较慢
RocketMQ
RocketMQ 是阿里巴巴在2012年开源的分布式消息中间件目前已经捐赠给 Apache 软件基金会并于2017年9月25日成为 Apache 的顶级项目。作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件以其高性能、低延时和高可靠等特性近年来已经也被越来越多的国内企业使用。 RocketMQ基本概念
生产者组Producer
负责产生消息生产者向消息服务器发送由业务应用程序系统生成的消息。 RocketMQ 提供了三种方式发送消息同步、异步和单向。
名称服务器NameServer
主要负责对于源数据的管理包括了对于Topic和路由信息的管理。
NameServer 被设计成几乎无状态的可以横向扩展节点之间相互之间无通信通过部署多台机器来标记自己是一个伪集群。每个 Broker 在启动的时候会到 NameServer 注册Producer 在发送消息前会根据 Topic 到 NameServer 获取到 Broker 的路由信息Consumer 也会定时获取 Topic 的路由信息。所以从功能上看应该是和 ZooKeeper 差不多RocketMQ 的早期版本确实是使用的 ZooKeeper 后来改为了自己实现的 NameServer 。
消息服务器Broker
是消息存储中心主要作用是接收来自 Producer 的消息并存储 Consumer 从这里取得消息。它还存储与消息相关的元数据包括用户组、消费进度偏移量、队列信息等。从部署结构图中可以看出 Broker 有 Master 和 Slave 两种类型Master 既可以写又可以读Slave不可以写只可以读。从物理结构上看 Broker 的集群部署方式有四种单 Master 、多 Master 、多 Master 多 Slave同步刷盘、多 Master多 Slave异步刷盘。
消费者组Consumer
负责消费消息消费者从消息服务器拉取信息并将其输入用户应用程序,支持PUSH和PULL两种消费模式支持集群消费和广播消息提供实时的消息订阅机制。
Pull拉取型消费者Pull Consumer主动从消息服务器拉取信息只要批量拉取到消息用户应用就会启动消费过程所以 Pull 称为主动消费型。Push推送型消费者Push Consumer封装了消息的拉取、消费进度和其他的内部维护工作将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型但从实现上看还是从消息服务器中拉取消息不同于 Pull 的是 Push 首先要注册消费监听器当监听器处触发后才开始消费消息。
RocketMQ特性
1.灵活可扩展性 天然支持集群其核心四组件Name Server、Broker、Producer、Consumer每一个都可以在没有单点故障的情况下进行水平扩展。
2.海量消息堆积 采用零拷贝原理实现超大的消息的堆积能力据说单机已可以支持亿级消息堆积而且在堆积了这么多消息后依然保持写入低延迟。
3.顺序消息 可以保证消息消费者按照消息发送的顺序对消息进行消费。顺序消息分为全局有序和局部有序一般推荐使用局部有序即生产者通过将某一类消息按顺序发送至同一个队列来实现。
4.消息过滤 分为在服务器端过滤和在消费端过滤。服务器端过滤时可以按照消息消费者的要求做过滤优点是减少不必要消息传输缺点是增加了消息服务器的负担实现相对复杂。消费端过滤则完全由具体应用自定义实现这种方式更加灵活缺点是很多无用的消息会传输给消息消费者。
5.事务消息 除了支持普通消息顺序消息之外还支持事务消息这个特性对于分布式事务来说提供了又一种解决思路。
6.消息回溯 是指消费者已经消费成功的消息由于业务上需求需要重新消费RocketMQ 支持按照时间回溯消费时间维度精确到毫秒可以向前回溯也可以向后回溯。
RocketMQ优点
单机支持 1 万以上持久化队列RocketMQ 的所有消息都是持久化的先写入系统 PAGECACHE然后刷盘可以保证内存与磁盘都有一份数据访问时直接从内存读取。模型简单接口易用JMS 的接口很多场合并不太实用性能非常好可以大量堆积消息在broker中支持多种消费包括集群消费、广播消费等。各个环节分布式扩展设计主从HA开发度较活跃版本更新很快。
RocketMQ缺点
支持的客户端语言不多目前是java及c其中c不成熟RocketMQ社区关注度及成熟度不高没有web管理界面提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题没有在 mq 核心中去实现JMS等接口
ActiveMQ
ActiveMQ是由Apache出品旨在为应用程序提供高效、可扩展、稳定、安全的企业级消息通信它是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现比如 JMX 管理、主从管理、消息组通信、消息优先级、延迟接收消息、虚拟接收者、消息持久化、消息队列监控等等。它非常快速支持多种语言的客户端和协议而且可以非常容易的嵌入到企业的应用环境中并有许多高级功能。 和上面的mq类似主要的基本组件有Broker、Producer、Consumer、Topic、Queue、Message
ActiveMQ优点
跨平台(JAVA编写与平台无关有ActiveMQ几乎可以运行在任何的JVM上)可以用JDBC可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能但是数据库一直都是开发人员最熟悉的存储介质。将消息存到数据库看得见摸得着。而且公司有专门的DBA去对数据库进行调优主从分离支持JMS 支持JMS的统一接口;支持自动重连有安全机制支持基于shirojaas等多种安全配置机制可以对Queue/Topic进行认证和授权。监控完善拥有完善的监控包括Web ConsoleJMXShell命令行Jolokia的REST API界面友善提供的Web Console可以满足大部分情况还有很多第三方的组件可以使用如hawtio
ActiveMQ缺点
社区活跃度不及RabbitMQ高根据其他用户反馈会出莫名其妙的问题会丢失消息对5.x的维护较少不适合用于上千个队列的应用场景
RabbitMQ、Kafka、RocketMQ、ActiveMQ对比
特性RabbitMQKafkaRocketMQActiveMQ开发语言ErlangScalaJavaJavaJava客户端支持官方支持Erlang、Java、Ruby等社区产出多语言API几乎支持所有常用语言官方支持Java社区有多语言版本如PHP、Python、Go、C/C、Ruby、NodeJs等Java、CJava、C/C、Python、PHP、Perl、.net等协议支持AMQP、XMPP、SMTP、SMTOP自定义协议社区提供了HTTP协议支持自定义协议社区提供JMSOpenWire、SMTOP、REST、XMPP、AMQP可用性高基于主从架构实现高可用很高分布式一个数据多个副本少数机器宕机不会丢失数据不会导致不可用很高分布式架构高基于主从架构实现高可用集群支持支持支持支持负载均衡支持支持支持支持单机吞吐量万级十万级十万级万级topic数量对吞吐量的影响-topic从几十到几百个时候吞吐量会大幅度下降因为Kafka的每个Topic、每个分区都会对应一个物理文件若需要支撑大规模的topic则需要增加更多的机器资源topic达到几百/几千的级别后吞吐量会有较小幅度的下降在同等机器下可以支撑大量的 topic-消息批量操作不支持支持支持支持消息推拉模式pull/push均支持pullpull/push均支持pull/push均支持消息可靠性支持最少投递一次支持最少投递一次支持最少投递一次有较低的概率丢失数据消息延迟微秒级 (最快)毫秒级毫秒级毫秒级持久化能力内存、文件支持数据堆积但影响生产速率磁盘文件只要容量够可以做到无限堆积磁盘文件内存、文件、数据库事务消息不支持不支持支持支持死信支持不支持支持支持消息回放不支持支持offset维度回放支持offset维度回放不支持延迟队列支持不支持支持支持
