Memcache-Java-Client-Release 원본 읽기(5)

1. 주요 내용 본 장의 주요 내용은Memcache Client의 실효 전이 메커니즘, 회복 메커니즘과 Sock 상태 검측 메커니즘의 실현 원리를 소개하는 것이다.
2. 준비 작업 1, 서버 시작 192.168.0.106:11211192.168.0.106:11212 두 서버 실례.2. 예제 코드:

String[] servers = { "192.168.0.106:11211", "192.168.0.106:11212" };
SockIOPool pool = SockIOPool.getInstance();
pool.setServers(servers);
pool.setInitConn(10);
pool.setMinConn(5);
pool.setMaxConn(250);
pool.setSocketTO(3000);
//  
pool.setFailover(true);
pool.setFailback(true);
pool.setAliveCheck(true);
pool.setNagle(false);
pool.initialize();
//  ......

3. Failover 실효 이전 메커니즘 1. 간단하게 말하면 A가 고객에게 서비스를 제공할 수 없을 때 시스템이 자동으로 전환되어 B가 제때에 고객에게 서비스를 계속 제공할 수 있고 고객이 느끼지 못하게 한다. 이것은 그에게 서비스를 제공하는 대상이 이미 바뀌었다.2. 장면은 반드시 하나 이상의 서버 노드가 있어야 하고 SockIOPool은 실효 이전 메커니즘을 설정한다. 그 중 한 노드가 일부 원인으로 인해 캐시 서비스를 제공하지 못할 때(예를 들어 네트워크 고장, 서버 실례 다운) 이 메커니즘은 다른 사용 가능한 서비스 노드를 검색한다.
3. 소스 코드는 SchoonerSockIOPool 클래스의 getSock() 메서드에서 구현되며 관련 소스 코드는 다음과 같습니다.

// from here on, we are working w/ multiple servers
// keep trying different servers until we find one
// making sure we only try each server one time
Set<String> tryServers = new HashSet<String>(Arrays.asList(servers));
// get initial bucket
long bucket = getBucket(key, hashCode);
String server = (this.hashingAlg == CONSISTENT_HASH) ? consistentBuckets
        .get(bucket) : buckets.get((int) bucket);
while (!tryServers.isEmpty()) {
    // try to get socket from bucket
    SchoonerSockIO sock = getConnection(server);
    if (sock != null)
        return sock;

    // if we do not want to failover, then bail here
    if (!failover)
        return null;
    // log that we tried
    tryServers.remove(server);
    if (tryServers.isEmpty())
        break;
    // if we failed to get a socket from this server
    // then we try again by adding an incrementer to the
    // current key and then rehashing
    int rehashTries = 0;
    while (!tryServers.contains(server)) {
        String newKey = new StringBuffer().append(rehashTries)
                .append(key).toString();
        // String.format( "%s%s", rehashTries, key );
        bucket = getBucket(newKey, null);
        server = (this.hashingAlg == CONSISTENT_HASH) ? consistentBuckets
                .get(bucket) : buckets.get((int) bucket);
        rehashTries++;
    }
}

4. 아이디어 실현 1) 기존 키에 따라 서버의 Sock을 취한다.2) 비어 있으면 키 접두사는 처음에 0이고hash를 다시 가져와 서버를 다시 지정합니다.3) 비어 있으면 접두사가 1(점증1)이 되고 Sock을 정상적으로 가져올 수 있는 서버를 찾을 때까지 2단계를 반복합니다.원리: 키값 접두사를 이용하여 점차적으로 증가하면hash영사는 서로 다른 서버로 변화하여 사용 가능한 서버를 발견할 때까지 실효된 서버에서 사용 가능한 서버로 이동합니다.
5. 문제 사고 실효 이전 메커니즘이 실현되는 과정에서 캐시 대상의 키 값은 사실 변화가 있다. 키에서 newkey로 바뀌었다. 우리는 이런 장면을 고려한다. 두 개의 서버 실례 11211과 11212가 있다. 클라이언트가 실효 이전 메커니즘을 사용했다. 어떤 캐시 대상이 11211 노드에 비치면 11211 실례가 갑자기 다운된다. 그리고 이 캐시 대상에 대해 set 조작을 한다. 시간이 지나면 get 조작을 한다.그러나 11211 노드가 다시 시작되었습니다. 캐시 대상을 정상적으로 얻을 수 있습니까?이 작은 실험은 여러분이 스스로 테스트해 보셔도 됩니다. 본인은 테스트 결과로 캐시를 찾을 수 없습니다.실효 전이 메커니즘 때문에 이 캐시는 newkey로 11212 노드에 저장되지만 get을 조작할 때 다운된 서버 노드가 복구되었고 키 값으로 11211 노드에서 get 작업을 하기 때문에 찾을 수 없습니다.따라서 이 곳은 주의를 기울여야 한다. 실효 이전 메커니즘을 사용한 후 다운된 서비스 노드가 다시 시작되면 일부 캐시가 정상적으로 접근할 수 없게 된다. 정식 생산 환경의memcache 서비스 노드는 일반적으로 자동 감청 리셋을 설정한다. (예를 들어Monit 구성 요소를 사용하여 감청을 한다).
4. Failback 복구 메커니즘 1. 트리거 네트워크 시스템(두 개 이상의 서버가 연결된 네트워크)에서 어떤 서버를 수리하려면 네트워크 자원과 서비스가 일시적으로 예비 시스템으로 재정비되어야 한다. 그 다음에 네트워크 자원과 서버를 원시 호스트가 제공하는 과정으로 복구하는 것을 자동 복구라고 한다.2. 장면 서버 노드가 일부 원인으로 인해 캐시 서비스를 제공하지 못할 때(예를 들어 네트워크 고장, 서버 실례 다운타임 등), 만약에 SockIOPool이 고장 자동 복구 메커니즘을 설정하면 매번 서버 연결을 시도한다.자동 복구 메커니즘을 닫기 위해 설정하면 연결이 실패한 서버 노드는 서버 사신 대기열에 기록되고 일정한 실효 시간이 되면 더 이상 연결 작업을 시도하지 않습니다. 클라이언트가 이 서버를 완전히 포기한 것과 같습니다.3. 소스 코드는 SchoonerSockIOPool 클래스의 getConnection() 메서드에서 구현되며 관련 소스 코드는 다음과 같습니다.

if (!failback && hostDead.containsKey(host)
        && hostDeadDur.containsKey(host)) {

    Date store = hostDead.get(host);
    long expire = hostDeadDur.get(host).longValue();

    if ((store.getTime() + expire) > System.currentTimeMillis())
        return null;
}

//  

if (socket == null) {
    Date now = new Date();
    hostDead.put(host, now);

    long expire = (hostDeadDur.containsKey(host)) ? (((Long) hostDeadDur
            .get(host)).longValue() * 2) : 1000;

    if (expire > MAX_RETRY_DELAY)
        expire = MAX_RETRY_DELAY;

    hostDeadDur.put(host, new Long(expire));

    // also clear all entries for this host from availPool
    sockets.clear();
}

4. 사고방식을 실현하기 위해 우리는 먼저 뒷부분의 코드(중국어 주석 문장 뒤의 코드)를 본다. 코드에서 보듯이 클라이언트가 서버에 연결할 때의 socket 대상이 비어 있을 때 연결을 만드는 데 실패했음을 나타낸다. 이 서버 연결 정보를hostDead 사신 대기열에 기록하고 해당하는 기한이 만료된 시간을 설정한 다음에 최대 10분으로 되돌아와 클라이언트가 연결을 만드는 데 실패했음을 알려준다.이어서 앞부분의 코드(중국어 주석 문장 앞부분의 코드)를 보면 클라이언트가failback을true로 설정할 때 이 부분의 코드는 실행되지 않고 매번 서버 연결을 시도한다는 것을 의미한다.클라이언트가failback을false로 설정하고 신뢰 대기열에 해당하는 서버 정보가 기록되어 있을 때, 실효 시간을 초과하면null값을 영원히 되돌려줍니다. 이것은 이 서버가 다시 연결하려고 하지 않는다는 것을 의미합니다.
5. AliveCheck Sock 상태 검출 메커니즘 1. 소개는 말 그대로 매번 Sock 대상을 사용하기 전에 이 Sock이 정상적으로 사용될 수 있는지 검사하는 것이다.2. 장면 SockIOPool은 상태 검사 메커니즘을 설정하고 서버 Sock이 생성될 수 있으나 연결이 효력을 잃으면 연결성 검사 조작을 촉발한다.이 메커니즘은 기본적으로 닫힌 3, 원본 코드가 SchoonerSockIOPool 클래스의 getConnection () 방법에 구현됩니다. 관련 원본은 다음과 같습니다.

if (socket != null && aliveCheck && !socket.isAlive()) {
    socket.close();
    try {
        socket.sockets.invalidateObject(socket);
    } catch (Exception e1) {
        log.error("++++ failed to close socket : " + socket.toString());
    }
    socket = null;
}

socket.isAlive() SockIOPool ， ：
/* * checks to see that the connection is still working * * @return true if still alive */
public boolean isAlive() {

     if (!isConnected())
            return false;

     // try to talk to the server w/ a dumb query to ask its version
     try {
            this.write( "version\r
".getBytes());
            this.flush();
            this.readLine();
     } catch (IOException ex) {
            return false;
     }

     return true;
}

4. 사고방식 isAlive () 방법의 실현 원리는 매우 간단하다. 바로 지정한 서버에 버전 명령을 보내서 정상적으로 사용할 수 있는지를 보는 것이다.aliveCheck 속성 값과 관련된 이 부분의 코드는 사실Commons-pool 프레임워크Generic ObjectPool 클래스를 호출하는 invalidate Object 방법입니다. if의 조건을 주의하십시오. isAlive는false이기 때문에 invalidate Object 방법을 호출하는 것입니다. 그래서 이 방법의 대략적인 사고방식은 이 연결 대상을 먼저 없애고 allocate () 방법을 호출하여 연결 자원을 다시 초기화하려고 합니다. 여기서 더 이상 깊이 토론하지 않겠습니다.관심 있는 아동화는 Commons-pool 프레임워크를 연구해 볼 수 있다.
6. FAQ Q1: 이 세 가지 특성은 서로 관련이 있습니까?A1: 연락이 있습니다. 우선 복구 메커니즘이 반환 값이 비어 있으면 실효 전이 메커니즘은 새로운 서버를 다시 검색한 다음에 복구 메커니즘이라는 일부 코드를 계속 실행합니다. 정상적으로 사용할 수 있는 서버를 찾을 때까지 Sock 상태 검사 메커니즘은 복구 메커니즘 사이에 섞여 있습니다. 복구 메커니즘에서 Sock의 연결성을 검사할지 결정합니다.