프로그래밍에서 캐시 사용

캐싱은 시스템 성능을 최적화하는 가장 일반적인 방법 중 하나입니다. 시간이 많이 걸리는 구성 요소(예: 데이터베이스)보다 먼저 캐시를 추가하면 실제 호출 수와 응답 시간을 줄일 수 있습니다. 그러나 캐싱을 도입하기 전에 다시 한번 생각해 보십시오.

인터넷을 통해 자원을 얻는 것은 느리고 비용이 많이 듭니다. 이를 위해 HTTP 프로토콜에는 HTTP 클라이언트가 이전에 획득한 리소스를 캐시하고 재사용할 수 있도록 캐시 제어 부분이 포함되어 있어 성능을 최적화하고 경험을 향상시킵니다. HTTP의 캐시 제어 부분은 프로토콜이 발전함에 따라 약간의 변경이 있습니다. 하지만 백엔드 프로그래머로서 웹 서비스를 개발할 때 요청 헤더 If-None-Match, 응답 헤더 ETag, 응답 헤더 Cache-Control에만 주의하면 된다고 생각합니다. 이 세 가지 HTTP 헤더는 사용자의 요구를 충족할 수 있고 오늘날 대부분의 브라우저는 이 세 가지 HTTP 헤더를 지원하기 때문입니다. 우리가 해야 할 일은 각 서버 응답이 브라우저에 응답을 캐시할 수 있는 시기와 기간을 지시하는 올바른 HTTP 헤더 지시문을 제공하는지 확인하는 것입니다.

캐시는 어디에 있나요?

위 그림에는 브라우저, 웹 프록시, 서버의 세 가지 역할이 있습니다. 그림과 같이 브라우저와 웹 프록시에는 HTTP 캐시가 존재합니다. 물론 서버 내부에도 다양한 캐시가 있지만 이는 더 이상 이 글에서 논의할 HTTP 캐시가 아닙니다. 소위 Http 캐시 제어란 서로 다른 응답 헤더 Cache-Control을 설정하여 브라우저와 웹 프록시의 캐시 사용 전략을 제어하고, 요청 헤더 If-None-Match와 응답 헤더 ETag를 설정하여 캐시를 제어하는 ​​계약입니다. .효과를 검증합니다.

응답 헤더 ETag

ETag의 전체 이름은 Entity Tag이며 리소스를 식별하는 데 사용됩니다. 특정 구현에서 ETag는 리소스의 해시 값이거나 내부적으로 유지 관리되는 버전 번호일 수 있습니다. 그러나 무슨 일이 있어도 ETag는 Http 캐싱이 제대로 작동하기 위한 기초가 되는 리소스 콘텐츠의 변경 사항을 반영할 수 있어야 합니다.

위의 예에서 볼 수 있듯이 서버가 응답을 반환할 때 일반적으로 Http 헤더에 응답에 대한 일부 메타데이터 정보가 포함되며, 그 중 하나가 ETag입니다. 이 예에서는 값이 x1323ddx인 ETag가 반환됩니다. 리소스/파일의 내용이 변경되면 서버는 다른 ETag를 반환해야 합니다.

요청 헤더 If-None-Match

이전 예의 /file과 같은 동일한 리소스에 대해 요청한 후 브라우저에는 이미 /file 콘텐츠 버전이 있으며, 이 버전의 ETag. 다음에 사용자가 이 리소스를 필요로 하고 브라우저가 서버에 다시 요청하면 요청 헤더 If-None-Match를 사용하여 서버에 x1323ddx의 ETag가 있는 /file이 이미 있음을 알릴 수 있습니다. , 서버의 /file이 변경되지 않은 경우, 즉 서버의 /file의 ETag도 x1323ddx인 경우 서버는 /file의 내용을 반환하지 않고 304 응답을 반환하여 브라우저에 알립니다. 리소스가 변경되지 않았으므로 캐시가 유효합니다.

위의 예에서 볼 수 있듯이 If-None-Match를 사용한 후 서버는 작은 응답만 있어도 동일한 결과를 얻을 수 있으므로 성능이 최적화됩니다.

응답 헤더 Cache-Control

각 리소스는 응답을 캐시할 수 있는 사람과 기간을 제어하는 ​​Http 헤더 Cache-Control을 통해 자체 캐싱 전략을 정의할 수 있습니다. 가장 빠른 요청은 서버와 통신할 필요가 없는 요청입니다. 응답의 로컬 복사본을 사용하면 모든 네트워크 대기 시간과 데이터 전송에 따른 데이터 비용을 피할 수 있습니다. 이를 위해 HTTP 사양을 사용하면 서버는 브라우저나 기타 릴레이 캐시가 응답을 캐시하는 방법과 기간을 제어하는 ​​일련의 다양한 Cache-Control 지시어를 반환할 수 있습니다.

Cache-Control 헤더는 HTTP/1.1 사양에 정의되어 이전에 응답 캐싱 정책(예: Expires)을 정의하는 데 사용된 헤더를 대체합니다. 현재 모든 브라우저는 Cache-Control을 지원하므로 이를 사용하는 것으로 충분합니다.

Cache-Control에서 설정할 수 있는 공통 명령어를 소개하겠습니다.

max-age

이 지시어는 현재 요청부터 얻은 응답을 재사용할 수 있는 최대 시간(초)을 지정합니다(예: Cache-Control:max-age). =60은 응답을 캐시하고 60초 동안 다시 사용할 수 있음을 의미합니다. max-age에 지정된 시간 내에 브라우저는 캐시가 유효한지 확인하는 요청을 포함하여 서버에 어떤 요청도 보내지 않습니다. 즉, 이 기간 내에 서버의 리소스가 변경되면 브라우저에 알리지 않고 이전 버전의 리소스를 사용하게 되므로 캐시 시간 길이를 설정할 때 주의가 필요합니다.

공개 및 비공개

공개가 설정되면 응답이 브라우저 또는 릴레이된 웹 프록시에 캐시될 수 있음을 의미합니다. 공개가 기본값, 즉 Cache-Control입니다. :max-age=60은 Cache-Control:public, max -age=60과 동일합니다.

Cache-Control: private, max-age=60과 같이 서버가 비공개로 설정된 경우 이는 다음을 의미합니다. 사용자의 브라우저만 개인 응답을 캐시할 수 있으며 릴레이 웹 프록시는 캐시할 수 없습니다. – 예를 들어 사용자의 브라우저는 사용자의 개인 정보가 포함된 HTML 페이지를 캐시할 수 있지만 서버가 no-를 설정하면 CDN은 이를 캐시할 수 없습니다. 즉, Cache-Control: no-cache인 경우 브라우저는 캐시된 리소스를 사용하기 전에 반환된 응답이 변경되었는지 먼저 서버에 확인해야 합니다. 이렇게 하면 다운로드를 피할 수 있습니다. 이는 위에서 소개한 요청 헤더 If-None-match와 응답 헤더 ETag를 통해 달성됩니다.

no-cache라는 이름이 약간 오해의 소지가 있다는 의미는 아닙니다. no-cache를 설정한 후 브라우저는 더 이상 데이터를 캐시하지 않지만, 캐시된 데이터를 사용할 때 브라우저는 먼저 데이터가 여전히 서버와 일치하는지 확인해야 하며 ETag 구현이 반영되지 않습니다. 리소스가 변경되면 브라우저의 캐시된 데이터가 업데이트되지 않습니다.

no-store

서버가 no-store, 즉 Cache-Control: no를 설정하면 -응답에 저장한 다음 검색합니다. 이번에는 서버와 릴레이된 웹 프록시가 해당 데이터를 저장하지 않습니다. 다음에 리소스가 요청되면 브라우저는 서버에 다시 요청하고 서버에서 리소스를 다시 읽을 수만 있습니다. .

리소스를 결정하는 방법.

다음 흐름도가 도움이 될 수 있습니다.

일반적인 오류

시작 시 캐싱

가끔 애플리케이션이 매우 느리게 시작되는 것을 볼 수 있습니다. 결국 종속 서비스 중 하나가 응답하는 데 오랜 시간이 걸리는 것으로 나타났습니다. 어떻게 해야 합니까?

일반적으로 이런 종류의 문제가 발생하면 종속 서비스가 수요를 충족할 수 없다는 의미입니다. 이것이 제3자 서비스이고 통제권이 우리 손에 있지 않은 경우, 우리는 이때 캐싱을 도입할 수 있습니다.

이번에 캐싱을 도입할 때의 문제점은 캐시 무효화 전략을 적용하기 어렵다는 것입니다. 캐시 설계의 원래 의도는 가능한 한 적은 수의 종속 서비스를 요청하는 것이기 때문입니다.

조기 캐싱

여기서 언급된 '초기'는 애플리케이션의 수명 주기가 아니라 개발 주기입니다. 때로는 일부 개발자가 시스템 병목 현상을 추정하고 개발 초기 단계에서 캐싱을 도입하는 것을 볼 수 있습니다.

사실 이 접근 방식은 가능한 성능 최적화 지점을 가립니다. 어쨌든, 이 서비스의 반환 값은 그때까지 캐시될 것입니다. 왜 코드의 이 부분을 최적화하는 데 시간을 소비해야 합니까?

통합 캐싱

SOLID 원칙의 "S"는 단일 책임 원칙을 의미합니다. 애플리케이션이 캐시 모듈을 통합하면 캐시 모듈과 서비스 계층이 강력하게 결합되어 캐시 모듈의 참여 없이는 독립적으로 실행할 수 없습니다.

모든 콘텐츠 캐시

가끔 응답 지연을 줄이기 위해 무작정 외부 통화에 캐싱을 추가할 수도 있습니다. 실제로 이러한 동작은 개발자와 유지관리자가 캐시 모듈의 존재를 인식하는 것을 쉽게 방해할 수 있으며 궁극적으로 기본 종속 모듈의 신뢰성을 잘못 평가할 수 있습니다.

계단식 캐싱

모든 내용 또는 대부분의 콘텐츠를 캐싱하면 다른 캐시된 데이터가 포함된 캐시된 데이터가 생성될 수 있습니다.

애플리케이션에 이러한 계단식 캐시 구조가 포함되어 있으면 캐시 만료 시간을 제어할 수 없는 상황이 발생할 수 있습니다. 최상위 캐시는 최종 반환 데이터가 완전히 업데이트되기 전에 각 캐시 수준이 무효화되고 업데이트될 때까지 기다려야 합니다.

캐시를 새로 고칠 수 없습니다

일반적으로 캐시 미들웨어는 캐시를 새로 고치는 도구를 제공합니다. 예를 들어 Redis를 사용하면 관리자는 제공되는 도구를 통해 일부 데이터를 삭제하거나 전체 캐시를 새로 고칠 수도 있습니다.

그러나 일부 임시 캐시에는 이러한 도구가 포함되어 있지 않을 수 있습니다. 예를 들어 단순히 콘텐츠 내에 데이터를 저장하는 캐시는 일반적으로 외부 도구가 캐시된 콘텐츠를 수정하거나 삭제하는 것을 허용하지 않습니다. 이때, 비정상적인 캐시 데이터가 발견되면 유지보수 담당자는 서비스를 다시 시작해야만 하므로 운영 및 유지관리 비용과 응답 시간이 크게 증가하게 됩니다. 게다가 일부 캐시는 백업을 위해 캐시 내용을 파일 시스템에 쓸 수도 있습니다. 이때 서비스를 다시 시작하는 것 외에도 애플리케이션이 시작되기 전에 파일 시스템의 캐시 백업이 삭제되었는지도 확인해야 합니다.

캐싱의 영향

위에서 언급한 캐싱 도입으로 인해 발생할 수 있는 일반적인 오류는 캐시 없는 시스템에서는 고려되지 않습니다.

캐시에 크게 의존하는 시스템을 배포하면 캐시가 만료될 때까지 기다리는 데 많은 시간이 소요될 수 있습니다. 예를 들어 CDN을 통해 콘텐츠를 캐시하는 경우 시스템이 릴리스된 후 CDN 구성 및 CDN에서 캐시된 콘텐츠를 새로 고치는 데 몇 시간이 걸릴 수 있습니다.

또한 성능 병목 현상이 발생할 때 캐시를 우선순위로 지정하면 성능 문제가 가려지고 제대로 해결되지 않을 수 있습니다. 실제로 코드를 튜닝하는 데 소요되는 시간은 캐싱 구성 요소를 도입하는 것과 크게 다르지 않습니다.

마지막으로 캐싱 구성 요소가 포함된 시스템의 경우 디버깅 비용이 크게 증가합니다. 코드가 반나절 동안 추적되고 결과 데이터가 캐시에서 나오며 실제 논리가 의존해야 하는 구성 요소와 아무 관련이 없는 경우가 종종 있습니다. 관련 테스트 케이스를 모두 실행한 후에도 동일한 문제가 발생할 수 있지만 수정된 코드는 실제로 테스트되지 않았습니다.

캐시를 잘 활용하는 방법은?

캐싱을 폐기하세요!

캐싱은 불가피한 경우가 많습니다. 인터넷 기반 시스템에서는 캐시 사용을 완전히 피하기가 어렵습니다. http 프로토콜 헤더에도 캐시 구성(Cache-Control: max-age=xxx)이 포함되어 있습니다.

데이터 이해

데이터를 캐시하려면 먼저 데이터 업데이트 전략을 이해해야 합니다. 데이터를 업데이트해야 하는 시기를 명확하게 이해해야만 If-Modified-Since 헤더를 사용하여 클라이언트가 요청한 데이터를 업데이트해야 하는지 여부를 결정할 수 있습니다. 간단히 304 Not Modified 응답을 반환하고 클라이언트가 이를 재사용하도록 해야 합니다. 이전 로컬 캐시 데이터입니까, 아니면 최신 데이터를 반환해야 합니까? 또한, http 프로토콜에서 캐시를 더 잘 활용하기 위해서는 데이터의 버전을 구별하거나 eTag를 사용하여 캐시된 데이터의 버전을 표시하는 것이 좋습니다.

캐싱을 사용하는 대신 성능 최적화

앞서 언급했듯이 캐싱을 사용하면 잠재적인 성능 문제가 가려지는 경우가 많습니다. 가능할 때마다 성능 분석 도구를 사용하여 애플리케이션의 느린 응답의 실제 원인을 찾아 수정하십시오. 예를 들어 잘못된 코드 호출을 줄이고 SQL 실행 계획에 따라 SQL을 최적화하는 등의 작업을 수행합니다.

다음은 애플리케이션의 모든 캐시를 지우는 코드입니다

/* 
 * 文 件 名:  DataCleanManager.java 
 * 描   述:  主要功能有清除内/外缓存，清除数据库，清除sharedPreference，清除files和清除自定义目录 
 */  
package com.test.DataClean;  
  
import java.io.File;  
  
import android.content.Context;  
import android.os.Environment;  
  
/** 
 * 本应用数据清除管理器 
 */  
public class DataCleanManager {  
    /** 
     * 清除本应用内部缓存(/data/data/com.xxx.xxx/cache) 
     *  
     * @param context 
     */  
    public static void cleanInternalCache(Context context) {  
        deleteFilesByDirectory(context.getCacheDir());  
    }  
  
    /** 
     * 清除本应用所有数据库(/data/data/com.xxx.xxx/databases) 
     *  
     * @param context 
     */  
    public static void cleanDatabases(Context context) {  
        deleteFilesByDirectory(new File("/data/data/"  
                + context.getPackageName() + "/databases"));  
    }  
  
    /** 
     * 清除本应用SharedPreference(/data/data/com.xxx.xxx/shared_prefs) 
     *  
     * @param context 
     */  
    public static void cleanSharedPreference(Context context) {  
        deleteFilesByDirectory(new File("/data/data/"  
                + context.getPackageName() + "/shared_prefs"));  
    }  
  
    /** 
     * 按名字清除本应用数据库 
     *  
     * @param context 
     * @param dbName 
     */  
    public static void cleanDatabaseByName(Context context, String dbName) {  
        context.deleteDatabase(dbName);  
    }  
  
    /** 
     * 清除/data/data/com.xxx.xxx/files下的内容 
     *  
     * @param context 
     */  
    public static void cleanFiles(Context context) {  
        deleteFilesByDirectory(context.getFilesDir());  
    }  
  
    /** 
     * 清除外部cache下的内容(/mnt/sdcard/android/data/com.xxx.xxx/cache) 
     *  
     * @param context 
     */  
    public static void cleanExternalCache(Context context) {  
        if (Environment.getExternalStorageState().equals(  
                Environment.MEDIA_MOUNTED)) {  
            deleteFilesByDirectory(context.getExternalCacheDir());  
        }  
    }  
  
    /** 
     * 清除自定义路径下的文件，使用需小心，请不要误删。而且只支持目录下的文件删除 
     *  
     * @param filePath 
     */  
    public static void cleanCustomCache(String filePath) {  
        deleteFilesByDirectory(new File(filePath));  
    }  
  
    /** 
     * 清除本应用所有的数据 
     *  
     * @param context 
     * @param filepath 
     */  
    public static void cleanApplicationData(Context context, String... filepath) {  
        cleanInternalCache(context);  
        cleanExternalCache(context);  
        cleanDatabases(context);  
        cleanSharedPreference(context);  
        cleanFiles(context);  
        for (String filePath : filepath) {  
            cleanCustomCache(filePath);  
        }  
    }  
  
    /** 
     * 删除方法 这里只会删除某个文件夹下的文件，如果传入的directory是个文件，将不做处理 
     *  
     * @param directory 
     */  
    private static void deleteFilesByDirectory(File directory) {  
        if (directory != null && directory.exists() && directory.isDirectory()) {  
            for (File item : directory.listFiles()) {  
                item.delete();  
            }  
        }  
    }  
}

요약

캐싱은 매우 유용한 도구이지만 쉽게 남용될 수 있습니다. 마지막 순간까지 캐싱을 사용하지 말고 애플리케이션 성능을 최적화하기 위한 다른 방법에 우선순위를 두십시오.