redis服务器(redis有哪些集群模式)
很多朋友对于redis服务器和redis有哪些集群模式不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！
Redis内存满了怎么办
长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？
在Redis的配置文件 redis.conf文件中，配置 maxmemory的大小参数如下所示：
倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有淘汰策略，把需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用。
Redis提供了 6种的淘汰策略，其中默认的是 noeviction，这6中淘汰策略如下：
LRU(Least Recently Used)即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。
它的核心的思想就是：假如一个key值在最近很少被使用到，那么在将来也很少会被访问。
实际上Redis实现的LRU并不是真正的LRU算法，也就是名义上我们使用LRU算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。
Redis使用的是近似的LRU算法，通过随机采集法淘汰key，每次都会随机选出5个key，然后淘汰里面最近最少使用的key。
这里的5个key只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：
当近似LRU算法取值越大的时候就会越接近真实的LRU算法，可以这样理解，因为取值越大那么获取的数据就越全，淘汰中的数据的就越接近最近最少使用的数据。
那么为了实现根据时间实现LRU算法，Redis必须为每个key中额外的增加一个内存空间用于存储每个key的时间，大小是3字节。
在Redis 3.0中对近似的LRU算法做了一些优化，Redis中会维护大小是 16的一个候选池的内存。
当第一次随机选取的采样数据，数据都会被放进候选池中，并且候选池中的数据会根据时间进行排序。
当第二次以后选取的数据，只有小于候选池内的最小时间的才会被放进候选池中。
当某一时刻候选池的数据满了，那么时间最大的key就会被挤出候选池。当执行淘汰时，直接从候选池中选取最近访问时间最小的key进行淘汰。
这样做的目的就是选取出最近似符合最近最少被访问的key值，能够正确的淘汰key值，因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。
但是LRU算法有一个弊端：就是假如一个key值在以前都没有被访问到，然而最近一次被访问到了，那么就会认为它是热点数据，不会被淘汰。
然而有些数据以前经常被访问到，只是最近的时间内没有被访问到，这样就导致这些数据很可能被淘汰掉，这样一来就会出现误判而淘汰热点数据。
于是在Redis 4.0的时候除了LRU算法，新加了一种LFU算法，那么什么是LFU算法算法呢？
LFU(Least Frequently Used)即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的key，它以最近的时间段的被访问次数的频率作为一种判断标准。
它的核心思想就是：根据key最近被访问的频率进行淘汰，比较少被访问的key优先淘汰，反之则优先保留。
LFU算法反映了一个key的热度情况，不会因为LRU算法的偶尔一次被访问被认为是热点数据。
在LFU算法中支持 volatile-lfu策略和 allkeys-lfu策略。
在Redis种有三种删除的操作此策略，分别是：
在Redis中持久化的方式有两种 RDB和 AOF
在RDB中是以快照的形式获取内存中某一时间点的数据副本，在创建RDB文件的时候可以通过 save和 bgsave命令执行创建RDB文件。
这两个命令都不会把过期的key保存到RDB文件中，这样也能达到删除过期key的效果。
当在启动Redis载入RDB文件的时候， Master不会把过期的key载入，而 Slave会把过期的key载入。
在AOF模式下，Redis提供了Rewite的优化措施，执行的命令分别是 REWRITEAOF和 BGREWRITEAOF，这两个命令都不会把过期的key写入到AOF文件中，也能删除过期key。
RDB是一种快照存储持久化方式，具体就是将 Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dump.rdb，而在 Redis服务器启动时，会重新加载 dump.rdb文件的数据到内存当中恢复数据。
开启RBD持久化方式
开启 RDB持久化方式很简单，客户端可以通过向 Redis服务器发送 save或 bgsave命令让服务器生成 rdb文件，或者通过服务器配置文件指定触发 RDB条件。
save命令是一个同步操作。
当客户端向服务器发送 save命令请求进行持久化时，服务器会阻塞 save命令之后的其他客户端的请求，直到数据同步完成。
与 save命令不同， bgsave命令是一个异步操作。
当客户端发服务发出 bgsave命令时， Redis服务器主进程会 forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
所以，与 save命令相比， Redis服务器在处理 bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但 forks子进程是同步的，所以 forks子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
除了通过客户端发送命令外，还有一种方式，就是在 Redis配置文件中的 save指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写操作】就开启 RDB数据同步。
例如我们可以在配置文件redis.conf指定如下的选项：
之后在启动服务器时加载配置文件。
这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：
Redis的另外一个持久化方式： AOF(Append-only file)。
与 RDB存储某个时刻的快照不同， AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以 Redis协议追加保存到以后缀为 aof文件末尾，在Redis服务器重启时，会加载并运行 aof文件的命令，以达到恢复数据的目的。
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redis.conf文件：
在上面的配置文件中，我们可以通过 appendfsync选项指定写入策略,有三个选项
客户端的每一个写操作都保存到 aof文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
appendfsync的默认写入策略，每秒写入一次 aof文件，因此，最多可能会丢失1s的数据。
Redis服务器不负责写入 aof，而是交由操作系统来处理什么时候写入 aof文件。更快，但也是最不安全的选择，不推荐使用。
AOF将客户端的每一个写操作都追加到 aof文件末尾，比如对一个key多次执行incr命令，这时候， aof保存每一次命令到aof文件中，aof文件会变得非常大。
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性能，因此默认值为no，不推荐使用。
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。
当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
redis到底是个什么东西
1.什么是Redis
Redis是由意大利人Salvatore Sanfilippo（网名：antirez）开发的一款内存高速缓存数据库。Redis全称为：Remote Dictionary Server（远程数据服务），该软件使用C语言编写，Redis是一个key-value存储系统，它支持丰富的数据类型，如：string、list、set、zset(sorted set)、hash。
2. Redis特点
Redis以内存作为数据存储介质，所以读写数据的效率极高，远远超过数据库。以设置和获取一个256字节字符串为例，它的读取速度可高达110000次/s，写速度高达81000次/s。
Redis跟memcache不同的是，储存在Redis中的数据是持久化的，断电或重启后，数据也不会丢失。因为Redis的存储分为内存存储、磁盘存储和log文件三部分，重启后，Redis可以从磁盘重新将数据加载到内存中，这些可以通过配置文件对其进行配置，正因为这样，Redis才能实现持久化。
Redis支持主从模式，可以配置集群，这样更利于支撑起大型的项目，这也是Redis的一大亮点。
3. Redis应用场景，它能做什么
众多语言都支持Redis，因为Redis交换数据快，所以在服务器中常用来存储一些需要频繁调取的数据，这样可以大大节省系统直接读取磁盘来获得数据的I/O开销，更重要的是可以极大提升速度。
拿大型网站来举个例子，比如a网站首页一天有100万人访问，其中有一个板块为推荐新闻。要是直接从数据库查询，那么一天就要多消耗100万次数据库请求。上面已经说过，Redis支持丰富的数据类型，所以这完全可以用Redis来完成，将这种热点数据存到Redis（内存）中，要用的时候，直接从内存取，极大的提高了速度和节约了服务器的开销。
总之，Redis的应用是非常广泛的，而且极有价值，真是服务器中的一件利器，所以从现在开始，我们就来一步步学好它。
redis有哪些集群模式
Redis集群一般有5种：
1，主从复制
2，哨兵模式
3，Redis官方提供的Cluster集群模式(服务端)
4，Jedis sharding集群(客户端sharding)
5,利用中间件代理，比如豌豆荚的codis等
介绍完他们的模式，现在来分析一下他们的原理：
主从复制（Master-Slave Replication）:
实现主从复制（Master-Slave Replication）的工作原理：Slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。
主从复制配置
修改从节点的配置文件：slaveof masterip masterport
如果设置了密码，就要设置：masterauth master-password
哨兵模式:
该模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来，无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。
Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。
Sentinel（哨兵）进程的作用
监控(Monitoring):哨兵(sentinel)会不断地检查你的Master和Slave是否运作正常。
提醒(Notification)：当被监控的某个Redis节点出现问题时,哨兵(sentinel)可以通过 API向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel)会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
Sentinel（哨兵）进程的工作方式
每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING命令。
如果一个实例（instance）距离最后一次有效回复 PING命令的时间超过 down-after-milliseconds选项所指定的值，则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN），则Master主服务器会被标记为客观下线（ODOWN）
在一般情况下，每个 Sentinel（哨兵）进程会以每 10秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO命令。
当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO命令的频率会从 10秒一次改为每秒一次。
若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING命令返回有效回复，Master主服务器的主观下线状态就会被移除。
Redis官方 Cluster集群模式
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。
在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。
Redis集群数据分片
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384求余数，这样每个 key都会对应一个编号在 0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
Jedis sharding集群
Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式，其主要思想是采用hash算法将存储数据的key进行hash散列，这样特定的key会被定为到特定的节点上。
庆幸的是，Java Redis客户端驱动Jedis已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool
Jedis的Redis Sharding实现具有如下特点：
采用一致性哈希算法，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。
为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
利用中间件代理
中间件的作用是将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。
常用的中间件有这几种
Twemproxy
Codis
nginx
文章分享结束，redis服务器和redis有哪些集群模式的答案你都知道了吗？欢迎再次光临本站哦！