jedis-252
commons-pool2-22jar
使用单连接
此方式仅建议用于开发环境做调试用。
// 创建连接
String host = "19216856102";
int port = 6379;
Jedis client = new Jedis(host, port);
// 执行set指令
String result = clientset("key-string", "Hello, Redis!");
Systemoutprintln( Stringformat("set指令执行结果:%s", result) );
// 执行get指令
String value = clientget("key-string");
Systemoutprintln( Stringformat("get指令执行结果:%s", value) );
运行上述代码，控制台输出：
set指令执行结果:OK
get指令执行结果:Hello, Redis!
使用连接池
此方式适用于仅使用单个Redis实例的场景。
// 生成连接池配置信息
JedisPoolConfig config = new JedisPoolConfig();
configsetMaxIdle(10);
configsetMaxTotal(30);
configsetMaxWaitMillis(31000);
// 在应用初始化的时候生成连接池
JedisPool pool = new JedisPool(config, "19216856102", 6379);
// 在业务 *** 作时，从连接池获取连接
Jedis client = poolgetResource();
try {
// 执行指令
String result = clientset("key-string", "Hello, Redis!");
Systemoutprintln( Stringformat("set指令执行结果:%s", result) );
String value = clientget("key-string");
Systemoutprintln( Stringformat("get指令执行结果:%s", value) );
} catch (Exception e) {
// TODO: handle exception
} finally {
// 业务 *** 作完成，将连接返回给连接池
if (null != client) {
poolreturnResource(client);
}
} // end of try block
// 应用关闭时，释放连接池资源
pooldestroy();
运行上述代码，控制台输出：
set指令执行结果:OK
get指令执行结果:Hello, Redis!
使用连接池+分布式
在规模较大的系统中，往往会有多个Redis实例做负载均衡。并且还实现主从备份，当主实例发生故障时，切换至从实例提供服务。
类似于Memcached的客户端，Jedis也提供了客户端分布式 *** 作的方式，采用一致性哈希算法。
// 生成多机连接信息列表
List<JedisShardInfo> shards = new ArrayList<JedisShardInfo>();
shardsadd( new JedisShardInfo("127001", 6379) );
shardsadd( new JedisShardInfo("19216856102", 6379) );
// 生成连接池配置信息
JedisPoolConfig config = new JedisPoolConfig();
configsetMaxIdle(10);
configsetMaxTotal(30);
configsetMaxWaitMillis(31000);
// 在应用初始化的时候生成连接池
ShardedJedisPool pool = new ShardedJedisPool(config, shards);
// 在业务 *** 作时，从连接池获取连接
ShardedJedis client = poolgetResource();
try {
// 执行指令
String result = clientset("key-string", "Hello, Redis!");
Systemoutprintln( Stringformat("set指令执行结果:%s", result) );
String value = clientget("key-string");
Systemoutprintln( Stringformat("get指令执行结果:%s", value) );
} catch (Exception e) {
// TODO: handle exception
} finally {
// 业务 *** 作完成，将连接返回给连接池
if (null != client) {
poolreturnResource(client);
}
} // end of try block
// 应用关闭时，释放连接池资源
pooldestroy();
运行上述代码，控制台输出：
set指令执行结果:OK
get指令执行结果:Hello, Redis!
主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
a,配置主从复制方式一、新增redis6380conf, 加入 slaveof 192168152128 6379, 在6379启动完后再启6380，完成配置；
b,配置主从复制方式二、redis-server --slaveof 192168152128 6379 临时生效
c,查看状态：info replication
d,断开主从复制：在slave节点，执行6380:>slaveof no one
e,断开后再变成主从复制：6380:> slaveof 192168152128 6379
f,数据较重要的节点，主从复制时使用密码验证： requirepass
e, 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭
参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房
a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响
b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定
c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。
redis 28版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）
部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率
a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
b)主从复制主节点的写能力单机，能力有限
c)单机节点的存储能力也有限
a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
b)其它的节点成为新主节点的从节点，并从新节点复制数据；
c)需要人工干预，无法实现高可用。
1 为什么要有哨兵机制？
原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知
任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线 *** 作，也就说是客观下线
a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
a)由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移
c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程：
1 将slave-1脱离原从节点，升级主节点，
d) 故障转移后的redis sentinel的拓扑结构图
a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
b) 选择salve-priority从节点优先级最高（redisconf）的
c) 选择复制偏移量最大，指复制最完整的从节点
以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署
1 前提： 先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：
A）主节点6379节点（/usr/local/bin/conf/redis6379conf）：
修改 requirepass 12345678，注释掉#bind 127001
B) 从节点redis6380conf和redis6381conf: 配置都一样
修改 requirepass 12345678 ,注释掉#bind 127001,
加上访问主节点的密码masterauth 12345678 ,加上slaveof 192168152128 6379
2 redis sentinel哨兵机制核心配置 (也是3个节点)：
将三个文件的端口改成: 26379 26380 26381
然后：sentinel monitor mymaster 192168152128 6379 2 //监听主节点6379
三个配置除端口外，其它一样。
3 哨兵其它的配置 ：只要修改每个sentinelconf的这段配置即可：
sentinel monitor mymaster 192168152128 6379 2
//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码
sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步
sentinel leader-epoch mymaster 2
sentinel failover-timeout mymasterA 180000 //故障转移超时时间180s，
a,如果转移超时失败，下次转移时时间为之前的2倍；
b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过 180S 时，则故障转移失败
c,从节点复制新主节点时间超过 180S 转移失败
sentinel down-after-milliseconds mymasterA 300000 //sentinel节点定期向主节点ping命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了……
sentinel parallel-syncs mymasterA 1 //故障转移后， 1 代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销
4 启动redis服务和sentinel服务:
a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件
b)启动主从复制服务，先启动主再启动从
主：/redis-server conf/redis6379conf &
从：
/redis-server conf/redis6380conf &
/redis-server conf/redis6381conf &
c）启动sentinel服务:
/redis-sentinel conf/sentinel_26381conf &
到此服务全部启动完毕
连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点
5 测试： kill -9 6379 杀掉6379的redis服务
可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点
重新启动6379以后变为6380的从节点
看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点
假设6380升级为主节点:进入6380>info replication 可以看到role:master
打开sentinel_26379conf等三个配置，sentinel monitor mymaster 192168152128 6380 2
打开redis6379conf等三个配置, slaveof 192168152128 6380,也变成了6380
注意：生产环境建议让redis Sentinel部署到不同的物理机上。
a，sentinel节点应部署在多台物理机（线上环境）
b，至少三个且奇数个sentinel节点
c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点
sentinel
参考资料：
redis sentinel的机制与用法一： >应该是redis本身的服务有问题了
本文所针对的连接超时问题所涉及的相关元素如下:
Redis客户端: Jedis (java)
Redis版本 :2812
Redis部署 *** 作系统类型:Linux
正文开始:
No 1Redis执行大命令(时间复杂度为O(N)的命令)
问题剖析:
aRedis服务器端通过单线程处理命令,一旦有大命令被执行,Redis将无法及时响应来自客户端的任何命令
关于Redis大命令的监控,可以查看slowlog来观察
b在使用jedis作为redis客户端时,当redis连接池的配置参数testOnBorrow=true时,默认会在获取redis连接
时,先执行redis的ping方法,而基于原因a,此时redis将无法及时响应,自然会报出time out异常
如何解决:
a尽量避免使用时间复杂度为O(N)的命令
b如果无法避免使用时间复杂度为O(N)的命令,则应降低其使用频率,避免在业务高峰期时使用
No 2Redis单次 *** 作数据包过大
问题分析
a单次 *** 作数据包过大,且 *** 作频繁,极有可能会导致网络拥堵
b在使用jedis作为redis客户端时,当redis连接池的配置参数testOnBorrow=true时,默认会在获取redis连接
时,先执行redis的ping方法,而基于原因a,此时redis将无法及时响应,自然会报出time out异常
如何解决:
a排查代码,确定是否存在大数据(数据条目过多/单条数据过大) *** 作,将其进行改造,改造方案有两个:
a1数据拆分,变更数据类型(常见的情况是将java中的collection类型序列化后存入redis的String数据
类型中),如将String数据类型调整为hash/list/set等,这常用于解决单条数据量过大的情况
a2调整业务逻辑,减少单次数据查询范围(常见的情况如将redis中的整个hash数据取回,在应用程序内存中获取需要的entry),如使用hget等单条查询命令替换hgetall命令应用Redis实现数据的读写，同时利用队列处理器定时将数据写入mysql。
同时要注意避免冲突，在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。
这样处理，主要是实时读写redis，而mysql数据则通过队列异步处理，缓解mysql压力，不过这种方法应用场景主要基于高并发，而且redis的高可用集群架构相对更复杂，一般不是很推荐。
就拿蜗牛学院的历届线下学员来说，有很多也是非计算机专业转行过来学习java的，所以我们在课程设置上，从基础储备、理论知识、实战练习、进阶项目、综合项目分阶段循序渐进。只要用心学，基本都能听懂上课内容，并且掌握这项技术，所以跨专业并不是问题。如果想自学的话，这里也整理了一份java全栈开发的学习路线，希望可以帮助到你~
第一阶段：Java专业基础课程
阶段目标：
1 熟练掌握Java的开发环境与编程核心知识
2 熟练运用Java面向对象知识进行程序开发
3 对Java的核心对象和组件有深入理解
4 熟练应用JavaAPI相关知识
5 熟练应用JAVA多线程技术
6 能综合运用所学知识完成一个项目
知识点：
1、基本数据类型，运算符，数组，掌握基本数据类型转换，运算符，流程控制。
2、数组，排序算法，Java常用API，类和对象，了解类与对象，熟悉常用API。
3、面向对象特性，集合框架，熟悉面向对象三大特性，熟练使用集合框架。
4、IO流，多线程。
5、网络协议，线程运用。
第二阶段：JavaWEB核心课程
阶段目标:
1 熟练掌握数据库和MySQL核心技术
2 深入理解JDBC与DAO数据库 *** 作
3 熟练运用JSP及Servlet技术完成网站后台开发
4 深入理解缓存，连接池，注解，反射，泛型等知识
5 能够运用所学知识完成自定义框架
知识点：
1、数据库知识，范式，MySQL配置，命令，建库建表，数据的增删改查，约束，视图，存储过程，函数，触发器，事务，游标，建模工具。
2、深入理解数据库管理系统通用知识及MySQL数据库的使用与管理。为Java后台开发打下坚实基础。Web页面元素，布局，CSS样式，盒模型，JavaScript，jQuery。
3、掌握前端开发技术，掌握jQuery。
4、Servlet，EL表达式，会话跟踪技术，过滤器，FreeMarker。
5、掌握Servlet相关技术，利用Servlet，JSP相关应用技术和DAO完成B/S架构下的应用开发。
6、泛型，反射，注解。
7、掌握JAVA高级应用，利用泛型，注解，枚举完成自己的CRUD框架开发为后续框架学习做铺垫。
8、单点登录，支付功能，项目整合，分页封装熟练运用JSP及Servlet核心知识完成项目实战。
第三阶段：JavaEE框架课程
阶段目标：
1 熟练运用Linux *** 作系统常见命令及完成环境部署和Nginx服务器的配置
2 熟练运用JavaEE三大核心框架：Spring,SpringMVC,MyBatis
3 熟练运用Maven,并使用SpringBoot进行快速框架搭建
4 深入理解框架的实现原理，Java底层技术，企业级应用等
5 使用Shiro,Ztree和Spring,SpringMVC,Mybaits完成企业项目
知识点：
1、Linux安装配置，文件目录 *** 作，VI命令，管理，用户与权限，环境部署，Struts2概述，hiberante概述。
2、Linux作为一个主流的服务器 *** 作系统，是每一个开发工程师必须掌握的重点技术，并且能够熟练运用。
3、SSH的整合,MyBatis,SpringMVC,Maven的使用。
4、了解AOP原理，了解中央控制器原理，掌握MyBatis框架，掌握SSM框架的整合。
5、Shiro,Ztree，项目文档，项目规范，需求分析，原型图设计，数据库设计，工程构建，需求评审，配置管理，BUG修复，项目管理等。
6、独立自主完成一个中小型的企业级综合项目的设计和整体架构的原型和建模。独立自主完成一个大型的企业级综合项目，并具备商业价值。
第四阶段：分布式与微服务课程
阶段目标：
1掌握前端框架VUE及Bootstrap的应用开发
2基于SpringCloud完成微服务架构项目的开发
3掌握NoSQL数据库Redis的使用
4掌握消息队列RabbitMQ的使用
5掌握Mycat数据库中间件的使用
知识点：
1、Bootstrap前端框架、VUE前端框架、RabbitMQ消息队列。
2、掌握Bootstrap前端框架开发、掌握VUE前端框架开发、掌握RabbitMQ消息队列的应用、掌握SpringBoot集成RabbitMQ。
3、Redis缓存数据库的应用、Java基于Redis的应用开发、基于SpringCloud微服务架构开发实战。
4、掌握NOSQL数据库Redis的安装、使用，Redis客户端的安装使用，Java访问 *** 作Redis数据库，Redis的持久化方案、主从复制、高可用。
5、掌握SpringCloud微服务架构的开发，注册中心，网关配置，配置中心，微服务间通信及容器化部署。
6、项目文档，项目规范，需求分析，数据库设计，工程构建，需求评审，配置管理，BUG修复，项目管理等。
7、掌握数据库中间件Mycat的应用，基于Mycat实现数据读写分离，高可用集群。
8、掌握项目开发的流程，按照项目开发流程完成基于微服务架构项目的需求分析，编码开发。
Spring Boot连接Redis哨兵集群的原理如下：1 Spring Boot使用Jedis客户端连接Redis哨兵集群。Jedis是一个Java Redis客户端，它支持连接Redis哨兵集群。
2 Jedis客户端会向Redis哨兵集群发送SENTINEL get-master-addr-by-name命令，获取当前Redis主节点的IP地址和端口号。
3 Jedis客户端会使用获取到的IP地址和端口号连接Redis主节点，并发送PING命令测试连接是否正常。
4 如果连接正常，Jedis客户端会将连接信息保存在连接池中，以便后续使用。
5 如果连接失败，Jedis客户端会向Redis哨兵集群发送SENTINEL get-master-addr-by-name命令，获取新的Redis主节点的IP地址和端口号，然后重复步骤2-4。
6 如果Redis主节点发生故障，Redis哨兵会自动将从节点升级为主节点，并通知Jedis客户端更新连接信息。
总之，Spring Boot连接Redis哨兵集群的原理是通过Jedis客户端向Redis哨兵集群发送命令获取当前Redis主节点的IP地址和端口号，然后使用获取到的信息连接Redis主节点。如果连接失败，Jedis客户端会重新获取新的Redis主节点的IP地址和端口号，直到连接成功为止。如果Redis主节点发生故障，Redis哨兵会自动将从节点升级为主节点，并通知Jedis客户端更新连接信息。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）