cc消息流设计

消息流设计

1. 简介

消息系统也可称为队列消费系统,主要是将业务操作以消息的形式转发给服务端(消息系统),服务端接收到消息之后,异步去处理相应的业务,以实现项目解耦

2. 技术实现

Inotify(PHP扩展):
Inotify 是一个 Linux 内核特性,它监控文件系统,并且及时向专门的应用程序发出相关的事件告知,比如删除、读、写和卸载操作等

Swoole(PHP扩展):
主要用到了swoole_event_add函数,此函数将一个socket加入到swoole的reactor事件监听中。也可理解为在进程中将此socket注册到epoll事件中

Rabbitmq(消息队列)

实现描述:
API接口: 请求接口(接收消息)——》写入文件——》返回状态码(成功 or 失败)
异步:
Producer[数据入队]:Swoole+Inotify异步监听文件[api接口写入的文件]——》获取写入的数据——》存数据库——》存队列
Consumer[数据出队列]:队列取数据——》转发给业务接口——》获取返回值——》失败重发 or 成功更新数据库状态

ps:) 使用API接口+文件方式,一方面可以防止因为消息队列的异常所导致接口不可用的问题,另一方面也可以防止因为频繁的队列链接释放所带来的性能损耗,当数据量大的时候也可以通过加服务器来横向扩展。理论上来说只要API接口写入文件成功,即可保证这条消息最终一定会被消费成功

流程图如下：

image.png

3. 为什么用消息流

解耦、并行；如下图：

image.png

4. 应用场景

异步任务、延迟队列、业务解耦、消息订阅、所有队列场景

5. 线上用例

1. 订单积分处理
订单支付成功,会给用户加积分,将此操作产生一条消息扔给消息系统,由消息系统异步去给用户加积分，注意幂等性，不能重复累加。
2. 订单未付款3天关闭
用户3天未付款的订单,会发到消息队列,由队列去异步完成。可以由队列定时任务来执行，将待付款的订单加入队列，并标记时间，3天后如果队列中还有此数据，则执行取消订单任务。

以上都为单一订阅者,也可实现一条消息多个订阅者,延迟队列支持消息延迟一段时间之后出队列(定时任务)

6. 业务接口规范

1. 接受数据
业务接口需以POST方式来获取数据，获取body参数(消息体数据)，例：$_POST['body']
2. 接口返回
业务处理正常需返回{"code":"200"}, 所有非200的值，都为异常数据，会重复发送给接口，直到返回正确(后台可设置重发次数，一般为10次)；如果是接口返回超时或者接口不通，会一直重试直到接口可用并返回正确的结果；
{"code":"1001"},返回此值，会将消息重新扔到队列尾(新增)

7. 环境部署

测试机： test-web-01
项目目录(服务名即为业务的标识，所有的日志和消息记录都在此目录下)：
/home/ec2-user/quemsg/data/服务名
服务名下目录说明：
-----error 异常错误记录
-----inotify 消息记录
-----log 接口请求记录
-----offset 消息文件偏移量记录

数据库：db-dev-00 ——》 queue库——》表名以 (服务名_分表规则) 为前缀，如 order_201601 (按年月分表)

HOST绑定：
10.30.6.180 queadmin.chuchujie.com

管理后台：http://queadmin.chuchujie.com/
帐号： admin 密码： 123456

线上机： message-003, message-004
项目目录：
/home/ec2-user/quemsg/master/current/data/服务名
服务名下目录说明：
-----error 异常错误记录
-----inotify 消息记录
-----log 接口请求记录
-----offset 消息文件偏移量记录

线上管理后台暂未开放权限访问