一 Linux配置优化
1.1 内存分配控制
vm.overcommit_memory
Redis在启动的时候，可能会出现这样的日志：
什么是overcommit?Linux对大部分的申请内存的请求回复yes，以便能够运行更多的程序。申请内存后，并不会马上使用内存，这种技术叫做overcommit。如果Redis启动有上述日志说明vm.overcommit_memory=0，Redis提示设置为1.
vm.overcommit_memory用来设置内存分配策略，有三个可选值：
日志中Background save代表就是bgsave和bgrewriteaof，如果当前可用内存不足，操作系统应该如何处理fork操作。如果vm.overcommit_memory=0，代表没有可用内存，就申请内存失败，对应到Redis就是执行fork失败，在Redis日志出现Cannot allocate memory
查看这个值：
cat /proc/sys/vm/overcommit_memory
0
设置这个值：
echo "vm.overcommit_memory=1" >>/etc/sysctl.conf
sysctl vm.overcommit_memory=1
最佳实践：
# 设置合理的maxmemory参数，保证机器有20%-30%的闲置内存
# 设置vm.overcommit_memory=1，防止极端情况下会造成fork失败
1.2swappiness
Swappiness对于操作系统来说比较重要，当物理内存不足，可以将一部分内存页进行交换操作，以解决燃煤直接。但是swap是由硬盘提供的，对需要高并发，高吞吐的应用来说，磁盘IO通常会成为系统瓶颈。
在Linux中，并不是要等到所有物理内存都使用完才会使用到swap，参数swappiness会决定操作系统使用swap的倾向程度。取值范围0-100，swappiness值越大，说明操作系统可能使用swap的概率越高，swappiness值越小，说明操作系统可能使用swap的概率越小，更倾向于使用物理内存。
其默认值是60.
设置swappiness:
echo vm.swappiness=值 >> /etc/sysctl.conf
监控swap
# free命令查看内存使用情况：
# vmstat: 查看系统相关性能指标，其中包含负载，CPU，内存，swap，IO先关属性，其中和swap有关的 指标是si 和 so,分别表示swap in 和 swap out
vmstat 秒数
# 查看指定进程的swap使用情况
Linux中/proc/{pid}/存储指定进程相关的信息，其中/proc/{pid}/smaps记录了当前进程所对应内存映像信息。
1.3THP(Transparent Huge Pages)
在Redis启动的时候，如果发现有这个警告：
建议修改THP的相关配置，Linux 内核在2.6.38增加了THP的特性支持大内存页2MB的分配，默认开启。
开启的时候，可以降低fork子进程的速度，但fork之后，每一个内存页从原来4KB变为2MB，大幅度增加重写期间父进程的消耗。
同时每次写命令引起的复制内存页单位放大了512倍，会拖慢写操作的执行时间，导致大量写操作慢查询。因此Redis建议将此特性禁用。
echo never >/sys/kernel/mm/transparent_hugepage/enabled
为了重启THP配置依然有效，可以在/etc/rc.local中追加
vim /etc/rc.local
echo never >/sys/kernel/mm/transparent_hugepage/enabled
1.4OOM Killer
OOM Killer会在可用内存不足的情况下，杀掉用户进程，他会为每一个用户进程设置一个权值，这个权值越高，被杀掉的可能越大，每一个进程的权值存放在/proc/{pid}/oom_score中，这个值是受/proc/{pid}/oom_adj的控制的，当oom_adj设置为最小值时，该进程不会被OOM Killer杀掉：
echo {score} > /proc/{pid}/oom_adj
1.5 使用NTP
NTP: Network Time Protocal，网络时间协议，是一种保证不同机器时钟一致性的服务。如果集群或者高可用时间不同步，可能有时候会带来些问题。
yum install ntp -y
修改第一台/etc/ntp.conf
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
restrict 192.168.3.0 mask 255.255.255.0 nomodifynotrap
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
service ntpd start
chkconfig ntpd on
其他机器
crontab -e
00 1 * * * root /usr/sbin/ntpdate 192.168.3.101>> /root/ntpdate.log 2 > &1
每一台机器必须开机都启动ntpd服务
chkconfig ntpd on
service ntpd start
1.6ulimit
Linux可通过ulimit查看和设置系统当前用户进程的资源数。ulimit –a包含打开文件的参数，是单个用户可以同时打开的最大文件个数。
Redis允许有多个客户端通过网络进行连接，可以通过配置maxclients来限制最大客户端连接数。
Redis启动的时候，经常可以看到以下日志：
建议把maxclients设置成10032，默认是10000用来处理客户端,而且内部还会使用最多32个文件描述符。
但是Redis进程因为没有权限无法将open files设成10032
当前系统open files是4096，你可以将maxclinet设置成4096-32 = 4064个，如果想设置更高的maxclinets,使用ulimit –n来设置
1.7TCP Backlog
默认值是511，如果Linux的tcp-backlog小于Redis设置的tcp-backlog，那么在redis启动的时候会看到如下日志：
WARNING: The TCP backlog setting of 511 cannot beenforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
查看方法：cat/proc/sys/net/core/somaxconn
修改它：
echo 511 > /proc/sys/net/core/somaxconn
二flushdb/flushall误操作
当使用了flushdb或者flushall会将redis所有数据删除掉。如果有时候误删除了怎么办?
2.1AOF机制恢复
如果Redis启用了AOF机制，那么当你执行完flushall、flushdb的时候，AOF文件会记录你的命令。
这样我们就可以通过编辑AOF文件，然后把错误的命令删除后，然后恢复就可以了
但是有可能你在恢复的时候，会发生AOF重写，意味着会覆盖之前AOF文件，也就是以前的数据也丢失了，利用AOF来恢复就失效了。
所以误操作后，步骤如下：
# 调大AOF重写参数，也不能手动执行bgrewriteaof：
auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size
这样可以避免短时间内的AOF自动重写
config set auto-aof-rewrite-percentage 1000
config set auto-aof-rewrite-min-size 10000000000
# 紧接着打来AOF文件，去掉误操作的命令
# 检验AOF文件格式是否正确
/opt/app/redis/bin/redis-check-aof appendonly.aof
AOF analyzed: size=85545588, ok_up_to=85545588,diff=0
AOF is valid
2.2RDB恢复
对于RDB，我们应该区分是否是否开启了自动策略，如果是自动的，可能被重写了，那么就不好恢复了。如果不是自动的，即配置文件没有这样的配置：
save 900 1
save 300 10
save 60 10000
那么以前的数据就还在。只是有可能丢失部分数据。只要这时候有没有执行save或者bgsave这种操作，就可以。
所以AOF如果已经开启了，那么AOF来恢复是比较好的方案，但确实AOF没有启用，那也就只能使用RDB.
2.3 对于从节点而言，我们应该怎么做呢？
首先主节点如果误操作，首先主节点调大AOF重写参数，然后从节点调大AOF重写参数：
config set auto-aof-rewrite-percentage 1000
config set auto-aof-rewrite-min-size 10000000000
紧接着去掉主从节点flush相关的内容,从AOF文件中移除
*1
$8
Flushall
校验AOF数据
bin/redis-check-aof data/appendonly.aof
最后重新启动主从节点，加载数据
三 安全的redis
3.1Redis的密码机制
Redis提供了一个requirepass的配置为Redis提供密码功能，如果这样，客户端如果密码不对就不能执行命令。
客户端有两种提供密码的方式：
# 在redis-cli命令后加上-a参数
bin/redis-cli -h 192.168.3.200 -p 6379 -a 123abcAbc
# 进入redis-cli的交互式模式，敲入auth 密码
192.168.3.200:6379> auth 123abcABC
OK
一般情况下，密码最好最够复杂，64字节以上，房子暴力破解
如果是主从结构，主节点加了requirepass，那么从节点需要加上masterauth(master的requriepass配置)
3.2 伪装危险命令
Redis常见的危险命令包括：
keys: 如果键值较多，有可能阻塞Redis
flushall/flushdb: 数据全部被清除
save: 如果键值较多，存在阻塞的可能性
debug: debug reload会重启redis
config: config应该交给管理员用
shutdown: 关闭redis
如何重命名呢？
rename-command flushall cleanall
这样的话，你再执行flushall就没有用了
但是缺点就是，我们需要对客户端修改，比如jedis.flushall操作内部就是调用的flushall命令；而且rename-command不支持config set；如果AOF和RDB文件包含了rename-command之前的命令，Redis将无法启动
所以你一旦要设置，最好在第一次的时候就配置好，而且主从结构，从的配置应该和主保持一致，否则存在主从数据结构不一致的情况。
3.3 防火墙
一般来说，比较成熟的公司都会对有外网IP的服务器做端口的限制，例如只允许开放80端口，但是诸如存储服务器之类的无需对外开放。
3.4bind
3.5 定期备份数据
3.6 不使用默认端口
3.7 使用非root用户启动
四 处理bigkey
bigkey是指key对应的value所占的内存空间比较大，例如一个字符串类型value可以最大存到512M，一个list的value最多可以存储2^32-1各元素，如果按照数据结构来细分的话，可分为一般字符串类型bigkey和非字符串bigkey
字符串类型：一般认为超过10k的就是bigkey，但是这个值和具体的OPS相关
非字符串类型：体现在哈希，列表，集合类型元素过多
4.1bigkey的危害
# 内存空间不平衡：
# 超时阻塞：如果key教导，redis又是单线程，操作bigkey比较耗时，那么阻塞redis的可能性增大
# 网络负载较大：每次获取bigKey的网络流量较大，假设一个bigkey为1MB,每秒访问量为1000，那么每秒产生1000MB的流量，对于普通千兆网卡，按照字节算128M/S的服务器来说可能扛不住。而且一般服务器采用单机多实例方式来部署，所以还可能对其他实例造成影响。
4.2 如何统计有哪些bigkey
我们可以通过命令bin/redis-cli–bigkeys统计bigkey的分布 。判断一个key是否为bigkey,只需要执行debug objectkey查看serializedlength属性，表示序列化之后的字节数。
4.3 删除bigkey
当发现bigkey想删除的时候，对于string类型，一般不存在阻塞，但是对于hash,list,set,zset就不好说了
private void delBigKey(String bigkey) {
Jedis jedis = JedisUtils.getInstance().getJedis("192.168.3.200",6379);
String cursor = null;
while (true) {
ScanResult<Map.Entry<String,String>> scanResult = jedis.hscan(bigkey, cursor, new ScanParams().count(100));
// 扫描后获取新的游标
cursor = scanResult.getStringCursor();
// 获取扫描结果
List<Map.Entry<String,String>> list = scanResult.getResult();
if (CollectionUtils.isEmpty(list)) {
continue;
}
String[] fields = getFieldsFrom(list);
// 删除多个字段
jedis.hdel(bigkey,fields);
// 游标为0为止
if (cursor.equals("0")) {
break;
}
}
jedis.del(bigkey);
}
private String[] getFieldsFrom(List<Map.Entry<String, String>> list) {
List<String> fields = new ArrayList<String>();
for(Map.Entry<String,String> entry : list){
fields.add(entry.getKey());
}
return fields.toArray(new String[fields.size()]);
}
五 寻找热点key
热门新闻事件或是商品通常会给系统带来巨大的流量，对于存储这类信息的Redis来说却是一个巨大的挑战，以Redis 集群来说，它会造成整体流量的不均衡，个别节点出现OPS过大的情况。因此寻找热点key很重要。
5.1 客户端
在客户端设置全局字典（key和调用次数），每次调用Redis命令时，使用这个字典进行记录。
5.2 代理端
诸如Twemproxy和Codis都是基于代理的Redis分布式架构，所有客户端的请求都是通过代理端完成的，最适合做热点key统计
5.3Redis 服务端
使用monitor命令统计热点key,facebook开源的 redis-faina就是用python实现的一个工具:
redis-cli -h 192.168.3.200 -p 6379 -a 123abcABC monitor|head -n 10000| ./redis-faina.py
但是该方法有以下问题：
＃monitor在高并发场景下，会存在内存暴增的和影响Redis的性能的隐患
# 只适合统计单机，集群的话需要会中统计
六 配置
6.1 info
# info all: 查看所有
# info Server: 查看服务器信息
# info Clients: 查看客户端信息
# info Memory： 查看内存信息
# info Persistence: 查看持久化信息
# info Stats：查看统计信息
# info Replication: 查看复制信息
# info CPU: 查看CPU情况
# info Commandstats：查看命令统计信息
# info Cluster: 查看集群信息
# info Keyspace： 数据库key统计信息
313
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
