概述
大数据下Redis的应用
1、Redis客户端区别
1.1 redis常用客户端
目前市面上比较流行的客户端有jedis、lettuce、redisson
•jedis
jedis客户端连接方式是基于TCP阻塞方式
•lettuce
lettuce内部是基于netty的多路复用异步非阻塞方式（目前业界解决高并发大数据的问题的思路）
•redisson
相对于上面两种使用得较少
在并发数量不大的情况下，两者性能可能差不多，jedis的性能可能还优于lettuce，但当并发量的提升，jedis的超时错误会增加，但lettuce只是平均响应时间增加和最大响应时间会增加，lettuce是已稳定性为主的
1.2 epoll模型-单线程的redis为什么快
redis内部使用epoll模型来提高链接处理能力
传统TCP链接与epoll模型的本质区别
•TCP链接存在链接数瓶颈，随着连接数的增加，响应速度会明显变慢
•epoll可支持更大数量的连接数而不会对性能有明显的影响
2、大数据下的redis的存储方案
2.1 分片模式
分片模式是把部署多个redis节点，然后由客户端决定数据分片规则，常见的分片规则就是以节点数量进行哈希分片
优点：
•服务端不需要进行繁琐的配置，由客户端决定路由规则
缺点：
•缺点很明显，如果多个节点中的某个节点挂了，将丢失这一部分数据，因为客户端还是为每个节点分配了连接，而且客户端配置分片节点IP的时候要注意
•IP列表的顺序不能随意指定顺序，IP变更也会影响数据，扩容相当麻烦。
建议：如果分片节点较少可以使用分片来适当的分摊压力
配置示例：
spring:
remote:
ecredis:
type: sharding
uri:
- 192.168.1.3:6379
- 192.168.1.4:6379
- 192.168.1.5:6379
- 192.168.1.6:6379
- 192.168.1.7:6379
db: 1
maxIdle: 10
minIdle: 5
maxActive: 10
password: GpG4fZoxsp7cTB5f
keyPrefix: 'ERP:EXPORT-CENTER:'
2.2 哨兵机制
在Redis 2.8版本开始引入，就有了哨兵这个概念，哨兵实现了自动化的故障恢复，无需关心IP是否变更。
优点：
•哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
•主从可以自动切换，系统更健壮，可用性更高。
•Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。当被监控的某个 Redis 服务器出现问题，Sentinel 通过API脚本向管理员或者其他的应用程序发送通知。
缺点：
•Redis较难支持在线扩容，对于集群，容量达到上限时在线扩容会变得很复杂。
spring:
redis:
password: 123456
sentinel:
master: master
nodes: 47.98.217.106:26379,47.98.217.109:26380,47.98.217.109:26381
timeout: 20000
database: 0
jedis:
pool:
max-active: 300
max-wait: -1
max-idle: 100
min-idle: 20
2.3 redis cluster集群
通过数据分片的方式来进行数据共享问题，同时提供数据复制和故障转移功能，包含了哨兵模式的所有功能。
优点：数据按slot来分散存储，访问任何一个master节点都可以获取任何分片上面的数据，任何一个master节点都可以做扩容或者新增master节点的时候，数据会自动分片同步迁移(redis集群的重新分片由redis内部的redis-trib负责执行)，服务器不需要下线。如果每个master使用了主从模式，那么当master发生故障的时候，下面的slave们会选举一个新的master
缺点：需要使用ruby进行部署，配置相当麻烦，维护不方便
配置示例：
spring:
redis:
password:
cluster:
nodes: 192.168.1.3:6379,192.168.1.4:6379,192.168.1.5:6379
max-redirects: 3
lettuce:
pool:
max-idle: 16
max-active: 32
min-idle: 8
2.4 cachecloud
cachecloud是一套解决方案，实现多种类型(Redis Standalone、Redis Sentinel、Redis Cluster)自动部署、解决Redis实例碎片化现象、提供完善统计、监控、运维功能、减少运维成本和误操作，提高机器的利用率，提供灵活的伸缩
优点：
使配置更简单，集群节点不再由客户端维护，配置一个domain即可自动获取节点列表
配置示例：
spring:
domain: cachecloud.server1.com:8080
remote:
ecredis:
appid: 2
type: cloud
uri:
db: 1
maxIdle: 10
minIdle: 5
maxActive: 10
password: GpG4fZoxsp7cTB5f
keyPrefix: 'ERP:EXPORT-CENTER:'
应用案例：
2.5 redis存储方案选型
•吞吐量数据量较少、数据安全性不高：单机模式或者分片模式
•吞吐量数据量较大、数据安全性较高：哨兵模式、集群模式
•吞吐量数据量大、数据安全性高、扩展性强：集群模式
3、性能优化
3.1 日志优化
Redis日志存储模式分为两种：RDB和AOF，RDB为实时写入磁盘，AOF为延迟批量写入磁盘
RDB模式：
•优点：实时存储日志，在数据恢复方面更有优势
•缺点：磁盘IO比较频繁，会影响redis的吞吐能力
AOF模式：
•优点：定时批量刷新日志到磁盘，适合高吞吐的场景，对redis性能影响较小
•缺点：如果某一个时刻redis发生故障，可能会丢失内存中的数据，故障恢复的时候恢复不了这部分数据
模式选择：
•如果吞吐量较小，使用RDB即可，吞吐量较大，可以选择AOF来提高性能，两种方式根据具体场景来选择
AOF配置:
appendonly yes
#aof文件名设置
appendfilename "appendonly-${port}.aof"
#配置选择
appendfsync everysec
dir /bigdiskpath
#不开启aof重写，因为太消耗性能
no-appendfsync-on-rewrite yes
AOF重写：分析当前redis中key对应的值来优化指令，来减少磁盘空间和压力，但因为需要判断合并逻辑，会有很大的性能开销，一般不开启aof重写
# 假设服务器对键list执行了以下命令;
127.0.0.1:6379> RPUSH list "A" "B"
(integer) 2
127.0.0.1:6379> RPUSH list "C"
(integer) 3
127.0.0.1:6379> RPUSH list "D" "E"
(integer) 5
127.0.0.1:6379> LPOP list
"A"
127.0.0.1:6379> LPOP list
"B"
127.0.0.1:6379> RPUSH list "F" "G"
(integer) 5
127.0.0.1:6379> LRANGE list 0 -1
1) "C"
2) "D"
3) "E"
4) "F"
5) "G"
127.0.0.1:6379>
正常AOF会把前面的6条写入命令都存入日志中，AOF重写会先去redis获取list的值，发现是["C","D","E","F","G"]，然后生成一条RPUSH list "C" "D" "E" "F" "G"来代替前面6条
3.2 缓存更新策略
redis默认情况下就是使用LRU策略的，因为内存是有限的，但是如果你不断地往redis里面写入数据，那肯定是没法存放下所有的数据在内存的
（1）noeviction: 如果内存使用达到了maxmemory，client还要继续写入数据，那么就直接报错给客户端
（2）allkeys-lru: 就是我们常说的LRU算法，移除掉最近最少使用的那些keys对应的数据（最常用的）
（3）volatile-lru: 也是采取LRU算法，但是仅仅针对那些设置了指定存活时间（TTL）的key才会清理掉
（4）allkeys-random: 随机选择一些key来删除掉
（5）volatile-random: 随机选择一些设置了TTL的key来删除掉
（6）volatile-ttl: 移除掉部分keys，选择那些TTL时间比较短的keys
除了LRU，还可以使用scan的方式进行轮询ttl的方式清理
3.3 代码中使用redis的一些建议
•避免使用keys *这种模糊查询，会阻塞当前线程，使用scan的方式去处理，redis客户端建议不要使用redis desktop manager
String cursor = ScanParams.SCAN_POINTER_START;
ScanParams scanParams = new ScanParams();
// 匹配表达式
scanParams.match("key*");
// 每次scan的条数
scanParams.count(1000);
while (true) {
ScanResult<< span="">String> result = jedis.scan(cursor, scanParams);
cursor = result.getStringCursor();
if ("0".equals(cursor)) {
break;
}
}
•hgetall也应该避免使用，使用hscan代替，但如果通过RedisTemplate回调的方式使用hscan应该注意资源的释放，否则会出现请求到达一定次数的时候就不能发起请求的问题(客户端hang住了)
•如果set的时候同时设置expire过期时间，不要先set再expire这种方式，应该使用原子操作
set key value [EX seconds] [PX milliseconds] [NX|XX]
•对于同一个需求多次改版redis中写入不同格式的数据，会产生兼容性问题，可以使用type命令去处理兼容，然后监控等老数据不存在之后再把判断逻辑移除
String type = jedis.type("a");
if ("string".equalsIgnoreCase(type)) {
// do something
} else if ("list".equalsIgnoreCase(type)) {
// do something
}
•如果redis中的数据需要做去重，可以使用set或hashmap，hashmap性能更高，但对于维护hashmap数据结构之外的数据比较多，之前测试过，100B的数据存放到hashmap，但实际占用量可能有200B~300B甚至更多，set对于数据多的情况下性能会低一点
建议：数据少的情况下用set，数据多就用hashmap，但要注意尽量减少存储内容的长度，比如{"source":"order"}可以改成{"s":1}
去重操作不建议使用list，因为每次判断都要从list中取数据然后再add进去，多线程操作下还是可能会出现重复问题（比如两个线程同时lrange操作）
// 在多线程模式下会有问题
// 假设线程A和线程B同时执行lrange
List<< span="">String> list = jedis.lrange("a", 0, -1);
if (!list.contains("bbb")) {
jedis.lpush("bbb");
}
•如果一次处理的命令很多，使用pipeline性能更好
•list可以结合lpush/rpop、rpush/lpop来实现队列功能，但不建议把list当成是MQ的功能，因为没有记录的状态，无法跟踪数据处理情况
•关于redis分布式锁，目前流行的实现方式还没有完美的方案，使用lua脚本的版本也不是完美的，如果需求允许延时或者一定时间内不允许执行多次，setnx设置过期时间是最好的方案
4、故障转移与数据迁移
4.1 数据迁移方案
•老节点替换为新节点、新老key兼容处理
–将新节点作为老节点的slave节点，等数据自动同步完成之后下架老节点，不建议使用代码迁移，因为不同业务数据结构可能很多
–不同类型的节点之间迁移的方法不同，如果单节点迁移至分片集群只能借助迁移工具来完成
–如果新业务将使用新的key，要保留旧key，可以开启两个连接池，一个处理新key，一个处理旧key，这样等旧key都失效的时候移除对旧key的连接就可以完全迁移到新key业务
•动态扩容
–必须在集群模式下才可以进行动态扩容，也可以使用cachecloud，数据会自动同步到各个节点
–在数据迁移的过程中即使访问的某个key正在迁移，数据也是可以正常返回的，不用担心迁移过程会对数据访问造成影响
4.2 故障转移对于客户端的影响
redis集群模式虽然可以在某个master节点发生故障的时候自动从slave中选举节点当master，但类似jedis的客户端并不支持故障转移，也就是当集群某节点发生故障正在切换的时候，客户端如果正在访问故障节点，这时集群故障转移还没有完成，客户端会报错，如果需要让客户端也支持故障转移，需要修改jedis客户端源码来实现。
总结了很多有关于java面试的资料，希望能够帮助正在学习java的小伙伴。由于资料过多不便发表文章，创作不易，望小伙伴们能够给我一些动力继续创建更好的java类学习资料文章，
请多多支持和关注小作，别忘了点赞+评论+转发。右上角私信我回复【03】即可领取免费学习资料谢谢啦！
最后
以上就是微笑春天为你收集整理的大数据下Redis的应用的全部内容，希望文章能够帮你解决大数据下Redis的应用所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复