rabbitq消息队列分析

消息队列为什么要使用消息队列解耦扩展性异步通信……消息队列要解决的其它问题送达保证流量控制/缓冲保证时序主要的使用举例场景（概念图）单模块对单模块Waybill推送订单给区域模块用来排线使用。主要的使用举例场景（概念图）单模块对多模块（多消息类型）三体需要发送线路任务和每日运力，同时用于时效监控和财务。多模块对单模块（多消息类型）问题和风险下游模块之间相互影响（消费能力）。存在消息优先级问题。（优先级的定义？）需要同时接收多数据类型。rabbitmq的概念和特点用户权限控制的粒度为VirtualHost（可以理解为命名空间）。所有的数据都只能发送给rabbit的exchange。Exchange分为三种模式：fanout，direct，topic。在发送和接收数据的时候要指定queuename。可以持久化数据。只有pull的方式。有ack的机制。rabbitmq的解决方案下游模块之间相互影响每个模块使用独立的queue（name），模块之间无干扰。没有办法接收多种数据类型。rabbitmq的解决方案同时接收多种数据类型单个队列可以接收多种不同类型的数据。存在严重的优先级问题。封装策略其他模块在架构中对rabbitmq无感：将pull的方式修改成push的方式。pusher根据下游使用方式的要求，可以同时接一个或者多个queuequeuename由Pusher来自行决定，下游不关注。屏蔽了rabbitmq奇怪的noack机制解决多下游的竞争机制不完善的。（消息会乱序）增加了转运功能，将单条1*N的数据拆分成N*1的数据，然后下发。队列的接收方需要自行决定数据是继续处理还是跳过。队列的接收方需要保证自己的逻辑幂等+可重入。解决方案（PHP）未封装的功能没有主动数据回放的机制。不区分完全时序和相对时序。封装之后的使用（PHP）21:8095/display/beeper/rabbitmqExchange：每个模块独立一个exchange，exchange按照模块名称命名，exchange不允许在代码中自动创建。在Pusher新增Queue：命名方式exchange.功能.下游名称，允许代码自动创建。漫话架构绝对原创，一笑了之为什么大家都想做架构师挣钱多好跳槽让别人觉得牛X可以对小弟呼来喝去更多……全宇宙中最常出现的架构web代码Mysql架构（Architecture）框架（Framework）什么是软件架构软件架构不是软件，而是关于软件设计的一种决策。架构是问题的抽象解决方案，它主要关注大局。软件架构定义系统的技术选型。软件架构决策如何将软件系统分解成不同的部分，以及各个部分之间的交互关系。软件架构约束整个系统的数据流。经过完整的开发过程之后，这些架构决策将要体现在最终开发出的软件系统中。架构师存在是为了什么做设计决策为设计决策失败承担责任为开发不到位引起的失败承担责任为测试不到位引起的失败承担责任为性能不满足引起的失败承担责任为稳定性不满足引起的失败承担责任为所有最终交付之前出现的任何技术错误导致的失败承担责任成功架构师需要具备的XX经验权利能力前瞻性变通运气TMS的架构设计原则优先业务功能：分析真实的业务需求。业务后续的可能演进方向。将业务需求转变成通用的技术需求其他的考虑：尽量少依赖第三方和开源。和外部功能解耦。在需求的基础上做少量的技术规划。新建派车单和对外API接口（PM）政策需要新建立派车单和配送点。要求可以通过API接口和外部系统交互。要求可以根据派车单维度查询司机的在途位置。对策需要承载派车单和订单数据实体和逻辑。需要规划新的模块API接口对外，为了安全性，需要添加鉴权机制，为了扩展和部署。在代码和逻辑上都独立开派车单维度查询位置。派车单的执行主体是司机，所以将数据维度转换成按照司机+时间保存。语言/存储和公司统一node.js+mongodb。功能之间对数据库的访问独立。派车单模板、排线和地址查询功能（PM）政策创建派车单太麻烦，需要只填写一次，创建一堆。要求引入订单的概念。要求支持排线功能。排线需要依赖坐标，需要地址和坐标转换功能。对策公司语言限制放开，php+mysql。派车单模板生成派车单，放在一模块（node.js+mongodb）。订单，直接新模块。新增区域，区域不是运单的属性，也和司机无关，继续新加模块，单独管理区域。有区域才能落点排线，排线和区域放一起。落点和订单需要交互，但是不要求实时性，添加队列，业务解耦。地址转转换涉及到很多人工的维护，直接独立，方便后续独立添加人工地址审核功能和地址检索功能。Node.js+mongodb迁移php+mysql（架构）政策原有的Node.js模块线上各种超时日志，搞不定，换之…跨数据库查询，获取数据的时候想死的心都有了。对策平移Node.js+mongodb的所有功能。派车单和订单一直绑定出现，放在一个模块。司机位置，在关系数据库中需要考虑数据量问题，按照天分表。保证开发速度，协议依旧选择HTTP。时效+异常功能（开发+PM）政策时效产品派车单+订单维度的异常监控和预警。对策时效，怎么看都和现在的东西不相关，也不在规划范围内，随便找个地方丢吧…时效需要依赖运力，引入队列。异常监控，这么重要的功能，又和