c 做网站优点100种禁用的视频软件短视频

c 做网站优点,100种禁用的视频软件短视频,网站建设公司新,wordpress上传完了一、MQ相关的概念 1.1 什么是MQ? MQ#xff0c;即Message Queue#xff08;消息队列#xff09;#xff0c;是一种基于“生产者-消费者”模式的分布式通信中间件。从字面意思上看就个 FIFO 先入先出的队列#xff0c;只不过队列中存放的内容是 message 而已#xff0c…一、MQ相关的概念1.1 什么是MQ?MQ即Message Queue消息队列是一种基于“生产者-消费者”模式的分布式通信中间件。从字面意思上看就个FIFO 先入先出的队列只不过队列中存放的内容是 message 而已它是一种具有接收数据、存储数据、发送数据等功能的技术服务。简单来说它就像现实生活中的“快递驿站”——生产者发送消息的系统/模块将消息投递到队列中无需等待消费者接收并处理消息的系统/模块立即响应消费者则可以根据自身能力从队列中异步获取消息并处理。这种“存储-转发”的机制实现了消息发送方与接收方的解耦以及消息的异步传递、流量削峰等核心能力。从技术本质上看MQ的核心功能包括消息的可靠存储、高效传输、路由分发以及监控运维等。它屏蔽了底层复杂的网络通信细节让开发人员无需关注“消息如何送达”只需专注于业务逻辑本身极大地简化了分布式系统的架构设计。1.2 为什么要用MQ常见的MQ消息中间件有很多例如ActiveMQ、RabbitMQ、Kafka、RocketMQ等等。那么为什么我们要使用它呢因为它能很好的帮我解决一些复杂特殊的场景1️⃣ 高并发的流量削峰举个例子假设某订单系统每秒最多能处理一万次订单也就是最多承受的10000qps这个处理能力应付正常时段的下单时绰绰有余正常时段我们下单一秒后就能返回结果。但是在高峰期如果有两万次下单操作系统是处理不了的只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲我们可以取消这个限制把一秒内下的订单分散成一段时间来处理这时有些用户可能在下单十几秒后才能收到下单成功的操作但是比不能下单的体验要好。2️⃣ 应用解耦以电商应用为例应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后如果耦合调用库存系统、物流系统、支付系统任何一个子系统出了故障都会造成下单操作异常。当转变成基于消息队列的方式后系统间调用的问题会减少很多比如物流系统因为发生故障需要几分钟来修复。在这几分钟的时间里物流系统要处理的内存被缓存在消息队列中用户的下单操作可以正常完成。当物流系统恢复后继续处理订单信息即可中单用户感受不到物流系统的故障提升系统的可用性。3️⃣ 异步处理有些服务间调用是异步的例如 A 调用 BB 需要花费很长时间执行但是 A 需要知道 B 什么时候可以执行完以前一般有两种方式A 过一段时间去调用 B 的查询 api 查询。或者 A 提供一个 callback api B 执行完之后调用 api 通知 A 服务。这两种方式都不是很优雅使用消息队列可以很方便解决这个问题A 调用 B 服务后只需要监听 B 处理完成的消息当 B 处理完成后会发送一条消息给 MQMQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api也不用提供 callback api。同样B 服务也不用做这些操作。A 服务还能及时的得到异步处理成功的消息。4️⃣ 分布式事务以订单服务为例传统的方式为单体应用支付、修改订单状态、创建物流订单三个步骤集成在一个服务中因此这三个步骤可以放在一个jdbc事务中要么全成功要么全失败。而在微服务的环境下会将三个步骤拆分成三个服务例如支付服务订单服务物流服务。三者各司其职相互之间进行服务间调用但这会带来分布式事务的问题因为三个步骤操作的不是同一个数据库导致无法使用jdbc事务管理以达到一致性。而 MQ 能够很好的帮我们解决分布式事务的问题有一个比较容易理解的方案就是二次提交。基于MQ的特点MQ作为二次提交的中间节点负责存储请求数据在失败的情况可以进行多次尝试或者基于MQ中的队列数据进行回滚操作是一个既能保证性能又能保证业务一致性的方案如下图所示5️⃣数据分发MQ 具有发布订阅机制不仅仅是简单的上游和下游一对一的关系还有支持一对多或者广播的模式并且都可以根据规则选择分发的对象。这样一份上游数据众多下游系统中可以根据规则选择是否接收这些数据能达到很高的拓展性。6️⃣订单超时取消订单超时取消是电商、外卖、票务等业务中典型的场景如 “下单后 15 分钟未支付自动取消订单”核心诉求是精准、高效、可靠地检测订单超时状态并触发取消逻辑。创建订单时发送延时消息用户提交订单后系统立即向 RabbitMQ 发送一条 “订单超时取消” 的延时消息消息体包含订单 ID、超时时间如 15 分钟消息属性设置 TTLTime-To-Live存活时间15 分钟消息发送至 “延时交换机”绑定 “延时队列”该队列无消费者仅用于存储消息至 TTL 过期。延时消息过期进入死信队列若 15 分钟内订单未支付消息 TTL 到期因 “延时队列” 无消费者且绑定了 “死信交换机”消息会被转发至 “死信队列”即实际的 “订单取消队列”。消费死信队列触发取消逻辑系统启动消费者监听 “订单取消队列”获取到超时消息后执行以下操作查订单当前状态若仍为 “待支付”则执行取消逻辑改状态、释放库存等若订单已支付用户在超时前完成支付则直接丢弃该消息不执行任何操作。支付成功时取消延时消息可选但关键若用户在 15 分钟内完成支付系统需主动删除 “延时队列” 中对应的未过期消息避免后续误取消实现方式发送消息时指定唯一的 message_id关联订单 ID支付成功后通过 RabbitMQ 的 basic.get 或批量删除接口移除该消息兜底即使消息未删除成功步骤 3 的 “查订单状态” 也会作为最后一道屏障。1.3 常用的MQ 对比对比维度ActiveMQRabbitMQRocketMQKafka开发语言Java基于JMS规范Erlang面向并发的函数式语言Java参考Kafka架构自主研发Scala/Java基于分布式日志架构核心定位全功能消息队列支持多种消息模式高可靠、低延迟的消息中间件侧重路由灵活高吞吐量、高可靠的分布式消息队列面向业务场景高吞吐量的分布式日志系统侧重数据传输与存储吞吐量较低万级/秒单节点无法满足高并发场景中高十万级/秒集群部署支持高并发高十万级/秒单节点百万级/秒集群极高百万级/秒集群是吞吐量最优的产品消息可靠性支持持久化但在高并发下可靠性易波动存在消息丢失风险高支持消息持久化、确认机制ACK、事务消息极少丢失高支持同步/异步刷盘、主从复制、事务消息适合金融级场景可配置默认异步刷盘下存在少量丢失风险同步刷盘副本机制可提升可靠性但会降低吞吐量延迟性能中平均延迟100ms级低微秒级延迟是实时性最优的产品中低毫秒级延迟满足大部分业务需求中基于“批量发送批量处理”延迟在10ms-100ms级不适合实时性极高的场景功能特性支持JMS规范消息模式丰富点对点、发布订阅、队列等但功能较陈旧支持多种交换器类型direct/fanout/topic/headers路由灵活支持死信队列、延迟队列、消息重试等支持事务消息、顺序消息、延迟消息、消息回溯、死信队列提供丰富的业务级API支持消息分区、副本机制、日志压缩侧重简单的“生产-消费”模式高级功能较少运维成本文档陈旧社区活跃度低问题排查难度大集群扩展复杂Erlang语言门槛高自定义开发难度大但有成熟的管理界面RabbitMQ Management运维工具丰富Java开发源码易读自定义开发方便提供完善的监控工具集群扩展简单运维简单集群扩展灵活但监控、告警等运维生态需要自行搭建如结合PrometheusGrafana适用场景传统企业级应用并发量低、对消息功能要求简单的场景目前逐渐被淘汰实时性要求高的场景如即时通讯、订单状态推送路由灵活的场景如分布式系统的消息分发高并发、高可靠的业务场景如电商下单、金融交易需要事务消息、顺序消息的场景大数据日志采集与传输如ELK日志系统高吞吐量的数据同步场景如实时计算、数据仓库同步1.4 如何选择合适的MQMQ的选择没有“最优解”只有“最适合”。结合上述对比可按照以下原则进行选型若追求实时性与路由灵活优先选择RabbitMQ如即时通讯、实时通知等场景。若侧重高并发与业务可靠性优先选择RocketMQ如电商下单、金融支付等核心业务场景。若需要高吞吐量处理大数据优先选择Kafka如日志采集、实时计算、数据同步等场景。若为传统老旧系统若已使用ActiveMQ且无高并发需求可维持现状新系统不建议选用。二、消息队列协议2.1 什么是协议协议是在TCP/IP协议基础之上构建的种约定成的规范和机制目的是让客户端进行沟通和通讯。并且这种协议下规范必须具有持久性高可用高可靠的性能。为什么不直接采用TCP/IP协议去传递消息因为TCP/IP协议太过于简单并不能承载消息的内容和载体因此在此之上增加一些内容给消息的传递分发高可用提供基础。我们知道消息中间件负责数据的传递存储和分发消费三个部分数据的存储和分发的过程中肯定要遵循某种约定成俗的规范是采用底层的TCP/IPUDP协议还是在这基础上自己构建等而这些约定成俗的规范就称之为协议。所谓协议是指计算机底层操作系统和应用程序通讯时共同遵守的组约定只有遵循共同的约定和规范系统和底层操作系统之间才能相互交流。和一般的网络应用程序的不同它主要负责数据的接受和传递所以性能比较的高。协议对数据格式和计算机之间交换数据都必须严格遵守规范。2.2 网络协议的三要素语法语法是用户数据与控制信息的结构与格式以及数据出现的顺序。语义语义是解控制信息每个部分的意义。它规定了需要发出何种控制信息以及完成的动作与做出什么样的响应。时序时序是对事件发生顺序的详细说明。# 类比http请求协议1.语法htp规定了请求报文和响应报文的格式2.语义客户端主动发起请求称之为请求。这是一种定义同时你发起的是post/get请求3.时序一个请求对应个响应。定先有请求在有响应这个是时序而消息中间件采用的并不是http协议而常见的消息中间件协议有OpenWire、AMQP、MQTT、Kafka、OpenMessage协议面试题为什么消息中间件不直接使用http协议呢因为http请求报文头和响应报文头是比较复杂的包含了cookie、数据的加密解密、状态码、晌应码等附加的功能但是对于个消息而言我们并不需要这么复杂也没有这个必要性它其实就是负责数据传递存储分发就够要追求的是高性能。尽量简洁快速。 大部分情况下http大部分都是短链接在实际的交互过程中一个请求到响应很有可能会中断中断以后就不会就行持久化就会造成请求的丢失。这样就不利于消息中间件的业务场景因为消息中间件可能是一个长期的获取消息的过程出现问题和故障要对数据或消息就行持久化等目的是为了保证消息和数据的高可靠和稳健的运行。2.3 常用消息中间件协议1.AMQP协议Advanced Message Queuing Protocol—高级消息队列协议它由摩根大通集团联合其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议是应用层协议的一个开放标准为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息并不受客户端/中间件不同产品不同的开发语言等条件的限制。特性分布式事务支、消息的持久化支持、高性能和高可靠的消息处理优势AMQP典型的实现者是RabbitMQ、ACTIVEMQ等其中RabbitMQ由Erlang开发2.MQTT协议Message Queueing Telemetry Transport—消息队列遥测传输协议它是一种基于发布/订阅publish/subscribe模式的轻量级通讯协议该协议构建于TCP/IP协议上由IBM在1999年发布。特点轻量、结构简单、传输快、不支持事务、没有持久化设计应用场景适用于计算能力有限、低带宽、网络不稳定的场景支持者RabbitMQ、ACTIVEMQ默认情况下关闭需要打开3.OpenMessage协议是近几年由阿里、雅虎和滴滴出行、 Stremalio等公司共同参与创立的分布式消息中间件、流处理等领域的应用开发标准。特点结构简单、解析速度快、支持事务和持久化设计4.Kafka协议基于TCP/IP的二进制协议。消息内部是通过长度来分割由些基本数据类型组成。特点结构简单、解析速度快、无事务支持、有持久化设计2.3、消息队列持久化持久化简单来说就是将数据存入磁盘而不是存在内存中随服务器宕机断开而消失使数据能够永久保存等服务重启时可以继续消费。常见的持久化方式和对比ActiveMQRabbitMQKafkaRocketMQ文件存储支持支持支持支持数据库支持///2.4、消息的分发策略MQ消息队列有如下几个角色Producer消息生产者。负责产生和发送消息到 BrokerBroker消息处理中心。负责消息存储、确认、重试等一般其中会包含多个 queueConsumer消息消费者。负责从 Broker 中获取消息并进行相应处理生产者产生消息后MQ进行存储消费者如何获得消息呢一般的获取方式无外乎外推push或者pull两种方式典型的git就有推拉机制我们发送的http请求就是一种典型的拉取数据库数据返回的过程。而消息队列MQ是一种推送过程而这些推机制会适用到很多的业务场景也有很多对应的推机制策略场景分析一比如我在APP上下了一个订单我们的系统和服务很多我们如何得知这个消息被那个系统或者那些服务或者系统进行消费此时就需要一个消费策略或称为消费的方法论。场景分析二在发送消息的过程中可能会出现异常或者网络的抖动故障等等因为造成消息的无法消费比如用户在下订单消费MQ接受订单系统出现故障导致用户支付失败那么这个时候就需要消息中间件就必须支持消息重试机制策略。也就是支持出现问题和故障的情况下消息不丢失还可以进行重发消息分发策略的机制和对比ActiveMQRabbitMQKafkaRocketMQ发布订阅支持支持支持支持轮询分发支持支持支持/公平分发/支持支持/重发支持支持/支持消息拉取/支持支持支持2.5、消息队列的高可用和高可靠所谓高可用是指产品在规定的条件和规定的时刻或时间内处于可执行规定功能状态的能力。当业务量增加时请求也过大一台消息中间件服务器的会触及硬件CPU、内存、磁盘的极限一台消息服务器你已经无法满足业务的需求所以消息中间件必须支持集群部署来达到高可用的目的。1️⃣Master-slave主从共享数据的部署方式将多个消息服务器Broker连接共享一块消息存储空间其中Master节点负责消息的写入。客户端会将消息写入到Master节点一旦Master挂掉slave节点继续服务从而形成高可用。2️⃣Master-slave主从同步部署方式该模式写入消息同样在Master节点上但是主结点会同步数据到slave节点形成副本和zookeeper或者redis主从机制很类似。这样可以达到负载均衡的效果如果消费者有多个就可以到不同的节点进行消费但是消息的拷贝和同步会占用很大的贷款和网络资源。在rabbitMQ中会有使用3️⃣ 多主集群同步部署模式和上述方式区别不大但是该方式任意节点都可以进行写入。4️⃣多主集群转发部署模式如果插入的数据是Broker1元数据信息会存储数据的相关描述和记录存放的位置队列它会对描述信息也就是元数据进行同步如果消费者在Broker2中进行消费发现自己没有对应的消息就会在自己的元数据信息中去查询如果查询到了直接返回。如果没有查询到就会将该消息的信息携带在请求中转发到其他节点去询问直到找到所需的信息为止。场景比如买火车票或者黄牛买演唱会门票比如第一个黄牛没有顾客说要买的演唱会门票但是他会去联系其他的黄牛询问如果有就返回5️⃣Master-slave与Breoker-cluster组合的方案实现多主多从的热备机制来完成消息的高可用以及数据的热备机制在生产规模达到定的阶段的时候这种使用的频率比较高。这些集群模式最终目的都是为保证消息服务器不会挂掉出现了故障依然可以抱着消息服务继续使用。要么消息共享要么消息同步要么元数据兴享参考链接https://zhuanlan.zhihu.com/p/611247550https://blog.csdn.net/wqc19920906/article/details/82193316