Twitter의 Twemproxy는 현재 시장에서 가장 널리 사용되고 있으며 Redis 클러스터 서비스에 사용됩니다. Redis는 단일 스레드이므로 공식 클러스터는 그다지 안정적이지 않고 널리 사용되지 않습니다. Twemproxy는 프록시 샤딩 메커니즘으로, 여러 프로그램의 액세스를 허용하고 라우팅 규칙에 따라 백그라운드에서 다양한 Redis 서버로 전달한 다음 원래 경로로 돌아갈 수 있습니다. 이 솔루션은 단일 Redis 인스턴스의 전송 용량 문제를 잘 해결합니다. 물론 Twemproxy 자체도 단일 지점이므로 Keepalived를 고가용성 솔루션(또는 LVS)으로 사용해야 합니다. Twemproxy를 통해 여러 서버를 사용하여 Redis 서비스를 수평으로 확장할 수 있으므로 단일 실패 지점을 효과적으로 방지할 수 있습니다. Twemproxy를 사용하면 더 많은 하드웨어 리소스가 필요하고 Redis 성능이 어느 정도 손실되지만(트위터 테스트에서 약 20%) 전체 시스템의 HA를 향상시키는 것이 상당히 비용 효율적입니다. 실제로 twemproxy는 redis 프로토콜을 구현할 뿐만 아니라 memcached 프로토콜도 구현합니다. 즉, twemproxy는 redis를 프록시할 뿐만 아니라 memcached도 프록시할 수 있습니다.
1) 액세스 노드를 외부 세계에 노출하면 프로그램 복잡성이 줄어듭니다.
2) 실패한 노드의 자동 삭제를 지원합니다. 노드를 다시 연결하는 시간을 설정하고 연결 횟수를 설정한 후 노드를 삭제할 수 있습니다. 이 방법은 캐시 저장에 적합합니다. 그렇지 않으면 키가 손실됩니다. 3) HashTag 설정을 지원합니다. HashTag를 통해 두 개의 KEYhash를 동일한 인스턴스에 해시하도록 자체적으로 설정할 수 있습니다.
4) 여러 해시 알고리즘과 백엔드 인스턴스의 가중치를 설정할 수 있습니다.
5) Redis에 대한 직접 연결 수를 줄입니다. Redis와의 긴 연결을 유지하고, 에이전트와 백엔드 간의 각 Redis 연결 수를 설정하고, 이를 백엔드의 여러 Redis 인스턴스로 자동으로 분할합니다.
6) 단일 지점 문제 방지: 여러 프록시 레이어를 병렬로 배포할 수 있으며 클라이언트는 자동으로 사용 가능한 레이어를 선택합니다.
7) 높은 처리량: 연결 재사용, 메모리 재사용, 다중 연결 요청은 Redis 파이프라인 및 Redis에 대한 통합 요청으로 구성됩니다.
Twemproxy의 단점:
2) Redis 트랜잭션 작업은 지원되지 않습니다.
3) 적용된 메모리는 해제되지 않습니다. 모든 머신에는 대용량 메모리가 있어야 하며 정기적으로 다시 시작해야 합니다. 그렇지 않으면 클라이언트 연결 오류가 발생합니다.
4) 노드의 동적 추가 및 삭제는 지원되지 않으며, 구성 수정 후 재시작이 필요합니다.
5) 노드를 변경할 때 시스템은 기존 데이터를 재할당하지 않습니다. 데이터 마이그레이션을 위한 스크립트를 직접 작성하지 않으면 일부 키가 손실됩니다. (키 자체는 특정 Redis에 존재하지만 키는 다른 Redis에 해시됩니다. 노드로 인해 "손실"이 발생함).
6) 가중치는 키의 해시 결과에 직접적인 영향을 미칩니다. 노드 가중치를 변경하면 일부 키가 손실됩니다.
7) 기본적으로 Twemproxy는 단일 스레드에서 실행되지만, Twemproxy를 사용하는 대부분의 회사에서는 자체적으로 2차 개발을 수행하고 멀티스레딩으로 변경합니다.
일반적으로 twemproxy는 성능이 떨어지더라도 여전히 매우 안정적입니다. 오랫동안 테스트를 거쳐 널리 사용되고 있습니다. 보다 자세한 내용은 공식 문서를 참고하시기 바랍니다. 또한 twemproxy는 정적 클러스터에만 적합하며 노드의 동적 추가 및 삭제와 수동 로드 조정이 필요한 시나리오에는 적합하지 않습니다. https://github.com/wandoulabs/codis 이 시스템은 twemproxy를 기반으로 하며 동적 데이터 마이그레이션과 같은 기능을 추가합니다. 특정 사용법에는 추가 테스트가 필요합니다.
Twemproxy 사용 아키텍처
ps: 하드웨어 리소스를 절약하지만 단일 장애 지점이 발생하기 쉽습니다. 두 번째: 고가용성 Twemproxy
PS: 리소스의 절반을 낭비하지만 노드의 가용성은 높습니다. 세 번째 유형: 로드 밸런싱 Twemproxy
PS: 대규모 Redis 또는 Memcached 애플리케이션 시나리오인 경우 Twemproxy 로드 밸런싱 시나리오, 즉 고가용성을 기반으로 LVS 노드를 추가할 수 있습니다. Twemproxy. Twemproxy 로드 밸런싱을 위해 LVS(Linux 가상 서버)를 사용하십시오. LVS는 매우 강력한 프록시 기능을 갖춘 4계층 로드 밸런싱 기술입니다. 하지만 LVS를 사용하게 되면 Twemproxy의 문제와 단일 장애 지점이 다시 발생하게 됩니다. 이때 LVS에 대한 고가용성을 구현해야 합니다. OSPF 라우팅 기술을 사용하여 LVS는 로드 밸런싱도 달성할 수 있습니다. 그리고 이 아키텍처가 제가 현재 작업에 사용하고 있는 아키텍처입니다. 또한 위의 아키텍처 방법 중 어떤 방법을 사용하더라도 Redis의 단일 오류 지점 문제는 피할 수 없으며 Redis 지속성도 하드웨어 오류 문제를 피할 수 없습니다. Redis 데이터 액세스의 중단성을 보장해야 한다면 Redis 클러스터 모드를 사용해야 합니다. 클러스터 모드는 현재 JAVA를 잘 지원하며 업무에 널리 사용됩니다.
Twemproxy 설치
다음 문장을 한 문장으로 다시 작성해주세요. 다음 명령을 사용하여 twemproxy 저장소를 로컬 시스템에 복제합니다. git clone https://github.com/twitter/twemproxy.git 다시 작성한 후: 로컬 컴퓨터에서 다음 명령을 사용하세요. git clone https://github.com/twitter/twemproxy.git twemproxy 저장소
2를 복제하세요. Twemproxy 설치
Twemproxy는 컴파일 및 구성을 위해 Autoconf를 사용해야 합니다. GNU Autoconf는 Bourne 쉘에서 소프트웨어를 컴파일, 설치 및 패키징하기 위한 구성 스크립트를 생성하는 도구입니다. Autoconf는 프로그래밍 언어에 의해 제한되지 않으며 일반적으로 C, C++, Erlang 및 Objective-C에서 사용됩니다. 구성 스크립트는 특정 시스템의 소프트웨어 패키지 설치를 제어합니다. 일련의 테스트를 실행하여 구성 스크립트는 템플릿에서 makefile과 헤더 파일을 생성하고 필요에 따라 패키지를 조정하여 특정 시스템에 적합하게 만듭니다. Autoconf는 Automake 및 Libtool과 함께 GNU 빌드 시스템을 구성합니다. Autoconf는 1991년 여름 David McKenzie가 자유 소프트웨어 재단(Free Software Foundation)에서의 프로그래밍 작업을 지원하기 위해 작성했습니다. Autoconf는 여러 사람이 작성한 개선된 코드를 통합했으며 가장 널리 사용되는 무료 컴파일 및 구성 소프트웨어가 되었습니다.
autoreconf를 사용하여 twemproxy를 컴파일하고 구성해 보겠습니다.
[root@www twemproxy]# autoreconfconfigure.ac:8: error: Autoconf version 2.64 or higher is required configure.ac:8: the top level autom4te: /usr/bin/m4 failed with exit status: 63 aclocal: autom4te failed with exit status: 63 autoreconf: aclocal failed with exit status: 63 [root@www twemproxy]# autoconf --versionautoconf (GNU Autoconf) 2.63
autoreconf 버전이 너무 낮다는 메시지가 표시됩니다. 위에서는 autoconf 2.63 버전을 사용하므로 컴파일 및 설치를 위해 autoconf 2.69 버전을 다운로드해 보겠습니다. CentOS6인 경우 기본 버전은 2.63이고, CentOS7인 경우 기본 버전은 2.69입니다. Debian8 또는 Ubuntu16인 경우 기본 버전도 2.69입니다. 어쨌든, autoreconf를 실행할 때 오류가 보고된다면 버전이 오래되어 컴파일하고 설치해야 한다는 의미입니다.
[root@www ~]# wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz[root@www ~]# tar xvf autoconf-2.69.tar.gz[root@www ~]# cd autoconf-2.69[root@www autoconf-2.69]# ./configure --prefix=/usr[root@www autoconf-2.69]# make && make install[root@www autoconf-2.69]# autoconf --versionautoconf (GNU Autoconf) 2.69
[root@www ~]# cd /root/twemproxy/[root@www twemproxy]# autoreconf -fvi[root@www twemproxy]# ./configure --prefix=/etc/twemproxy CFLAGS="-DGRACEFUL -g -O2" --enable-debug=full[root@www twemproxy]# make && make install
autoreconf -fvi가 다음 오류를 보고하는 경우 libtool 도구를 설치해야 하며 libtool을 사용해야 함을 의미합니다(CentOS인 경우 yum install을 사용하면 됩니다). libtool을 직접 사용하세요. Debian이라면 apt를 사용하세요. libtool을 설치하세요.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory contrib/yaml-0.1.4 to autoreconf
autoreconf: Entering directory `contrib/yaml-0.1.4'autoreconf: configure.ac: not using Autoconf
autoreconf: Leaving directory `contrib/yaml-0.1.4'
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
configure.ac:36: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1[root@www twemproxy]# mkdir /etc/twemproxy/conf[root@www twemproxy]# cat /etc/twemproxy/conf/nutcracker.ymlredis-cluster: listen: 0.0.0.0:22122 hash: fnv1a_64 distribution: ketama timeout: 400 backlog: 65535 preconnect: true redis: true server_connections: 1 auto_eject_hosts: true server_retry_timeout: 60000 server_failure_limit: 3 servers: - 172.16.0.172:6546:1 redis01 - 172.16.0.172:6547:1 redis02
구성 옵션 소개:
redis-cluster: 이 구성 세그먼트에 이름을 지정합니다. 여러 구성 세그먼트가 있을 수 있습니다.
듣기: 모니터링 IP 및 포트 포트를 설정합니다. : 특정 해시 함수는 md5, crc16, crc32, finv1a_32, fnv1a_64, hsieh, murmur, jenkins 등을 지원합니다. 일반적으로 fnv1a_64를 선택하고 기본값도 fnv1a_64입니다.
다시 작성: hash_tag 함수를 사용하여 키에 따라 함수를 조정하세요. 키의 해시 값을 부분적으로 계산합니다. Hash_tag는 두 개의 문자로 구성되며, 하나는 hash_tag의 시작이고 다른 하나는 hash_tag의 끝입니다. hash_tag의 시작과 끝 사이에는 키의 해시 값을 계산하는 데 사용되는 부분이 있으며, 계산된 결과는 다음과 같습니다. 서버를 선택하는 데 사용됩니다. 예: hash_tag가 "{}"로 정의된 경우 "user:{user1}:ids" 및 "user:{user1}:tweets"의 키 값이 있는 해시 값은 " user1"이며 결국 동일한 서버에 매핑됩니다. 그리고 "user:user1:ids"는 전체 키를 사용하여 해시를 계산하며, 이는 다른 서버에 매핑될 수 있습니다.
배포: 해시 알고리즘을 지정합니다. 이 해시 알고리즘은 위의 해시된 키가 여러 서버에 배포되는 방식을 결정합니다. 기본값은 "ketama" 일관된 해싱입니다. ketama: ketama 일관성 해시 알고리즘은 서버를 기반으로 해시 링을 구성하고 링의 노드에 해시 범위를 할당합니다. 케타마의 장점은 단일 노드를 추가하거나 삭제한 후 전체 클러스터에 캐시된 키 값을 최대한 재사용할 수 있다는 점이다. Modula: Modula는 키 값의 해시 값을 기반으로 모듈로를 취하고 모듈로 결과를 기반으로 해당 서버를 선택합니다. Random : 무작위란 키 값의 해시가 무엇이든 서버를 무작위로 키 값 연산의 대상으로 선택하는 것을 의미합니다.
timeout: twemproxy의 시간 초과를 설정합니다. 시간 초과 후 서버로부터 응답이 수신되지 않으면 시간 초과 오류 메시지 SERVER_ERROR 연결 시간 초과가 클라이언트에 전송됩니다. TCP 백로그(연결 대기 큐)의 기본값은 512입니다.
preconnect: 시스템이 시작될 때 twemproxy가 모든 redis와 연결을 설정할지 여부를 지정합니다. 기본값은 부울 값입니다.
redis: Redis가 추가되지 않은 경우 이 구성 섹션을 사용할지 여부를 지정합니다. , memcached 클러스터에 대한 프록시 역할을 할 수 있습니다(이것이 Twemproxy를 redis로 사용하거나 memcached 클러스터 프록시로 사용하는 경우의 유일한 차이점입니다).
redis_auth: 백엔드 Redis에 인증이 켜져 있으면 redis_auth가 필요합니다.
server_connections: twemproxy와 각 redis 서버 간의 연결 수는 기본적으로 1입니다. 1보다 크면 사용자 명령이 다른 연결로 전송될 수 있으며 이로 인해 명령의 실제 실행 순서가 달라질 수 있습니다. 지정된 사용자와 일치하지 않음(동시성과 유사)
auto_eject_hosts: 노드가 응답할 수 없는 경우 제거 여부. 기본값은 true입니다. 그러나 노드가 제거된 후에는 머신 수가 감소하고 머신 해시 위치가 변경되면 일부 키가 적중되지 않습니다. 그러나 프로그램 연결이 제거되지 않으면 오류가 보고됩니다.
server_retry_timeout: 서버 연결 시간 간격을 밀리초 단위로 제어합니다. 기본값은 30000밀리초입니다.
server_failure_limit：Redis连续超时的次数，超过这个次数就视其为无法连接，如果auto_eject_hosts设置为true，那么此Redis会被移除；
servers：一个pool中的服务器的地址、端口和权重的列表，包括一个可选的服务器的名字，如果提供服务器的名字，将会使用它决定server的次序，从而提供对应的一致性hash的hash ring。否则，将使用server被定义的次序，可以通过两种字符串格式指定’host:port:weight’或者’host:port:weight name’。一般都是使用第二种别名的方式，这样当其中某个Redis节点出现问题时，可以直接添加一个新的Redis节点但服务器名字不要改变，这样twemproxy还是使用相同的服务器名称进行hash ring，所以其他数据节点的数据不会出现问题（只有挂点的机器数据丢失）。
PS：要严格按照Twemproxy配置文件的格式来，不然就会有语法错误；另外，在Twemproxy的配置文件中可以同时设置代理Redis集群或Memcached集群，只需要定义不同的配置段即可。
刚已经加好了配置文件，现在测试下配置文件：
[root@www twemproxy]# /etc/twemproxy/sbin/nutcracker -tnutcracker: configuration file 'conf/nutcracker.yml' syntax is ok
说明配置文件已经成功，现在开始运行nutcracker：
[root@www ~]# /etc/twemproxy/sbin/nutcracker -c /etc/twemproxy/conf/nutcracker.yml -p /var/run/nutcracker.pid -o /var/log/nutcracker.log -d选项说明: -h, –help #查看帮助文档，显示命令选项;-V, –version #查看nutcracker版本;-c, –conf-file=S #指定配置文件路径 (default: conf/nutcracker.yml);-p, –pid-file=S #指定进程pid文件路径，默认关闭 (default: off);-o, –output=S #设置日志输出路径，默认为标准错误输出 (default: stderr);-d, –daemonize #以守护进程运行;-t, –test-conf #测试配置脚本的正确性;-D, –describe-stats #打印状态描述;-v, –verbosity=N #设置日志级别 (default: 5, min: 0, max: 11);-s, –stats-port=N #设置状态监控端口，默认22222 (default: 22222);-a, –stats-addr=S #设置状态监控IP，默认0.0.0.0 (default: 0.0.0.0);-i, –stats-interval=N #设置状态聚合间隔 (default: 30000 msec);-m, –mbuf-size=N #设置mbuf块大小，以bytes单位 (default: 16384 bytes);
PS:一般在生产环境中，都是使用进程管理工具来进行twemproxy的启动管理，如supervisor或pm2工具，避免当进程挂掉的时候能够自动拉起进程。
[root@www ~]# ps aux | grep nutcrackerroot 20002 0.0 0.0 19312 916 ? Sl 18:48 0:00 /etc/twemproxy/sbin/nutcracker -c /etc/twemproxy/conf/nutcracker.yml -p /var/run/nutcracker.pid -o /var/log/nutcracker.log -d root 20006 0.0 0.0 103252 832 pts/0 S+ 18:48 0:00 grep nutcracker [root@www ~]# netstat -nplt | grep 22122tcp 0 0 0.0.0.0:22122 0.0.0.0:* LISTEN 20002/nutcracker
这里我们使用第一种方案在同一台主机上测试Twemproxy代理Redis集群，一个twemproxy和两个Redis节点（想添加更多的也可以）。Twemproxy就是用上面的配置了，下面只需要增加两个Redis节点。
在安装Redis之前，需要安装Redis的依赖程序tcl，如果不安装tcl在Redis执行make test的时候就会报错的哦。
[root@www ~]# yum install -y tcl[root@www ~]# wget https://github.com/antirez/redis/archive/3.2.0.tar.gz[root@www ~]# tar xvf 3.2.0.tar.gz -C /usr/local[root@www ~]# cd /usr/local/[root@www local]# mv redis-3.2.0 redis[root@www local]# cd redis[root@www redis]# make[root@www redis]# make test[root@www redis]# make install
[root@www ~]# mkdir /data/redis-6546[root@www ~]# mkdir /data/redis-6547[root@www ~]# cat /data/redis-6546/redis.confdaemonize yes pidfile /var/run/redis/redis-server.pid port 6546bind 0.0.0.0 loglevel notice logfile /var/log/redis/redis-6546.log [root@www ~]# cat /data/redis-6547/redis.confdaemonize yes pidfile /var/run/redis/redis-server.pid port 6547bind 0.0.0.0 loglevel notice logfile /var/log/redis/redis-6547.log
PS：简单提供两个Redis配置文件，如果开启了Redis认证，那么在twemproxy中也需要填写Redis密码。
[root@www ~]# /usr/local/redis/src/redis-server /data/redis-6546/redis.conf[root@www ~]# /usr/local/redis/src/redis-server /data/redis-6547/redis.conf[root@www ~]# ps aux | grep redisroot 23656 0.0 0.0 40204 3332 ? Ssl 20:14 0:00 redis-server 0.0.0.0:6546 root 24263 0.0 0.0 40204 3332 ? Ssl 20:16 0:00 redis-server 0.0.0.0:6547
首先twemproxy配置项中servers的主机要配置正确，然后连接Twemproxy的22122端口即可测试。
[root@www ~]# redis-cli -p 22122127.0.0.1:22122> set key vlaue OK 127.0.0.1:22122> get key"vlaue"127.0.0.1:22122> FLUSHALL Error: Server closed the connection 127.0.0.1:22122> quit
上面我们set一个key，然后通过twemproxy也可以获取到数据，一切正常。但是在twemproxy中使用flushall命令就不行了，不支持。
然后我们去找分别连接两个redis节点，看看数据是否出现在某一个节点上了，如果有，就说明twemproxy正常运行了。
[root@www ~]# redis-cli -p 6546127.0.0.1:6546> get key (nil) 127.0.0.1:6546>
由上面的结果我们可以看到，数据存储到6547节点上了。目前没有很好的办法明确知道某个key存储到某个后端节点了。
Twemproxy没有为启动提供脚本，只能通过命令行参数启动。所以，无法使用对twemproxy进行reload的操作，在生产环境中，一个应用无法reload（重载配置文件）是一个灾难。当你对twemproxy进行增删节点时如果直接使用restart的话势必会影响线上的业务。所以最好的办法还是reload，既然twemproxy没有提供，那么可以使用kill命令带一个信号，然后跟上twemproxy主进程的进行号即可。
kill -SIGHUP PID
注意，PID就是twemproxy master进程。
위 내용은 Redis 데이터 샤딩을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
