标签：队列 额外 定时任务 根据 应用 数学 属性 一个人 man
1）信息的发送者和接收者如何维持连接，如果一方的连接中断，这期间的数据如何防止丢失？
2）如何降低发送者和接收者的耦合度？
3）如何让Priority高的接收者先接到数据？
4）如何做到load balance？有效均衡接收者的负载？
5）如何有效的将数据发送到相关的接收者？也就是说接收者subscribe 不同的数据，如何做有效的filter。
6）如何做到可扩展，甚至将这个通信模块发到cluster上？
7）如何保证接收者接收到了完整，正确的数据？
那么消息队列可以起到一个缓存的作用,先把工作记录下,然后尽自己最大努力进行读取.（具体功能请自行百度）
关键词
Queue
指具体某一个队列
RouteKey
路由和交换机在进行绑定时,定义一个路由名
Exchange
交换机,用于把生产者的消息根据不同工作方式分发到不同队列中.
Publish
消息发送者
Consume
消息接收者
Message
消息本身
6种主要工作模式
HelloWorld
这种方式是最简单的一个应用,P为生产方,C为接收方.如果班级里边只有我一个人,和一个老师可以看成是这种模式.那么队列呢..就是我手里的iphone吧.照着手机拍的内容先埋头写..
Work queues 工作队列
老师让两个学生帮忙跟着一起批作业.
Publish/Subscribe 发布订阅模式
可以看成如果说班级里边的人一起在抄黑板.可以看成这种模式.每个人得到的结果一样.
老师只关注去写,不需要关注谁没有抄.这个是由学生去主动关注(绑定)的
此方式实际上也可以看做是设计模式中观察者模式的分布式实现.
同时因为这种方式导致了生产者与具体队列接耦.所以需要额外增加一个交换机
Routing 路由方式
老师批了不同课程的作业,并一起交给了班长,说根据课程发给课代表.再让课代表发给具体学生.
那么老师是生产者,班长根据老师持续给的不同的作业本发给不同的课代表,班长即代表了Exchange,而课代表要发的作业则是具体的Queue.当然也可以某一个人是多个课程的课代表.
Topics 主题方式
期中考试,老师公布了所有人的考试试卷情况,有优良差三等,以及不同的课程.所以试卷的标题写的为"语文.差"."数学.优"..这样.同时安排一个人,对成绩为查的进行辅导,同时所有专业的成绩.也要通知课代表.即.一个消息可以通过.间隔,含有多重属性.不同的队列可以对特别属性做关注.比如进行辅导的人关注的关键字为**"*.差"** 而对于课代表来说.可能关心的是**"语文.*"**
RPC 远程调用
校长找个学生说去找下语文老师,让来校长室.我等着他.也就相当于发起了一个任务队列.并且发起者会等待.
学生去办公室找了结果发现没人(消费端处理失败),等了一会人来了.并把老师带到了校长室.在这个期间校长一直在等,即便中途学生没找成功.
在常规的RPC调用中,都是使用的单次链接,如果目标失败,则RPC失败,而使用MQ,目标失败, 可以从新领取RPC任务从新处理.在此期间RCP调用端一直阻塞
关于使用MQ的4个关键点
由于消息队列实现了顺序性,和可到达性.所以我们基于此设计就比较稳定
之前的远程调用实现方式是采用数据库,并进行超时计数,问题在于有一些API必须先执行,比如推荐人的注册.但是因为超时机制的设计,可能会出现后执行问题.同时达到超时计数之后.就不在发送,可到达性就无从谈起.至于数据库对接么.即便是在一个机房甚至一台服务器上.对接时如果存在锁表.或者系统繁忙.也会导致对接失败.属于同步执行.而非异步执行.如果服务端距离比较远的话..那么网络的不稳定性.同时也不存在重发机制也会导致SQL执行出现问题.
效率问题,之前的对接方式,是实现通过数据库记录进行处理.并通过1秒执行一次定时任务进行查询.结果带来问题是某些项目的服务器一半以上的资源都在处理API表的查询工作.同时API的对接响应时间,也降低到0-1秒之间.
MQ带来的好处在于他是一种基于TCP/IP的通讯方式,发送即收到.
拉上WorkerMan的原因.作为消息队列的消费端.需要时刻收取最新发来的消息并做处理.所以执行方式类似于一个服务端程序而不是一个定时的web脚本.而WorkerMan的作用就是把PHP变成应用程序.
WorkerMan+PHP+rebbitMQ作为处理端,因我们的程序设计是基于Tp.所以希望能够让WorkerMan直接调用Model进行具体处理.如果中间在加一层CLI调用.就有点多余.
标签：队列 额外 定时任务 根据 应用 数学 属性 一个人 man
原文地址：https://www.cnblogs.com/Jeely/p/10784162.html
