PHP는 Redis를 기반으로 경량 지연 대기열(멀티스레딩)을 구현합니다.

지연 대기열은 이름에서 알 수 있듯이 지연 기능이 있는 메시지 대기열입니다. 그렇다면 어떤 상황에서 이러한 대기열이 필요합니까?

1. 배경

먼저 비즈니스 시나리오를 살펴보겠습니다.

1. 멤버십 만료 3일 전에 리콜 알림을 보냅니다.

2. 주문 결제가 성공한 후 다운스트림 링크가 작동하는지 확인합니다. 회원가입 후 모든 회원상태가 정상적으로 설정되나요? 3. 환불상태의 주문이 성공적으로 환불되었는지 정기적으로 확인하는 방법은 무엇인가요?

4. 알림 구현 실패, 상대방이 응답할 때까지 1, 3, 5, 7분 안에 알림을 반복하시겠습니까?

보통 위의 문제를 해결하는 가장 간단하고 직접적인 방법은 측정기를 정기적으로 스캔하는 것입니다.

테이블 스캐닝의 문제점은 다음과 같습니다.

1. 테이블 스캐닝이 데이터베이스에 오랫동안 연결되어 있으면 연결이 비정상적으로 중단되기 쉽기 때문에 더 많은 예외 처리가 필요하고 높은 프로그램 견고성이 필요합니다. 2. 데이터의 양이 많을 경우 지연 시간이 크고 정해진 시간 내에 처리를 완료할 수 없어 업무에 영향을 미칠 수 있습니다. 해결되었습니다.

3. 각 기업은 자체 측정기 스캔 논리를 유지해야 합니다. 비즈니스가 증가하면 미터 스캐닝 부분의 로직이 반복적으로 개발될 것으로 예상되지만 이는 매우 유사합니다.

지연 대기열은 위의 요구 사항을 매우 잘 해결할 수 있습니다. 2. 연구

몇 가지 오픈 소스를 조사했습니다. 다음과 같은 솔루션을 출시할 계획입니다.

1. Youzan 기술: 원칙만 있고 오픈 소스 코드 없음

2. github 개인: https://github.com/ouqiang/delay-queue

(1) 기반 Redis 구현에서는 redis만 구성할 수 있습니다. redis가 중단되면 전체 서비스를 사용할 수 없으며 가용성이 떨어집니다.

(2) 소비자 측에서는 풀 모드를 구현하며 각 프로젝트는 액세스 비용이 높습니다. 액세스 코드 구현

(3) Star를 사용하는 사람은 많지 않습니다. 또한, Go 언어를 이해하지 못하면 문제가 발생하면 유지 관리가 어렵습니다. .스케줄러는 가볍지 않습니다

4. RabbitMQ 지연 작업: 자체적으로 기능을 구현해야 하는데, 회사에서는 이 대기열을 배포하지 않았습니다. 딜레이 큐를 만들기 위해 별도의 배포를 하고 있고, 유지 관리를 위한 특별한 운영 및 유지 관리도 필요하지만 현재 팀에서는 지원하지 않습니다

기본적으로 위와 같은 이유로 직접 작성하려고 합니다. 주로 PHP를 사용합니다. 프로젝트의 기본 redis zset 구조는 저장소로 사용되며 PHP 언어로 구현됩니다. 구현 원리는 Youzan 팀을 참조하세요: https://tech.youzan.com/queuing_delay/

전체 지연 큐는 크게 4개의 부분으로 구성됩니다

JobPool은 모든 작업의 ​​메타 정보를 저장하는 데 사용됩니다.

DelayBucket은 시간을 기준으로 정렬된 대기열 세트로, 지연되어야 하는 모든 작업을 저장하는 데 사용됩니다(여기에는 작업 ID만 저장됩니다).

Timer는 각 버킷을 실시간으로 스캔하고 지연 시간이 현재 시간보다 크거나 같은 작업을 해당 준비 대기열에 배치하는 역할을 담당합니다.

ReadyQueue는 소비자 프로그램에서 사용할 수 있도록 준비 상태(여기에는 JobId만 저장됨)로 작업을 저장합니다.

메시지 구조

각 작업에는 다음 속성이 포함되어야 합니다.

주제: 작업 유형. 구체적인 사업명으로 이해될 수 있습니다.

id: 작업의 고유 식별자입니다. 지정된 Job 정보를 검색하고 삭제하는 데 사용됩니다.

delayTime: jod 지연된 실행 시간, 13자리 타임스탬프

ttr(time-to-run): 작업 실행 시간 초과.

body: 소비자가 특정 비즈니스 처리를 수행하기 위한 작업 콘텐츠로, json 형식으로 저장됩니다.

동일한 종류의 토픽 지연 시간은 일반적으로 ttr이 고정되어 있으며, 직업 속성을 단순화할 수 있습니다.

1.topic: 직업 종류. 구체적인 업체명으로 이해하시면 됩니다

2.id: Job의 고유 식별자입니다. 지정된 Job 정보를 검색하고 삭제하는 데 사용됩니다.

3.body: 소비자가 특정 비즈니스 처리를 수행하기 위한 Job의 콘텐츠로, json 형식으로 저장됩니다.

delaytime, ttr은 topicadmin 백그라운드에서 구성됩니다.

3. 목표

경량: swoole, workman 등과 같은 네트워크 프레임워크를 도입할 필요 없이 더 적은 PHP 확장으로 직접 실행할 수 있습니다.

안정적 특징: 마스터 작업 아키텍처를 채택합니다. 마스터는 비즈니스 처리를 수행하지 않고 하위 프로세스 관리만 담당합니다. 가용성:

1. , 각 인스턴스는 상태가 없으며 하나의 인스턴스는 서비스에 영향을 미치지 않습니다

2. 하나의 Redis가 끊어지면 일부 메시지에만 영향을 미칩니다. 접속하고, 백그라운드에서 관련 메시지 유형과 콜백 인터페이스만 작성하면 됩니다

확장성: 소비 시 프로세스에 병목 현상이 있을 때 소비 프로세스 수를 늘리도록 구성할 수 있습니다. 쓰기를 하면 인스턴스 수를 늘릴 수 있습니다. 쓰기 성능은 선형적으로 향상될 수 있습니다

실시간: 특정 시간 오류가 허용됩니다.

메시지 삭제 지원: 비즈니스 사용자는 언제든지 지정된 메시지를 삭제할 수 있습니다.

메시지 전송 신뢰성: 메시지가 지연 대기열에 들어간 후 적어도 한 번은 소비된다는 것이 보장됩니다.

쓰기 성능: qps>1000+

IV. 아키텍처 설계 및 설명

전체 아키텍처

采用master-work架构模式，主要包括6个模块：

1.dq-mster: 主进程，负责管理子进程的创建，销毁，回收以及信号通知

2.dq-server: 负责消息写入，读取，删除功能以及维护redis连接池

3.dq-timer-N: 负责从redis的zset结构中扫描到期的消息，并负责写入ready 队列，个数可配置，一般2个就行了，因为消息在zset结构是按时间有序的

4.dq-consume-N: 负责从ready队列中读取消息并通知给对应回调接口，个数可配置

5.dq-redis-checker: 负责检查redis的服务状态，如果redis宕机，发送告警邮件

6.dq-http-server: 提供web后台界面，用于注册topic

五、模块流程图

消息写入:

timer查找到期消息:

consumer消费流程:

六、部署

环境依赖：PHP 5.4+ 安装sockets，redis，pcntl,pdo_mysql 拓展

ps: 熟悉docker的同学可以直接用镜像: shareclz/php7.2.14 里面包含了所需拓展

step1:安装数据库用于存储一些topic以及告警信息

执行:

mysql> source dq.sql

step2:在DqConfg.文件中配置数据库信息： DqConf::$db

step3: 启动http服务

在DqConf.php文件中修改php了路径

命令：

php DqHttpServer.php --port 8088

访问:http://127.0.0.1:8088,出现配置界面

redis信息格式：host:port:auth 比如 127.0.0.1:6379:12345

stop4:配置告信息(比如redis宕机)

stop5:注册topic

重试标记说明:

1.接口返回为空默认重试
2.满足指定返回表达会重试，res表示返回的json数组，比如:
回调接口返回json串：{"code":200,"data":{"status":2,"msg":"返回失败"}}，重试条件可以这样写
    {res.code}!=200 
    {res.code}!=200 && {res.data.status}!=2 
    {res.code}==200 && {res.data.status}==2 || {res.data.msg}=='返回失败'

step6:启动服务进程:

php DqInit.php --port 6789 &

执行 ps -ef | grep dq 看到如下信息说明启动成功

step7: 写入数据，参考demo.php

step8:查看日志

默认日志目录在项目目录的logs目录下，在DqConf.php修改$logPath

1.请求日志：request_ymd.txt

2.通知日志：notify_ymd.txt

3.错误日志：err_ymd.txt

step9:如果配置文件有改动

1.系统会自动检测配置文件新，如果有改动，会自动退出(没有找到较好的热更新的方案)，需要重启，可以在crontab里面建个任务,1分钟执行一次，程序有check_self的判断

2.优雅退出命令: master检测侦听了USR2信号，收到信号后会通知所有子进程，子进程完成当前任务后会自动退出

ps -ef | grep dq-master| grep -v grep | head -n 1 | awk '{print $2}' | xargs kill -USR2

七、性能测试

需要安装pthreads拓展：

测试原理：使用多线程模拟并发，在1s内能成功返回请求成功的个数

八、值得一提的性能优化点：

1.redis multi命令：将多个对redis的操作打包成一个减少网络开销

2.计数的操作异步处理，在异步逻辑里面用函数的static变量来保存，当写入redis成功后释放static变量，可以在redis出现异常时计数仍能保持一致，除非进程退出

3.内存泄露检测有必要: 所有的内存分配在底层都是调用了brk或者mmap，只要程序只有大量brk或者mmap的系统调用，内存泄露可能性非常高 ,检测命令: strace -c -p pid | grep -P 'mmap| brk'

4.检测程序的系统调用情况：strace -c -p pid ，发现某个系统函数调用是其他的数倍，可能大概率程序存在问题

九、异常处理

1. 알림 인터페이스가 시간 초과 기간 내에 호출되고 응답이 수신되지 않으면 알림이 실패한 것으로 간주됩니다. 시스템은 데이터를 다시 대기열에 넣고 다시 알림을 보냅니다. $notify_exp_nums는 Dqconf.php 파일에서 수정 가능) 알림 간격은 2n+1입니다. 예를 들어 처음 알림이 1분 동안 실패하면 두 번째 알림이 3분 후에 응답을 받을 때까지 시스템은 최대 알림 개수를 초과하면 자동으로 폐기되며, 동시에 이메일 알림도 전송됩니다

2. Online redis는 매 1초마다 지속되며, 이 경우 1초의 데이터가 손실되는 상황이 발생할 수 있습니다. 경우 request_ymd.txt와 inform_ymd.txt 로그를 비교하여 수동으로 복원할 수 있습니다

3. redis 가동 중지 시간 알림:

ps: 알림 인터페이스에 핵심 서비스가 포함된 경우 필연적으로 네트워크 지터가 발생합니까? 멱등성이어야 합니다! !

10. 온라인 상황

각 컴퓨터실에 하나씩 2개의 인스턴스가 온라인으로 배포되었으며, 저장용 메모리가 총 16G인 4개의 Redis가 몇 달 동안 안정적으로 실행되었으며 모든 지표가 일치합니다. 기대와 함께.

주요접근업무 :

·주문시 10분 리콜 알림

·호출 인터페이스 타임아웃 또는 실패시 보상

·회원 만료 3일 전 리콜 알림

11. 단점 및 전망

1. 팀에서 사용하는 이미지에는 libevent 확장이 부족하므로 dq-server는 선택 모델을 기반으로 하며 높은 동시성 시나리오에서 성능 병목 현상이 발생하도록 변경될 수 있습니다. 동시성 성능을 향상시키기 위해 향후 libevent 이벤트 모델을 기반으로 합니다.

2. 타이머와 소비자는 현재 다중 프로세스를 사용하여 구현됩니다. 멀티 스레딩 모드 사용을 고려하고 스레드 수를 동적으로 생성하여 소비자 성능을 최대한 보장할 수 있습니다. .

3.dq-server와 redis는 동기적으로 호출되는데, 이는 성능상의 병목현상이기도 합니다. swoole_redis를 기반으로 비동기적으로 처리할 계획입니다.

PHP 중국어 웹사이트에는 무료 PHP 비디오 튜토리얼이 많이 있습니다. 누구나 배울 수 있습니다!

이 기사는 https://www.jianshu.com/p/58f10ac42162

에서 복제되었습니다.