Cache는 Storage/DB와 병렬이다. (+MESI protocol)

알게 된 사실

1) 캐싱을 할 때

VM - REDIS - DB/Storage 구조로 보통 나타내지만

이건 논리적인 구조다.

물리적으로는 VM - REDIS

                       - DB

                       - Storage 

이렇게 연결되어있다.

왜? REDIS도 결국 storage인데, storage - storage가 연결되면 어떻게 데이터를 가져와?

 

2) write back vs write through

write back : 캐시에 먼저 저장하고, 캐시에서 더이상 필요 없을 때 disk로 내린다.

장점) 속도가 빠르다. 단점) 일관성 문제가 생길 수 있다. -> 이거 CPU에서만 생기는거 아냐?

http://blog.skby.net/%EC%BA%90%EC%8B%9C-%EC%9D%BC%EA%B4%80%EC%84%B1-%EC%9C%A0%EC%A7%80%EA%B8%B0%EB%B2%95/

캐시 일관성 유지기법 > 도리의 디지털라이프

 

일관성 유지를 위해 MESI 프로토콜을 사용한다.

https://www.slideserve.com/mardi/snooping-protocol

Snooping Protocol

ㄴ 슬라이드 하나 하나 잘 설명해놨음... 이해는 안가지만...

 

-> 그러면 디스크 캐시에서는 일어나지 않는거 아냐????

기껏해야 메모리 - 캐시 - 디스크 니까

메모리에서 캐시로 write 했는데, 캐시에서 디스크로 write 못해서 데이터 날아가는게 끝 아닌가?

이러면 일관성에 문제가 생긴다고 할 수 없지 않음?

 

 

 

write through : 캐시와 disk 동시에 저장한다.

장점) 안정성이 높다. 단점) 속도가 느리다. (disk write operation이 끝날 때까지 기다려야함)

 

 

 

https://azure.microsoft.com/ko-kr/blog/azure-premium-storage-now-generally-available-2/

 

 

 

 

http://melonicedlatte.com/computerarchitecture/2019/02/12/203749.html

[Cache] Write Through과 Write Back의 차이 - Easy is Perfect

 

 

확인필요) 형모 : 서버의 경우 Raid Controller에 배터리가 달려있잖아. 이 배터리가 충전되어 있으면, write back, 방전되어있으면 write through로 작동한다고 들었다!

(대개 캐시는 write back으로 작동한다고 함)

 

 

캐시 일관성 문제 - 하드웨어적 해결

---

1. 스누피 프로토콜(snoopy protocol)

각각 CPU의 캐시들은 공유되는 캐시 데이터를 파악하고 있으며, 공유되는 캐시 데이터가 갱신 되었을 경우 이를 기반으로 갱신되지 않은 나머지 데이터를 무효화한다. 공유되는 버스 구조가 Broadcasting 및 Snooping에 유리하므로 버스 기반 다중 프로세서 시스템에 적합한 방식이다.

 

2. 디렉토리 프로토콜(directory protocol)

주기억장치의 중앙 제어기가 캐시 일관성을 관리하는 형태이다. 주기억장치의 중앙 제어기는 각각 CPU의 캐시 데이터들을 가지고 있으며, 모든 지역 캐시 제어기의 동작을 제어하고 보고받으며 캐시 일관성을 관리한다.

 

https://newdevlog.tistory.com/6

[Operating System] 캐시 일관성 (Cache Coherence)