做搜狗网站优化首页今天昆明刚刚发生的新闻

当前位置： 首页 > news >正文

做搜狗网站优化首页,今天昆明刚刚发生的新闻,wordpress主题模板 教育,宁波网页设计培训班一、语言不同 RabbitMQ是由内在高并发的erlanng语言开发#xff0c;用在实时的对可靠性要求比较高的消息传递上。 kafka是采用Scala语言开发#xff0c;它主要用于处理活跃的流式数据,大数据量的数据处理上 RocketMQ是采用java语言开发的 二、吞吐量 kafka吞吐量更高用在实时的对可靠性要求比较高的消息传递上。 kafka是采用Scala语言开发它主要用于处理活跃的流式数据,大数据量的数据处理上 RocketMQ是采用java语言开发的 二、吞吐量 kafka吞吐量更高 　　1Zero Copy机制内核copy数据直接copy到网络设备没必要通过内核到用户再到内核的copy减少了copy次数和上下文切换次数大大提升了效率。 　　2磁盘顺序读写减小了寻道等待的时间。 　　3批量处理机制服务端批量存储客户端主动批量pull数据消息处理效率高。 　　4存储具备O(1)的复杂度读物由于分区和segment是O(log(n))的复杂度。 　　5分区机制有助于提升吞吐量。 三、可靠性 rabbitmq可靠性更好 　　1确认机制生产者和exchange消费者和队列 　　2支持事务但会形成阻塞 　　3委托添加回调来处理发送失败的消息和备份交换器将发送失败的消息存下来后面再处理机制 四、高可用 　　1rabbitmq采用mirror queue即主从模式数据是异步同步的当消息过来主从所有写完后回ack这样保障了数据的一致性。 　　2每一个分区均可以有一个或多个副本这些副本保存在不一样的broker上broker信息存储在zookeeper上当broker不可用会从新选举leader。 　　kafka支持同步负责消息和异步同步消息有丢消息的可能生产者从zk获取leader信息发消息给leaderfollower从leader pull数据而后回ack给leader。 五、负责均衡 　　1kafka经过zk和分区机制实现zk记录broker信息生产者能够获取到并经过策略完成负载均衡经过分区投递消息到不一样分区消费者经过服务组完成均衡消费。 　　2须要外部支持。 六、模型 　　1rabbitmq 　　　　producerbroker遵循AMQPAdvanced Message Queuing Protocol高级消息队列协议是一个进程间传递异步消息的网络协议由Exchange,Binding,queue组成consumer 　　　　broker为中心exchange分topicdirectfanout和header路由模式适合多种场景 　　　　consumer消费位置由broker经过确认机制保存 　　2kafka 　　　　producerbrokerconsumer未遵循AMQP 　　　　consumer为中心获取消息模式由consumer本身决定 　　　　offset保存在消费者这边broker无状态 　　　　消息是名义上的永久存储每一个parttition按segment保存本身的消息为文件可配置清理周期 　　　　consumer能够经过重置offset消费历史消息 　　　　须要绑定zk kafka采用mq结构broker 有part 分区的概念 RabbitMQ 采用push的方式 kafka采用pull的方式 rabbitMQ的负载均衡需要单独的loadbalancer进行支持。 kafka采用zookeeper对集群中的broker、consumer进行管理 数据可靠性 RocketMQ支持异步实时刷盘同步刷盘同步Replication异步ReplicationKafka使用异步刷盘方式异步Replication 总结RocketMQ的同步刷盘在单机可靠性上比Kafka更高不会因为操作系统Crash导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠数据完全无单点。另外Kafka的Replication以topic为单位支持主机宕机备机自动切换但是这里有个问题由于是异步Replication那么切换后会有数据丢失同时Leader如果重启后会与已经存在的Leader产生数据冲突。开源版本的RocketMQ不支持Master宕机Slave自动切换为Master阿里云版本的RocketMQ支持自动切换特性。 性能对比 Kafka单机写入TPS约在百万条/秒消息大小10个字节RocketMQ单机写入TPS单实例约7万条/秒单机部署3个Broker可以跑到最高12万条/秒消息大小10个字节 总结Kafka的TPS跑到单机百万主要是由于Producer端将多个小消息合并批量发向Broker。 RocketMQ为什么没有这么做 Producer通常使用Java语言缓存过多消息GC是个很严重的问题Producer调用发送消息接口消息未发送到Broker向业务返回成功此时Producer宕机会导致消息丢失业务出错Producer通常为分布式系统且每台机器都是多线程发送我们认为线上的系统单个Producer每秒产生的数据量有限不可能上万。缓存的功能完全可以由上层业务完成。 单机支持的队列数 Kafka单机超过64个队列/分区Load会发生明显的飙高现象队列越多load越高发送消息响应时间变长RocketMQ单机支持最高5万个队列Load不会发生明显变化 队列多有什么好处 单机可以创建更多Topic因为每个Topic都是由一批队列组成Consumer的集群规模和队列数成正比队列越多Consumer集群可以越大 消息投递实时性 Kafka使用短轮询方式实时性取决于轮询间隔时间RocketMQ使用长轮询同Push方式实时性一致消息的投递延时通常在几个毫秒。 消费失败重试 Kafka消费失败不支持重试RocketMQ消费失败支持定时重试每次重试间隔时间顺延 总结例如充值类应用当前时刻调用运营商网关充值失败可能是对方压力过多稍后在调用就会成功如支付宝到银行扣款也是类似需求。 这里的重试需要可靠的重试即失败重试的消息不因为Consumer宕机导致丢失。 严格的消息顺序 Kafka支持消息顺序但是一台Broker宕机后就会产生消息乱序RocketMQ支持严格的消息顺序在顺序消息场景下一台Broker宕机后发送消息会失败但是不会乱序 Mysql Binlog分发需要严格的消息顺序 定时消息 Kafka不支持定时消息RocketMQ支持两类定时消息 开源版本RocketMQ仅支持定时Level阿里云ONS支持定时Level以及指定的毫秒级别的延时时间 分布式事务消息 Kafka不支持分布式事务消息阿里云ONS支持分布式定时消息未来开源版本的RocketMQ也有计划支持分布式事务消息 消息查询 Kafka不支持消息查询RocketMQ支持根据Message Id查询消息也支持根据消息内容查询消息发送消息时指定一个Message Key任意字符串例如指定为订单Id 总结消息查询对于定位消息丢失问题非常有帮助例如某个订单处理失败是消息没收到还是收到处理出错了。 消息回溯 Kafka理论上可以按照Offset来回溯消息RocketMQ支持按照时间来回溯消息精度毫秒例如从一天之前的某时某分某秒开始重新消费消息 总结典型业务场景如consumer做订单分析但是由于程序逻辑或者依赖的系统发生故障等原因导致今天消费的消息全部无效需要重新从昨天零点开始消费那么以时间为起点的消息重放功能对于业务非常有帮助。 消费并行度 Kafka的消费并行度依赖Topic配置的分区数如分区数为10那么最多10台机器来并行消费每台机器只能开启一个线程或者一台机器消费10个线程并行消费。即消费并行度和分区数一致。 RocketMQ消费并行度分两种情况 顺序消费方式并行度同Kafka完全一致乱序方式并行度取决于Consumer的线程数如Topic配置10个队列10台机器消费每台机器100个线程那么并行度为1000。 消息轨迹 Kafka不支持消息轨迹阿里云ONS支持消息轨迹 开发语言友好性 Kafka采用Scala编写RocketMQ采用Java语言编写 Broker端消息过滤 Kafka不支持Broker端的消息过滤RocketMQ支持两种Broker端消息过滤方式 根据Message Tag来过滤相当于子topic概念向服务器上传一段Java代码可以对消息做任意形式的过滤甚至可以做Message Body的过滤拆分。 消息堆积能力 理论上Kafka要比RocketMQ的堆积能力更强不过RocketMQ单机也可以支持亿级的消息堆积能力我们认为这个堆积能力已经完全可以满足业务需求。 开源社区活跃度 Kafka社区更新较慢RocketMQ的github社区有250个个人、公司用户登记了联系方式QQ群超过1000人。 商业支持 Kafka原开发团队成立新公司目前暂没有相关产品看到RocketMQ在阿里云上已经开放公测近半年目前以云服务形式免费供大家商用并向用户承诺99.99%的可靠性同时彻底解决了用户自己搭建MQ产品的运维复杂性问题 成熟度 Kafka在日志领域比较成熟RocketMQ在阿里集团内部有大量的应用在使用每天都产生海量的消息并且顺利支持了多次天猫双十一海量消息考验是数据削峰填谷的利器。 五、使用场景 rabbitMQ支持对消息的可靠的传递支持事务不支持批量的操作基于存储的可靠性的要求存储可以采用内存或者硬盘。 金融场景中经常使用 kafka具有高的吞吐量内部采用消息的批量处理zero-copy机制数据的存储和获取是本地磁盘顺序批量操作具有O(1)的复杂度与分区上的存储大小无关消息处理的效率很高。大数据 补充 Server:又称Broker接受客户端的连接实现AMQP实体服务 Connection连接应用程序与Broker的网络连接 Channel网络信道几乎所有的操作都在Channel中进行Channel是进行消息读写的通道。客户端可建立多个Channel每个Channel代表一个会话任务。 Message消息服务器和应用程序之间传送的数据由Properties和Body组成。Properties可以对消息进行修饰比如消息的优先级、延迟等高级特性Body则就是消息体内容。 Virtual host:虚拟地址用于进行逻辑隔离最上层的消息路由。一个Virtual Host里面可以有若干个Exchange和Queue同一个VirtualHost 里面不能有相同名称的Exchange或Queue Exchange:交换机接收消息根据路由键转发消息到绑定的队列 Binding:Exchange和Queue之间的虚拟连接binding中可以包含routing key Routing key:一个路由规则虚拟机可用它来确定如何路由一个特定消息 Producer消息生产者向Broker发送消息的客户端 Consumer消息消费者从Broker读取消息的客户端 Broker消息中间的处理节点这里和kafka不同kafka的Broker没有主从的概念都可以写入请求以及备份其他节点数据RocketMQ只有主Broker节点才能写一般也通过主节点读当主节点有故障或者一些其他特殊情况才会使用从节点读有点类似- 于mysql的主从架构。 Topic消息主题一级消息类型生产者向其发送消息, 消费者读取其消息。 Group分为ProducerGroup,ConsumerGroup,代表某一类的生产者和消费者一般来说同一个服务可以作为Group,同一个Group一般来说发送和消费的消息都是一样的。 TagKafka中没有这个概念Tag是属于二级消息类型一般来说业务有关联的可以使用同一个Tag,比如订单消息队列使用Topic_Order,Tag可以分为Tag_食品订单,Tag_服装订单等等。 Queue: 在kafka中叫Partition,每个Queue内部是有序的在RocketMQ中分为读和写两种队列一般来说读写队列数量一致如果不一致就会出现很多问题。 NameServerKafka中使用的是ZooKeeper保存Broker的地址信息以及Broker的Leader的选举在RocketMQ中并没有采用选举Broker的策略所以采用了无状态的NameServer太存储由于NameServer是无状态的集群节点之间并不会通信所以上传数据的时候都需要向所有节点进行发送。 引用https://www.jianshu.com/p/0364a171c2ae