<div id="readability-page-1" class="page"><div class="page" post="">
 
 
 <hr>
 <article itemscope="" itemtype="http://schema.org/BlogPosting">
 <ul id="markdown-toc">
 <li><a href="#brpop이란" id="markdown-toc-brpop이란">BRPOP이란?</a></li>
 <li><a href="#blocking-vs-polling" id="markdown-toc-blocking-vs-polling">Blocking vs Polling</a></li>
 <li><a href="#n개의-소비자가-접근을-한다면" id="markdown-toc-n개의-소비자가-접근을-한다면">n개의 소비자가 접근을 한다면?</a></li>
 <li><a href="#timeout-발생-후-값-재확인" id="markdown-toc-timeout-발생-후-값-재확인">Timeout 발생 후 값 재확인</a></li>
 <li><a href="#summary" id="markdown-toc-summary">Summary</a></li>
</ul>

<h2 id="brpop이란">BRPOP이란?</h2>

<ul>
 <li>
 BRPOP(Blocking List Pop)은

 Redis에서 사용되는 명령어 중 하나로

 블로킹 방식으로 Redis List에서 요소를 팝(pop)하는 데 사용된다.
 </li>
 <li>
 기본적으로 BRPOP 명령어는

 하나 이상의 리스트를 대상으로 하며

 리스트가 비어 있으면

 블로킹 상태에 들어가 새로운 요소가 추가될 때까지 기다린다.
 </li>
 <li>
 만약 여러 리스트가 지정되었다면

 가장 먼저 요소가 추가된 리스트부터 팝을 시도한다.
 </li>
</ul>

<blockquote>
 BRPOP Signature
</blockquote>

<div><pre><code>BRPOP key1 key2 key3 timeout
- key1, key2, key3: 팝(pop)을 시도할 Redis 리스트의 키 목록이다.
- timeout: 블로킹 상태에서 기다릴 최대 시간(초)이다. 0일 경우 무한대로 기다린다.
</code></pre></div>

<ul>
 <li>
 만약 리스트가 비어 있지 않다면

 BRPOP은 리스트에서 요소를 팝 하고 해당 요소를 반환한다.
 </li>
 <li>
 만약 블로킹 상태에서 대기 중일 경우

 timeout이 발생하면 nil을 반환한다.
 </li>
</ul>

Example



<ul>
 <li>
 mylist 리스트에서 요소를 최대 10초까지 기다린다.

 만약 10초 동안 리스트에 새로운 값이 추가되지 않으면 nil을 반환하고

 새로운 값이 추가되면 해당 값을 반환하고 팝 한다.
 </li>
</ul>

<hr>

<h2 id="blocking-vs-polling">Blocking vs Polling</h2>

<ul>
 <li>
 위에서 BRPOP은 Blocking을 한다했는데

 그러면 Polling 방식과 어떤 차이가 있고

 왜 Blocking 방식을 사용하는지 알아보자.
 </li>
 <li>
 폴링은 주기적으로 Redis에게 “새로운 메시지가 있나요?”라고 물어보는 행위를 하게 된다.

 이런 접근 방식은 CPU 주기를 낭비하고

 특히 메시지가 자주 도착하지 않는 경우에는 더욱 비효율적이게 된다.
 </li>
 <li>
 반면에 BRPOP은 메시지가 도착할 때까지 블로킹되므로

 메시지가 도착할 때까지 대기하면서 CPU 주기를 낭비하지 않는다.
 </li>
 <li>
 즉 BRPOP은 메시지가 도착할 때까지 대기하면서도

 CPU 사용량을 최소화하므로 효율적이라고 할 수 있다.
 </li>
</ul>

<hr>

<h2 id="n개의-소비자가-접근을-한다면">n개의 소비자가 접근을 한다면?</h2>

<ul>
 <li>
 여러 소비자가 동시에 BRPOP 명령어를 사용하여

 같은 리스트를 대상으로 메시지를 기다리고 있을 경우

 첫 번째로 메시지를 수신한 소비자만이 해당 메시지를 처리하게 된다.
 </li>
 <li>
 위에서 BRPOP을 사용하면

 메시지를 수신할 때까지 블로킹 상태로 대기한다고 했다.
 </li>
 <li>
 따라서 여러 소비자 중

 첫 번째로 메시지를 수신한 소비자만이 해당 메시지를 처리할 수 있고

 나머지 소비자들은 순차적으로 처리를 기다려야 한다.
 </li>
 <li>
 이런 동작 방식은 메시지의 처리를 공정하게 나누는 것이 아니라

 첫 번째로 메시지를 수신한 소비자에게 우선권을 주는 방식이므로

 경쟁 상황에서 메시지 처리 요구 사항을 해결하는데 방법이 될 수 있다.
 </li>
</ul>

<hr>

<h2 id="timeout-발생-후-값-재확인">Timeout 발생 후 값 재확인</h2>



<ul>
 <li>
 10초를 기다렸는데 mylist에 값이 없어서 nil을 반환을 했다면

 다음에 mylist에 값이 있는지는 언제 확인할까?
 </li>
 <li>
 자동으로 확인하길 기대했지만 그렇지 않다.
 </li>
 <li>
 BRPOP 자체는 대기 후에 다시 자동으로 호출되지 않으므로

 값 확인을 위해선 BRPOP 명령어를 다시 호출해야 한다.
 </li>
 <li>
 따라서 새로운 값이 추가되었는지 확인하려면

 애플리케이션 로직에서 주기적으로 Redis 명령어를 호출하는 것이 한 가지 방법이 될 수 있다.
 </li>
</ul>

<hr>

<h2 id="summary">Summary</h2>

<ul>
 <li>
 Redis의 BRPOP 명령어에 대해 알아봤다.
 </li>
 <li>
 BRPOP 명령어를 사용하면 블로킹 상태로 대기를 하며

 Polling에 비해 CPU의 성능을 저하시키지 않는다는 특징을 기억하자.
 </li>
</ul>

 </article>
 
 <hr>

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 


 </div></div>

Gidhub

BRPOP이란?
Blocking vs Polling
n개의 소비자가 접근을 한다면?
Timeout 발생 후 값 재확인
Summary
BRPOP이란?
BRPOP(Blocking List Pop)은
Redis에서 사용되는 명령어 중 하나로
블로킹 방식으로 Redis List에서 요소를 팝(pop)하는 데 사용된다.
기본적으로 BRPOP 명령어는
하나 이상의 리스트를 대상으로 하며
리스트가 비어 있으면
블로킹 상태에 들어가 새로운 요소가 추가될 때까지 기다린다.
만약 여러 리스트가 지정되었다면
가장 먼저 요소가 추가된 리스트부터 팝을 시도한다.
BRPOP Signature
BRPOP key1 key2 key3 timeout
- key1, key2, key3: 팝(pop)을 시도할 Redis 리스트의 키 목록이다.
- timeout: 블로킹 상태에서 기다릴 최대 시간(초)이다. 0일 경우 무한대로 기다린다.
만약 리스트가 비어 있지 않다면
BRPOP은 리스트에서 요소를 팝 하고 해당 요소를 반환한다.
만약 블로킹 상태에서 대기 중일 경우
timeout이 발생하면 nil을 반환한다.
Example
BRPOP mylist 10
mylist 리스트에서 요소를 최대 10초까지 기다린다.
만약 10초 동안 리스트에 새로운 값이 추가되지 않으면 nil을 반환하고
새로운 값이 추가되면 해당 값을 반환하고 팝 한다.
Blocking vs Polling
위에서 BRPOP은 Blocking을 한다했는데
그러면 Polling 방식과 어떤 차이가 있고
왜 Blocking 방식을 사용하는지 알아보자.
폴링은 주기적으로 Redis에게 “새로운 메시지가 있나요?”라고 물어보는 행위를 하게 된다.
이런 접근 방식은 CPU 주기를 낭비하고
특히 메시지가 자주 도착하지 않는 경우에는 더욱 비효율적이게 된다.
반면에 BRPOP은 메시지가 도착할 때까지 블로킹되므로
메시지가 도착할 때까지 대기하면서 CPU 주기를 낭비하지 않는다.
즉 BRPOP은 메시지가 도착할 때까지 대기하면서도
CPU 사용량을 최소화하므로 효율적이라고 할 수 있다.
n개의 소비자가 접근을 한다면?
여러 소비자가 동시에 BRPOP 명령어를 사용하여
같은 리스트를 대상으로 메시지를 기다리고 있을 경우
첫 번째로 메시지를 수신한 소비자만이 해당 메시지를 처리하게 된다.
위에서 BRPOP을 사용하면
메시지를 수신할 때까지 블로킹 상태로 대기한다고 했다.
따라서 여러 소비자 중
첫 번째로 메시지를 수신한 소비자만이 해당 메시지를 처리할 수 있고
나머지 소비자들은 순차적으로 처리를 기다려야 한다.
이런 동작 방식은 메시지의 처리를 공정하게 나누는 것이 아니라
첫 번째로 메시지를 수신한 소비자에게 우선권을 주는 방식이므로
경쟁 상황에서 메시지 처리 요구 사항을 해결하는데 방법이 될 수 있다.
Timeout 발생 후 값 재확인
BRPOP mylist 10
10초를 기다렸는데 mylist에 값이 없어서 nil을 반환을 했다면
다음에 mylist에 값이 있는지는 언제 확인할까?
자동으로 확인하길 기대했지만 그렇지 않다.
BRPOP 자체는 대기 후에 다시 자동으로 호출되지 않으므로
값 확인을 위해선 BRPOP 명령어를 다시 호출해야 한다.
따라서 새로운 값이 추가되었는지 확인하려면
애플리케이션 로직에서 주기적으로 Redis 명령어를 호출하는 것이 한 가지 방법이 될 수 있다.
Summary
Redis의 BRPOP 명령어에 대해 알아봤다.
BRPOP 명령어를 사용하면 블로킹 상태로 대기를 하며
Polling에 비해 CPU의 성능을 저하시키지 않는다는 특징을 기억하자.

Redis에서 POP 명령어 대신 BRPOP 명령어를 사용하는 이유는 뭘까?

댓글