diff --git "a/CS Deep Dive/Database/\353\240\210\353\224\224\354\212\244(Redis).md" "b/CS Deep Dive/Database/\353\240\210\353\224\224\354\212\244(Redis).md"
index 24744bda..203c64e8 100644
--- "a/CS Deep Dive/Database/\353\240\210\353\224\224\354\212\244(Redis).md"	
+++ "b/CS Deep Dive/Database/\353\240\210\353\224\224\354\212\244(Redis).md"	
@@ -1,5 +1,6 @@
 # 레디스(Redis)
 
+
 Key, Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템 (DBMS)이다.  
 데이터베이스, 캐시, 메시지 브로커로 사용되며 인메모리 데이터 구조를 가진 저장소이다.
 
@@ -14,6 +15,11 @@ Key, Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오
 
 캐시는 한번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결괏값을 받을 수 있도록 도와주는 공간이라 같은 요청이 여러 번 들어오는 경우 매번 데이터 베이스를 거치는 것이 아니라 캐시 서버에서 첫 번째 요청 이후 저장된 결괏값을 바로 내려주기 때문에 DB의 부하를 줄이고 서비스의 속도도 느려지지 않는 장점이 있다.
 
+### 로컬 캐시가 있는데도 Redis를 사용하는 이유가 뭘까?
+서버 어플리케이션은 대부분 자체 로컬 캐시를 지원한다. 다만 로컬 캐시는 단일 서버에서만 동작하므로 분산 시스템에서는 로컬캐시가 올바르게 동작하기 힘들다.
+Redis 서버를 따로 두어 관리하면 분산 환경에서도 캐시를 원활하게 이용할 수 있다.
+또한 복제와 샤딩을 지원하기 때문에 대규모 시스템에서 확장성을 유지할 수 있다. 반면 로컬 캐시는 이러한 기능이 없다는 단점이 있다.
+
 
 ### Redis의 특징
 - Key, Value 구조이기 때문에 쿼리를 사용할 필요가 없다.  
@@ -35,7 +41,29 @@ Key, Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오
  
 
 ### Redis 사용시 주의할 점
-- 서버에 장애가 발생했을 경우 그에 대한 운영 플랜이 꼭 필요하다.
-    - 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있기 때문이다.
-- 메모리 관리가 중요하다.
+1. 장애 대응
+   - 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있다.
+     -> 클러스터를 구성해서 복사본을 만들어둔다.
+   - 장애가 일어났을 때 레디스를 사용하는 어플리케이션에 장애가 전파될 수 있다.
+     -> 서킷브레이커 패턴을 이용해서 장애 전파 차단
+     <details>
+      <summary>서킷브레이커 패턴</summary>
+      <div markdown="1">
+     서킷브레이커는 장애가 발생했을 때 단순 예외처리를 하는것이 아니고, 특정 가용률 아래로 떨어지면 잠시동안 아예 시도를 하지 않는다.
+     레디스를 예로들면 레디스 서버가 다운되어서 접근이 불가능하면, 잠시 레디스의 접근 자체를 하지 않는 방식으로 장애 전파를 차단한다.
+      </div>
+      </details>
+
+   
+2. 메모리 관리
     - 싱글 스레드의 특성상, 한 번에 하나의 명령만 처리할 수 있기 때문에, 처리하는데 시간이 오래 걸리는 요청, 명령은 피해야 한다.
+    - 인메모리 데이터 스토어이므로 메모리 부족현상이 일어날 수 있다.
+    - 따라서 하나의 인스턴스에 서버 어플리케이션, db어플리케이션, 레디스를 한 번에 두면 메모리 부족이 일어날 수 있으므로 따로 두는 것이 좋다.
+3. 정합성 관리
+    - 레디스 뿐만 아니라 캐시를 사용하는 경우, 실제 데이터베이스와는 다른 데이터가 조회될 수 있는 문제가 발생할 수 있다.
+    - 비즈니스 요구사항에 맞춰 어느정도까지 실시간성을 맞출지 고려하여 적절하게 설정하는 전략이 필요하다.
+  
+### 캐시 이외에 Redis가 주로 쓰이는 곳
+1.  세션 스토어 : 사용자 세션 정보를 관리
+2.  메시지 브로커 : 여러 시스템 간에 메시지를 전달하는 기능
+      
diff --git "a/CS Deep Dive/Database/\355\212\270\353\236\234\354\236\255\354\205\230 \352\262\251\353\246\254 \354\210\230\354\244\200(Transaction Isolation Level).md" "b/CS Deep Dive/Database/\355\212\270\353\236\234\354\236\255\354\205\230 \352\262\251\353\246\254 \354\210\230\354\244\200(Transaction Isolation Level).md"
index 56b9cfd0..020f4709 100644
--- "a/CS Deep Dive/Database/\355\212\270\353\236\234\354\236\255\354\205\230 \352\262\251\353\246\254 \354\210\230\354\244\200(Transaction Isolation Level).md"	
+++ "b/CS Deep Dive/Database/\355\212\270\353\236\234\354\236\255\354\205\230 \352\262\251\353\246\254 \354\210\230\354\244\200(Transaction Isolation Level).md"	
@@ -16,16 +16,22 @@
 - 트랜잭션 A가 문제가 생겨 ROLLBACK을 해도 B는 계속 로직을 수행한다.
 - 데이터 부정합이 발생한다.
 
-**2. Non-Repeatable Read**
+**2. Dirty Write**
+
+**3. Read Skew1**
 
 - 트랜잭션 A가 같은 쿼리를 반복해서 수행하는 도중, 트랜잭션 B가 A의 실행에 사용하는 값을 변경한다.
 - 트랜잭션 A가 같은 쿼리를 수행하는데에도 B에 의해 다른 결과가 나온다.
 - 같은 쿼리문에 대해 일관된 결과값이 나와야하는 `REPEATABLE READ` 정합성을 만족하지 못한다.
 
-**3. Phantom Read**
+**4. Lost Update**
 
 - 한 트랜잭션 내에서 같은 쿼리를 두 번 실행했는데, 첫 번째 쿼리에서 없던 유령(Phantom) 레코드가 두 번째 쿼리에서 나타나는 현상이다.
 
+**5. Read Skew2**
+
+
+
 <br/>
 
 ## 4가지 격리 수준