查询数据放入了redis中缓存，怎么查看缓存的数据

普通分页

一般分页做缓存都是直接查找出来，按页放到缓存里，但是这种缓存方式有很多缺点。

如缓存不能及时更新，一旦数据有变化，所有的之前的分页缓存都失效了。

比如像微博这样的场景，微博下面现在有一个顶次数的排序。这个用传统的分页方式很难应对。

一种思路

最近想到了另一种思路。

数据以ID为key缓存到Redis里；

把数据ID和排序打分存到Redis的skip list，即zset里；

当查找数据时，先从Redis里的skip list取出对应的分页数据，得到ID列表。

用multi get从redis上一次性把ID列表里的所有数据都取出来。如果有缺少某些ID的数据，再从数据库里查找，再一块返回给用户，并把查出来的数据按ID缓存到Redis里。

在最后一步，可以有一些小技巧：

比如在缺少一些ID数据的情况下，先直接返回给用户，然后前端再用ajax请求缺少的ID的数据，再动态刷新。

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 10339465 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

如果设置了

redispooltestOnBorrowREL=true

redispooltestOnReturnREL=true

这两个参数是说在或者pool中的连接和返回连接给pool的时候都需要检查一下连接的有用性，也就是ping一下这个redis是不是好的，

这样在高并发的时候，由于并发线程太多，ping *** 作相对线程启动来说很慢，因此，应用会堵在类似如下线程dump的地方

"[ACTIVE] ExecuteThread: '19' for queue: 'weblogickernelDefault (self-tuning)'" id=33 idx=0x9c tid=273669 prio=5 alive, native_blocked, daemon

at jrockit/net/SocketNativeIOreadBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)

at jrockit/net/SocketNativeIOsocketRead(SocketNativeIOjava:32)

at java/net/SocketInputStreamsocketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStreamjava)

at java/net/SocketInputStreamread(SocketInputStreamjava:129)

at java/net/SocketInputStreamread(SocketInputStreamjava:90)

at redis/clients/util/RedisInputStreamfill(RedisInputStreamjava:109)

at redis/clients/util/RedisInputStreamreadByte(RedisInputStreamjava:45)

at redis/clients/jedis/Protocolprocess(Protocoljava:64)

at redis/clients/jedis/Protocolread(Protocoljava:131)

at redis/clients/jedis/Jedisping(Jedisjava:35)

at redis/clients/jedis/JedisPool$JedisFactoryvalidateObject(JedisPooljava:104)

at org/apache/commons/pool/impl/GenericObjectPooladdObjectToPool(GenericObjectPooljava:922)

at org/apache/commons/pool/impl/GenericObjectPoolreturnObject(GenericObjectPooljava:917)

^-- Holding lock: org/apache/commons/pool/impl/GenericObjectPool@0xb8513338[fat lock]

at redis/clients/util/PoolreturnResourceObject(Pooljava:29)

at redis/clients/util/PoolreturnResource(Pooljava:41)

at com/paic/icore/mams/common/jedis/util/RedisPoolCacheToolsrelease(RedisPoolCacheToolsjava:43)

虽然后面会自动恢复，不过导致应用响应缓慢解决方法是将该两个参数设置为false，并且定期检查：

testOnBorrowREL=false

testOnReturnREL=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执行的命令次数

在秒杀等高并发场景下，既要保证库存安全，也要拥有极高的系统性能。从存储结构上，很多同学会选用Redis，毕竟Redis的单线程 *** 作特性，很好地避免了线程安全的问题，同时具备极高的读写性能。

我们先来看下库存系统设计的几大核心要点：

1 库存安全：既要保证线程安全，也要防止出现超卖

2 同步响应：业务场景基本不允许异步响应库存扣减结果

3 性能极限：在seckill场景下，性能总是被要求越高越好

我们来看下如何利用Redis来解决上面的三个问题。

一库存安全

利用Redis来做库存扣减，避免超限的"方法"很多，坑也很多，我们先来看下常用的陷阱有哪些。

1 先获取当前库存值进行比较，再进行扣减

defdecr_stock():conn=redis_conn()key="productA"current_storage=connget(key)current_storage_int=int(current_storage)ifcurrent_storage_int<=0 :return0result=conndecr(key)returnresult

我们先在Redis中拿到当前的库存值，然后check是否已经扣减到了零，如果已经扣减到了零，则直接return；否则，就利用Redis的decr原子 *** 作进行扣减，同时返回扣减后的库存值。

这种方法的问题很明显，在并发条件下，会出现脏读，设想一个场景，AB两个请求进来，A获取的库存值为1，B获取的库存值为1，然后两个请求都被发到redis中进行扣减 *** 作，然后这种场景下，A最后得到的库存值为0；但是B最后得到的库存值为-1，超限。

2 先扣减库存，再做比较，跟进情况是否做回滚

defdecr_stock():conn=redis_conn()key="productA"current=conndecr(key)ifcurrent>=0:returncurrentelse:          #回滚库存connincr(key)return0

直接先对库存值进行扣减，得到当前的库存值；然后，对此库存值进行check，如果库存>=0，则返回库存值，如果库存<0，则回滚库存，以便于防止负库存量的存在。

Redis Decr命令：DECR 命令会返回键 key 在执行减1 *** 作之后的值。

这种做法引入了两个新的问题：

1)如果大批量的并发请求过来，redis承受的写 *** 作的量，是加倍的，因为回滚库存的存在导致的。所以这种情况下，高并发量进来，极有可能将redis的写 *** 作打出极限值，然后会出现很多redis写失败的错误警告

2) Redis的Decr *** 作和回滚 *** 作无法保证原子性，在宕机情况下，容易产生数据不一致

3先扣库存，然后通过整数溢出控制，根据情况进行回滚

defdecr_stock():conn=redis_conn()key="productA"current=conndecr(key)      #通过整数控制溢出的做法ifcheck_overflow(current):returncurrentelse:          #回滚库存connincr(key)return0  defcheck_overflow(stock):      #如果当前库存未被递减到0，则check_number为int类型，isinstance方法检测结果为true      #如果当前库存已被递减到负数，则check_number为long类型，isinstance方法检测结果为falsecheck_number=sysmaxint - stockcheck_result=isinstance(check_number,int)returncheck_result

这种做法和方法2类似，只是比对部分由直接和0比对，变成了通过检测integer是否溢出的方式来进行。这样就彻底解决了高并发情况下，直接和零比对，限制不住的问题了。

虽然此种做法，相对于做法二说来，要靠谱很多，但是仍然解决不了在高并发情况下，redis写并发量加倍的问题，极有可能某个促销活动，在开始的那一刻，直接将redis的写 *** 作打出问题来。

4基于分布式锁的库存扣减

defdecr_stock():key ="productA"    lock = getLock(key)iflocked ==1:        current_storage = connget(key)        current_storage_int = int(current_storage)ifcurrent_storage_int<=0:return0        result = conndecr(key)returnresultelse:return"someone in it"

Redis在28以后支持Lua脚本的原子性 *** 作，可以用来做分布式锁，解决超限的问题。

5 All in Lua

defstorage_scenario_six():        conn = redis_conn()lua ="""                local storage = rediscall('get','storage_seckill')                if  storage ~= false then                    if tonumber(storage) > 0 then                        return rediscall('decr','storage_seckill')                    else                        return 'storage is zero now, can't perform decr action'                    end                else                    return rediscall('set','storage_seckill',10)                end              """result = conneval(lua,0)        print(result)

二、同步响应

如果只用Redis来进行存储，处理完数据直接返回前端即可。如果还要持久化到DB，要尽量避免直接 *** 作DB，因为DB往往是最大的IO瓶颈，如果要异步落库到DB，比如使用MQ。要注意处理Redis扣减和消息发送的原子性处理。

三、性能

官网上redis的读写性能能到10W/QPS左右，这个量级应该可以解决绝大部分的场景。

但是经常有同学在压测的时候达不到这个性能，主要还是卡在网络环境上，在5W/QPS的时候，带宽就超过10M/s了。所有想追求Redis的极致性能，最好还是在同机房进行调用。

一、Redis集群介绍

Redis真的是一个优秀的技术，它是一种key-value形式的NoSQL内存数据库，由ANSI C编写，遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。 Redis最大的特性是它会将所有数据都放在内存中，所以读写速度性能非常好。Redis是基于内存进行 *** 作的，性能较高，可以很好的在一定程度上解决网站一瞬间的并发量，例如商品抢购秒杀等活动。

网站承受高并发访问压力的同时，还需要从海量数据中查询出满足条件的数据，需要快速响应，前端发送请求、后端和mysql数据库交互，进行sql查询 *** 作，读写比较慢，这时候引入Redis ,把从mysql 的数据缓存到Redis 中，下次读取时候性能就会提高；当然，它也支持将内存中的数据以快照和日志的形式持久化到硬盘，这样即使在断电、机器故障等异常情况发生时数据也不会丢失，Redis能从硬盘中恢复快照数据到内存中。

Redis 发布了稳定版本的 50 版本，放弃 Ruby的集群方式，改用 C语言编写的 redis-cli的方式，是集群的构建方式复杂度大大降低。Redis-Cluster集群采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。

为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

redis-cluster投票:容错，投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉。

集群中至少应该有奇数个节点，所以至少有三个节点，每个节点至少有一个备份节点，所以下面使用6节点（主节点、备份节点由redis-cluster集群确定）。6个节点分布在一台机器上，采用三主三从的模式。实际应用中，最好用多台机器，比如说6个节点分布到3台机器上，redis在建立集群时为自动的将主从节点进行不同机器的分配。

二、单机redis模式

下载源码redis50并解压编译

wget >

前端时间，正好在做公司权限相关的架构问题，然后选择了Spring OAuth2来作为公司权限框架，先记录下目前遇到原生问题吧，后续有时间再来整理这个框架的整体脉络；

RedisTokenStore 主要是来做token持久化到redis的工具类

我们先来看下缓存到redis中有哪些key

ACCESS ：用来存放 AccessToken 对象（登录的token值，还有登录过期时间，token刷新值）

AUTH_TO_ACCESS ：缓存的也是AccessToken 对象，是可以根据用户名和client_id来查找当前用户的AccessToken

AUTH ：用来存放用户信息（OAuth2Authentication），有权限信息，用户信息等

ACCESS_TO_REFRESH ：可以根据该值，通过AccessToken找到refreshToken

REFRESH ：用来存放refreshToken

REFRESH_TO_ACCESS ：根据refreshToken来找到AccessToken

CLIENT_ID_TO_ACCESS ：存放当前client_id有多少AccessToken

UNAME_TO_ACCESS ：当没有做单点登录的话，可以使用该key，根据用户名查找当前用户有多少AccessToken可以使用

根据client_id和用户名，来获取当前用户的accessToken，如果缓存中的OAuth2Authentication已经过期，或者雷勇有变化，则会重新更新缓存；

缓存OAuth2AccessToken 和 OAuth2Authentication 对象，该方法主要在登录时调用，会把上面说的所有key值都缓存起来；

再看下，移除accessToken时

目前主要是看这几个方法，其他方法也挺简单的，主要是一些redis缓存 *** 作的；

client_id_to_access 和 uname_to_access 使用的是set集合，众所周知redis的set集合的过期时间是按照整个key来设置的；

每次登陆时，会先根据client_id和用户名去缓存中查找是否有可使用的AccessToken，如果有则返回缓存中的值，没有则生成新的；

所以每次登陆都会往这两个集合中放入新的accessToken，如果当某个用户在AccessToken有效期内没有 *** 作，则当前用户的登陆信息会被动下线，access 和 auth 中缓存的值都会过期，再次登陆时就查找不到了；

但是如果当前平台用户量不小，那么一直都会有人 *** 作，client_id_to_access 这个集合就会一直续期，那么过期了的accessToken就会一直存在该集合中，且不会减少，造成内存泄漏；

1自己实现TokenStore，修改client_id_to_access 数据结构

2写个定时任务，定期扫描client_id_to_access ，清除掉已经过期的token

3如果不需要知道当前有哪些用户登录，或者该功能已经用了其他方式实现的，可以直接去掉这两个redis key

所谓的高可用，也叫 HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它是保证系统SLA的重要指标。Redis 高可用的主要有三种模式： 主从模式 ， 哨兵模式和集群模式 。

Redis 提供了 Redis 提供了复制(replication)功能，当一台 redis 数据库中的数据发生了变化，这个变化会被自动地同步到其他的 redis 机器上去。

Redis 多机器部署时，这些机器节点会被分成两类，一类是主节点（master 节点），一类是从节点（slave 节点）。一般 主节点可以进行读、写 *** 作 ，而 从节点只能进行读 *** 作 。一个主节点可以有多个从节点，但是一个从节点只会有一个主节点，也就是所谓的 一主多从结构 。

· 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离;

· Master 是以非阻塞的方式为主 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求;

· Slave 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis 则返回同步之前的数据。

· Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复;

· 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后面还会引入数据不一致的问题，降低了系统的可用性;

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂;

· Redis 的主节点和从节点中的数据是一样的，降低的内存的可用性

实际生产中，我们优先考虑哨兵模式。这种模式下，master 宕机，哨兵会自动选举 master 并将其他的 slave 指向新的 master。

在主从模式下，redis 同时提供了哨兵命令 redis-sentinel ，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵进程向所有的 redis 机器人发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。一般为了便于决策选举，使用 奇数个哨兵 。多个哨兵构成一个哨兵集群，哨兵直接也会相互通信，检查哨兵是否正常运行，同时发现 master 战机哨兵之间会进行决策选举新的 master

哨兵模式的作用:

· 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器;

· 然而一个哨兵进程对 Redis 服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多种哨兵模式。

哨兵很像 kafka 集群中的 zookeeper 的功能。

· 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

· 主从可以自动切换，系统更健壮，可用性更高。

· 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis 集群模式本身没有使用一致性 hash 算法，而是使用 slots 插槽 。

Redis 哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis30 上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容；每个节点都会通过集群总线(cluster bus)，与其他的节点进行通信。 通讯时使用特殊的端口号，即对外服务端口号加 10000。例如如果某个 node 的端口号是 6379，那么它与其它 nodes 通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

对客户端来说，整个 cluster 被看做是一个整体，客户端可以连接任意一个 node 进行 *** 作，就像 *** 作单一 Redis 实例一样， 当客户端 *** 作的时候 key 没有分配到该 node 上时，Redis 会返回转向指令，指向正确的 node，这有点儿像浏览器页面的 302 redirect 跳转。

根据官方推荐，集群部署至少要 3 台以上的 master 节点，最好使用 3 主 3 从六个节点的模式。

在 Redis 的每一个节点上，都有这么两个东西， 一个是插槽（slot），它的的取值范围是：0-16383， 可以从上面 redis-tribrb 执行的结果看到这 16383 个 slot 在三个 master 上的分布。还有一个就是 cluster，可以理解为是一个集群管理的插件，类似的哨兵。

当我们的存取的 Key 到达的时候，Redis 会根据 crc16 的算法对计算后得出一个结果，然后把结果和 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取 *** 作。

为了保证高可用， redis-cluster 集群引入了主从模式 ，一个主节点对应一个或者多个从节点。当其它主节点 ping 主节点 master 1 时，如果半数以上的主节点与 master 1 通信超时，那么认为 master 1 宕机了，就会启用 master 1 的从节点 slave 1，将 slave 1 变成主节点继续提供服务。

如果 master 1 和它的从节点 slave 1 都宕机了，整个集群就会进入 fail 状态，因为集群的 slot 映射不完整。 如果集群超过半数以上的 master 挂掉，无论是否有 slave，集群都会进入 fail 状态。

redis-cluster 采用去中心化的思想 ，没有中心节点的说法，客户端与 Redis 节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

对 redis 集群的扩容就是向集群中添加机器，缩容就是从集群中删除机器，并重新将 16383 个 slots 分配到集群中的节点上（数据迁移）。

扩缩容也是使用集群管理工具 redis-trirb。

扩容时，先使用 redis-trirb add-node 将新的机器加到集群中，这是新机器虽然已经在集群中了，但是没有分配 slots，依然是不起做用的。在使用 redis-trirb reshard 进行分片重哈希（数据迁移），将旧节点上的 slots 分配到新节点上后，新节点才能起作用。

缩容时，先要使用 redis-trirb reshard 移除的机器上的 slots，然后使用 redis-trirb add-del 移除机器。

采用去中心化思想，数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;

可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;

高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;

降低运维成本，提高系统的扩展性和可用性。

1Redis Cluster 是无中心节点的集群架构，依靠 Goss 协议(谣言传播)协同自动化修复集群的状态。但 GosSIp 有消息延时和消息冗余的问题，在集群节点数量过多的时候，节点之间需要不断进行 PING/PANG 通讯，不必须要的流量占用了大量的网络资源。虽然 Reds40 对此进行了优化，但这个问题仍然存在。

2数据迁移问题

Redis Cluster 可以进行节点的动态扩容缩容，这一过程，在目前实现中，还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。

而 Redis 为了保证迁移的一致性，迁移所有 *** 作都是同步 *** 作 ，执行迁移时，两端的 Redis 均会进入时长不等的阻塞状态，对于小 Key，该时间可以忽略不计，但如果一旦 Key 的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。

主从模式：master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。

哨兵模式：master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。

集群模式：数据量比较大，QPS 要求较高的时候使用。 Redis Cluster 是 Redis 30 以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

redis cluster 前端调度需要加lvs keepalived

Keepalived的安装：

yum -y install openssl-devel

yum install popt-devel

wget

 

tar zxf keepalived-126targz 

 

cd keepalived-126

 

/configure --prefix=/usr/local/keepalived 

 

make

 

make install

cp /usr/local/keepalived/etc/rcd/initd/keepalived /etc/initd/keepalived

chmod +x /etc/initd/keepalived

#修改/etc/initd/keepalived, 寻找大约15行左右的 /etc/sysconfig/keepalived, 修改为： 

#  /usr/local/keepalived/etc/sysconfig/keepalived, 即指向正确的文件位置

 

#同时在上述行下添加以下内容（将keepavlied主程序所在路径导入到环境变量PATH中）：

 

#PATH="$PATH:/usr/local/keepalived/sbin"

 

#export PATH

 

#3 修改/usr/local/keepalived/etc/sysconfig/keepalived文件，设置正确的服务启动参数 

#KEEPALIVED_OPTIONS="-D -f /usr/local/keepalived/etc/keepalived/keepalivedconf"

#

 

#4 切勿忘记将此服务设置为开机启动

#

#chkconfig keepalived on

 

#5 经过以上修改，keepalived基本安装即可完成，启动测试之： 

#service keepalived restart

 

默认的配置文件中，指定了两个数个虚拟IP : 19216820016  19216820017  19216820018

可使用ip addr命令验证之。

LVS的安装：

wget

ln -s /usr/src/kernels/2618-164el5-i686/ /usr/src/linux

tar zxvf ipvsadm-124targz

cd ipvsadm-124

make && make install

ipvsadm  //将ipvsadm注入LINUX内核

可以通过ipvsadm –help或是lsmod | grep ip_vs查看是否成功安装

 

keepalivedconf的配置如下：

! Configuration File for keepalived

global_defs {

   notification_email {

     hesongling@meilelecom

   }

   notification_email_from service@meilelecom

   smtp_server localhost

   smtp_connect_timeout 30

   router_id NodeA

}

 

vrrp_instance VI_1 {

    state MASTER

    interface eth0

    virtual_router_id 51

    priority 100

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

    }

    virtual_ipaddress {

         1921680201

    }

}

以上就是关于查询数据放入了redis中缓存，怎么查看缓存的数据全部的内容，包括:查询数据放入了redis中缓存，怎么查看缓存的数据、redis集群角色切换java调用异常、利用Redis设计库存系统的苦与乐等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！