2025 06 20
2025-06-20¶
REDIS set, setnx¶
- set
- setnx
- set if not exist - 별도 expiry 없음
- setnx + expire
def setnxex(key: String, expiry: Long, value: String) = { master.set(key, value, StringApi.NX, expiry.seconds) } override def set(key: Any, value: Any, whenSet: SetBehaviour = Always, expire: Duration = null) (implicit format: Format): Boolean = processForKey(key)(_.set(key, value, whenSet, expire))- NX: Not Exist의 줄임말 - expiry 제공 - 분산락/일회성 작업을 구현할 때 유용하게 사용 가능
- setnxex vs redisson
- redisson: Redis의 분산락을 구현한 고수준의 자바 라이브러라. 락의 획득/해제/갱신 등 추상화하여 제공
- 내부적으로 RedLock을 사용하여, 클러스터 환경에서 락 획득.
- setnxex: SET 명령어 직접 사용하여 락을 구현하는 저수준 방식
- 단일 Redis 인스턴스에서 락을 잡음
- 그러면 클러스터 환경에서 장애가 날수있는 상황은?
- ex) 클러스터 마스터 리소스 (A, B, C) 구성시... 1. Redlock 사용 - Client1이 Redlock을 사용하여 락을 요청합니다. - Redlock은 3개의 마스터 노드 모두에게 락 요청을 보냅니다. - 과반수 이상의 노드(2개 이상)에서 락을 획득해야 Client1이 락을 얻을 수 있습니다. - Client1이 마스터 노드 A와 B에서 락을 획득했다고 가정합니다. - 이후 마스터 노드 A에 장애가 발생하여 응답하지 않게 됩니다. - Client2가 Redlock을 사용하여 락을 요청합니다. - Redlock은 마스터 노드 B와 C에게 락 요청을 보냅니다. - 마스터 노드 B는 이미 Client1에게 락을 부여했으므로 Client2의 요청을 거부합니다. - 마스터 노드 C는 아직 락을 부여하지 않았으므로 Client2에게 락을 부여할 수 있습니다. - 그러나 과반수 노드에서 락을 획득하지 못했으므로 Client2는 락을 얻을 수 없습니다. - 따라서 Redlock은 마스터 노드 A의 장애 상황에서도 락의 안정성을 유지할 수 있습니다. 2. setnxex 사용 - Client1이 setnxex를 사용하여 마스터 노드 A에 락을 요청하고 획득합니다. - 이후 마스터 노드 A에 장애가 발생하여 응답하지 않게 됩니다. - Client2가 setnxex를 사용하여 마스터 노드 B에 락을 요청합니다. - 마스터 노드 B는 Client1이 마스터 노드 A에서 획득한 락에 대해 알 수 없으므로 Client2에게 락을 부여합니다. - 이 경우 Client1과 Client2가 모두 락을 획득한 것으로 간주되어 데이터 불일치나 race condition이 발생할 수 있습니다. - 따라서 setnxex는 단일 마스터 노드 장애 시에 락의 안정성을 보장할 수 없습니다.
- [결론]
setnx: 보다 가벼운 락 제어redisson: 분산환경에서의 안정성 + 정합성 보장
- redisson: Redis의 분산락을 구현한 고수준의 자바 라이브러라. 락의 획득/해제/갱신 등 추상화하여 제공
android intent¶
- 개요
intent://: 안드로이드에서만 동작하는 특수 URL 스킴- 해당 url을 통해 안드로이드 시스템에서 정의된 패키지명, 액션, 데이터를 바탕으로 해당 앱 실행 가능
- 공유하기
action=android.intent.action.SEND: 안드로이드 공유 액션type=text/plain: 공유 데이터 타입이 일반 텍스트S.android.intent.extra.SUBJECT: 공유 내용의 제목S.android.intent.extra.TEXT: 공유 내용의 본문