memcache proxy 의 memagent 소개 분석

1. 각 memcache server 와 여러 개의 긴 연결 을 유지 합 니 다. 효 과 는 memcache server 가 유지 하 는 연결 수량 을 줄 이 고 연결 을 없 애 는 비용 을 만 드 는 것 입 니 다.그러나 memcache 자체 가 동시 접속 을 지원 하 는데 이 기능 은 별 다른 말 이 없다.
2. memcache 를 지원 하 는 binary 프로 토 콜 명령 으로 요청 한 퍼 가기 를 실현 합 니 다.
3. memcache 와 마찬가지 로 libevent 의 이벤트 구동 을 바탕 으로 IO 를 처리 합 니 다.
4. ketama 의 일치 성 hash 알고리즘 을 지원 합 니 다.
5. memcache backup 클 러 스 터 를 지원 합 니 다. memcache 클 러 스 터 에 기계 가 끊 기 면 memagent 는 get 요청 을 memcache backup 클 러 스 터 로 전환 합 니 다.이 기능 은 cache 의 안정성 에 대한 요구 가 높 은 장면 에서 유용 할 것 이다.
제 공 된 기능 으로 볼 때 memagent 는 매우 간단 한 것 이다.비교적 큰 memcache 군집 에 대해 서 는 memagent 를 proxy 로 사용 하 는 것 을 고려 할 수 있다.
실현 분석
1. memagent 버 전 은 0.5 입 니 다.일치 성 hash 알고리즘 ketama 의 코드 를 제외 하고 memagent 의 코드 는 모두 magent. c 파일 에 있 으 며 코드 총 줄 수 는 2000 여 줄 입 니 다.하룻밤 만 꺼 내 면 이 코드 를 거의 다 르 지 않 게 분석 할 수 있다.
2. memagent 는 memcache 처럼 libevent 를 사용 하여 상태 와 처 리 를 구동 합 니 다.Libevent 는 이벤트 구동 에 적합 한 장면 이다.memagent 와 같이 client 엔 드 의 요청 에 대해 client 엔 드 의 네트워크 IO 를 처리 해 야 할 뿐만 아니 라 server 엔 드 의 네트워크 IO 도 처리 해 야 합 니 다. back server 의 네트워크 IO 를 처리 할 수도 있 습 니 다. 한 절차 에서 6, 7 번 에 달 하 는 네트워크 IO 사건 이 발생 했 습 니 다.
3. memagent 는 단일 프로 세 스 단일 스 레 드 프로그램 입 니 다. 주로 요청 을 받 아들 이 고 요청 을 조금 분석 한 후에 퍼 가기 요청 을 하 는 것 이기 때문에 논리 적 으로 비교적 간단 합 니 다. 가장 많은 것 은 메모리 복사 작업 입 니 다. 단일 프로 세 스 단일 스 레 드 를 사용 하면 충분 합 니 다.
4. memagent 의 이벤트 리 셋 함 수 는 각각 serveraccept、drive_client、 drive_memcached_server、drive_backup_server。이 4 개의 반전 함수 의 기능 도 매우 뚜렷 하 다. driveclient、 drive_memcached_server 와 drivebackup_server 도 읽 기와 쓰기 처리 의 상태 기 체제 와 관련 되 는데 이 부분 코드 는 프로 토 콜 분석 과 IO 처리 와 관련 되 고 코드 디 테 일 도 복잡 합 니 다.기본 적 인 과정 은:
1) memagent 는 client 단의 데이터 (주로 명령 형식 과 key) 를 분석 하여 매 핑 된 memcache server 에 데 이 터 를 보 냅 니 다. memcache server 가 연결 되 지 않 으 면 memagent 는 backup 클 러 스 터 (설정 하면) 에 데 이 터 를 보 냅 니 다.
2) memcache server 에서 돌아 온 데 이 터 를 얻 은 후에 memagent 는 분석 해 야 합 니 다. 만약 에 이 시간 에 memcache server 가 돌아 오 는 데 실패 하면 memagent 는 backup 클 러 스 터 에 데 이 터 를 요청 할 것 입 니 다.
3) 마지막 으로 memagent 는 데 이 터 를 client 에 되 돌려 줍 니 다.
5. backup 클 러 스 터 에 대해 설정 하면 memagent 는 제출 할 때마다 backup 클 러 스 터 에 보 냅 니 다.get 의 한 memcache server 가 실 패 했 을 때 backup 클 러 스 터 에 다시 요청 합 니 다.
6. gets 명령 에 대해 memagent 는 대량의 key 에 대해 단독으로 memcache server 와 상호작용 을 합 니 다.이것 은 최적화 할 수 있다 고 생각 합 니 다. 같은 memcache server 에 비 친 key 를 합 쳐 server 로 보 내 는 요청 에서 대량으로 처리 할 수 있 습 니 다.
7. client 데 이 터 를 읽 든 server 엔 드 데 이 터 를 읽 든 memagent 는 이 요청 에 몇 바이트 의 데이터 가 있 는 지 모 르 기 때문에 읽 을 때 먼저 ioctl (fd, FIONREAD, & toread) 함수 로 IO buffer 에서 받 은 네트워크 바이트 데 이 터 를 계산 한 다음 에 받 은 데 이 터 를 분석 하여 계속 read 해 야 하 는 지 확인 합 니 다.이 기 교 는 데이터 포두 의 크기 를 모 르 는 상황 에서 사용 하 는 수단 이다.
8. 실현 되 는 작은 세부 사항 을 다시 말 합 니 다.이벤트 에 대하 여set 의 리 셋 함수 원형 은 사용 하지 않 는 매개 변수 에 대해 매크로 \ # define UNUSED (x) (void) (x)) 를 호출 하여 gcc 가 열 렸 을 때의 오 류 를 해결 할 수 있 습 니 다. 저 는 전에 \ # pragma 를 사용 해도 된다 는 글 을 보 았 지만 성공 하지 못 했 습 니 다.
일치 성 hash 알고리즘
memcache 클 라 이언 트 가 Cache key 가 어떤 memcache server 에 매 핑 되 는 지 에 대한 선택 알고리즘 에 대해 가장 간단 한 것 은 key 에 따라 계 산 된 hash 값 으로 count (memcache server) 의 나머지 를 취 하 는 것 입 니 다.작은 memcache 클 러 스 터 나 cache 클 러 스 터 를 전체적으로 끊 으 면 서비스 에 심각 한 영향 을 미 치지 않 을 경우 이러한 매 핑 방법 은 간단 하고 실 용적 입 니 다.
물론 더 좋 은 선택 은 일치 성 hash 알고리즘 입 니 다.이 알고리즘 의 효 과 는 memcache 노드 를 줄 이거 나 추가 하 는 것 으로 전체 군집 의 1 / n 데이터 에 만 영향 을 줄 수 있 습 니 다.실현 방법 에는 주로 두 가지 가 있다.
1. memcache 물리 노드 를 정수 범위 로 구 성 된 hash 링 에 고 르 게 분포 한다.하나의 노드 를 추가 할 때 이 노드 를 링 의 두 노드 사이 에 삽입 할 수 있 습 니 다. 그러면 1 / 2n 의 데이터 만 효력 을 잃 지만 hash 링 을 불 균형 하 게 만 들 수 있 습 니 다.다른 방법 은 memcache 노드 가 hash 링 의 위치 에 다시 분포 하면 모든 노드 의 데이터 가 약간 부족 하지만 부족 한 총 화 는 한 노드 의 데이터 범위 이다.
2. 가상 노드 의 사상 을 도입 하여 하나의 memcache 물리 노드 를 hash 링 에 있 는 여러 개의 가상 노드 에 분산 시 키 면 균형 적 인 방법 효과 가 더욱 좋 을 것 이다.물론 찾 는 알고리즘 복잡 도 는 O (1) 에서 log (N) 로 높 아 졌 다.Ketama 알고리즘 은 이 사상 을 실현 하 는 첫 번 째 이자 많은 실현 을 사용 할 수 있 습 니 다.
[url]http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients [/url]
이 알고리즘 의 다 중 언어 버 전 을 얻어 실현 하 다.
Memagent 가 사용 하 는 일치 성 hash 알고리즘 은 Ketama 이지 만 Memagent 는 코드 에 대해 간략하게 수정 했다.Ketama 의 두 핵심 데이터 구 조 는:

struct dot {   
    
   unsigned int point;// unsigned int          
    
   int srvid;//memcache server id   
    
};   
    
struct ketama {   
    
   unsigned int numpoints;//    hash         
    
   struct dot *dot;//   hash          
    
   int count;//memcache server     
    
   char **name;//  memcache server       
    
   int *weight;//  memcache server  ，          
    
   int totalweight;//       
    
};  

struct dot 구 조 는 hash 링 의 가상 노드 를 나타 내 고 struct ketama 는 알고리즘 의 전체적인 데이터 구조 입 니 다.Ketama 알고리즘 과 관련 된 두 가지 함 수 는:

int create_ketama(struct ketama *ring, int step) 

Ring 은 Memagent 이전에 memcache server 클 러 스 터 정보 구조 에 따라 step 의 수 치 는 500 이 고 함수 내부 에 4 를 곱 하면 memcache server 가 hash 링 에 2000 개의 가상 노드 가 있 음 을 나타 낸다.
가상 노드 의 수치 와 대응 하 는 server id 를 계산 하 는 방법 은 다음 과 같다.

for (i = 0; i < ring->count; i ++) {   
    pct = (float) ring->weight[i] / (float) ring->totalweight;   
    ks = (int) floorf(pct * step *(float) ring->count); /* divide by 4 for 4 part */  
    for (k = 0; k < ks; k ++) {   
        snprintf(temp, 255, "%s-%d", ring->name[i], k);   
        ketama_md5_digest(temp, digest);   
        for (h = 0; h < 4; h ++) {   
                dot[cont].point = ( digest[3+h*4] << 24 ) | ( digest[2+h*4] << 16 )   
                        | ( digest[1+h*4] <<  8 ) | digest[h*4];   
                dot[cont].srvid = i;   
                cont ++;   
        }   
    }   
}  

마지막 으로 얻 은 dot 목록 을 point 크기 에 따라 정렬 하여 getserver 의 2 분 찾기.
클립보드 인쇄 에 원본 복사?
int get_server(struct ketama *, const char *); 
int get_server(struct ketama *, const char *);이 함 수 는 키 에 따라 struct ketama 구조 에서 대응 하 는 memcache server index 를 찾 습 니 다.Cache key 의 hash 값 계산 은 16 비트 md5 알고리즘 을 사용 합 니 다.key 의 hash 값 에 따라 hash 링 에 해당 하 는 위 치 를 찾 습 니 다. 2 분 검색 을 사용 합 니 다.
작은 매듭
간단 하고 실 용적 인 memcache proxy 만 원한 다 면 memagent 는 좋 은 선택 입 니 다.물론 memcache proxy 가 할 수 있 는 일 도 더 많 을 수 있 습 니 다. 마치 다른 memcache proxy 가 moxi (http://labs.northscale.com/moxi/) 더욱 풍부 한 기능 을 제 공 했 습 니 다. 저 는 다음 글 에서 moxi 를 계속 소개 하 겠 습 니 다.
댓 글:
http://www.kafka0102.com/2010/01/9.html