织梦网站怎样做百度主动推送,做网站建设公司企业,岳阳市内从事网站建设的公司,学校网站建设 应用情况前些天发现了一个巨牛的人工智能学习网站#xff0c;通俗易懂#xff0c;风趣幽默#xff0c;忍不住分享一下给大家。点击跳转到教程。
消息中间件的作用
1. 应用解耦
2. 异步处理
比如用户注册场景#xff0c;注册主流程完成以后#xff0c;需要调用邮件系统发送邮件…前些天发现了一个巨牛的人工智能学习网站通俗易懂风趣幽默忍不住分享一下给大家。点击跳转到教程。
消息中间件的作用
1. 应用解耦
2. 异步处理
比如用户注册场景注册主流程完成以后需要调用邮件系统发送邮件通知用户注册成功可能还需要调用其他系统。这是串行的如果一个系统依赖很多系统那么这个主流程会比较长耦合度高整个系统维护成本也会越来越高。那么我们就可以使用消息中间件来进行解耦通过发布订阅模式完成用户注册之后向中间件发送消息这样就可以马上给用户返回至于后续工作其他系统向中间件订阅这个消息并完成后续工作就好。这也就是一个解耦和异步处理过程。 中间件有下面两种模型
点对点模型 发布订阅模型 消息中间件的解耦和异步是两个最重要的需求点除此之外还应该做一些其他事情比如 保证一致性产生消息和发送消息是一致的也就是如果操作成功那么消息一定发送成功如果业务操作没有成功那么就不能发送消息 具备一定消息堆积能力可以为后端挡住一些数据流保证后端不会被压垮 具备消息实时性保证消息的低延迟 具备消息的可靠性主要是可靠地存储和投递 消息系统里面应该有这样一个假设消息一定会堆积。下游系统通常有很多里面有重要的也不重要的面对突发流量高峰一定会有后端系统处理不过来的情况从而造成消息堆积当然还有一种情况是后端系统出现问题导致暂时无法消费消息从而造成消息中间件的消息堆积。所以中间件要起到蓄水池的作用。 数据一致性这个很容易理解因为是分布式异步的但是又不能容忍数据出错所以在性能和数据一致性方面就需要有所妥协通常在互联网行业中采取最终一致性。需要注意的是最终一致性和弱一致性不同弱一致性表示允许在异常情况下数据可能不一致而最终一致性则是在某段时间内允许不一致但是最终会一致。 RocketMQ介绍
基于发布订阅的队列模型消息中间件它只有发布和订阅的消息方式消息类型只支持Message消息可以持久化。服务端使用JAVA编写客户端支持JAVA、C。阿里2012年开源之后作为Apache基金会的一个项目进行维护。是一款低延迟、高可靠、可伸缩、易于使用的中间件。在Github上有相关介绍。 特性
消息可靠性 生产者的可靠性保证生产者发送消息后返回SendResult如果isSuccess返回true则表示消息已经确认发送到服务器并被服务器接收保存。整个发送过程是一个同步过程。 服务器的可靠性消息生产者发送的消息RocketMQ服务收到后在做必要的校验和检查之后马上保存到磁盘写入成功后返回给生产者。因此可以确认每条发送结果为成功的消息都会被消息服务器写入磁盘。 消费者的可靠性消费者是一条一条顺序消费的之后在成功消费一条后才会消费吓一跳。如果在消费某一条消息时失败则会重试消费这条消息默认为5次如果超过最大次数仍然无法消费则将消息保存到本地后台线程继续重试消费主线程则会继续往后走消费队列后面的消息。
消息持久性RocketMQ收到消息后会将消息持久化到文件并利用Linux文件系统内存来提高性能
消息实时性RocketMQ采取长轮询PULL模式保证消息的持久性
消息重复对于消费者来说通过拉取方式将消息保存到本地消费完再向服务器返回在网络异常的情况下可能会出现重复。
消息过滤 服务器端过滤减少不必要消息传输但是会增加服务器负担 客户端过滤根据客户端需求来定制消息缺点是客户端会收到对它来说没用的消息如果客户端无法承载这么多消息就会导致故障
消息堆积支持10亿级别的消息堆积不会因为消息堆积影响性能 术语说明 角色说明Producer Producer 生产者用于将消息发送到RocketMQ生产者本身既可以是生成消息也可以对外提供接口由外部来调用接口再由生产者将受到的消息发送给MQ。 Consumer Consumer 消费者从Broker拉取消息进行消费。从应用角度来说有两类消费者 PullConsumer主动拉取消息一旦拉取到消息应用的消费进程进行初始化 PushConsumer封装消息拉取消费进程和内部 Broker Broker RocketMQ服务器也是整个服务的核心它实现了消息的存储、拉取功能。它通常以集群方式启动并可配置主从每个broker上提供对指定topic的服务。理解了broker的原理以及它和其他服务交互的过程也就命令消息中间件的原理其实都大同小异。它具有2中角色 Master能写、能读 Slave只能读不能写 Topic Topic 消息的主题由用于定义并在服务端配置消费者可以按照主题进行订阅也就是消息分类通常一个应用一个Topic Message Message 在生产者、消费者、服务器之间传递的消息一个message必须属于一个Topic Namesrv Namesrv 一个无状态的名称服务可以集群部署每一个broker启动的时候都会向名称服务器注册主要是接收broker的注册broker每十秒就会向所有名称服务器发送心跳请求同时注册topic信息到名称服务器接收客户端的路由请求并返回路由信息你可以理解为服务自动发现就是相当于zookeeper在dubbo框架中的作用。 生产者发消息时会根据Topic向名称服务器获取到指定broker的路由信息 消费者根据Topic到名称服务器获取该Topic到broker的路由信息 Group Group 组名一类消费者或者生产者的集合名称。 消费者组消费相同Topic内容的消费者可以并行消费Topic中Partition中的消息。 生产者组生产相同Topic内容的生产者 Offset Offset 偏移量消费者拉取消息时需要知道上一次消费到了什么位置这一次从哪里开始。 Partition Partition 分区Topic物理上的分组一个Topic可以分为多个分区每个分区是一个有序的队列。分区中的每条消息都会给分配一个有序的ID也就是偏移量。 分区的目的 减缓日志文件占用磁盘空间消息需要持久化到文件分区可以将消息粒度细分每个分区可以存放在不同的磁盘空间中 不同消费者同时消费分区中的数据一个分区仅由一个消费者组中的消费者消费1个消费者可以同时消费多个分区。 可以实现负载均衡如果同一个Topic的消息都放在同一个Broker上那消费的时候同一个Topic的消费者都去同一个Broker上消费这样会带来压力如果通过分区放在不同Broker上这样就可以到不同的Broker上消费当然同一个ID的消息只能存在一个分区上。你可以想象A这个topic的消息有10个那么每个消息有1个ID如果分布10个消息分布在不同的分区上比如3个那就形成3-3-4消费者去消费的时候消费10条消息时通过3个分区完成这样就提高了吞吐量。 Topic是消息的逻辑队列分区是物理队列。可以通过配置文件来设置topic的默认分区数量也可以在新建立topic的时候指定。建议分区数量和消费者数量一致因为消费者数量多多出来的不会去消费消息的因为一个队列只能被一个消费者消费。如果消费者数量少则消费者就会比较繁忙。 Tag Tag 用于对消息进行过滤理解文件message的子主题同一业务不同目的的message可以用相同的topic但是可以用不同的tag来区分在队列中tag在消息的数据结构中被 转换为一个8byte的hashcode这样节省空间。过滤分两步 在Broker端进行Message Tag对比先遍历Consume Queue如果存储的Message tag与订阅的tag不符合就跳过符合则传输给Consumer在队列中继续比对hashcode Consumer收到消息后对比真实的Message Tag字符串而不是Hashcode这样避免HASH冲突。 key key 消息的KEY字段是为了唯一表示消息的方便查问题不是说必须设置只是说设置为了方便开发和运维定位问题这个KEY可以是订单ID等。 原理
消费者 Push Consumer应用向Consumer对象注册一个Listener接口一但收到消息Consumer对象立刻回调Listener接口方法 Pull Consumer应用主动调用Consumer的拉取消息方法从Broker拉消息
消费模式 广播模式一条消息被多个消费者消费即使它们属于同一个消费者组消息会被组中的每个成员消费一次。 集群模式消息会被平均分配到消费者组中进行消费。
消息模式 顺序消息消息的消费顺序要和发送的顺序一致一类消息为满足顺序性生产者必须单线程顺序发送且发送到同一个队列这样消费者就可以按照生产者发送的顺序去消费。 普通顺序消息正常情况下可以保证完全顺序消费但是一旦发生异常比如broker重启由于队列总数发生变化会产生短暂的消息顺序不一致。如果业务可以容忍这种异常情况则可以使用。 严格顺序消息无论任何情况下都必须保证消息的顺序但是这就牺牲分布式的高可用功能也就是Broker集群中只要有一台不可用那么整个集群就不可用。如果集群部署模式为同步双写模式那么可以通过备机自动切换来避免不过仍然存在短暂间隙的服务不可用。
消息的存储 生产者上产消息根据Topic选择其对应的某一个分区然后发送到这个分区所在的Brocker上消费者根据订阅的Topic选择去Topic的某一个分区拉取消息。
RocketMQ收到消息后会把消息保存在本地文件中每个文件最大上线1G如果写入消息时超过当前文件大小会建立一个新文件文件名为起始字节大小。消息写入是顺序的读取是随机的因为数据持久化当前写入文件只有一个所以可以是顺序写入但是读取的时候因为有多个逻辑队列每个逻辑队列由多个分区所以就出现多个逻辑读队列这样读取的时候就是随机的。如何提高读取性能呢就是尽可能让读命中系统pageCache减少磁盘IO次数。RcoketMQ的持久化是先写入pageCache页面高速缓存然后刷盘这样保证内存与磁盘都有一份相同的数据访问时直接从内存读取。另外一方面RocketMQ在文件读写方面做了优化采用内存映射方式完成也就是把磁盘文件映射到内存地址空间避免了内核空间到用户空间的复制。
支持的部署架构 集群方式消息可靠性Master宕机服务可用性特点其他说明一组主主同步刷盘消息一条都不会丢失整体可用未被消费的消息无法取得影响实时性结构简单、扩容方便、性能最高适合消息可靠性高实时性低的需求一组主从异步有毫秒级丢失同步双写不丢失主备不能切换且备机只能读不能写会造成服务整体不可用 不推荐使用 多组主从 异步复制 故障是会丢失消息整体可用实时性影响是毫秒级别该组服务只能读不能写结构复杂、扩容方便性能很高。适合消息可靠性中等实时性要求中等的场景多组主从同步双写不丢消息整体可用不影响实时性。该组服务只能读不能写。不能自动切换。结构复杂扩容方便性能比异步低一点所以实时性也并不比异步方式高太多。适合消息可靠性高实时性中等性能要求不高的场景。
推荐的架构如下 高要求则使用多组主从同步双写低要求使用主主方案。
应用场景 RocketMQ应用到Cache可以用在大量机器同步信息的场景 业务削峰在大量交易涌入时后端可能无法及时处理所以MQ的大量消息堆积功能就可以发挥作用。 日志收集RocketMQ的设计模型从Kafka衍生而来kafka在日志收集系统中充当缓冲功能随意RocketMQ也适用此场景 对可靠性要求很高的场景尤其是电商里面的订单扣款因为扣款要涉及到很多第三方支付。
优缺点
优点 顺序性它支持顺序性可以做到局部有序在单线程内使用该生产者发送的消息按照发送的顺序到达服务器并存储并按照相同顺序被消费但前提是这些消息发往同一服务器的同一个分区 实时性采取长轮询PULL消费消息你可以自己决定如何在响应性和吞吐量之间做平衡配合合理的参数设置来获得更高的响应时间实时性不低于PUSH方式 提供了丰富的拉取模式 支持10亿级别的消息堆积不会因为堆积导致性能下降 高效的订阅者水平扩展机制
缺点 消息重复问题它不能保证不重复只能保证正常情况下不重复 不支持分布式事务 消息过滤功能扩展比较单一 消息顺序
消息顺序是只可以按照消息发送的顺序进行消费。一个订单产生3条消息订单创建、付款、订单完成。消费时只有按照顺序消费才有意义不可能先消费付款消息再消费订单创建消息这样就乱了。另外多笔订单又可以并行消费。如何保证呢
一个订单产生的消息只能发送给同一个MQ服务器中的同一个分区并且按顺序发送这样才能在理论上保证消费者消费时是按照顺序消费的因为一个分区就是一个逻辑队列。生产者虽然按顺序发送但是第一条消息到达MQ的耗时比第二条多那么第二条则会被先消费这样就又导致消费时不是顺序的。那么如何解决呢可以采取只有第一条被消费者消费成功后再发送第二条。看下图 但是如果第一条被发送到消费者后消费者没有响应消费者发送响应但是因为网络问题丢失或者消费者就没有收到消息那么在这种情况下你是继续发送第二条还是重发第一条呢如果是严格消息顺序那肯定是重发第一条但是如果是消费者消费后的响应丢失了那么重发第一条就会造成重复消费。 从另外一方面看如果不考虑网络异常那么要实现严格消息就必须采取一种一对一关系生产者A的消息对应到MQ服务器1的X队列消费者A消费X队列。这样串行结构就会造成系统吞吐量太低更多异常需要处理比如消费端出现问题那么整个消息队列就会出现阻塞。RocketMQ通过轮询所有队列来确定消息发送到哪一个队列负载均衡比如相同订单号的消息会被先后发送到统一队列中。所以RocketMQ 消息重复
造成消费重复的根本原因是网络不可达只要有网络这种网络的不稳定因素就存在你无法规避。所以解决这个问题的最好办法就是绕过它。这就变成了消费端收到两个一样的消息后如何处理而不是从发送端解决不发送2个一样的消息。对于消费端的要求就是 消费端处理业务消息要保持幂等性也就是同一个东西执行多次会得到相同结果 保证每条消息都有唯一编号切保证消息处理成功与去重表的日志同时出现
第一条好理解第二条就是利用一张日志表来记录已经处理成功的消息ID如果新到的消息ID已经存在表中那么就不再处理这个消息。第一条是在消费端实现的不属于消息系统的功能第二条可以是消息系统实现也可以是业务端实现处于对消息系统的吞吐量和高可用考虑最好还是由消费端去处理。所以这也就是RocketMQ不解决消息重复的原因。
转自http://blog.51cto.com/littledevil/2068474 http://blog.51cto.com/littledevil/2068548 http://blog.51cto.com/littledevil/2068718
