업데이트 버전을 보려면 여기를 클릭하십시오.

소개

2회에서는 우리가 시작한 내용을 설명하고 캐시 쓰기 기술을 소개할 것이다.

Please Note
If you're looking for an introduction about caching in general and reading techniques, you can go

뭐 공부 해요?작문 기교?!

I am still food drunk. GIMME THE CODE
나는 너의 서프라이즈를 완전히 보았다.읽기 기술에서, 우리는 이미 어떻게 그리고 언제 캐시층을 쓰는지 언급했는데, 왜 우리는 여기에 서로 다른 전략을 가지고 있습니까?
우리는 읽기 기교를 진정으로 읽기 행위와 관련된 기교라고 부른다.예를 들어 업무 목록을 가져옵니다.따라서 비록 우리는 이미 약간의 창작을 했지만, 사실 우리가 창작을 하는 것은 단지 읽기의 목적을 달성하기 위해서이다.
따라서 쓰기 기술은 기본적으로 쓰기 작업 기간에 캐시를 채우거나 업데이트하는 전략이다.그것들 중에서 가장 큰 장점은 나중에 데이터를 읽을 때이다.작성 작업의 예는 새로운 사무 만들기, 사용자 정보 편집 등을 포함한다.
앞에서 설명한 바와 같이, 우리는 이러한 모델에 대해 토론할 것이다.

직접 쓰기

뒤에 쓰기

쓰기

마지막과 마찬가지로 참여자는 다음과 같습니다.

고객: 데이터가 필요한 사람;

캐시: 데이터를 저장하는 곳;

자원 관리자: 고객에게 자원을 전달합니다.

데이터 접근기: 응용 프로그램 외부에서 데이터를 가져옵니다.

직접 쓰기(직접 쓰기라고도 함)

읽기 (또는 캐시 내연) 와 마찬가지로 자원 관리자는 클라이언트와 데이터 접근기 사이에 있습니다.
이 그림은 직접 쓰기 작업의 라이프 사이클을 나타냅니다.

다음 단계는 다음과 같습니다.

클라이언트가 쓰기 작업을 시작하고 자원 관리자를 호출합니다.

자원 관리자가 캐시에 쓰기;

자원 관리자가 호출 데이터 접근기를 쓰기;

고객에게 회신하여 전달하다.

근본 원인

언뜻 보기에 이것은 결코 가장 현명한 조치가 아니다. 사실 우리는 요청의 속도를 늦추고 추가 절차를 늘리고 있다.그렇다면 우리는 이 전략에서 무엇을 얻었는가?
우리가 여러 번 말했듯이 캐시 데이터의 가장 큰 문제 중 하나는 오래된 것이다.이 모델은 마침 이 문제를 해결했다.
다른 글에서 우리는 유행이 지난 항목을 처리하는 방법 중 하나가 TTL을 사용하는 것을 보았는데, 이 점은 여전히 성립되었다. 그러나 이런 상황에서 기한이 지난 것은 문제를 해결하는 가장 좋은 방법이다. 왜냐하면 우리는 얻고 있는 데이터를 생성하지 않았기 때문이다.이제 우리는 읽을 데이터를 제어할 수 있습니다. 그리고 데이터를 쓸 때마다 캐시를 업데이트하면 캐시 항목이 영원히 유행을 타지 않도록 합니다.
물론 음영이 없으면 빛이 없다. 쓰기 지연¹을 제외하고 클라이언트가 데이터를 자주 읽을 필요가 없을 때 이런 기술은 유해해질 수 있다.사실상, 이러한 상황에서 사용자는 결국 활동과 캐시를 동기화하는 데 필요한 자원을 낭비하고 읽기 이익을 얻지 못할 것이다.

뒤에 쓰다

다른 기술은 여전히 자원 관리자를 연결시키지만, 데이터 접근기를 통해 쓰는 것은 비동기적이다.

다음은 작업 라이프 사이클에 관련된 단계입니다.

클라이언트가 쓰기 작업을 시작하고 자원 관리자를 호출합니다.

자원 관리자가 캐시에 쓰기;

고객 회신;

최종적으로 자원 관리자는 호출 데이터 접근기를 기록합니다.

근본 원인

이런 캐시 기술이 왜 유용하고 어떻게 유용한지 이해하는 가장 좋은 방법은 예시를 제시하는 것이다.
만약에 우리가 현재 TrulyAwesomeBankAPI 을 개발하고 캐시를 사용하여 Payment 사무를 만들고 싶다고 가정하십시오.지불은 가능한 한 빨리 진행해야 하지만, 진정으로 경외스러운 은행이 우리의 API를 지원하는 것은 여전히 낡은 인프라 시설에서 최고치를 잘 처리할 수 없다.
Write-Behind를 사용하기로 결정했습니다.이것은 Payment를 실행할 때마다 이 업무를 캐시에 저장하고 클라이언트에게 응답을 되돌려준다는 것을 의미한다.그리고 나서 우리는 또 다른 작업 루틴이 생겼다. (백그라운드에서, 다른 프로세스에서 실행되고, CRON 표현식이나 다른 것을 바탕으로...)그것은 우리가 캐시한 분류 장부 버전을 진정한 은행의 실제 분류 장부와 동기화하는 것을 책임진다.이런 방식을 통해 우리는 은행이 주어진 시간에 얼마나 많은 요청을 지원할 수 있든지 간에 신속하게 응답을 제공할 수 있다.
그리고 우리는 외부 데이터 원본을 기다릴 필요가 없기 때문에 성능과 안정성을 얻을 것이다.이것은 구조가 전체적으로 외부 서비스에 대해 더욱 용착성을 가지게 하여 새로운 복구 가능성을 열었다. 예를 들어 우리는 클라이언트에게 영향을 주지 않는 상황에서 간단한 재시도 전략, 심지어 차단기를 실시할 수 있다.
그러나 우리가 지불하는 대가는 일치성이다. 직원들이 동기화 과정을 완성하기 전에 실제 데이터(예를 들어 진정으로 경외심을 불러일으키는 은행에 사는 데이터)와 우리가 제공한 데이터(예를 들어 캐시에 사는 데이터)는 다르다. 만약에 우리가 어떻게 잘못된 상황을 처리하는지 생각하기 시작하면 일이 더욱 복잡해질 수 있다².

여기저기 쓰다

좋아, 완전하게 보기 위해서, 우리는 마땅히 여기저기 써야 한다고 언급해야 하지만, 나에게는 그것이 진정한 패턴처럼 보이지 않는다.사실상, 다음 그림에서'캐시'라는 단어의 어떤 흔적도 찾을 수 없다.

기본적으로 Write-Around는 "읽기 전용으로 데이터 액세스기와 캐시 데이터를 직접 호출합니다."이것은 저에게 "쓰기 정책을 사용하지 않고 읽기 정책을 적용합니다."라는 것을 의미합니다.

근본 원인

이런 비모드를 사용하는 이유는 위의 창작 기교가 당신에게 적합하지 않기 때문이다. 아마도 당신은 매우 일치하는 데이터가 필요하거나 자주 데이터를 읽을 필요가 없을 것이다.
이런 상황에서 창작 기교를 사용하지 않거나 (또는 원한다면 변통 창작을 사용할 수 있다) 하면 된다.

당신은 코드를 좀 썼습니까?

You can find a more detailed version of these examples here

무엇 / 디자인 모델

디자인 모델이 실제 코드에서의 사용 예시

디자인 모델

Examples of usage of design patterns in real life code

These are the reference resources for

View on GitHub

네, 했습니다.이번엔 파이썬이야.
내가 여기서 제공한 예는 타이머를 사용하여 느리게 작성된 외부 서비스를 시뮬레이션하는 것이다.특히, 우리는 TrulyAmazingBankAPI 에서 발생하는 상황을 많거나 적게 모의할 것이다. 우리는 저장할 업무를 만들 것이다.
프로그램을 시작하면 몇 초 후에 직서와 쓰기 후 발생한 일의 궤적을 정확하게 볼 수 있다.
출력을 하나하나 검사합시다.
이렇게 써도 돼요.

>>> Save transaction
[14:59:17.971960] CacheManager.set
[14:59:17.971977] TrulyAwesomeBankAPIClient.save_transaction
>>> Get transaction
[14:59:19.974781] CacheManager.get

여기서 우리가 해야 할 첫 번째 일은 항목을 캐시에 저장한 다음 Awesome Bank에 저장하는 것입니다. 몇 초 후에 저장된 업무를 가져오려고 할 때, 캐시를 사용하여 검색합니다.
뒤에 써주세요.

>>> Save transaction
[14:59:24.976378] CacheManager.set
>>> Get transaction
[14:59:21.978355] CacheManager.get

--------------------------------------------
|    AWESOME BANK DATABASE (before sync)   |
--------------------------------------------
{}

[14:59:26.974325] TrulyAwesomeBankAPIClient.save_transaction

--------------------------------------------
|    AWESOME BANK DATABASE (after sync)    |
--------------------------------------------
{
   UUID('0f41f108-0859-11e9-a138-b46bfc6c5cb9'): {
      'id': UUID('0f41f108-0859-11e9-a138-b46bfc6c5cb9'), 
      'transaction': {
         'type': 'PAYMENT', 
         'amount': 100, 
         'currency': 'EUR'
      }
   }
}

만약 우리가 요청을 "set transaction"과 "get transaction"두 동작이라고 부른다면, 우리는 요청의 전체 생명 주기에서 유일하게 관련된 참여자가 Cache Manager라는 것을 출력에서 볼 수 있다.
우리가 Truly Awesome Bank APIClient를 호출하는 유일한 순간은 요청이 끝난 후 5초, 즉 우리가 동기화를 완성할 때이다.
여기에 타이머가 있기 때문에 동기화도 고의로 어리석고 느린 과정이라는 것을 주의하십시오.현실 세계에서 동기화 과정은 이보다 훨씬 복잡할 수 있다. 사실상 데이터의 일치성이 게임 규칙을 바꿀 때 이것은 주요한 문제이다.
동기화된 후에 보시다시피 데이터베이스와 캐시의 내용은 최신 것입니다.이 점에서 말하자면, 이 항목은 최신이며, 다른 창작 동작이 발생할 때까지 시종 최신일 것이다.

마지막 한마디

자, 이제 활성 캐시 부분을 끝냅니다.
우선, 당신의 이전 문장에 대한 피드백에 감사드립니다!분명히 이름이 잘 알려지지 않아서 나는 이곳에서 좀 갱신했다.나도 이 기회를 빌려 도표를 복습했다. 그러면 그것들이 너의 눈에서 피를 흘리지 않을 것이다.적어도 그렇게 많지 않다.
피드백을 계속하십시오.❤
다음까지!
1 . 특히 사용자는 읽기 지연보다 쓰기 지연을 더 용인한다.불행하게도, 나는 이 데이터가 어디에서 왔는지 기억하지 못하기 때문에, 나는 이 데이터의 진실한 지표를 나타낼 수 없다.이것을 소금과 함께 먹어라.
2 . 이 문제들은 모두 통상적으로 말하는'최종 일치성'과 관련이 있는데, 이것이 바로 내가 행동 생명주기의 마지막 단계에서'최종'이라는 단어를 사용하는 이유이다.이 주제는 충분히 커서 단독적인 문장이 될 만하지만, 너는 정말 무슨 일이 일어났는지 알고 싶다.