网站域名如何使用方法,电商网站竞价推广策略,廊坊建站模板系统,设计公司入川备案1. 什么是mq
消息队列是一种“先进先出”的数据结构
2. 应用场景
其应用场景主要包含以下3个方面
应用解耦
系统的耦合性越高#xff0c;容错性就越低。以电商应用为例#xff0c;用户创建订单后#xff0c;如果耦合调用库存系统、物流系统、支付系统#xff0c;任何…1. 什么是mq
消息队列是一种“先进先出”的数据结构
2. 应用场景
其应用场景主要包含以下3个方面
应用解耦
系统的耦合性越高容错性就越低。以电商应用为例用户创建订单后如果耦合调用库存系统、物流系统、支付系统任何一个子系统出了故障或者因为升级等原因暂时不可用都会造成下单操作异常影响用户使用体验。 使用消息队列解耦合系统的耦合性就会提高了。比如物流系统发生故障需要几分钟才能来修复在这段时间内物流系统要处理的数据被缓存到消息队列中用户的下单操作正常完成。当物流系统回复后
流量削峰 应用系统如果遇到系统请求流量的瞬间猛增有可能会将系统压垮。有了消息队列可以将大量请求缓存起来分散到很长一段时间处理这样可以大大提到系统的稳定性和用户体验。 一般情况为了保证系统的稳定性如果系统负载超过阈值就会阻止用户请求这会影响用户体验而如果使用消息队列将请求缓存起来等待系统处理完毕后通知用户下单完毕这样总不能下单体验要好。 处于经济考量目的 业务系统正常时段的QPS如果是1000流量最高峰是10000为了应对流量高峰配置高性能的服务器显然不划算这时可以使用消息队列对峰值流量削峰数据分发 通过消息队列可以让数据在多个系统更加之间进行流通。数据的产生方不需要关心谁来使用数据只需要将数据发送到消息队列数据使用方直接在消息队列中直接获取数据即可。 3. MQ的优点和缺点 优点解耦、削峰、数据分发 缺点包含以下几点系统可用性降低 系统引入的外部依赖越多系统稳定性越差。一旦MQ宕机就会对业务造成影响。 如何保证MQ的高可用系统复杂度提高 MQ的加入大大增加了系统的复杂度以前系统间是同步的远程调用现在是通过MQ进行异步调用。 如何保证消息没有被重复消费怎么处理消息丢失情况那么保证消息传递的顺序性一致性问题 A系统处理完业务通过MQ给B、C、D三个系统发消息数据如果B系统、C系统处理成功D系统处理失败。 如何保证消息数据处理的一致性 结论: (1)中小型软件公司建议选RabbitMQ.一方面erlang语言天生具备高并发的特性而且他的管理界面用起来十分方便。正所谓成也萧何败也萧何他的弊端也在这里虽然RabbitMQ是开源的然而国内有几个能定制化开发erlang的程序员呢所幸RabbitMQ的社区十分活跃可以解决开发过程中遇到的bug这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是一方面中小型软件公司不如互联网公司数据量没那么大选消息中间件应首选功能比较完备的所以kafka排除。但是rocketmq已经交给apache管理所以rocketmq的未来发展趋势看好。 (2)大型软件公司根据具体使用在rocketMq和kafka之间二选一。一方面大型软件公司具备足够的资金搭建分布式环境也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发毕竟国内有能力改JAVA源码的人还是相当多的。至于kafka根据业务场景选择如果有日志采集功能肯定是首选kafka了。具体该选哪个看使用场景
选择rocketmq基于两点考虑
延迟消息简单高效 1.RabbitMQ 死信队列也可以达到延迟效果完善的事务消息功能
Rocketmq的基本概念
Producer消息的发送者举例发信者Consumer消息接收者举例收信者Broker暂存和传输消息举例邮局–真正存数据的NameServer管理Broker举例各个邮局的管理机构注册中心Topic区分消息的种类一个发送者可以发送消息给一个或者多个Topic一个消息的接收者可以订阅一个或者多个Topic消息Message Queue相当于是Topic的分区用于并行发送和接收消息
rocketmq消息类型
按照发送的特点分 1. 同步发送 同步发送线程阻塞投递completes阻塞结束如果发送失败会在默认的超时时间3秒内进行重试最多重试2次投递completes不代表投递成功要check SendResult.sendStatus来判断是否投递成功SendResult里面有发送状态的枚举SendStatus同步的消息投递有一个状态返回值的 public enum SendStatus {SEND_OK, // 发送成功FLUSH_DISK_TIMEOUT,// 刷盘超时。当Broker设置的刷盘策略为同步刷盘时才可能出现这种异常状态。异步刷盘不会出现FLUSH_SLAVE_TIMEOUT,// Slave同步超时。当Broker集群设置的Master-Slave的复制方式为同步复制时才可能出现这种异常状态。异步复制不会出现SLAVE_NOT_AVAILABLE;// 没有可用的Slave。当Broker集群设置为Master-Slave的复制方式为同步复制时才可能出现这种异常状态。异步复制不会出现
}retry的实现原理:只有ack的SendStatusSEND_OK才会停止retry 注意事项发送同步消息且Ack为SEND_OK只代表该消息成功的写入了MQ当中并不代表该消息成功的被Consumer(消息的接收方)消费了 2. 异步发送 异步调用的话当前线程一定要等待异步线程回调结束再关闭producer(消息的发送者)因为是异步的不会阻塞,提前关闭producer会导致未回调链接就断开了异步消息不retry(重试)投递失败回调onException()方法只有同步消息才会retry,源码参考DefaultMQProducerImpl.class异步发送一般用于链路耗时较长对 RT 响应时间较为敏感的业务场景例如用户视频上传后通知启动转码服务转码完成后通知推送转码结果等。 3. 单向发送 消息不可靠性能高只负责往服务器发送一条消息不会重试也不关心是否发送成功此方式发送消息的过程耗时非常短一般在微秒级别 下表概括了三者的特点和主要区别。 按照使用功能特点分 1. 普通消息订阅–不能保证顺序 普通消息是我们在业务开发中用到的最多的消息类型生产者需要关注消息发送成功即可消费者消费到消息即可不需要保证消息的顺序所以消息可以大规模并发地发送和消费吞吐量很高适合大部分场景。 2. 顺序消息–并发没有那么高 顺序消息分为分区顺序消息和全局顺序消息全局顺序消息比较容易理解也就是哪条消息先进入哪条消息就会先被消费符合我们的FIFO很多时候全局消息的实现代价很大所以就出现了分区顺序消息。分区顺序消息的概念可以如下图所示 3. 延时消息 - 订单超时库存归还–性能高 延迟的机制是在 服务端实现的也就是Broker收到了消息但是经过一段时间以后才发送服务器按照1-N定义了如下级别 “1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”若要发送定时消息在应用层初始化Message消息对象之后调用Message.setDelayTimeLevel(int level)方法来设置延迟级别按照序列取相应的延迟级别例如level2则延迟为5s
msg.setDelayTimeLevel(2);
SendResult sendResult producer.send(msg);实现原理 发送消息的时候如果消息设置了DelayTimeLevel,那么该消息会被丢到不同ScheduleMessageService.SCHEDULE_TOPIC这个Topic里面根据DelayTimeLevel选择对应的queue再把真实的topic和queue信息封装起来set到msg里面然后每个SCHEDULE_TOPIC_XXXX的每个DelayTimeLevelQueue有定时任务去刷新是否有待投递的消息每 10s 定时持久化发送进度 4. 事务消息 云消息队列 RocketMQ 版 消息队列RocketMQ版提供的分布式事务消息适用于所有对数据最终一致性有强需求的场景。本文介绍消息队列RocketMQ版事务消息的概念、优势、典型场景、交互流程以及使用过程中的注意事项。 概念介绍
事务消息消息队列RocketMQ版提供类似X或OpenXA的分布式事务功能通过消息队列RocketMQ版事务消息能达到分布式事务的最终一致。半事务消息暂不能投递的消息发送方已经成功地将消息发送到了消息队列RocketMQ版服务端但是服务端未收到生产者对该消息的二次确认此时该消息被标记成“暂不能投递”状态处于该种状态下的消息即半事务消息。消息回查由于网络闪断、生产者应用重启等原因导致某条事务消息的二次确认丢失消息队列RocketMQ版服务端通过扫描发现某条消息长期处于“半事务消息”时需要主动向消息生产者询问该消息的最终状态Commit或是Rollback该询问过程即消息回查。
分布式事务消息的优势 消息队列RocketMQ版分布式事务消息不仅可以实现应用之间的解耦又能保证数据的最终一致性。同时传统的大事务可以被拆分为小事务不仅能提升效率还不会因为某一个关联应用的不可用导致整体回滚从而最大限度保证核心系统的可用性。在极端情况下如果关联的某一个应用始终无法处理成功也只需对当前应用进行补偿或数据订正处理而无需对整体业务进行回滚。
