- 浏览: 65856 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (69)
- 系统评估,设计与规划 (4)
- 性能测试与诊断 (3)
- 硬件,网络与操作系统 (1)
- &&&&性能层面&&&& (0)
- 负载均衡与反向代理 (4)
- 应用扩容-RPC,SOA和微服务 (11)
- 数据扩容-应用层面&中间件 (6)
- 网络协议框架 (0)
- OpenResty (5)
- 缓存 (7)
- 应用服务器:基础及优化 (2)
- JVM:基础及优化 (1)
- Java及开发框架相关技术 (2)
- 关系型数据库:基础优化及读写分离 (9)
- NOSQL数据库 (0)
- 开发工具 (1)
- 收藏 (1)
- 实践项目总结 (0)
- 搜索引擎 (1)
- Zookeeper (1)
- &&&&可用性层面&&&& (1)
- 池化技术 (2)
- 学习 (1)
- 分布式系统链路追踪 (1)
- 开发效率 (1)
- jdk使用及源码解析 (1)
- 高级架构设计师考试 (0)
- JAVA设计模式 (1)
- JAVA虚拟机 (1)
- 数据结构与算法 (1)
- 网络 (1)
- 多线程 (0)
- 源码解析 (1)
- 业务场景及解决方案 (0)
- 石杉架构 (1)
最新评论
1.介绍
1.1 一句话介绍Twemproxy是一个Redis/Memcached代理中间件,可以实现诸如分片逻辑、HashTag、减少连接数等功能;尤其在有大量应用服务器的场景下Twemproxy的角色就凸显了,能有效减少连接数。
1.2 特点
Twemproxy是一种代理分片机制,由Twitter开源。
Twemproxy作为代理,可接受来自多个程序的访问,按照路由规则,转发给后台的各个Redis服务器,再原路返回。该方案很好的解决了单个Redis实例承载能力的问题,通过Twemproxy可以使用多台服务器来水平扩张redis服务,可以有效的避免单点故障问题
当然,Twemproxy本身也是单点,需要用Keepalived做高可用方案。
虽然使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失(twitter测试约20%),但是能够提高整个系统的HA也是相当划算的。
twemproxy不光实现了redis协议,还实现了memcached协议,什么意思?换句话说,twemproxy不光可以代理redis,还可以代理memcached,官方说明:
twemproxy (pronounced "two-em-proxy"), aka nutcracker is a fast and lightweight proxy for memcachedand redis protocol. It was built primarily to reduce the number of connections to the caching servers on the backend. This, together with protocol pipeling and sharding enables you to horizontally scale your distributed caching architecture.
Twemproxy架构:
通常会结合keepalived来实现Twemproxy的高可用。架构图如下:
2.安装、配置与启动
2.1环境准备:
>>安装路径 /usr/local/twemproxy
>>需要安装autoconf、automake、libtool工具
说明:twemproxy的安装要求autoconf的版本在2.64以上,否则提示"error: Autoconf version 2.64 or higher is required"。
使用以下命令下载的autoconf版本如果小于2.64,方案如下:
(1) 查询当前版本 rpm -qf /usr/bin/autoconf
autoconf-2.63-5.1.el6.noarch
(2) 卸载当前版本 rpm -e --nodeps autoconf-2.63-5.1.el6.noarch
(3) 安装最新版本
[root@BobServerStation twemproxy]# wget ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.68.tar.gz
[root@BobServerStation twemproxy]# tar zxvf autoconf-2.68.tar.gz
[root@BobServerStation twemproxy]# cd autoconf-2.68
[root@BobServerStation twemproxy]# ./configure --prefix=/usr/
[root@BobServerStation twemproxy]# make && make install
[ubuntu]
apt-get install autoconf automake
apt-get install libtool
[centos]
#autoconf这一步使用此命令装的版本是小于2.64的,需要上面的方法安装
yum -y install autoconf
yum -y install automake
yum -y install libtool
2.2 安装及配置
2.2.1安装
cd /usr/localwget https://github.com/twitter/twemproxy/archive/v0.4.0.tar.gz
tar -xvf v0.4.0.tar.gz
cd twemproxy-0.4.0/
autoreconf -fvi
mkdir /usr/local/twemproxy
./configure --prefix=/usr/local/twemproxy
make -j 8
make install
注意:如上安装方式在有些服务器上可能在大量如mset时可能导致Twemproxy崩溃,需要使用如 CFLAGS="-O1" ./configure && make或CFLAGS="-O3 -fno-strict-aliasing" ./configure && make安装。
2.2.2配置变量
#设置环境变量:
echo "PATH=$PATH:/usr/local/twemproxy/sbin/" >> /etc/profile
source /etc/profile
#创建目录
cd /usr/local/twemproxy
mkdir run conf
#添加proxy配置文件
vi /usr/local/twemproxy/conf/nutcracker.yml
server1:
listen: 127.0.0.1:1111
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 192.168.1.106:6379:1
- 192.168.1.107:6379:1
- 192.168.1.108:6379:1
#把conf目录复制到/usr/local/twemproxy/sbin/目录下
cp -r /usr/local/twemproxy-0.4.0/conf /usr/local/twemproxy/sbin/
2.3启动及测试
(1)启动命令:nutcracker -d -c /usr/local/twemproxy/conf/nutcracker.yml -p /usr/local/twemproxy/run/redisproxy.pid -o /usr/local/twemproxy/run/redisproxy.log
Options:
-h, –help : 查看帮助文档,显示命令选项
-V, –version : 查看nutcracker版本
-t, –test-conf : 测试配置脚本的正确性
-d, –daemonize : 以守护进程运行
-D, –describe-stats : 打印状态描述
-v, –verbosity=N : 设置日志级别 (default: 5, min: 0, max: 11)
-o, –output=S : 设置日志输出路径,默认为标准错误输出 (default: stderr)
-c, –conf-file=S : 指定配置文件路径 (default: conf/nutcracker.yml)
-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)
-p, –pid-file=S : 指定进程pid文件路径,默认关闭 (default: off)
-m, –mbuf-size=N : 设置mbuf块大小,以bytes单位 (default: 16384 bytes)
(2)查看是否启动成功
ps aux | grep nutcracker
(3)简单测试
redis-cli -p 1111127.0.0.1:1111> set i 1
OK
127.0.0.1:1111> get i
"1"
Twemproxy文档请参考https://github.com/twitter/twemproxy。到此基本的安装就完成了。接下来做一些介绍。
(4)配置启动/重启/停止脚本方便操作
# cp /usr/local/twemproxy-0.4.0/scripts/nutcracker.init /usr/local/twemproxy
# chmod +x /usr/local/twemproxy/sbin/nutcracker.init
# vi /usr/local/twemproxy/sbin/nutcracker.init
-- 将OPTIONS改为 OPTIONS="-d -c /usr/local/twemproxy/conf/nutcracker.yml"
-- 注释掉. /etc/rc.d/init.d/functions;
-- 将daemon --user ${USER} ${prog} $OPTIONS改为${prog} $OPTIONS;
-- 将killproc改为killall。
这样就可以使用如下脚本进行启动、重启、停止了。
nutcracker.init {start|stop|status|restart|reload|condrestart}
[报错]:若nutcracker没设置为全局变量,则会报此错
nutcracker: command not found
写了全路径:/usr/local/twemproxy/run/${prog} $OPTIONS
(5)附加:(暂未实现)
将 Twemproxy配置成服务:
已下是相关资料:
按上面的操作步骤,Redis 的启动脚本为:/usr/local/src/redis3.0/utils/redis_init_script
将启动脚本复制到/etc/rc.d/init.d/目录下,并命名为 redis:
# cp /usr/local/src/redis3.0/utils/redis_init_script /etc/rc.d/init.d/redis
编辑/etc/rc.d/init.d/redis,修改相应配置,使之能注册成为服务:
# vi /etc/rc.d/init.d/redis
2.4Twemproxy集群(分片)设置
一旦涉及到一台物理机无法存储的情况就需要考虑使用分片机制将数据存储到多台服务器,可以说是Redis集群;
如果客户端都是如Java没什么问题,但是如果有多种类型客户端(如PHP、C)等也要使用那么需要保证它们的分片逻辑是一样的;
另外随着客户端的增加,连接数也会随之增多,发展到一定地步肯定会出现连接数不够用的;
此时Twemproxy就可以上场了。主要作用:分片、减少连接数。另外还提供了Hash Tag机制来帮助我们将相似的数据存储到同一个分片。
注:另外也可以参考豌豆荚的https://github.com/wandoulabs/codis。
>>1.基本配置
server1:
listen: 127.0.0.1:1111
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 192.168.1.106:6379:1
- 192.168.1.107:6379:1
- 192.168.1.108:6379:1
server1:是给当前分片配置起的名字,一个配置文件可以有多个分片配置;
listen : 监听的ip和端口;
hash:散列算法;
distribution:分片算法,比如一致性Hash/取模;
timeout:连接后端Redis或接收响应的超时时间;
redis:是否是redis代理,如果是false则是memcached代理;
servers:代理的服务器列表,该列表会使用distribution配置的分片算法进行分片;
>>2.分片算法
hash算法:
one_at_a_time
md5
crc16
crc32 (crc32 implementation compatible with libmemcached)
crc32a (correct crc32 implementation as per the spec)
fnv1_64
fnv1a_64
fnv1_32
fnv1a_32
hsieh
murmur
jenkins
分片算法:
ketama(一致性Hash算法)
modula(取模)
random(随机算法)
>>3.服务器列表
servers:
- ip:port:weight alias
如
servers:
- 127.0.0.1:6660:1
- 127.0.0.1:6661:1
或者
servers:
- 127.0.0.1:6660:1 server1
- 127.0.0.1:6661:1 server2
推荐使用后一种方式,默认情况下使用ip:port:weight进行散列并分片,这样假设服务器宕机换上新的服务器,那么此时得到的散列值就不一样了,因此建议给每个配置起一个别名来保证映射到自己想要的服务器。即如果不使用一致性Hash算法来作缓存服务器,而是作持久化存储服务器时就更有必要了(即不存在服务器下线的情况,即使服务器ip:port不一样但仍然要得到一样的分片结果)。
>>4.一致性Hash与服务器宕机
如果我们把Redis服务器作为缓存服务器并使用一致性Hash进行分片,当有服务器宕机时需要自动从一致性Hash环上摘掉,或者其上线后自动加上,此时就需要如下配置:
#是否在节点故障无法响应时自动摘除该节点,如果作为存储需要设置为为false
auto_eject_hosts: true
#重试时间(毫秒),重新连接一个临时摘掉的故障节点的间隔,如果判断节点正常会自动加到一致性Hash环上
server_retry_timeout: 30000
#节点故障无法响应多少次从一致性Hash环临时摘掉它,默认是2
server_failure_limit: 2
3.HashTag
3.1作用
比如一个商品有:商品基本信息(p:id:)、商品介绍(d:id:)、颜色尺码(c:id:)等,假设我们存储时不采用HashTag将会导致这些数据不会存储到一个分片,而是分散到多个分片,这样获取时将需要从多个分片获取数据进行合并,无法进行mget;那么如果有了HashTag,那么可以使用“::”中间的数据做分片逻辑,这样id一样的将会分到一个分片。
3.2配置
# vi /usr/local/twemproxy/conf/nutcracker.yml
nutcracker.yml配置如下
server1:
listen: 127.0.0.1:1111
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
hash_tag: "::"
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 192.168.1.106:6379:1 server1
- 192.168.1.107:6379:1 server2
- 192.168.1.108:6379:1 server3
3.3 测试HashTag
redis-cli -p 1111
127.0.0.1:1111> set p:12: 1
OK
127.0.0.1:1111> set d:12: 1
OK
127.0.0.1:1111> set c:12: 1
OK
在我的某台服务器上:
redis-cli -p 6660
127.0.0.1:6660> get p:12:
"1"
127.0.0.1:6660> get d:12:
"1"
127.0.0.1:6660> get c:12:
"1"
4.支持的Redis命令
不是所有Redis命令都支持,请参考https://github.com/twitter/twemproxy/blob/master/notes/redis.md。
5.对于扩容最简单的办法是:
1、创建新的集群;
2、双写两个集群;
3、把数据从老集群迁移到新集群(不存在才设置值,防止覆盖新的值);
4、复制速度要根据实际情况调整,不能影响老集群的性能;
5、切换到新集群即可,如果使用Twemproxy代理层的话,可以做到迁移对读的应用透明。
6.twemproxy主从备份和集群相结合
6.1 设置从库
192.168.1.106:6660 为 192.168.1.106:6660的从库,配置方法见主从配置
192.168.1.107:6660 为 192.168.1.107:6660的从库,配置方法见主从配置
192.168.1.108:6660 为 192.168.1.108:6660的从库,配置方法见主从配置
6.2 配置nutcracker.yml
vi /usr/local/twemproxy/conf/nutcracker.yml
配置server-slave:
server-slave:
listen: 127.0.0.1:1112
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
hash_tag: "::"
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 192.168.1.106:6660:1 server1
- 192.168.1.107:6660:1 server2
- 192.168.1.108:6660:1 server3
注:这里需写成server1 server2 server3和之前的一致
6.3 测试
redis-cli -p 6379 > set
redis-cli -p 6660 > get
============生产目标的架构=============
>>>>正经本地LocalRedis做法:106 107 108是一个主集群; 然后在116 117 118作为其从集群;需要修改:将主集群移到新的集群上面。
我的做法是:在某台新机器上,构建 6379 6660 6661作为3台分片机器,106:6379(6379从机) 107:6379(6660从机) 108:6379(6661从机)
待做
发表评论
-
Ehcache与Guava Cache的区别浅谈
2017-08-12 21:43 1605http://www.cnblogs.com/liushiji ... -
本地缓存-应用级缓存之Guava Cache
2017-08-12 21:36 620参考: 1.http://blog.csdn.net/k ... -
SSDB介绍与使用
2017-07-26 17:09 1169一.SSDB介绍 由于Redis本身主要用作内存缓 ... -
Redis 3.0 cluster 集群
2017-07-24 13:22 531参考资料: 吴水成老师的<<Redi ... -
Redis语法,Key值设计及常用案例介绍
2017-07-22 17:56 1505目录: 1.Redis的基础语法学习 2.Key的设计 ... -
Redis-sentinel哨兵模式集群
2017-07-22 17:45 0详见:http://blog.csdn.net/dongg ... -
Redis3.0 cluster 集群实践
2017-07-22 17:49 0Redis 3.0 cluster 集群 机器说明: ... -
Redis介绍,安装使用及集群介绍
2017-07-22 06:17 590目录: 1.Redis概述 2.Redis安装、配置(主从 ...
相关推荐
总结来说,基于Redis的分布式缓存系统通过Twemproxy实现了高效的分片和负载均衡,配合`redis-twemproxy-agent`,能够在主节点故障时快速恢复服务,保证系统的高可用性和稳定性。这样的设计适用于需要处理大量并发...
7、Redis集群的批量数据查询性能优化:对于分布式的Redis集群,数据在多个实例中分布式存储,如果要优化大批量数据的批量查询性能,就需要采用hash tag分片路由+mget单分批大批量读取的优化设计。 8、高可用架构...
- 基于代理分片如 Codis 和 Twemproxy,简化客户端操作,但引入额外的性能开销。 4. 双写一致性问题通常通过事务或特定策略解决,如双删延迟策略,先删除 Redis 数据,更新数据库,等待一段时间后再删除 Redis ...
3. **哈希槽分片**:Redis Cluster使用16384个哈希槽进行数据分片,通过CRC16算法确定键属于哪个哈希槽。 4. **故障容忍能力**:即使部分节点不可用,集群仍能继续处理请求。 5. **Master-Slave模型**:每个Master...
- **基于代理的分片(Proxy-based Sharding)**:通过中间层代理软件如Twemproxy或Codis等来实现数据的分片。 - **Redis-Cluster**:内置了自动分片功能,每个集群包含多个节点,数据被均匀分布到这些节点上,用户无需...
16.7.5 分片配置 342 16.7.6 模板元数据存储HTML 342 16.7.7 库存接口访问量600w/分钟 343 16.7.8 微信接口调用量暴增 344 16.7.9 开启Nginx Proxy Cache性能不升反降 344 16.7.10 配送至读服务因依赖太多,响应时间...
- **基于代理的分片**:通过中间层代理(如Twemproxy、Codis等)实现数据分发。 - **Redis-Cluster**:内置了数据分片能力,数据被划分成16384个槽,每个Master节点负责一部分槽。 3. **寻址机制**: - 每个键...
在豌豆荚的早期,他们尝试过多种方式来扩展 Redis,包括单实例、多实例分片、通过 Twemproxy 代理分片。然而,Twemproxy 无法实现平滑的扩容和缩容,而且缺少运维界面,而官方的 Redis Cluster 因其复杂性和缺乏稳定...
- Redis Cluster:官方分布式解决方案,自动分片,支持槽移动和故障转移。 - Twemproxy:轻量级代理,用于在客户端和Redis服务器之间分发请求。 10. **Redis的应用场景** - 缓存:提高读取速度,减轻后端数据库...
Redis 集群模式则采用分片策略,常见的有客户端分片、基于代理的分片(如 Twemproxy 和 Codis)以及 Redis-Cluster 自身的分片方案。Redis-Cluster 使用槽的概念,将数据分布到多个节点,每个节点负责一部分槽,通过...
- **Proxy-based Clustering(如 Twemproxy):** 代理层通过路由规则实现数据的分发。 - **External Load Balancer:** 通过外部负载均衡器进行数据分发和管理。 #### Codis 集群原理 Codis 是一个基于 Redis 的...
twemproxy是一种代理方式,通过一致性哈希算法分发请求到多个Redis实例,并支持自动节点故障转移。codis是另一个流行的集群方案,它解决了twemproxy中的数据自动迁移问题。Redis自带的集群方案基于hash槽,并支持从...
- **Twemproxy** / **Codis**:代理层解决方案,它们位于客户端与后端Redis实例之间,负责数据分片、负载均衡等功能。 - **优点**: - 提供了水平扩展能力。 - 自动故障转移机制增强了系统的健壮性。 - **缺点*...
MongoDB数据分片、转存及恢复策略 MyCat MySQL主从复制及读写分离实战 MySQL+keepalived实现双主高可用方案实践 MySQL高性能解决方案之分库分表 数据库中间件初始Mycat 基于Mycat实习MySQL数据库读写分离 ...