全部博文（51）
分类： 系统运维
2015-05-28 11:36:51
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)
1 **如果内存情况比较紧张的话，需要设定内核参数：
/etc/sysctl.conf 添加
vm.overcommit_memory=1
即使生效：sysctl vm.overcommit_memory=1
补充介绍：
echo 1 > /proc/sys/vm/overcommit_memory
内核参数说明如下：
overcommit_memory文件指定了内核针对内存分配的策略，其值可以是0、1、2。
0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2， 表示内核允许分配超过所有物理内存和交换空间总和的内存
2 下载最新的redis源码版本
解压直接安装:
Make
make PREFIX=/usr/local/redis install
从源码包里拷贝redis.conf到安装目录下
3 按需修改配置文件：
**编辑redis.conf配置文件，按需求做出适当调整，比如：
daemonize yes #转为守护进程，否则启动时会每隔5秒输出一行监控信息
save 60 1000 #减小改变次数，其实这个可以根据情况进行指定
maxmemory 256000000 #分配256M内存
部分配置文件解释
daemonize：是否以后台daemon方式运行
pidfile：pid文件位置
port：监听的端口号
timeout：请求超时时间
loglevel：log信息级别
logfile：log文件位置
databases：开启数据库的数量
save * *：保存快照的频率，第一个*表示多长时间，第三个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。
rdbcompression：是否使用压缩
dbfilename：数据快照文件名（只是文件名，不包括目录）
dir：数据快照的保存目录（这个是目录）
appendonly：是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。
appendfsync：appendonlylog如何同步到磁盘（三个选项，分别是每次写都强制调用fsync、每秒启用一次fsync、不调用fsync等待系统自己同步）
4 启动redis
/usr/local/redis/bin/redis-server /usr/local/redis/redis.conf
5 一台机器可以启动多个redis的进程，只需要复制出多个配置文件，并修改每个配置文件的路径相关的信息，然后启动就可以了，这样多个redis进程之间是相互独立的存在的。
/usr/local/redis/bin/redis-server /usr/local/redis/redis6380.conf
/usr/local/redis/bin/redis-server /usr/local/redis/redis6381.conf
/usr/local/redis/bin/redis-server /usr/local/redis/redis6382.conf
/usr/local/redis/bin/redis-server /usr/local/redis/redis6383.conf
Redis的主从配置就是为一个redis的服务器配置一个从服务器，从服务器实时的同步主服务器的数据，从而作为一个主服务器数据的实时备份或者只读的从服务器来使用。
1 配置过程
只需要在从服务器的配置文件里增加主服务器相关的配置信息即可
slaveof 172.21.13.2 6379
slave-read-only设置从服务器是否可写。
Twemproxy,也叫nutcraker。是一个twtter开源的一个redis和memcache代理服务器。 redis作为一个高效的缓存服务器，非常具有应用价值。但是当使用比较多的时候，就希望可以通过某种方式 统一进行管理。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：它全部用C写成，使用Apache 2.0 License授权。Twemproxy 通过引入一个代理层，可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配，使应用程序只需要在 Twemproxy 上进行操作，而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。
1 twemproxy特性：
? 支持失败节点自动删除
? 可以设置重新连接该节点的时间
? 可以设置连接多少次之后删除该节点
? 该方式适合作为cache存储
? 支持设置HashTag
? 通过HashTag可以自己设定将两个KEYhash到同一个实例上去。
? 减少与redis的直接连接数
? 保持与redis的长连接
? 可设置代理与后台每个redis连接的数目
? 自动分片到后端多个redis实例上
? 多种hash算法：能够使用不同的策略和散列函数支持一致性hash。
? 可以设置后端实例的权重
? 避免单点问题
? 可以平行部署多个代理层.client自动选择可用的一个
? 支持redis pipelining request
支持请求的流式与批处理，降低来回的消耗
? 支持状态监控
? 可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串
? 可设置监控信息刷新间隔时间
? 高吞吐量
? 连接复用，内存复用。
? 将多个连接请求，组成reids pipelining统一向redis请求。
2 安装与配置
autoconf下载地址：
twemproxy的安装要求autoconf的版本在2.64以上，否则提示”error: Autoconf version 2.64 or higher is required“。autoconf直接make和make install即可。
Twemproxy下载 git clone
cd twemproxy
autoreconf -fvi
./configure --prefix=/usr/local/twemproxy
Make
Make install
修改配置文件/usr/local/twemproxy/conf/nutcracker.yml
启动 nutcracker -d –c nutcracker.yml -s 22221 -m 1024
redis1:
listen: 0.0.0.0:8888
redis: true
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: false
timeout: 400
servers:
- 192.168.149.128:6380:1
- 192.168.149.128:6381:1
- 192.168.149.128:6382:1
- 192.168.149.128:6383:1
redis2:
listen: 0.0.0.0:9999
redis: true
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: false
timeout: 400
servers:
- 192.168.149.128:6380:1
- 192.168.149.128:6381:1
- 192.168.149.128:6382:1
- 192.168.149.128:6383:1
配置项解释
redis1:
listen: 127.0.0.1:6379 #使用哪个端口启动Twemproxy
redis: true #是否是Redis的proxy
hash: fnv1a_64 #指定具体的hash函数
distribution: ketama #具体的hash算法
auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点
timeout: 400 #超时时间（毫秒）
server_retry_timeout: 2000 #重试的时间（毫秒）
server_failure_limit: 1 #结点故障多少次就算摘除掉
servers: #下面表示所有的Redis节点（IP:端口号:权重）
- 127.0.0.1:6380:1
- 127.0.0.1:6381:1
- 127.0.0.1:6382:1
你可以同时开启多个 Twemproxy (对应配置文件里的redis1和redis2)实例，它们都可以进行读写，这样你的应用程序就可以完全避免所谓的单点故障。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动 Redis Sentinel 。
1 安装
和redis的安装步骤一样，安装完成后安装bin目录下会生成redis-sentinel命令文件。
创建配置文件sentinel.conf
daemonize yes
port 26379
logfile "/usr/local/sentinel/sentinel.log"
pidfile "/usr/local/sentinel/sentinel.pid"
dir /tmp
sentinel monitor redis-128-6380-master 192.168.149.128 6380 1
sentinel down-after-milliseconds redis-128-6380-master 60000
sentinel failover-timeout redis-128-6380-master 180000
sentinel parallel-syncs redis-128-6380-master 1
配置文件解释：
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决。
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。
2 Sentinel API
在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。Sentinel 接受 Redis 协议格式的命令请求， 所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。
有两种方式可以和 Sentinel 进行通讯：第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态， 以及 Sentinel 所知道的关于其他 Sentinel 的信息， 诸如此类。另一种方法是使用发布与订阅功能， 通过接收 Sentinel 发送的通知： 当执行故障转移操作， 或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相应的信息。
Sentinel 命令
以下列出的是 Sentinel 接受的命令：
PING ：返回 PONG 。
SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。
SENTINEL slaves ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。
SENTINEL get-master-addr-by-name ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。
SENTINEL reset ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。
SENTINEL failover ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
发布与订阅信息
SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三个命令实现了发布与订阅信息泛型（Publish/Subscribe messaging paradigm）， 在这个实现中， 发送者（发送信息的客户端）不是将信息直接发送给特定的接收者（接收信息的客户端）， 而是将信息发送给频道（channel）， 然后由频道将信息转发给所有对这个频道感兴趣的订阅者。发送者无须知道任何关于订阅者的信息， 而订阅者也无须知道是那个客户端给它发送信息， 它只要关注自己感兴趣的频道即可。对发布者和订阅者进行解构（decoupling）， 可以极大地提高系统的扩展性（scalability）， 并得到一个更动态的网络拓扑（network topology）。
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。 订阅一个主服务器切换的消息为：PSUBSCRIBE +switch-master 。
这样就可以收到关于主服务器切换频道的消息。
BGSAVE
CLIENT GETNAME
CLIENT KILL
CLIENT LIST
CLIENT SETNAME
CONFIG GET
CONFIG RESETSTAT
CONFIG REWRITE
CONFIG SET
DBSIZE
DEBUG OBJECT
DEBUG SEGFAULT
FLUSHALL
FLUSHDB
INFO
LASTSAVE
MONITOR
PSYNC
SAVE
SHUTDOWN
SLAVEOF
SLOWLOG
SYNC
TIME
