面向加薪学习

如何保证数据安全非加密 加密-解密 防篡改 非对称加密 领取优惠券，到手价：1元，只能帮到这了，冲鸭！ 添加微信 公众号更多内容

Go语言+支付宝基础准备支付宝开放平台网页/移动应用开发 -> 创建应用 1https://open.alipay.com/ 秘钥工具1https://opendocs.alipay.com/common/02kkv7 沙箱环境1https://openhome.alipay.com/develop/sandbox/app 内网穿透ngrok 官网 1https://ngrok.com/download 领取优惠券，到手价：1元，只能帮到这了，冲鸭！ 添加微信 公众号更多内容

死信队列前面小节中，学习了如何设置消息过期，过期后消息就被丢弃了。 数据是很宝贵的，丢弃后，后续业务无法运行。 RabbitMQ解决方案：死信队列 死信队列:队列被配置DLX属性(Dead-Letter-Exchange) 一个消息如何变成死信？消息被拒绝(reject或者nack)，并且requeue=false,如果设置requeue=true， 就会重新回到队列，那么下次还是消费这个消息，还是消费失败，这样反复，对系统压力也大， 那我们消息被拒绝并且设置了requeue=false，就会进入死信队列。 消息过期TTL 队列达到最大长度(队列的max-length,如果大于这个值，那么就会被发送到死信队列里) 如何设置死信队列？Exchange:dlx.exchangeQueue:dlx.queueRoutingKey:# 在需要设置死信的队列加入参数x-dead-letter-exchange=dlx.exchange 死信队列解决什么问题消息设置过期时间，过期后直接丢弃，系统也不知道消息被丢弃了（很容易出大事儿，这个锅谁来背）。只能将过 ...

消费端限流如果业务促销，流量暴增，可能出现发送端和消费端性能不一致， 瞬间，大量消息同时推给消费端，导致消费端崩溃。 RabbitMQ提供了消费端限流机制。 限制消息推送速度，保证消费端服务稳定。 如果是微服务，不同物理机部署相同的服务，由于硬件的处理能力差异，最终导致处理慢的机器， 就挂了。 qos（服务质量保证） 不适用自动确认，确保在一定数量的消息未被确认前，不消费新消息。 参数配置prefetchCount 一个消费端最多推送多少个未确认的消息（如果设置3，意味着如果有3条未被确认，那么就不推送了）global设置为true 针对整个消费端限流；false针对当前channelprefetchSize 0 单个消息大小限制，一般设置为0 后2个rabbitmq还没有实现，只是amqp协议里面的 RabbitMQ该如何学习计算机学科是一个要求动手能力很强的学科，通过实战，用实际项目，把知识牢牢掌握住。 添加微信 公众号更多内容

消息过期怎么办当大量堆积的消息堆积后，默认是消息进入队列后，一直会存在，直到消费掉。rabbitmq的压力会很大，如果rabbitmq因为消息积压而导致崩溃。 业务会受到影响，甚至瘫痪。 RabbitMQ解决方案:消息过期时间（TTL=Time to Live），防止消息大量堆积。 TTL应该大于服务的平均启动时间。防止由于重启消息过期后被丢弃。如果TTL设置3秒，但是我们的应用启动要8秒，那重启一次，数据就过期了。 TTL大于业务高峰期。比如秒杀这种场景，可以设置30-50分钟。 消息(TTL)单条消息的过期时间。 队列(TTL)进入这个队列的所有消息都有一个固定过期时间，队列中所有消息的过期时间。 队列过期时间(Expire) 在发送的时候,设置消息的过期时间。 12func (ch *Channel) Publish(exchange, key string, mandatory, immediate bool, msg Publishing)Publishing类型中 Expiration字段中，设置TTL RabbitMQ该如何学习计算机学科是一个要求动手能力很强的 ...

消息过期机制默认情况，生产者发送消息到RabbitMQ中，就会被存储下来，直到消费者取走，消费掉。大量消息堆积会让RabbitMQ产生很大的压力。（可能RabbitMQ崩溃，后果很严重） 需要使用RabbitMQ消息过期机制 TTL=Time To Live消息TTL 每个消息有一个过期时间。队列TTL 进入队列的所有消息，有一个统一的过期时间。（非队列过期时间，因为RabbitMQ还有一个队列的过期时间是Expire） 如何合理设置TTL？大于服务的最长或平均重启时间，要比业务高峰期时间长 不推荐直接用TTL,建议和死信队列一起使用。 RabbitMQ该如何学习计算机学科是一个要求动手能力很强的学科，通过实战，用实际项目，把知识牢牢掌握住。 添加微信 公众号更多内容

消费端异常怎么处理消费端确认机制RabbitMQ默认自动确认（ACK）。但是在消费端如果遇到异常， 发送端和RabbitMQ是不知道的。（如果很重要的信息，比如订单，随便丢弃，那肯定出大事儿）所以RabbitMQ提供了消费端确认机制，确认消息可以被正确处理。如果我们不用代码告诉 RabbitMQ已经签收，那么这条消息就会在RabbitMQ里是未签收状态， 如果这条消息一直未被签收，那么消费端重启后，这条消息会被变成ready状态， 还会被其他消费端进行消费。 单条消息手动ACK multiple=false多条消息手动ACK multiple=true 多条消息手动ACK,如果有问题，不好处理。 推荐使用:单条消息手动ACK 如果消费端消费失败，可以重回队列，但是，反复从rabbitMQ和消费端，循环消费消息，但是一直不成功所以不建议使用重回队列这个功能，建议使用报警机制。 RabbitMQ该如何学习计算机学科是一个要求动手能力很强的学科，通过实战，用实际项目，把知识牢牢掌握住。 添加微信 公众号更多内容

消息返回机制生产者，发送消息后，不知道消息是否被真正的路由到了正确的地方？ 如果路由出现异常，那么消息就被丢弃了，如果是重要的业务场景， 如:订单处理，消息丢弃后，必然业务异常，数据错乱。解决方案: RabbitMQ的消息返回机制，也就是确认消息是否被正确的路由了。生产者提供一个回调方法给RabbitMQ,如果生产者发送的消息， 没有正确的路由(也就是没有匹配Exchange上的BindingKey)，就会回调这个方法，告知生产者，让生产者知道消息没有被正确的路由，接下来采取异常业务处理流程。 RabbitMQ中 Mandatory选项配置false - 直接丢弃无法路由的消息true - 发现无法路由，就返回给发送方， RabbitMQ该如何学习计算机学科是一个要求动手能力很强的学科，通过实战，用实际项目，把知识牢牢掌握住。 添加微信 公众号更多内容

10.消息真的被路由了吗生产者，发送消息后，发送端不知道消息是否被路由了？如果没有被路由，或路由异常了，消息会被丢弃。 消息被丢弃后，业务流程停止，业务停止，甚至可能出现业务异常。 RabbitMQ解决方案消息返回机制，确认消息被正确路由 消息被发送以后，Exchange会进行路由，如果没有发现目标Queue,会，通过回调机制，返回通知发送方。 RabbitMQ该如何学习计算机学科是一个要求动手能力很强的学科，通过实战，用实际项目，把知识牢牢掌握住。 添加微信 公众号更多内容

发送端确认原理单条同步确认 配置channel,开启确认模式 发送一条消息后 等待确认 如果返回true,证明RabbitMQ已经接收到了，如果返回false,证明RabbitMQ没有收到之前发送的那条消息。 多条同步确认 配置channel,开启确认模式 发送多条消息后 等待确认 如果返回true,证明RabbitMQ已经接收到了 如果返回false,证明之前发送的消息有失败的（我不知道哪条失败了，哪条成功了，不建议使用这个多条同步确认机制）。 异步确认 配置channel,开启确认模式 在channel上添加监听，发送消息以后，等待回调，通知是否成功。 异步回调确认，可能是单条通知，也可能是多条通知，这个是由RabbitMQ以当时的情况决定的。（我们有些业务，已经处理完成了，但是异步通知回来告诉我们失败了，这个就比较麻烦，如果返回多条消息中，有多条消息是失败的,是哪几条消息失败了，还要去查询数据库，查找deliverytag来判断，所以也不是很推荐。但是异步方式，这种解耦的思想，如果符合你的某些业务场景，可以考虑使用） RabbitMQ该如何学习计算机学科是一个要求动 ...