RabbitMQ 总结及 window环境安装使用RabbitMQ

RabbitMQ 总结及 window环境安装使用RabbitMQ

window环境安装使用RabbitMQ 1.-erlang 并安装：esl-erlang_22.1_windows_amd64.exe 2.-rabbitmq 解压er_rabbitmq_server-3.8.3并复制到c:，配置环境变量C:\Program Files\er_rabbitmq_server-3.8.3\sbinrabbitmq-server-windows-3.8.3.zip 3.安装和启动rabbitmq服务C:\Program Files\er_rabbitmq_server-3.8.3\sbin cmd安装服务：rabbitmq-service install服务启用：rabbitmq-service enable启动服务：rabbitmq-service start 4 root权限 设置C:\Program Files\er_rabbitmq_server-3.8.3\sbin cmdrabbitmqctl add_user admin admin//添加用户，后面两个参数分别是用户名和密码rabbitmqctl set_permissions -p / admin ".*" ".*" ".*" //添加权限rabbitmqctl set_user_tags admin administrator //修改用户角色,将用户设为管理员   1、什么是RabbitMQ？为什么使用RabbitMQ？ 答：RabbitMQ是一款开源的，Erlang编写的，基于AMQP协议的，消息中间件； 可以用它来：解耦、异步、削峰。   2、RabbitMQ有什么优缺点？ 答：优点：解耦、异步、削峰； 缺点：降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低； 增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。   3、如何保证RabbitMQ的高可用？ 答：没有哪个项目会只用一搭建一台RabbitMQ服务器提供服务，风险太大； RabbitMQ 的4种集群架构： 1. 主从模式：也叫主备模式，主节点供读写，被用节点不供读写，主挂了，切换到备用节点；设计架构模式：在一个集群里，有三台服务器，其中一台使用磁盘模式，另两台使用内存模式。两台内存模式的节点速度更快，因此通过客户端连接访问它们。但是在客户端不可能分别连接两台内存节点，肯定是通过前端反向代理去轮询分发请求。如果担心前端反向代理服务器故障，可以通过keepalived软件做一个高可用架构。而磁盘模式的节点，由于磁盘IO相对较慢，因此仅作数据备份使用   2. 远程模式  3. 镜像模式     4、如何保证RabbitMQ不被重复消费？ 答：先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除； 但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。 针对以上问题，一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性； 比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；   5、如何保证RabbitMQ消息的可靠传输？ 答：消息不可靠的情况可能是消息丢失，劫持等原因； 丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息；   生产者丢失消息：从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息； transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降； confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后； rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了； 如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。   消息队列丢数据：消息持久化。 处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。 这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。 这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。 那么如何持久化呢？ 这里顺便说一下吧，其实也很容易，就下面两步 将queue的持久化标识durable设置为true,则代表是一个持久的队列 发送消息的时候将deliveryMode=2 这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据   消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！ 消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息； 如果这时处理消息失败，就会丢失该消息； 解决方案：处理消息成功后，手动回复确认消息。   6、如何保证RabbitMQ消息的顺序性？ 答：单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息；    7.大量消息在mq里积压了几个小时了还没解决 几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下： 先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据来消费数据等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息这里我们假设再来第二个坑假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。这个情况下，就不是说要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次然后我们再来假设第三个坑如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。