자바 면접 문제 돌진 다음 날--레 디 스 편
진지 하 게 대답 하 다.
Redis 는 현재 가장 잘 알려 진 높 은 병발 을 완화 하고 사용 가능 한 능력 을 향상 시 키 는 수단 중 하나 로 서버 의 성능 을 향상 시 키 는 데 효과 가 현저 하 다.
여기 서 높 은 동시 다발 장면 을 언급 할 수 밖 에 없다.우 리 는 동시 다발 장면 에서 핵심 점 이 데이터 베이스 에 있 고 캐 시(그리고 모든 부하 균형,클 러 스 터 등 전략 도입)를 도입 하 는 목적 은 데이터 베이스 의 압력 을 줄 이 고 DB 에 걸 려 있 던 요청 을 더 많이 하 며 중간 에 차단 되 어 처리 하 는 것 임 을 알 고 있다.니 가 가짜 라 도 내 고 큰 사장 님 이 사인 하 는 것 처럼?
쉽게 말 하면 높 은 병발 은 서버 에 있어 서 마치 당신 이 한 대 맞 은 것 과 같 습 니 다.이 주먹 은 매우 단단 합 니 다.웃 통 을 벗 으 면 한 대 에 피 를 토 합 니 다.그럼 내 가 이 주먹 을 견 디 기 위해 서?솜옷 을 입고,보호 대 를 입고,입고...그 렇 죠?두 껍 기만 하면 간 지 러 움 을 긁 어 주 는 줄 알았어 요.마찬가지 로 레 디 스 는 두 껍 고 튕 기 는 솜옷 이에 요.
그 나 저 나 얼마나 두 껍 고 많이 치 나 요?캐 시 를 조작 하 는 것 은 바로 메모 리 를 직접 조작 하 는 것 으로 속도 가 상당히 빠 르 고 캐 시 를 직접 조작 하면 감당 할 수 있 는 요청 수 는 데이터 베 이 스 를 직접 방문 하 는 것 보다 훨씬 크다.
Redis 우세:
저희 업무 에 서 는 핫 이 슈 어 조회,실시 간 차 트 데이터,방 문 량 좋아요 통계,Session 공유 등 을 모두 Redis 를 도입 하여 처리 할 수 있 습 니 다.
깊이 추궁:1:Redis 에는 어떤 데이터 형식 이 있 습 니까?
풍부 한 데이터 형식,Redis 는 8 가지 데이터 형식 이 있 습 니 다.물론 String,Hash,List,Set,Sort Set 등 5 가지 유형 을 자주 사용 합 니 다.그들 은 모두 키 값 을 바탕 으로 데 이 터 를 구성 합 니 다.모든 데이터 형식 은 매우 풍부 한 조작 명령 을 제공 하여 대부분의 수 요 를 만족 시 킬 수 있 습 니 다.특별한 수요 가 있 으 면 lua 스 크 립 트 를 통 해 스스로 새로운 명령 을 만 들 수 있 습 니 다(원자 성 을 갖 추고 있 습 니 다).
2:Redis 와 Memcached 는 어떤 차이 가 있 습 니까?
둘 다
인 데 지금 회 사 는 보통 Redis 로 캐 시 를 실현 하 는데 왜 Memcached 를 사용 하지 않 습 니까?매개 변수
Redis
Memcached
유형
1.메모리 지원 2.비 관계 형 데이터베이스
1.메모리 지원 2.키 쌍 형식 3.캐 시 형식
데이터 저장 형식
1. String 2. List 3. Set 4. Hash 5. Sort Set
1.텍스트 형 2.바 이 너 리 형식
추가 기능
1.게시/구독 모드 2.마스터 파 티 션 3.직렬 화 지원 4.스 크 립 트 지원[Lua 스 크 립 트]
다 중 스 레 드 서비스 지원
네트워크 IO 모델
단일 스 레 드 의 다 중 IO 재 활용 모델
다 중 스 레 드,비 차단 IO 모드
지구 화 지원
1. RDB 2. AOF
지지 하지 않 음
군집 모드
원생 지원 cluster 모드,주종 복사,읽 기와 쓰기 분리 가능
네 이 티 브 클 러 스 터 모드 가 없 으 면 클 라 이언 트 에 의 해 클 라 이언 트 에 나 누 어 데 이 터 를 기록 해 야 합 니 다.
메모리 관리 메커니즘
Redis 에 서 는 모든 데이터 가 메모리 에 저장 되 어 있 는 것 이 아니 라 오랫동안 사용 하지 않 았 던 value 를 디스크 로 교환 할 수 있 습 니 다.
Memcached 의 데 이 터 는 메모리 에 계속 있 습 니 다.Memcached 는 메모리 조각 문 제 를 완전히 해결 하기 위해 특정한 길이 의 블록 으로 나 누 어 데 이 터 를 저장 합 니 다.
적용 필드
복잡 한 데이터 구 조 는 지속 적 이 고 사용 가능 한 수요 가 높 으 며 value 저장 내용 이 비교적 크 고 최대 512 M 이다.
순수 key-value,데이터 양 이 매우 많 고 병발 량 이 매우 많은 업무
RDB （ ）AOF （ ）always 모든 쓰기 명령 이 동기 화 됩 니 다.everysec 초 에 한 번 동기 화;no 은 운영 체제 로 하여 금 언제 동기 화 할 지 결정 하 게 한다. everysec 옵션 이 적당 합 니 다.시스템 이 붕 괴 될 때 1 초 정도 의 데 이 터 를 잃 어 버 릴 수 있 고 Redis 는 1 초 에 한 번 동기 화 를 실행 하 는 것 이 서버 성능 에 거의 영향 을 주지 않 습 니 다.면접 문제 2:레 디 스 는 왜 단일 스 레 드 입 니까?
Redis is single threaded. How can I exploit multiple CPU / cores? It's not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 1 million requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU. However, to maximize CPU usage you can start multiple instances of Redis in the same box and treat them as different servers. At some point a single box may not be enough anyway, so if you want to use multiple CPUs you can start thinking of some way to shard earlier. You can find more information about using multiple Redis instances in the Partitioning page. However with Redis 4.0 we started to make Redis more threaded. For now this is limited to deleting objects in the background, and to blocking commands implemented via Redis modules. For future releases, the plan is to make Redis more and more threaded.
진지 하 게 대답 하 다.
위 는 Redis 홈 페이지 에서 보 낸 설명(공식 문서 링크)입 니 다.번역 한 후에 간단하게 말 하면
Redis CPU ， 。 에 다시 말 하면 단일 스 레 드 전환 비용 이 적 고 실현 하기 쉽 습 니 다.단일 스 레 드 가 쉽게 실현 되 고 CPU 가 병목 이 되 지 않 는 이상 단일 스 레 드 방안 을 순조롭게 사용 하 는 것 도 물론 다 중 스 레 드 에 존재 하 는 많은 구 덩이 를 피하 기 위해 서 입 니 다. ， 。깊이 추궁:추궁 1:단일 라인 은 단일 핵 CPU 만 사 용 했 습 니 다.너무 낭비 적 입 니 다.다 중 핵 CPU 의 성능 을 발휘 할 방법 이 있 습 니까?
우 리 는 한 컴퓨터 에서 여러 개의 Redis 인 스 턴 스 를 열 수 있 습 니 다.우리 가 강조 하고 있 는 단일 스 레 드 는 우리 의 네트워크 요청 을 처리 할 때 하나의 스 레 드 만 처리 할 수 있 습 니 다.실제로 정식 적 인 Redis Server 가 실 행 될 때 한 스 레 드 만 있 는 것 이 아니 라 클 러 스 터 형식 이 고 몇 개의 노드 가 있 기 때문에 실제 환경 에서 이런 문 제 를 걱정 하지 않 아 도 된다.
면접 문제 3:캐 시 관통,캐 시 뚫 기,캐 시 눈사태 에 대한 이해
진지 하 게 대답 하 다.
을 말 합 니 다.모든 요청 이 데이터베이스 에 걸 린 후에 데이터 베 이 스 를 찾 을 수 없습니다(예 를 들 어 null).데이터 베 이 스 를 짧 은 시간 에 스 레 드 수가 가득 차 서 다른 서비스 가 막 히 고 결국은 온라인 서 비 스 를 사용 할 수 없 게 됩 니 다.이런 상황 은 해커 학생 들 과 같 습 니 다. (일반적으로 핫 이 슈 데이터 캐 시 시간 이 만 료 됨)을 말 합 니 다.이때 동시 다발 사용자 가 매우 많 기 때문에 캐 시 를 읽 지 못 하고 데 이 터 를 읽 지 못 했 습 니 다.또한 데이터 베 이 스 를 찾 아 보 는 동시에 데이터 베 이 스 를 찾 아 보 는 압력 이 순간 커지 고 온라인 시스템 이 걸 립 니 다. ,캐 시 격 차 업그레이드 버 전.추궁 1:그럼 캐 시 에 대한 해결 방법 을 말씀 해 주세요.
static Lock reenLock = new ReentrantLock();
public List<String> getData04() throws InterruptedException {
List<String> result = new ArrayList<String>();
//
result = getDataFromCache();
if (result.isEmpty()) {
if (reenLock.tryLock()) {
try {
System.out.println(" , DB ");
//
result = getDataFromDB();
//
setDataToCache(result);
} finally {
reenLock.unlock();//
}
} else {
result = getDataFromCache();//
if (result.isEmpty()) {
System.out.println(" , , ");
Thread.sleep(100);//
return getData04();//
}
}
}
return result;
}
이 글 은 여기까지 입 니 다.당신 에 게 도움 을 줄 수 있 기 를 바 랍 니 다.또한 당신 이 우리 의 더 많은 내용 에 관심 을 가 져 주 실 수 있 기 를 바 랍 니 다!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
JPA + QueryDSL 계층형 댓글, 대댓글 구현(2)이번엔 전편에 이어서 계층형 댓글, 대댓글을 다시 리팩토링해볼 예정이다. 이전 게시글에서는 계층형 댓글, 대댓글을 구현은 되었지만 N+1 문제가 있었다. 이번에는 그 N+1 문제를 해결해 볼 것이다. 위의 로직은 이...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
