사설 : 레디 스 메시지 큐는 메시지의 신뢰성에 대한 높은 요구가있는 경우, 그들은 지금 포기, 보장의 ACK가 아닌 고급 기능의 특히 많은 수는 없다, 전문 메시지 큐되지 않습니다.
1.Redis 메시지 큐
레디 스 내부 비동기 메시지 큐에서 데이터 구조에 의해 달성된다. 을 통해 rpush, lpush그리고 lpop, rpop다른 효과를 구성.
예를 들어, rpush및 lpop작업 큐 (FIFO)를 구성하는 결합 된 효과와 유사하다; rpush및 rpop큐 효과의 조합을 사용하여 효과 스택 (LIFO)이지만, 일반적으로 메시지 큐의 형태 인 구성 될 수있다.
>rpush hobby basketball football tennis
(integer) 3
>lpop hobby
"basketball"
>lpop hobby
"football"
>lpop tennis
"tennis"
>lpop hobby
(nil)
고객이 큐의 소비자 클라이언트 라이프 사이클, 순환되어, 팝 조작에 의해 메시지 큐를 가져온 다음 다시 다음을 처리 한 후 메시지가, 이상 처리, 처리.
위에서 언급 한 바와 같이 큐가 비어있는 경우, 팝업 작업을 수행하는 방법, 자원 레디 스 클라이언트 및 서비스 측면을 소모하면서 대중의 무한 루프가, 쓸모없는 빈 폴링 한 무리의 생산에, 클라이언트가 적발 된 데이터를 얻을 수 없다?
첫째, 당신이 요청 큐가 비어 만들 수도 그 생각을 수 있으며, sleep명령 스레드를 중지합니다. 더 나은 접근 방식을 통해입니다 blpop및 brpop대체 전에 lpop하고 rpop있음을 읽을 차단 (가 큐에 데이터가 없으며, 바로 잠을로 이동, 다시 요청 즉시 데이터가 도착했을 때 등) 슬립 명령을 제공하기 때문에 지연 다루는 방법.
목록 데이터가없는 긴 시간 인 경우, 클라이언트 스레드가 항상 유휴 연결의 형성을 차단하지만,이 경우, 서버 자원을 절약하기 위해 일반적으로이 링크를 끊 있습니다 :하지만이 새로운 문제가 발생해야합니다. 클라이언트 blpop/ brpop오류가보고됩니다.
그래서 당신은 소비자가 다시 시도 할 때 클라이언트 측 캐치 예외를 작성합니다.
2. 대기 시간 대기열
요청을 처리하는 동안 지연 분산 개발을 해결하기 위해 대기열 발생, 클라이언트 잠금 문제는 실패했습니다. 이러한 방법으로 현재의 충돌이 지연 잠금 충돌을 피하기 위해 다른 프로세스의 요청 큐에 발생합니다.
대기열 레디 스 지연되고 zset, 기본 모드 (명령리스트)를 사용하고 구현 zset key score value. 종종 문자열 지연 큐에 메시지 시퀀스에서 zset의 value메시지의 유효 시간과, score스레드 (가용성 보장)하는 복수의 다음 폴링하는 zset프로세스 작업으로 인해 얻었다. 동시 잡아에게 계정에 작업을 촬영 작업이 여러 번 수행 될 가능성이 높습니다.
def delay(msg):
msg.id = str(uuid4()) #序列化保证value的唯一性
value = json.dumps(msg)
retry_ts = time.time() + 5 # 5s后重试
redis.zadd('delay-queue',retry_ts,value)
def loop():
while True:
# 最多取一条
value_list = redis.zrangebyscore("delay-queue",0,time.time(),start=0,num=1):
if not value_list:
time.sleep(1)
continue
value = value_list[0]
# 将取到的消息从redis消息队列中删除
success = redis.zrem("delay-queue",value)
# 多进程并发下，只有一个线程可以抢到消息
if success:
msg = json.loads(value)
handle_msg(msg)
레디 스는 zrem방법은 발생하지 않습니다 중요한 혼란이 멀티 스레드 경쟁을 보장하는 것입니다.
실행에 그 주 () handle_msg 예외가 문제를 방지하기 위해 캡처해야하는 경우가 예기치 않게 종료 단일 작업 사이클로 이어집니다.