#caching
글
-
Gradle 소스 파헤치기 11: 빌드 캐시와 설정 캐시 — 결과를 다시 쓰는 두 가지 방법
콘솔의 FROM-CACHE와 Reusing configuration cache.는 소스의 어디서 나올까요. 실행 엔진의 스텝 사슬에 끼어 있는 ResolveMutableCachingStateStep과 BuildCacheStep, MD5로 만드는 캐시 키에 무엇이 들어가는지, @CacheableTask와 캐시하지 않는 이유 목록, 키가 파일 이름이 되는 로컬 디렉터리 캐시와 tar.gz 항목, 그리고 작업 그래프를 통째로 직렬화했다가 첫 빌드에서조차 다시 읽어 실행하는 설정 캐시, 환경 변수 읽기를 바이트코드에서 가로채는 핑거프린트와 문제 보고서까지 기준 커밋의 소스와 도커 예제로 확인합니다.
-
Gradle 소스 파헤치기 12: 의존성 해석 — implementation 한 줄이 jar 파일이 되기까지, 그리고 연재를 마치며
build.gradle.kts의 implementation 한 줄은 소스에서 무엇이 될까요. 생성된 접근자가 부르는 DependencyHandler.add(), 선언·해석·소비로 역할이 나뉜 구성(configuration), 파일 목록을 달라고 할 때까지 미뤄지는 해석, DependencyGraphBuilder가 그래프를 넓혀 가는 반복문, 같은 라이브러리의 두 버전이 부딪칠 때 높은 쪽을 고르는 LatestModuleConflictResolver와 strictly·force가 그 결과를 바꾸는 자리, 캐시를 먼저 보고 저장소로 가는 두 번의 탐색과 --offline·읽기 전용 캐시까지 기준 커밋의 소스와 도커 예제로 확인하고, 12편 연재를 정리합니다.
-
Kafka 소스 파헤치기 7: 로그 저장소 — 세그먼트, 인덱스, 보존과 압축
파티션 폴더의 00000000000000003830.log 같은 파일이 언제 새로 생기고, 오프셋 하나를 파일의 바이트 위치로 어떻게 바꾸고, retention.ms 가 지난 세그먼트를 누가 언제 지우고, cleanup.policy=compact 가 같은 키의 옛 값을 어떻게 걷어 내는지 UnifiedLog·LocalLog·LogSegment·OffsetIndex·LogCleaner 소스로 따라갑니다. 세그먼트 롤의 다섯 조건, 4KB마다 한 항목만 적는 희소 인덱스와 mmap, .deleted 로 이름을 바꾼 뒤 지우는 두 단계, 키의 MD5로 만드는 SkimpyOffsetMap, 브로커가 죽었다 살아날 때의 복구 지점을 예제로 확인합니다.
-
MariaDB 소스 파헤치기 5: 프로토콜과 명령 처리 — 패킷 하나가 dispatch_command에 닿기까지
클라이언트가 보낸 바이트가 어떻게 패킷이 되고, 첫 바이트 하나로 COM_QUERY·COM_PING·COM_STMT_EXECUTE가 갈리고, 결과가 다시 패킷이 되어 나가는지를 sql/net_serv.cc, sql_parse.cc의 do_command()·dispatch_command(), protocol.cc로 따라갑니다. bash의 /dev/tcp로 클라이언트 라이브러리 없이 서버와 직접 말을 주고받고, 쿼리 캐시가 왜 파싱보다 먼저 문자열로 찾는지도 실행해서 확인합니다.
-
MariaDB 소스 파헤치기 7: 준비 단계 — 권한 확인, 테이블 열기, 이름 찾기
파서가 만든 LEX를 받은 서버가 실행 계획을 세우기 전에 하는 세 가지 일을 소스로 따라갑니다. mysql_execute_command()의 큰 switch에서 check_table_access()로 권한을 보고, open_and_lock_tables()로 메타데이터 잠금을 얻고 TABLE_SHARE와 TABLE을 캐시에서 꺼내고, JOIN::prepare()에서 열 이름을 Field에 잇습니다. 열 권한 오류 1142·1143, Opened_tables와 Table_open_cache_hits의 변화, ALTER TABLE이 열린 트랜잭션 뒤에서 기다리고 그 뒤 SELECT까지 줄을 서는 모습, 1054·1052 오류가 나는 호출 스택을 직접 확인합니다.
-
MariaDB 소스 파헤치기 10: InnoDB 1 — 페이지, 버퍼 풀, B-트리
handler 아래로 내려가 InnoDB가 데이터를 담는 세 가지 그릇을 소스로 읽습니다. 16KB 페이지의 FIL 헤더·페이지 헤더·레코드·페이지 디렉터리, 페이지를 메모리에 붙잡아 두는 버퍼 풀(buf_page_get_gen, LRU의 old 구역, 더티 페이지와 page cleaner), 테이블 그 자체인 클러스터드 인덱스 B-트리(search_leaf, 페이지 분할), 그리고 페이지 잠금과 redo를 묶는 미니 트랜잭션 mtr_t입니다. .ibd 파일을 od로 열어 페이지 머리를 읽고, information_schema로 버퍼 풀 안을 보고, 행을 늘려 B-트리 높이와 분할을 세고, gdb로 SELECT·INSERT가 B-트리에 닿는 길을 확인합니다.
-
Spring 소스 파헤치기 27: 캐시, 스케줄링, 검증, 리질리언스 — 컨테이너 위에 얹힌 기능들
@Cacheable, @Scheduled, @Async, @Validated, @Retryable은 따로 만든 기능처럼 보이지만 속은 같은 틀을 되풀이합니다. 스위치 어노테이션이 무엇을 등록하고, 어느 후처리기가 빈을 감싸고, 어느 인터셉터가 호출을 가로채는지를 Spring을 처음 보는 사람 기준으로 소스에서 확인하고, 연재 전체를 정리합니다.