为什么我网站打不开,wordpress做微商城,湖南好搜网站建设,做的比较好的购物网站RabbitMQ的优缺点优点这边的流量削峰功能主要应用在秒杀活动中#xff0c;在秒杀活动中一般因为流量过大#xff0c;导致应用挂掉#xff0c;为了解决这个问题#xff0c;在应用前端、库存系统前端加入消息队列#xff0c;在订单系统中#xff0c;服务器收到用户的请求后… RabbitMQ的优缺点优点这边的流量削峰功能主要应用在秒杀活动中在秒杀活动中一般因为流量过大导致应用挂掉为了解决这个问题在应用前端、库存系统前端加入消息队列在订单系统中服务器收到用户的请求后首先写入消息队列超过消息队列的长度的用户请求则被直接抛弃或者跳转到错误页面这样可以控制活动人数在接下来秒杀业务处理系统根据消息队列中的请求信息可以按照自己的最大处理能力获取订单能有效的避免短时间内高流量涌入压垮应用的问题。一般用户在下单成功后订单系统户调用库存系统来进行库存的减少传统做法是下单成功后直接调用库存系统这样做有两个问题一.当库存系统出现问题就导致下单失败。二.订单系统和库存系统耦合性高。但是当我们引入RabbiMQ后订单系统只需要把订单信息进行持久化把消息存入消息队列返回给用户下单成功的信息。对库存系统来说就是订阅下单信息从消息队列中获取下单消息来进行库存的修改当库存系统出现问题也会因为消息队列能保证消息的可靠投递不会导致消息的丢失。就订单系统而言下单成功后需要调用短信接口给用户发送下单成功的短信一般的做法是在下单成功后直接调用短信接口给用户发送短信但是如果调用的接口或者短信运营商出现问题就会造成下单过程的阻塞导致整个下单流程的不成功。我们引入RabbitMQ后可以对像发短信这样的不是必须的业务逻辑进行异步处理就能有效的避免下单过程的阻塞。应用异步对系统解耦对高并发流量进行削峰缺点A系统处理成功后直接返回成功接收到消息BC系统也写库成功但是D系统处理写库失败这个时候就造成了数据的不一致问题。系统增加了外部依赖越多容易挂掉举例以前是A系统直接调用BCD系统现在在中加入了MQ加入MQ挂掉了那整套系统就崩溃了。需要处理消息丢失消息的重复消费有些系统会对消息的顺序有要求这样就需要针对各队系统对消息顺序传递性问题的处理增加系统的复杂性系统可用性降低一致性问题如何保证消息队列的高可用(1)RabbitMQ的高可用性RabbitMQ是比较有代表性的因为是基于主从做高可用性的我们就以他为例子讲解第一种MQ的高可用性怎么实现。rabbitmq有三种模式单机模式普通集群模式镜像集群模式1)单机模式就是demo级别的一般就是你本地启动了玩玩儿的没人生产用单机模式2)普通集群模式意思就是在多台机器上启动多个rabbitmq实例每个机器启动一个。但是你创建的queue只会放在一个rabbtimq实例上但是每个实例都同步queue的元数据。完了你消费的时候实际上如果连接到了另外一个实例那么那个实例会从queue所在实例上拉取数据过来。这种方式确实很麻烦也不怎么好没做到所谓的分布式就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据要么固定连接那个queue所在实例消费数据前者有数据拉取的开销后者导致单实例性能瓶颈。而且如果那个放queue的实例宕机了会导致接下来其他实例就无法从那个实例拉取如果你开启了消息持久化让rabbitmq落地存储消息的话消息不一定会丢得等这个实例恢复了然后才可以继续从这个queue拉取数据。所以这个事儿就比较尴尬了这就没有什么所谓的高可用性可言了这方案主要是提高吞吐量的就是说让集群中多个节点来服务某个queue的读写操作。3)镜像集群模式这种模式才是所谓的rabbitmq的高可用模式跟普通集群模式不一样的是你创建的queue无论元数据还是queue里的消息都会存在于多个实例上然后每次你写消息到queue的时候都会自动把消息到多个实例的queue里进行消息同步。这样的话好处在于你任何一个机器宕机了没事儿别的机器都可以用。坏处在于第一这个性能开销也太大了吧消息同步所有机器导致网络带宽压力和消耗很重第二这么玩儿就没有扩展性可言了如果某个queue负载很重你加机器新增的机器也包含了这个queue的所有数据并没有办法线性扩展你的queue那么怎么开启这个镜像集群模式呢我这里简单说一下避免面试人家问你你不知道其实很简单rabbitmq有很好的管理控制台就是在后台新增一个策略这个策略是镜像集群模式的策略指定的时候可以要求数据同步到所有节点的也可以要求就同步到指定数量的节点然后你再次创建queue的时候应用这个策略就会自动将数据同步到其他的节点上去了。
