./bin/mysqladmin -u root shutdown

[mysqld]

character-set-server=utf8

collation-server=utf8_general_ci

init_connect=SET collation_connection=utf8_general_ci

init_connect=SET NAMES utf8

[client]

default-character-set=utf8

[mysql]

default-character-set=utf8

./bin/mysqld_safe &

출처 : http://the-earth.tistory.com/entry/Redis-%EB%8C%80%EB%9F%89-insert

Redis로 대량 insert를 하기에는 여러가지 문제점이 있다. 

매번 클라이언드토 요청하는 것은 RTT(Round trip time)때문에 아주 느릴것이다. 

파이프라이닝(pipelining)을 사용할 수도 있겠지만 대량의 insert를 위해서는 수행한 후 그 결과들을 읽으면서 새로운 command들을 write하는 것이 필요하다. 

소수의 client만이 non-blocking I/O를 지원하며 또 모든 client가 최대의 처리량을 달성할 수 있도록 결과들을 효과적으로 파싱하지 못한다. 

이런 이유들 때문에 Redis는 row format으로 Redis protocol을 담은 text file을 import하는 방식을 제공한다. 

예를 들어 10억개의 key들이 'keyN -> ValueN' 형태로 insert되어야한다면 우리는 아래와 같이 Redis protocol 형식을 따르는 파일을 만들면 된다. 

SET Key0 Value0

SET Key1 Value1

...

SET KeyN ValueN

이제 남은것은 이 파일을 Redis에 가능한한 빠르게 보내는 것이다. 예전 방식으로는 아래의 명령어를 통해 netcat으로 보내는 것이었다. 

(cat data.txt; sleep 10) | nc localhost 6379 > /dev/null

하지만 이런 방법은 안전하지 못한데 이유는 netcat이 데이터를 다 보냈는지 모르며 에러 또한 check할 수 없다. 

아직 불안전한 Redis의 branch에서는 pipe mode라고 불리는 새로운 모드의 redis-cli utility를 제공하는데 이 util은 대량의 insert를 위해 만들어졌다. 

pipe mode를 사용해서 아래와 같은 명령어로 실행이 가능하다. 

cat data.txt | redis-cli --pipe

그리고 결과로 아래와 같은 output을 생산한다. 

All data transferred. Waiting for the last reply...

Last reply received from server.

errors: 0, replies: 1000000

redis-cli utility는 또 standard output으로 에러만 출력되도록 해놓았다. 

출처 : http://the-earth.tistory.com/182

Redis clustering 튜토리얼페이지 요약

참고 : http://redis.io/topics/cluster-tutorial

이 페이지에서는 Redis cluster의 구성방법을 다룬다.더 자세한 정보는 아래를 참고하자. 

Redis Cluster specification

Redis cluster tutorial

Redis Cluster 101

Redis cluster는 데이터가 자동으로 sharding되어 다수의 Redis 노드로 분산되어 들어가도록 해준다. 

여러가지 Key에 대한 command는 cluster에서 다루지 않는데 이유는 이런 방식을 노드간의 data이동을 필요로하고 부하가 많은 경우에 Redis cluster의 redis 본연의 성능을 보장해 주지 못하게 하기 때문이다. 

Redis Custer는 노드의 fail이나 통신 불능 상태등에 대해 지속적으로 동작할 수 있도록 파티션 간의 어느정도의 가용성을 제공한다. 

그게 뭐냐하면 

• 여러 노드들에 데이터들을 분리해서 넣을 수 있다. 
• 부분적인 노드들에서 실패 혹은 통신 불능 상태에서 지속적인 동작을 제공한다. 

Redis Cluster TCP ports

모든 Redis cluster 노드는 두개의 TCP connection을 필요로한다. 기본적인 Redis TCP port는 client를 위한 것이고, (예를 들어 6379), 추가로 10000을 더한 portt는 데이터 port로 쓰인다. (예를 들면 16379)

두번째 port는 Cluster bus로 사용되는데 노드간의 바이너리 커뮤니케이션 채널로 사용된다. Cluster bus는 노드의 실패 detection이나 설정 업데이트, failover authorization 등등에 쓰이게 된다. Client는 당연히 이 port를 사용하면 안된다. 아까 설명한 첫번째 Redis command port를 사용하자. 

그리고 이 두개의 port가 방화벽에서 열려있는지도 체크하자. 안그러면 cluster가 작동하지 않을 수 있다. 

command port와 cluster bus port의 offset은 항상 10000으로 정해져 있다. 

Cluster가 제대로 작동하기 위해서는 다음을 잘 숙지해야한다. 

1. 기본 client communication port (보통 6379)는 cluster에 접근하고자하는 모든 client와 다른 cluster 노드들(Key 이동을 위해)에 의해서 사용된다.

2. cluster bus port (client port + 10000)은 다른 node cluster에게 항상 개방되어 있어야한다. 

Redis Cluster data sharding

Redis Cluster는 consistency hashing을 사용하지 않고 모든 key가 개념적으로 hash slot의 일부인 다른 sharding을 사용한다. 

Redis cluster는 16384개의 hash slot을 사용하고 key modulo 16384를 사용하는 CRC16를 사용해서 hash slot을 계산한다. 

Redis cluster의 모든 노드는 hash slot의 subset이다. 만약 3개의 노드가 있다면 아래와 같이 slot이 나뉘어 질 수 있다. 

• Node A contains hash slots from 0 to 5500.
• Node B contains hash slots from 5501 to 11000.
• Node C contains hash slots from 11001 to 16384.

이 방법은 노드를 더하고 제가하는 것을 쉽게 한다. 예를 들어 D라는 노드가 추가되었다면 A,B,C의 어느정도의 slot을 D에게 할당하면 된다. 비슷하게 노드 A를 제가한다면 단순히 A의 slot을 B나 C로 옮기면된다. 노드 A가 empty가 되면 언제든지 이 노드를 제거할 수 있다. 

hash slot을 이동하는 것이 cluster를 정지할 필요가 없기 때문에 노드를 더하거나 제거하거나 hash slot의 비율을 변경하는 것이 언제고 가능하다. 

Redis Cluster master-slave model

부분적인 노드가 실패나 통신 불능에서도 가용성을 확보하기 위해 Redis cluster에서는 master-slave를 지원한다. 

아까 예로들었던 A,B, C로 구성된 Cluster에서 B가 실패한다면 5501-11000의 slot을 서비스 할 수 없게 된다. 

그러나 slave를 추가해서 A,B,C가 master이고 A1, B1, C1이 slave가 되도록 cluater를 구성한다면 B1은 B를 replication하게 B의 장애시에 B1가 elaction(투표)를 통해 새로운 master로 선출된다. 

하지만 B와 B1이 동시에 fail되면 지속적으로 서비스 할 수 없다. 

Redis Cluster consistency guarantees

Reids Cluster는 strong consistency를 보장하지 않는다. 쉽게 말하면 특정 조건에서 Redis Cluster에 성공적으로 응답을 받은 데이터를 Cluster가 잃어 버릴 수 있다는 뜻이다. 

첫번째 이유는 Redis Cluster가 asynchronous replication을 사용하기 때문이다. 이 말은 write를 할 때 아래와 같은 절차를 따른다는 뜻이다. 

• Client가 Master B에 데이터를 쓴다. 
• master B가 Client에 OK라고 대답한다. 
• Master B가 B1, B2, B3의 replica에 쓰기를 전달한다. 

보시다싶이 B는 B1, B2, B3에서의 확인을 받기 전에 client에 확인 결과를 보낸다. 이유는 저런 확인이 비용이 비싼 잠재적인 패널티가 될 수 있기 때문이다. B가 쓰기를 확인하고 slave에 이를 전달하기 전에 fail일 발생한다면 데이터가 손실 될 수 있다. 

이것은 대다수의 데이터 베이스들이 1초마다 disk로 데이터를 flush하는 경우에서와 마찬가지다. client에 확인 요청을 보내기 전에 disk에 강제로 flush할 수 있지만 이런 방법은 보통 엄청난 성능 저하를 가져온다. 

기본적으로 consistency와 성능간에는 trade off가 있다. 

또 데이터를 잃을 수 있는 다른 시나리오가 있는데 네트워크 파티션이 일어나고 client가 minor한 파티션에 속하게 되었을 때이다. 

예를 들어보자. 6개의 노드가 있는데 A, B, C, A1, B1, C1으로 3개의 master와 3개의 slaver로 구성되었다고 생각하자. 또 Z1이라는 client도 존재한다고 치자. 

만약 네트워크 파티션이 발생하면 A, C, A1, B1, C1과 B, Z1으로 분리될 수 있다. Z1은 B에게 계속 쓸 수 있다. 만약 파티션된 네트워크가 금방 회복 된다면 cluster는 평상시처럼 지속될 것이다. 

하지만 이 시간이 B1이 master로 선출될 수 있는 충분한 시간이라면 Z1이 B에게 썼던 데이터는 잃게 된다. 

이 설정을 node timeout이라 부르는데 Redis cluster 설정에서 에서 매우 중요하다. 

node timeout이 발생하면 master node는 실패되었다고 간주되고 다른 replica들중에 하나로 교체된다. 비슷하게 node timeout이 발생하고 major한 master 노드들을 감지할 수 없다면 이 노드는 에러 상태로 들어가고 쓰기를 받지 않게된다. 

Creating and using a Redis Cluster

Cluster를 생성하기 위해 필요한 것은 몇개의 cluster mode로 동작하고 있는 empty상태의 Redis instance들이다. 이것은 기본적으로 이 Redist instatnce들이 보통의 instance들이 아니라 Cluster에 부합하는 특징과 command들을 사용할 수 있도록 설정된 특별한 모드의 instance들이라는 것이다. 

아래는 최소한의 Redis cluster 설정파일이다. 

port 7000

cluster-enabled yes

cluster-config-file nodes.conf

cluster-node-timeout 5000

appendonly yes

보이는 것 처럼 cluster mode를 enable시키는 것은 cluster-enabled 지시자이다. 모든 instance들은 마찬가지로 파일의 경로를 가지고 있는데 이것은 이 노드의 설정이 어디에 저장되어 있는지를 알리는 것이며 default로 nodes.conf를 사용한다. 

이 파일들은 사람에 의해서 수정되어서는 안되고 단순히 Redis Cluster가 시작될때 cluster에 의해서 생성되고 매 시간 필요시마다 업데이트된다. 

적어도 세게 이상의 master node가 있어야 minimal cluster가 될 수 있다는 점을 숙지해야한다. 당신을 위해 처음에 3개의 master와 3개의 slave로 구성된 cluster를 강력하게 추천한다. 

그러기 위해서는 새 디렉토리에서 아래와 같이 새로운 instance들이 실행될 수 있는 instance port number를 따르는 디렉토리들을  만들djdi gksek. 

mkdir cluster-test

cd cluster-test

mkdir 7000 7001 7002 7003 7004 7005

각각의 7000부터 7005까지의 directory안에 redis.conf 파일을 생성한다. 템플릿으로는 위의 최소한의 example을 사용하며 port를 각 디렉토리 이름에 맞도록 수정해야한다. 

이제 Github의 unsatble branch를 최신으로 컴파일되거나 실행가능한 redis-server를 복사해서 cluster-test디렉토리에 복사한다. 

아래와 같이 모든 insatance를 실행시킨다. 

cd 7000

../redis-server ./redis.conf

아래와 같이 모든 instance에서 다음과 같은 log를 볼 수 있다. 이것은 nodes.conf 파일이 존재하지 않기 때문이며 모든 노드들을 각자 새로운 ID를 자신에게 할당한다. 

[82462] 26 Nov 11:56:55.329 * No cluster configuration found, I'm 97a3a64667477371c4479320d683e4c8db5858b1

이 ID는 cluster안에서 각자의 유일한 이름으로 영원히 사용된다. 모든 노드들은 IP혹은 port가 아닌 ID로 다른 노드들을 기억한다. IP와 port는 바뀔 수 있지만 이 유일한 노드 식별자는 노드의 일생동안 바뀌지 않는다. 이것을 Node ID라고 부른다. 

Creating the cluster

이제 우리는 실행되고 있는 instance들을 가지고 있고, 노드들에게 뭔가 의미있는 설정을 생성해서 cluster에 써줄 필요가 있다. 

redis-trib이라는 utility를 사용해서 하면 되는데, 이것은 새로운 cluster를 생성하거나 shard를 바꾸거나 하는데 쓰인다. 

redis-trib utility는 배포 코드의 src 디렉토리에 위치한다. cluster를 생성하기위해서는 간단히 아래와 같이 하면 된다. 

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \

127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

우리가 원하는 것은 새로운 cluster를 생성하는 것이기 때문에 여기서 사용된 command는 create이다. --replica 1이라는 옵션은 우리가 생성되는  모든 master에 대해서 slave를 원한다는 것을 의밓나다. 다른 argument들은 생성하고자 하는 새로운 cluster에 주소 목록이다. 

명백히 우리가 단지 원하는 것은 3개의 master와 3개의 slave를 가진 cluster이다. 

Redis-trib은 설정을 위해 쓰인다. Yes를 typing한다. 그러면 cluster들이 설정되고 join될 것이다. 이것은 instace들이 서로 이야기하면서 시동됨을 의미한다. 

결론적으로 문제가 없다면 우리는 아래와 같은 메시지를 보게 될 것이다. 

[OK] All 16384 slots covered

이것은 적어도 master instance들의 16384개의 slot들이 사용가능하다는 것을 뜻ㅎ나다. 

Playing with the cluster

현재 단계에서 문제는 Redis Cluster에 대한 client 구현이 미비하다는 것이다. 

현재 알려진 구현은 아래와 같다. 

• redis-rb-cluster is a Ruby implementation written by me (@antirez) as a reference for other languages. It is a simple wrapper around the original redis-rb, implementing the minimal semantics to talk with the cluster efficiently.
• redis-py-cluster appears to be a port of redis-rb-cluster to Python. Not recently updated (last commit 6 months ago) however it may be a starting point.
• The popular Predis has support for Redis Cluster, the support was recently updated and is in active development.
• The most used Java client, Jedis recently added support for Redis Cluster, see the Jedis Cluster section in the project README.
• The redis-cli utility in the unstable branch of the Redis repository at Github implements a very basic cluster support when started with the -c switch.

쉽게 Redis Cluster를 테스트 해보는 방법은 redis-cli command line 유틸을 사용하는 것이다. 아래는 그 예이다. 

$ redis-cli -c -p 7000

redis 127.0.0.1:7000> set foo bar

-> Redirected to slot [12182] located at 127.0.0.1:7002

OK

redis 127.0.0.1:7002> set hello world

-> Redirected to slot [866] located at 127.0.0.1:7000

OK

redis 127.0.0.1:7000> get foo

-> Redirected to slot [12182] located at 127.0.0.1:7002

"bar"

redis 127.0.0.1:7000> get hello

-> Redirected to slot [866] located at 127.0.0.1:7000

"world"

redis-cli cluster가 제공하는 것은 기본적인 것이어서 항상 Redis Cluster 노드들이 올바를 client로 redirect된다는 것만을 사용한다. 

좀더 좋은 client는 이것보다 더 나은데 hash slot이나 nodes의 주소 정보 map을 caching하여 바로 필요한 node로 연결될 수 있게 한다. map은 cluster의 설정이 변경될 때만 갱신된다. 예를 들면 failover가 일어 났다거나 admin이 노드를 추가 삭제하여 cluster의 형태가 변경되었을 때이다. 

Writing an example app with redis-rb-cluster

좀더 알아보기 전에 Redis cluster가 어떻게 failover, resharding등을 어떻게 하는지 새로운 example 어플리케이션을 통해서 알아보자. 

이를 통해 우리는 Redis cluster가 실제 상황에서 어떻게 행동하는지 보기 위해 example code를 돌려 fail과 resharding을 관찰수 있다. 

이 섹션은 redis-rb-cluster의 기본적인 두개의 example을 설명한다. 첫째는 아래와 같고 redis-rb-cluster 배포본의 example.rb 파일에 있다. 

     1  require './cluster'

     2

     3  startup_nodes = [

     4      {:host => "127.0.0.1", :port => 7000},

     5      {:host => "127.0.0.1", :port => 7001}

     6  ]

     7  rc = RedisCluster.new(startup_nodes,32,:timeout => 0.1)

     8

     9  last = false

    10

    11  while not last

    12      begin

    13          last = rc.get("__last__")

    14          last = 0 if !last

    15      rescue => e

    16          puts "error #{e.to_s}"

    17          sleep 1

    18      end

    19  end

    20

    21  ((last.to_i+1)..1000000000).each{|x|

    22      begin

    23          rc.set("foo#{x}",x)

    24          puts rc.get("foo#{x}")

    25          rc.set("__last__",x)

    26      rescue => e

    27          puts "error #{e.to_s}"

    28      end

    29      sleep 0.1

    30  }

이 프로그램을 돌리면 결과는 아래와 같은 command의 흐름이다. 

• SET foo0 0
• SET foo1 1
• SET foo2 2
• And so forth...

7번째 줄에서는 각각의 instance에 대해서 32개의 connection과 timeout 0.1초를 설정해 주고 있다. 

위에서 sartup 노드들은 꼭 cluster의 모든 노드일 필요는 없다. 중요한 점은 적어도 하나의 노드는 접근 가능해야한다는 것이다. redis-rb-cluster는  첫번째 노드에 접속할 수 있을때 startup 노드들의 목록을 업데이트한다. 

이제 rc라는 변수에 Redis cluster instance가 저장되었고 우리는 이 object를 통해서 보통의 Redis object instance처럼 Redis를 사용할 수 있다. 

이것이 11~19째줄에 나타나있다. 우리가 프로그램을 재시작했을 때 foo0부터 다시 시작하길 바라지 않기 때문에 우리는 현재의 count도 Redis에 저장한다. 그래서 11~19줄에서는 예전값을 redis로 부터 읽거나 없다면 0으로 할당하도록 디자인되어 있다. 

21~30째 줄에서는 loop를 돌면서 key를 set하거나 에러를 출력한다. 

결과는 아래와 같다. 

ruby ./example.rb

1

2

3

4

5

6

7

8

9

^C (I stopped the program here)

Resharding the cluster

resharding을 해보자. 

resharding은 기본적으로 특정 node들의 hash slot을 다른 노드들의 slot으로 이동하는 것을 뜻한다. cluster를 생성하는 것과 마찬가지로 redis-trip 유틸을 사용하면된다. 

resharding을 진행하게 위해서는 단순히 아래와 같이 하면 된다. 

./redis-trib.rb reshard 127.0.0.1:7000

하나의 노드만 정하면 다른 노드들은 redis-trib이 알아서 찾는다. 

현재의 redis-trip은 5%정도를 옮겨줘와 같은 것은 지원하지 않는다. redis-trip은 아래와 같은 질문으로 어마만큼 resharding하고 싶은지 물어본다. 

How many slots do you want to move (from 1 to 16384)?

우리는 1000개의 hash slot을 resharding해볼 수 있다. 만약 위의 예제에서 sleep을 주지 않는다면 이는 무시하지 못할 양의 key들이다. 

그다음 redis-trib에게 hash slot들을 받게될 resharding target 을 알려주어야한다. 우리는 127.0.0.1:7000인 첫번째 노드를 사용할 것이며 instance의 Node ID를 사용하게 된다. 아래와 같은 command로 원하는 node의 Node ID를 볼 수 잇따. 

$ redis-cli -p 7000 cluster nodes | grep myself

97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5460

이제 어떤 node들에 이 key들이 속할지 알려주어야한다. 우리는 hash slot들을 다른 master node들로 부터 가져오기위해 all이라고 입력할 것이다. 

마지막 conform후에 우리는 선택한 노드로 부터 다른 노드로 이동되는 모든 slot에 대한 메시지를 볼 수있을 것이다. 그리고 이동되는 모든 key마다 .이 출력될것이다. 

resharding이 진행되는 동안 우리는 example program이 영향을 받지 않고 동작함을 확인 할 수 있다. 

resharding이 완료되면 아래 명령어를 통해서 cluster의 health를 check할 수 있다. 

./redis-trib.rb check 127.0.0.1:7000

확인 해보면 127.0.0.1:7000에 더 많은 slot이 할당되어 있음을 확인 할 수 있다. 

ulimit는 유저가(쉘, 프로세스)에 대해서 할당할 자원의 한계를 정하는 것으로

다중 프로그램/사용자를 기본으로 하는 리눅스 시스템에서 과부하를 막아주는 설정이다. 

나 같은 경우는 linux서버의 openfile, corefile size를 많이 제어하는데 사용한다. 

그 이유는 분산처리 파일 환경, 또는 디비서버를 운영할 경우 동시에 많은 파일들이 

읽고 쓰고를 해서 openfile error가 생기는것을 막기 위해서 이다. 

기본적으로 hard 설정과 soft 설정이 있는데 

각 설정을 보려면 아래의 명령어로 확인한다. 

 $ ulimit -Ha 

 $ ulimit -Sa

(하드 설정 전체 보기 / 소프트 설정 전체 보기)

하드는 해당쉘의 최대값을 뜻한다 하면 되고,  소프트는 현재 설정을 말한다 생각하면 된다.

hard 설정의 경우는 root권한으로만 변경 가능

$ ulimit -Sa

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

file size               (blocks, -f) unlimited

max locked memory       (kbytes, -l) unlimited

max memory size         (kbytes, -m) unlimited

open files                      (-n) 256

pipe size            (512 bytes, -p) 1

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 266

virtual memory          (kbytes, -v) unlimited

ulimit -Sn 10240  <- 이런 식으로 각 설정별 옵션을 사용해서 변경 가능하면 된다.

원본 : http://www.mimul.com/pebble/default/2012/05/04/1336102052449.html

NoSQL 관련 기술 중에 하나인 Consistent Hashing의 개념은 1997년에 MIT의 karger가 웹서버의 숫자가 수시로 변경되는 중에 분산 요청을 처리하기 위해 처음 고안했다고 하는데 그 내용을 살펴보고자 한다.
아래의 내용은 'Consistent Hashing' 이라는 아티클을 많이 참조해서 작성했다.

왜 필요한가?

N개의 캐시 시스템(노드)이 있다고 하고 이때 부하 분산에 사용하는 일반적인 방법은 Object o를 hash(o) mod n 번째 캐시 시스템에 저장하는 방식이다. 이런 방식은 캐시 시스템이 추가되거나 제거되기 전까지는 잘 운영된다.
그러나 캐시 시스템이 추가되거나 장애로 제거 되었을 경우, n이 빠뀌게 되면 모든 Object는 새로운 위치에 모두 재할당을 해야하는데 그러기엔 부하 부담이 크다.
이 때 Consistent Hashing 방법을 사용하게 되면 캐시 시스템이 추가되거나 작동이 중단되어도 모든 Object를 할당을 하는 것이 아니라 추가되면 인접한 다른 캐시 시스템에서 적정한 양의 Object 를 받게되고 마찬가지로 제거된다면 남은 캐시 시스템들이 나누는 형태가 되어 일관되게 일부 Object에 대해서 재 할당을 수행하게 된다. 그러므로 기존에 저장된 대부분의 캐시를 사용할 수 있으며 시스템 변동이 히트율에 영향을 미치지 않게 된다.
기본 원리는 Consistent hashing 알고리즘은 Object와 캐시 시스템 둘다 동일한 Hash 함수를 사용해서 해싱하는 것이다. 캐시 시스템은 구간을 정하고 그 구간에는 많은 Object의 해시값을 가지고 있는다. 캐시 시스템이 제거도면 인접한 구간의 캐시 시스템이 제거된 구간을 맞게되고 다른 캐시 시스템은 영향을 받지 않는다.
Performance는 O(log n).

작동 방식은?

Hash 함수는 Object와 캐시 시스템이 일정 구간을 정하게 한다. Java 언어의 예를 보면 Object의 hashCode() 함수는 리턴을 int로 하고 리턴값 int의 구간은 -2^31에서 2^31-1을 가진다. 
다음 그림은 네 개의 Object(1,2,3,4)와 3개의 캐시 시스템(A, B, C)가 링에 배치되어 있다.

 
위의 그림에서 1,4는 캐시 시스템 A에 들어가고 2는 B, 3은 C에 들어 간다. 이때 C가 제거되었다고 가정하면 Object 3은 A에 들어간다. 기타 지원은 변하지 않는다. 다음 그림처럼 캐시 D가 추가되면, 3, 4는 D로 옮긴다. 그리고 1 만 A에 남아있다.

 
이렇게 함으로써 각 캐시 시스템에 할당된 구간의 사이즈에 예외가 발생해도 잘 동작하게 된다. 한가지 고민해야할 점은 무작위로 분포되기 때문에 캐시 시스템 사이의 Object의 분포는 균일하지 않을 수 있다. 이를 위한 해결책으로 '가상 노드'를 사용하는 방법이 있다. 가상 노드는 캐시 시스템의 링안에서 복제하는데 이는 캐시 시스템 하나 추가할때마다 링에 여러개 배치되게 되는 방식이다.
가상 노드의 효과는 다음 그래프와 같은데 10,000개의 Object를 10개의 캐시 시스템으로 시뮬레이션한 결과이다. X축이 캐시 시스템의 복제수가 되고 Y축은 표준 편차.
복제 수가 작은 Object들의 분산도가 언발란스한데 이는 캐시 시스템의 Object수의 평균의 표준 편차가 크기 때문일 것이다. 이 실험에서 복제를 100이나 200으로 했을 경우 합리적인 균형을 실현할 수 있다고 할 수 있었다고 한다. (표준 편차가 평균 5-10% 정도가 적당함)

 
시스템마다 다수의 Virtual Nodes(가상 노드)를 만들어서 로드발란싱을 좋게 한 예는 libketema이다.

구현 방법은?

Consistent Hashing 방법이 효력이 발휘하기 위해서는 해싱 함수가 잘 동작해야하는데 Object의 hashCode로는 부족하고 MD5를 추천한다.

public class ConsistentHash {

  private final HashFunction hashFunction;
  private final int numberOfReplicas;
  private final SortedMap circle =
    new TreeMap();

  public ConsistentHash(HashFunction hashFunction,
    int numberOfReplicas, Collection nodes) {

    this.hashFunction = hashFunction;
    this.numberOfReplicas = numberOfReplicas;

    for (T node : nodes) {
      add(node);
    }
  }

  public void add(T node) {
    for (int i = 0; i < numberOfReplicas; i++) {
      circle.put(hashFunction.hash(node.toString() + i),
        node);
    }
  }

  public void remove(T node) {
    for (int i = 0; i < numberOfReplicas; i++) {
      circle.remove(hashFunction.hash(node.toString() + i));
    }
  }

  public T get(Object key) {
    if (circle.isEmpty()) {
      return null;
    }
    int hash = hashFunction.hash(key);
    if (!circle.containsKey(hash)) {
      SortedMap tailMap =
        circle.tailMap(hash);
      hash = tailMap.isEmpty() ?
             circle.firstKey() : tailMap.firstKey();
    }
    return circle.get(hash);
  } 

}

사용 사례는?

- NoSQL

• Amazon의 Dynamo
• Memcached

- 오픈 소스 

• Chord(분산 해시 테이블 구현)
• Last.fm's ketama
• java-memcached-client
• BitTorrent

[참조 사이트]

• Consistent Hashing
• 위키피디아의 Consistent hashing
• Memcached 에서의 Consistent Hashing

rpm -Uvh http://mirror.webtatic.com/yum/el6/latest.rpm

yum install php54w php54w-mysql php54w-pear

End

CentOS/RHEL: Ulimit And Maximum Number Of Open Files

Sometimes you may want to set limits on some of your system resources(Processes, Files)
But other times, you may want to do the just the opposite - disable those limits or change them to higher limits like I needed to do few days ago.

1. Check what are the limits

Apparently, RedHat set the default max number of open files for users  to 1024 and and not long ago, this was change to 4096.
For some applications/users this is very low and can cause you a lot of problems.

You can check what is the current limit with ulimit using bash shell:

?

1	ulimit -Hn

This will show you the hard limit of maximum number of files for your user. you can use -S to check the soft limit.
tcsh: using tcsh you can can check this limit with limit descriptors

if you wish to check the max Open file descriptors for the process your user/application running, use the following command: 

?

1	cat /proc/[Process ID]/limits

To check what is the system limit for number of files descriptors use the following command:

?

1	cat /proc/sys/fs/file-max

2. Change the limit

lets start by changing the limit for the user mario:

?

1	vi /etc/security/limits.conf

now change the following lines:

?

1 2	mario soft nofile 4096 mario hard nofile 20480

save the file and verify the result by using ulimit like we used it in section 1.
If you want to set maximum number of processes use nproc instead of nofile
If you want to set this setting to all users use * instead of specify user name

Now lets change the limit for the entire system:

?

1	vi /etc/sysctl.conf

and put the line:

?

1	fs.file-max = 200500

update the system with::

?

1

sysctl -p

3. List number of open files/allocated file handles

To check the number of files opened on your system, use:

?

1	lsof | wc -l

You can also check the allocated file descriptors by using: 

?

1	cat /proc/sys/fs/files-nr

the first field is the number of total allocated files descriptors.

second field is unused file descriptors

and the third field is the maximum file descriptors that can be used