做一个招聘信息的网站_用什么做网站的软件,西安到北京火车票查询,如何制作自己的网站书签,手机网站头部代码目录 什么是消息中间件为什么使用消息中间件流量削峰应用解耦异步处理 主流消息中间件及选型选取原则RabbitMQRocketMQKafka如何选择 消息中间件应用场景电商秒杀案例拉勾B端C端数据同步案例支付宝购买电影票 什么是消息中间件
维基百科对消息中间件的解释#xff1a;面向消息… 目录 什么是消息中间件为什么使用消息中间件流量削峰应用解耦异步处理 主流消息中间件及选型选取原则RabbitMQRocketMQKafka如何选择 消息中间件应用场景电商秒杀案例拉勾B端C端数据同步案例支付宝购买电影票 什么是消息中间件
维基百科对消息中间件的解释面向消息的系统消息中间件是在分布式系统中完成消息的发送和接收的基础软件。
消息中间件也可以称消息队列是指用高效可靠的消息传递机制进行与平台无关的数据交流并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型可以在分布式环境下扩展进程的通信。
消息中间件就是在通信的上下游之间截断break itBroker然后利用中间件解耦、异步的特性构建弹性、可靠、稳定的系统。
为什么使用消息中间件
异步处理、流量削峰、限流、缓冲、排队、最终一致性、消息驱动等需求的场景都可以使用消息中间件。
流量削峰
如果订单系统每秒最多能处理一万次的订单这个处理能力应付正常时段的下单是绰绰有余的正常时段我们下单一秒后就能返回结果。但是在高峰期如果每秒有两万次的下单操作系统是处理不了的那么只能限制订单超过一万后的用户不能下单这样很不人性化的我可能等待怎么能直接告诉我下不了单呢。此时如果使用 MQ 之后那么就可以取消这个限制了将一秒内下的订单分散成一段时间来处理这时可能有些用户在下单十几秒之后才能收到下单成功的操作但是也有比不能下单的体验要好。 应用解耦
以电商系统为例应用中有订单系统、库存系统、物流系统、支付系统。用户在创建订单后如果耦合调用库存系统、物流系统、支付系统任何一个子系统出现故障都会造成下单操作异常。当使用了 MQ 之后系统间调用的问题就会减少很多如物流系统因为发生故障需要几分钟来修复在这几分钟之内物流系统要处理的消息会被缓存在 MQ 之后不会影响到用户的正常下单操作的。当物流系统恢复之后继续处理订单信息即可。在整个操作中间下单的用户是感受不到物流系统出现故障提高的系统的可用性。 异步处理
有些服务间调用是异步的例如A 调用 B B 需要花费很长时间去执行但是 A 需要知道 B 什么时候可以执行完毕以前有两种处理方式1A 每过一段时间就去轮询调用 B 提供的查询 API 。2 A 提供一个 callback 的 API B 执行完毕会后调用这个 API 告诉 A 执行完毕。这两种方式都不是很优雅使用 MQ 可以方便的解决这个问题。A 调用 B 服务后只需要监督 B 处理完成的消息当 B 处理完成后会发送一条消息给 MQ MQ 会将此消息转发给 A 服务这样 A 服务既不用循环调用 B 的查询 API 也不用提供 callback 的 API 。同样B 也不需要做这些操作A 服务还能及时得到异步处理成功的消息。 主流消息中间件及选型
当前业界比较流行的开源消息中间件包括ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等其中应用最为广泛的要数RabbitMQ、RocketMQ、Kafka这三款。
Redis在某种程度上也可以是实现类似“Queue”和“Pub/Sub”的机制严格意义上不算消息中间件。
选取原则
首先产品应该是开源的。开源意味着如果队列使用中遇到bug可以很快修改而不用等待开发者的更新。
其次产品必须是近几年比较流行的要有一个活跃的社区。这样遇到问题很快就可以找到解决方法。同时流行也意味着bug较少。流行的产品一般跟周边系统兼容性比较好。
最后作为消息队列要具备以下几个特性
1、消息传输的可靠性保证消息不会丢失。
2、支持集群包括横向扩展单点故障都可以解决。
3、性能要好要能够满足业务的性能需求。
RabbitMQ
RabbitMQ开始是用在电信业务的可靠通信的也是少有的几款支持AMQP协议的产品之一。
优点
轻量级快速部署使用方便支持灵活的路由配置。RabbitMQ中在生产者和队列之间有一个交换器模块。根据配置的路由规则生产者发送的消息可以发送到不同的队列中。路由规则很灵活还可以自己实现。RabbitMQ的客户端支持大多数的编程语言。
缺点
如果有大量消息堆积在队列中性能会急剧下降RabbitMQ的性能在Kafka和RocketMQ中是最差的每秒处理几万到几十万的消息。如果应用要求高的性能不要选择RabbitMQ。RabbitMQ是Erlang开发的功能扩展和二次开发代价很高。
RocketMQ
RocketMQ是一个开源的消息队列使用java实现。借鉴了Kafka的设计并做了很多改进。RocketMQ主要用于有序事务流计算消息推送日志流处理binlog分发等场景。经过了历次的双11考验性能稳定性可可靠性没的说。
优点
RocketMQ几乎具备了消息队列应该具备的所有特性和功能。java开发阅读源代码、扩展、二次开发很方便。对电商领域的响应延迟做了很多优化。在大多数情况下响应在毫秒级。如果应用很关注响应时间可以使用RocketMQ。性能比RabbitMQ高一个数量级每秒处理几十万的消息。
缺点
跟周边系统的整合和兼容不是很好。
Kafka
Kafka的可靠性稳定性和功能特性基本满足大多数的应用场景。
跟周边系统的兼容性是数一数二的尤其是大数据和流计算领域几乎所有相关的开源软件都支持Kafka。
Kafka高效可伸缩消息持久化。支持分区、副本和容错。
Kafka是Scala和Java开发的对批处理和异步处理做了大量的设计因此Kafka可以得到非常高的性能。它的异步消息的发送和接收是三个中最好的但是跟RocketMQ拉不开数量级每秒处理几十万的消息。
如果是异步消息并且开启了压缩Kafka最终可以达到每秒处理2000w消息的级别。但是由于是异步的和批处理的延迟也会高不适合电商场景。
如何选择
特点如下 基于以上特点选型可参考如下 KakaKafka 的主要特点是基于 pull 的模式来处理消息追求吞吐量一开始的目的就是用于日志收集和传输适合产生了大量数据的互联网服务的数据收集业务。大型公司建议选用如果有日志收集功能首选 Kafka 。 RocketMQ天生为金融互联网领域而生对于可靠性要求很高的场景尤其是电商里面的订单扣款以及业务削峰在大量交易涌入的时候后端可能无法及时处理的情况。RocketMQ 在稳定性上可能更值得信赖因为这些场景在阿里的双 11 经历了多次考验。 RabbitMQ结合 Erlang 语言本身的并发优势性能好时效性 us 级社区活跃度高管理界面用起来十分方便中小型公司优先选择功能完备的 RabbitMQ 。
消息中间件应用场景
消息中间件的使用场景非常广泛比如12306购票的排队锁座电商秒杀大数据实时计算等。
电商秒杀案例
比如6.18活动从0:00开始仅限前 200 名秒杀即将开始时用户会疯狂刷新 APP或者浏览器来保证自己能够尽早的看到商品。
当秒杀开始前用户在不断的刷新页面系统应该如何应对高并发的读请求呢在秒杀开始时大量并发用户瞬间向系统请求生成订单扣减库存系统应该如何应对高并发的写请求呢
1. 系统应该如何应对高并发的读请求
使用缓存策略将请求挡在上层中的缓存中能静态化的数据尽量做到静态化加入限流比如对短时间之内来自某一个用户某一个IP、某个设备的重复请求做丢弃处理
2. 系统应该如何应对高并发的写请求
生成订单扣减库存用户这些操作不经过缓存直达数据库。如果在 1s内有 1 万个数据连接同时到达系统的数据库会濒临崩溃。如何解决这个问题呢我们可以使用 消息队列。
消息队列的作用
削去秒杀场景下的峰值写流量——流量削峰通过异步处理简化秒杀请求中的业务流程——异步处理解耦实现秒杀系统模块之间松耦合——解耦
上面三点分别如何做
流量削峰
将秒杀请求暂存于消息队列业务服务器响应用户“秒杀结果正在处理中。。。”释放系统资源去处理其它用户的请求。
削峰填谷削平短暂的流量高峰消息堆积会造成请求延迟处理但秒杀用户对于短暂延迟有一定容忍度。
秒杀商品有 1000 件处理一次购买请求的时间是 500ms那么总共就需要 500s 的时间。这时你部署 10 个队列处理程序那么秒杀请求的处理时间就是 50s也就是说用户需要等待 50s 才可以看到秒杀的结果这是可以接受的。这时会并发 10 个请求到达数据库并不会对数据库造成很大的压力。
异步处理
先处理主要的业务异步处理次要的业务。如主要流程是生成订单、扣减库存次要流程比如购买成功之后会给用户发优惠券增加用户的积分。此时秒杀只要处理生成订单扣减库存的耗时发放优惠券、增加用户积分异步去处理了。
解耦
实现秒杀系统模块之间松耦合。
将秒杀数据同步给数据团队有两种思路
使用 HTTP 或者 RPC 同步调用即提供一个接口实时将数据推送给数据服务。系统的耦合度高如果其中一个服务有问题可能会导致另一个服务不可用。使用消息队列将数据全部发送给消息队列然后数据服务订阅这个消息队列接收数据进行处理。
拉勾B端C端数据同步案例
拉勾网站分B端和C端B端面向企业用户C端面向求职者。
这两个模块业务处理逻辑不同数据库表结构不同实际上是处于解耦的状态。但是各自又需要对方的数据需要共享如
当C端求职者在更新简历之后B端企业用户如何尽早看到该简历更新当B端企业用户发布新的职位需求后C端用户如何尽早看到该职位信息
无论是B端还是C端都有各自的搜索引擎和缓存B端需要获取C端的更新以更新搜索引擎和缓存C端需要获取B端的更新以更新C端的搜索引擎与缓存。
如何解决B端C端数据共享的问题
同步方式B端和C端通过RPC或WebService的方式发布服务让对方来调用以获取对方的信息。求职者每更新一次简历就调用一次B端的服务进行数据的同步B端企业用户每更新职位需求就调用C端的服务进行数据的同步。异步方式使用消息队列B端将更新的数据发布到消息队列C端将更新的数据发布到消息队列B端订阅C端的消息队列C端订阅B端的消息队列。
使用同步方式B端和C端耦合比较紧密如果其中一个服务有问题可能会导致另一个服务不可用。比如C端的RPC挂掉企业用户有可能无法发布新的职位信息因为发布了对方也看不到B端的RPC挂掉求职者可能无法更新简历因为即使简历更新了对方也看不到。
你可能会想可以让B端或C端在对方RPC挂掉的时候先将该通知消息缓存起来等对方服务恢复之后再进行同步。
这正是引入异步方式使用消息队列的目的。
使用消息队列的异步方式对B端C端进行解耦只要消息队列可用双方都可以将需要同步的信息发送到消息队列对方在收到消息队列推送来的消息的时候各自更新自己的搜索引擎更新自己的缓存数据。
支付宝购买电影票 如上图用户在支付宝购买了一张电影票后很快就收到消息推送和短信电影院地址、几号厅、座位号、场次时间等同时用户会积累一定的会员积分。
这里交易系统并不需要一直等待消息送达等动作都完成后才返回成功允许一定延迟和瞬时不一致最终一致性而且后面两个动作通常可以并发执行。
如果后期监控大盘想要获取实时交易数据只需要新增个消费者程序并订阅该消息即可交易系统对此并不感知松耦合。
