本文目录一览：
redis集群角色切换java调用异常
redis集群角色切换java调用异常
一、Redis状态检查
唯一标记一个redis实例的是ip和端口，前端是用tcp方式来访问redis的，我们提供给应用访问的是一个ip+63379(一般使用63379) 端口。因此我们执行如下命令检查redis状态:
上面的role这个值一定是master的，只要保证vip在master上我们的Padis cache服务就是没有问题的，如果不通或者role的角色是slave，那就得继续查看是什么问题.
二、两个redis的角色都是slave的问题
当两个主机都挂了或者我们自己不小心将两个redis停了，并且我们用下面的命令检查
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} info replication
发现无论是vip还是另外的两个ip都是role:slave 的角色，这个时候需要对vip所在的主机执行slaveof no one 的操作,将vip 所在的redis变成master,如:
/wls/wls81/redis/bin/redis-cli -h {vip} -p {port} -a {password} slaveof no one
三、sentinel的配置参数
我们的sentinel 配置文件里面有两个重要的配置
sentinel monitor pds_jks-core-prd 10.33.94.65 63379 1 -----------配置的ip和端口任何时候都需要是master的ip端口,切换的时候程序自动会改 。另外，红色所示部分pds_jks-core-prd为redis对外提供的主机名，一般Jedis在调用redis时会用到此名称。如果配置多个哨兵则一般要求此名称唯一标识
sentinel down-after-milliseconds pds_jks-core-prd 15000 ----------这个是sentinel连接master的超时时间，超过这个时间就认为master挂了，实现自动切换。这个默认是30秒，这个时间得调节好，大了会在真正出现故障的时候切换时间会长，小了有时候master由于持久化数据，繁忙不响应，会导致自动切换，实际只是瞬间不可用，现在认为设置为15秒为宜.
四、AOF日志
这个日志记录了每一个写入命令或者删除命令的，这个对于我们审计功能是有用的，由于占用很多磁盘，默认我们是关闭的
如果开启会生成一个.aof的文件在data文件中. 如: /wls/apache/servers/pds_jks-core-prd/data
在redis运行中中开启：
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set appendonly yes
开启了可以查看日志，记录每一个命令，如有必要可以开启查完问题后关闭. 同时说明一下
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set 可以在redis运行的时候设置多个它的参数
五、空闲连接的timeout
redis服务端不会自动断开客户端来的连接，redis服务端有设置客户端空闲连接超时时间，可用命令
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config get timeout
查看当前timeout时间，默认是0，就是不断开空闲的连接，如果不断开空闲的连接，就会造成redis连接过多
所以一般情况下可以设置为3600秒:
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set timeout 3600
也就是3600秒后将空闲的连接关闭掉. 可以用下面的命令查看某个连接空闲了多久:
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} client list
六、监控redis执行的命令
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} monitor
上述这个monitor命令可以查看redis执行了什么命令，有时候查问题很有必要用到，我们可以知道那段时间redis执行了什么，从而进行我们的问题诊断。
七、key的查找与执行
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} keys "*"
keys这个命令查找所有的key，但是最好慎用，因为它很耗redis的性能，每个key都遍历一遍. 也可以进行模糊匹配如： keys "send*"
千万记住在生产环境上不能随便乱用，因为它会将redis性能耗尽，导致其他连接获取不到响应.
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} dbsize
dbsize 这个命令可以看到整一个redis里面有多少个key，当然和keys "*" | wc -l结果是一样的。
当我们需要批量删除key值时可以用如下命令即可:
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} keys "send*" | xargs /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} del
我们需要将整个db都flush掉可以用:
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a MamcCorePrd flushdb
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a flushall
八、由于连接redis的客户端使用jedisPool
如果设置了
redis.pool.testOnBorrow.REL=true
redis.pool.testOnReturn.REL=true
这两个参数是说在或者pool中的连接和返回连接给pool的时候都需要检查一下连接的有用性，也就是ping一下这个redis是不是好的，
这样在高并发的时候，由于并发线程太多，ping操作相对线程启动来说很慢，因此，应用会堵在类似如下线程dump的地方
"[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'" id=33 idx=0x9c tid=273669 prio=5 alive, native_blocked, daemon
at jrockit/net/SocketNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)
at jrockit/net/SocketNativeIO.socketRead(SocketNativeIO.java:32)
at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStream.java)
at java/net/SocketInputStream.read(SocketInputStream.java:129)
at java/net/SocketInputStream.read(SocketInputStream.java:90)
at redis/clients/util/RedisInputStream.fill(RedisInputStream.java:109)
at redis/clients/util/RedisInputStream.readByte(RedisInputStream.java:45)
at redis/clients/jedis/Protocol.process(Protocol.java:64)
at redis/clients/jedis/Protocol.read(Protocol.java:131)
at redis/clients/jedis/Jedis.ping(Jedis.java:35)
at redis/clients/jedis/JedisPool$JedisFactory.validateObject(JedisPool.java:104)
at org/apache/commons/pool/impl/GenericObjectPool.addObjectToPool(GenericObjectPool.java:922)
at org/apache/commons/pool/impl/GenericObjectPool.returnObject(GenericObjectPool.java:917)
^-- Holding lock: org/apache/commons/pool/impl/GenericObjectPool@0xb8513338[fat lock]
at redis/clients/util/Pool.returnResourceObject(Pool.java:29)
at redis/clients/util/Pool.returnResource(Pool.java:41)
at com/paic/icore/mams/common/jedis/util/RedisPoolCacheTools.release(RedisPoolCacheTools.java:43)
虽然后面会自动恢复，不过导致应用响应缓慢.解决方法是将该两个参数设置为false，并且定期检查：
testOnBorrow.REL=false
testOnReturn.REL=false
timeBetweenEvictionRunsMillis=60000 -------每隔60秒定期检查空闲连接
minEvictableIdleTimeMillis=120000 ---------连接在池中保持空闲而不被空闲连接回收器线程回收的最小时间值,单位毫秒
numTestsPerEvictionRun=-1 ----------空闲连接扫描时，每次最多扫描的连接数,一般设置为-1，全部扫描
设置成这样之后就不用每次都测试了，这样就提高了应用的性能
有时候由于持久化导致master变得缓慢，所以建议关闭master的持久化，让slave持久化
关闭持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save ""
开通持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save "900 1 300 10 60 10000"
关闭持久化后如果发生主备切换了，请将master的持久化关闭，slave的持久化开启
九、查询每秒执行的命令个数
十、单位时间内Redis执行的命令次数
Java 集群锁如何实现
1. 用数据库，在数据库建一张表，需要锁的节点都可以尝试用 select * from Lock where id=xx for update. 这个时候只有一个节点能拿到结果，其它的都会等待，就能实现一个简单的悲观锁。
2. 用 Zookeeper 来做分布式锁，具体可以搜一下。
3. 自己实现，搞个节点来做这个事情，所有要获取锁的都走 RPC 调用来请求锁，用完以后记得释放，不然其他的节点就会挂那里。
java 集群
群集方法介乎两种计算机系统结构之间。当把多台计算机配置或互连在一起时，可采取松散耦合或紧密耦合结构。网络就是一个松散耦合的系统，我们也称其为异类系统结构。网络把由各种CPU、应用软件、NIC（网络接口控制器）、甚至是操作系统组成的多台计算机连接在一起。计算机之间的地理距离可以近在咫尺，也可以远在天边。可以用实时和/或异步方式耦合网络。
因特网就是一个典型的极为松散与异类配置的例子。因特网本身不能“实时”控制与它连接的任何主机。在松散耦合网络中，单机崩溃一般不会影响网络的其它部分。
相反，紧密耦合系统则高度依赖于构成系统的所有部件。当系统由相同部件组成，采用并行操作方式并共享所有子系统（存储器）时，我们称其为同类系统结构。紧密耦合系统最常见的例子是SMP（对称多处理）。在SMP状态下，根据工作量的多少把任务分给几台处理器，这样可均匀地分配工作量，以便提高数据吞吐量。
我们举了两个典型的松散和紧密耦合系统的例子，群集就介于松散和紧密耦合系统之间。根据系统的配置，在某些方面（比如操作系统），群集控制的系统也许更偏向紧密耦合的系统，或者偏向松散耦合的系统（比如独立计算能力，通过公共存储器连接）。
通常群集器放在同一设备区或同一办公楼里。从理论上说，群集控制方法可应用于闭路广域网环境中（现正在美国东北部地区进行试验）。可是在考虑到视频服务器应用时，一般来说只能把设备放在主要设施运行所在地。
公共数据共享
群集允许共享几个节点的数据。在此应用中，这些节点包括客户工作站、中央或多服务器。我们知道可以通过许多路径（比如星形结构）连接节点，客户可通过不同连接的节点路径存取数据。当节点就是服务器时便可共享公共存储器，某个服务器节点故障不会导致整个群集器系统瘫痪。
在12月专栏里，我们把群集描述成一个提供高可得性的系统。对广播或有线电视操作来说，视频服务器必须要提供连续的或高可得性的数据。考虑到这一点，我们认为视频服务器体系结构采用群集是大有潜力的。
待命或无源服务器结构就是一种群集形式。在这种结构下，一个或多个服务器（或节点）平时保持在待命状态，随时可以启动。利用后台控制系统管理待命服务器内容数据。在未发生故障之前一般不启用无源服务器。
无源服务器未必就是主服务器的完全镜像，它也可以有一些有限的数据源，包括存储器，要经常清除这些数据，然后重新装入最新的节目或广告。通过这一循环过程把适量的数据（或视频媒介）保持在待命状态，在需要时随时可以上线使用。
服务器在待命状态时通常由少量的部件组成，比如编解码器，在出现故障或另一个服务器需要它支持的时候，该服务器可立即被集成到系统中应用。此时，服务器进入负载均衡状态。
数据共享
数据共享是群集器需要提供的最基本功能之一。我们还是以视频服务器的应用为例，多个编辑站在这里独立地工作，不过利用一组公共服务器来管理数据和应用层的处理。
在这个例子中，多个新闻编辑站（或客户工作站）可以选择用哪个编辑服务器（包括编辑用的软件和硬件）来进行编辑。这些服务器控制对公共媒体数据库的存取，编辑站只是这些服务器的简单控制器GUI（图形用户界面）。编辑服务器进一步控制接入另一个更大的数据存储库（通常是新闻档案）。
这个概念可通过群集软件实现。在独立的编辑站通过群集器存取数据的过程中，编辑与数据存取或存储处理自动进行，不会影响其它的客户编辑站或预放站。通过提供连续的数据可得性，每个服务器可以是有源的，也可以是无源的，视工作负荷而定。假如有一个服务器发生了故障，该结构也可提供冗余或保护方式。
共享一个操作系统和平台是群集的又一个共同特点。让硬件与软件平台同属一类，也就是说，基本上是相同的，就可采用公用互连方案与公共文件格式结构。在SMP这样的系统中，所有部件都依赖于公用硬件而像单独部件一样运行。正如我们已提到的，群集可以让一部分系统保持同类结构，但脱离所有系统都有的依赖性，其它性能就会下降。
其它优点
我们现在还是回到基于群集服务器的编辑环境中来，我们又发现了其它一些优点。服务器硬件具有的冗余性可对数据起保护作用。在新闻编辑环境中，当即将播放时，一个或更多的服务器便可将客户工作站的功能变成播出功能，直接把新闻播出去。这样还能让所有客户和服务器接入别的服务器的数据，包括在最后一分钟直接存取中央存储库的数据。
通过使用多个服务器（每个服务器收集、编辑、存档和重放的资源是一个类型的），系统便可对硬件进行备份。在某个服务器出现故障时，可把资源转给或分给其它用户，系统的其余部分仍继续工作。
除了上述的数据共享外，其它群集器结构也是可行的。在有些情况下，某些资源可被一个特定的节点“拥有”，在未接到指令前不会放弃。可将该系统的结构配置成一个节点有多个输入编码器，但只有一个输出解码器。另一个节点可能没有输入，但有好几个输出供放像和预看用。如果某一个节点出现故障，可让与它相对应的节点顶替它，直到它被修复为止。
非共享结构
从硬件上说，每个节点的能力（或资源）基本上相同，但内部系统配置是用各种形式锁定的，除非另有要求。按照群集语言可把此结构
叫做非共享结构。在此结构里，某些资源在未被传送给其它节点或者该节点未出故障之前归一个节点所有。在采用非共享结构的计算机与模式里运用群集法通常会把硬盘等设备分配给一个节点，并阻止其他人使用它，除非将其开放或该节点发生故障。
群集结构的其它实施方面增加了系统的复杂程度。除了非共享结构外（只提供最简单的性能和可得性），还有磁盘共享结构。磁盘共享可提高存储接入不同主机系统的能力。
从硬件的角度看，系统的磁盘阵列控制器可以很容易地管理这个共享结构。比较难办的是在最低级别（文件或记录层）上协调更新数据。
协调工作必须成为群集软件的一部分。可以设想一下，如果两个用户同时接入同一记录层会发生什么情况。假定每个用户都修改了文件。用户1先把数据写入服务器，他发现用户2做了完全不同的修改并且把修改后的文件用同一文件名存入相同的磁盘，或许存在另一个服务器上，这样就有可能把第一个用户修改的文件冲掉。没有一个控制方案，就会乱成一团。
尽管每个文件或记录层都有简单的口令或锁定保护，但要确保用文件的正确版本存成另一个文件名或是“正式”版，则要求具有更高层的数据控制与管理能力。磁盘快速缓存问题又是另一种情形，我们等一会儿再说。
另一个防止错误数据覆盖正确数据的方法是在修改未最后定之前限制接入某一特定文件。在计算机数据域中，用一个称为信息传送的程序通知管理员（通常是应用后台软件的一部分）文件存取被锁定，直到修改程序结束为止。
原子操作
原子操作的三个步骤是：读数据、修改数据、然后重新写入新数据。在原子操作过程中，在未执行完操作之前不会受到任何干扰。还必须有其他保护措施，以防隐藏的备份文件在以后某个无法预测的时间改写其它的文件。
当数据分布在不止一个存储磁盘上时，或者当公共存储阵列中的数据被不同用户在不同时间存取时，如何防止数据不一致是群集软件需要解决的又一个问题。无论是通过硅缓存器还是通过远程接入的临时磁盘缓存器（甚至分区）进行高速缓存都会遇到定时和同步的问题。我们把这个问题叫做缓存相关性，它是因磁盘驱动器定时问题引起的。
磁盘驱动器并不一定能马上写入数据，磁头也许定位在错误的磁道上，导轮也许偏离相位190度，等结束运转后才能开始磁头的写入操作，或许还因为温度问题造成暂时性延缓，直到一切都符合条件为止。
这通常被称为等待时间，磁盘驱动器的机械部分要求在驱动器等待写入时暂存一下数据。最常见的方法是在驱动器上安一个硅缓存器，这个过程被叫做写回高速缓存。在把主机储存器中的数据转存到磁盘驱动器的过程中，设一个写回缓存器标识，对数据源表示写入程序成功了。实际上，得过一会儿才能开始真正的电磁机械式的数据储存过程。
假如系统上的另一个节点也从这个驱动器读数据，（这是经过许可的操作，因为数据发生器已接到通知，新数据已发送到了这个位置），那么缓存器已在指定位置存储了正确新数据的指示信号就不见了。我们用失效数据一词来表示未更新数据进入新数据区的状态。
无效数据
RAID控制器在各自磁盘阵列的写回缓存器里为与这个特殊的阵列有关的磁盘管理失效数据。假如在软件里设一些适当的开关来检测和阻止它发生，那么数据相关性就只是一个小问题了。
当系统是由多层阵列构成的时候，控制失效数据问题的任务就交给高级别软件去完成，把信号传送给各自的阵列，就不会发生孤立或失效数据问题了。
在这个简化的单一视频服务器模型里，媒体是通过单编码器输入的，并存在一个单实体阵列上。由一个更高级别（通常是第三方API，应用程序接口）登记和管理活动图像数据。通常将其作为任选的“媒体管理”或“资产管理器”包出售。通过这个软件，控制活动图像和数据的过程成为一个闭路过程，因为输入与输出指令必须通过这个管理软件包。该软件在自己的数据库里始终跟踪着数据的有效性。
如果有好几个服务器，每个服务器有自己的任务，情况就变得比较复杂了。这时可以让几个信号源的输入进入不同的编码器，并存在一个较大的磁盘阵列里。这些阵列通常与光纤通道仲裁环相连，由于它的连接方式决定，它可迫使部分重写动作由服务器推迟到存储器，直到有了充足的带宽来把该数据从这个存储器存入另一个存储器。
在类似的应用中，媒体管理软件就更完善，更必不可少了。有时候制造商会提供一个完全独立的CPU和资源管理软件包（作为选件）。这个软件包就像看门狗那样管理服务器之间的数据共享操作。除了这些基本概念外，还有大量的定时和数据验证问题，这些问题会经常在服务器结构的软件与子系统中碰到。
群集的过程和功能正在扩展到设备内和设备间应用中。群集器理念最终将允许整个广播集团通过光纤或通过广域网共享资源。虽然可以让设施连成网共享媒介，可是在这些设施相互离得很远的情况下实现节点资源共享的设想似乎还很遥远。
集群java版本和谁要匹配
集群java版本和谁要匹配：
搭建实验环境
需求：Tomcat实现群集功能，以Nginx做代理，同时用zabbix监控Tomcat服务。可以开启多台虚拟机，每台都安装Tomcat服务，用另一种方法，一台服务器安装多个Tomcat服务，以端口号区分，实现群集搭建。
java支持class集群模式吗
支持。
Java具有多线程功能，可以实现class集群模式。
分布式是指将不同的业务分布在不同的地方， 而集群指的是将几台服务器集中在一起，实现同一业务，分布式中的每一个节点，都可以做集群， 而集群并不一定就是分布式，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
