0.前言
Redis运维手册
1.redis cluster 集群搭建
1.1 redis 启动/停止
停止节点1
2
3# redis-cli -c -a 123456 shutdown
//或
# kill <pid : ps -ef|grep redis>
启动节点1
2
3#service redis start
//或
# redis-server redis.conf
1.2 redis cluster 配置
配置集群：
1 | cd /usr/local/redis-4.0.12/src/ |
查看集群节点：
1 | redis-cli -a 123456 -p 6379 cluster nodes |
检查分片情况(任意一台)1
./redis-trib.rb check 10.29.184.66:6481
2.redis密码修改
2.1 修改配置文件
1.redis.conf中修改密码
requirepass “zx0923ldz”
masterauth “zx0923ldz”
2.find / -name “client.rb”（无需修改）
vim /usr/local/rvm/gems/ruby-2.4.1/gems/redis-4.0.1/lib/redis/client.rb
修改密码
3.修改redis密码（无需修改）
vi /etc/init.d/redis
2.2 重启redis服务
1.每个节点停止/启动redis服务
1 | # cd /data/redisCluster/7000/ |
1 | # cd /usr/local/redis-4.0.12/etc/ |
2.3 查看集群状态
1 | # redis-cli -c -p 6379 -a "zx0923ldz" cluster nodes |
3.redis连接数优化
3.1 查看配置的最大连接数
1 | # CONFIG GET maxclients |
查看当前连接数：
1 | # info clients |
查看连接的客户端详情：
1 | # CLIENT LIST |
4.查看redis命令别名
在配置文件 redis.conf 中查找 “rename-command” 相关的配置
5.zset读取与修改
1 | //读取zset下key的score |
6.redis 使用注意的几个问题
6.1 缓存穿透
问题描述：我们将缓存数据以K/V的形式存储在Redis中，通过查询key是否在Redis中存在来判断是否命中缓存。一般情况下我们只将查询结果不为空的数据进行缓存。缓存穿透指的是前端请求的数据在缓存中一定不存在，导致请求直接访问数据库，若恶意构造大量这样的请求访问系统，那么数据库有可能会因为访问量过大而被压垮。
解决方案：
1.对查询结果为空的key也进行缓存。当我们缓存空数据时，再有相同条件的查询请求时，直接返回空即可而不必去请求数据库。由于导致结果为空值的查询条件可能会比较多，这样会导致缓存中存在大量value为空值的KV对，为了解决这个问题，我们可以将数据为空的缓存的过期时间设置的较短一些，使其快速过期，以释放内存空间。
2.使用布隆过滤器。我们按照查询条件去查询数据，查询条件一定是有限的，我们可以将所有可能的查询参数组合都放入布隆过滤器中，在controller中进行校验，在布隆过滤器中不存在的参数组合则会被过滤掉直接返回。这样连缓存层都不用访问了。
6.2 缓存雪崩
问题描述：缓存雪崩指的是缓存服务器重启或者缓存服务器宕机，那么此时所有的请求都会到达数据库层，导致数据库被压垮。
解决方案：使用缓存服务器集群，保证缓存的高可用，这个方案更偏向于架构与运维一些。
6.3 热点key
问题描述：热点key其实可以看做缓存雪崩的一个子类，这里把他分出来是为了结构更加清晰一点。一般情况下我们会给缓存设置过期时间，热点key指的是对于一些请求量较高的热点数据而言，一旦集中过期，此时将会有大量请求落在数据库层，从而可能会导致数据库崩溃。
解决方案：
1.错开过期时间。为了防止一批热点key同时失效，我们可以为这些key设置不同的过期时间，使其过期时间尽量错开。
2.使用互斥锁。利用Redis的setnx命令或者多参数的set命令实现互斥锁，只让一个线程去查询数据库构建缓存，其他线程等待该线程执行完成，重新从缓存获取数据就可以了。
3.永不过期。指的是不为缓存设置过期时间，只在value中存一个逻辑上的过期时间，每次get发现逻辑过期时间小于当前时间则新建一个线程去数据库重新获取数据构建缓存。
4.接口限流。这个方案就不涉及缓存操作相关代码了，就纯粹是做接口上的限流操作。