redis

redis是单线程的，然而个别的作为缓存应用的话，redis足够了，因为它的读写速度太快了。
官网的一个简略测试：
测试实现了50个并发执行100000个申请。
设置和获取的值是一个256字节字符串。
后果:读的速度是110000次/s,写的速度是81000次/s
但对于访问量特地大的服务来说，还是稍有有余。那么，如何晋升redis的性能呢？搭建集群。

redis次要提供三种集群策略：

  1. 主从复制
  2. 集群
  3. 哨兵

一、主从复制

在主从复制中，数据库分为俩类，主数据库(master)和从数据库(slave)。

1.1 主从复制有如下特点：

  1. 主数据库能够进行读写操作，当读写操作导致数据变动时会主动将数据同步给从数据库
  2. 从数据库个别都是只读的，并且接管主数据库同步过去的数据
  3. 一个master能够领有多个slave，然而一个slave只能对应一个master

1.2 工作机制

  1. slave从节点服务启动并连贯到Master之后，它将被动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后盾存盘过程，同时收集所有接管到的用于批改数据集的命令，在后盾过程执行结束后，Master将传送整个数据库文件到Slave，以实现一次齐全同步。而Slave从节点服务在接管到数据库文件数据之后将其存盘并加载到内存中。尔后，Master主节点持续将所有曾经收集到的批改命令，和新的批改命令顺次传送给Slaves，Slave将在本次执行这些数据批改命令，从而达到最终的数据同步。
  2. 复制初始化后，master每次接管到的写命令都会同步发送给slave，保障主从数据一致性。
  3. 如果Master和Slave之间的链接呈现断连景象，Slave能够主动重连Master，然而在连贯胜利之后，一次齐全同步将被主动执行。

1.3 主从配置

redis默认是主数据，所以master无需配置，咱们只须要批改slave的配置即可。
设置须要连贯的master的ip端口:
slaveof 192.168.0.107 6379
如果master设置了明码。须要配置：
masterauth master-password
连贯胜利进入命令行后，能够通过以下命令行查看连贯该数据库的其余库信息:
info replication

1.3 长处

  1. 同一个Master能够同步多个Slaves。
  2. Slave同样能够承受其它Slaves的连贯和同步申请，这样能够无效的分载Master的同步压力。因而咱们能够将Redis的Replication架构视为图构造。
  3. Master Server是以非阻塞的形式为Slaves提供服务。所以在Master-Slave同步期间，客户端依然能够提交查问或批改申请。
  4. Slave Server同样是以非阻塞的形式实现数据同步。在同步期间，如果有客户端提交查问申请，Redis则返回同步之前的数据
  5. 为了分载Master的读操作压力，Slave服务器能够为客户端提供只读操作的服务，写服务依然必须由Master来实现。即便如此，零碎的伸缩性还是失去了很大的进步。
  6. Master能够将数据保留操作交给Slaves实现，从而防止了在Master中要有独立的过程来实现此操作。
  7. 反对主从复制，主机会主动将数据同步到从机，能够进行读写拆散。

1.4 毛病

  1. Redis不具备主动容错和复原性能，主机从机的宕机都会导致前端局部读写申请失败，须要期待机器重启或者手动切换前端的IP能力复原。
  2. 主机宕机，宕机前有局部数据未能及时同步到从机，切换IP后还会引入数据不统一的问题，升高了零碎的可用性。
  3. Redis的主从复制采纳全量复制，复制过程中主机会fork出一个子过程对内存做一份快照，并将子过程的内存快照保留为文件发送给从机，这一过程须要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新退出集群或者从机和主机网络断开重连时都会进行，也就是网络稳定都会造成主机和从机间的一次全量的数据复制，这对理论的零碎经营造成了不小的麻烦。
  4. Redis较难反对在线扩容，在集群容量达到下限时在线扩容会变得很简单。为防止这一问题，运维人员在零碎上线时必须确保有足够的空间，这对资源造成了很大的节约。
  5. 其实redis的主从模式很简略，在理论的生产环境中是很少应用的，我也不倡议在理论的生产环境中应用主从模式来提供零碎的高可用性，之所以不倡议应用都是由它的毛病造成的，在数据量十分大的状况，或者对系统的高可用性要求很高的状况下，主从模式也是不稳固的。

二、哨兵

该模式是从Redis的2.6版本开始提供的，然而过后这个版本的模式是不稳固的，直到Redis的2.8版本当前，这个哨兵模式才稳定下来，无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能程度扩容，并且这两个模式的高可用个性都会受到Master主节点内存的限度。

2.1 哨兵的作用是监控 redis零碎的运行状况，性能如下

  1. 监控主从数据库是否失常运行。
  2. master呈现故障时，主动将它的其中一个slave转化为master。
  3. master和slave服务器切换后，master的redis.conf、slave的redis.conf和sentinel.conf的配置文件的内容都会产生相应的扭转，即，saster主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控指标会随之调换。
  4. 当被监控的某个Redis节点呈现问题时, 哨兵(sentinel) 能够通过 API 向管理员或者其余应用程序发送告诉。
  5. 多哨兵配置的时候，哨兵之间也会主动监控。
  6. 多个哨兵能够监控同一个redis。

2.2 哨兵工作机制

  1. 哨兵过程启动时会读取配置文件的内容，通过sentinel monitor master-name ip port quorum查找到master的ip端口。一个哨兵能够监控多个master数据库，只须要提供多个该配置项即可。
  2. 配置文件还定义了与监控相干的参数，比方master多长时间无响应即即断定位为下线。
  3. 哨兵启动后，会与要监控的master建设俩条连贯：
    3.1 一条连贯用来订阅master的sentinel:hello频道，并获取其余监控该master的哨兵节点信息
    3.2 另一条连贯定期向master发送INFO等命令获取master自身的信息
  4. 与master建设连贯后，哨兵会执行三个操作，这三个操作的发送频率都能够在配置文件中配置：
    4.1 定期向master和slave发送INFO命令
    4.2 定期向master和slave的sentinel:hello频道发送本人的信息
    4.3 定期向master、slave和其余哨兵发送PING命令

这三个操作的意义十分重大，发送INFO命令能够获取以后数据库的相干信息从而实现新节点的主动发现。所以说哨兵只须要配置master数据库信息就能够主动发现其slave信息。获取到slave信息后，哨兵也会与slave建设俩条连贯执行监控。通过INFO命令，哨兵能够获取主从数据库的最新信息，并进行相应的操作，比方角色变更等。

  1. 接下来哨兵向主从数据库的sentinel:hello频道发送信息，并与同样监控这些数据库的哨兵共享本人的信息，发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用途：
    5.1 其余哨兵能够通过该信息判断发送者是否是新发现的哨兵，如果是的话会创立一个到该哨兵的连贯用于发送ping命令。
    5.2 其余哨兵通过该信息能够判断master的版本，如果该版本高于间接记录的版本，将会更新
  2. 当实现了主动发现slave和其余哨兵节点后，哨兵就能够通过定期发送ping命令定时监控这些数据库和节点有没有进行服务。发送频率能够配置，然而最长间隔时间为1s，能够通过sentinel down-after-milliseconds mymaster 600设置。
  3. 如果被ping的数据库或者节点超时未回复，哨兵认为其主观下线。如果下线的是master，哨兵会向其余哨兵点发送命令询问他们是否也认为该master主观下线。如果一个master主服务器被标记为主观下线（SDOWN），则正在监督这个Master主服务器的所有 Sentinel（哨兵）过程要以每秒一次的频率确认Master主服务器确实进入了主观下线状态。如果达到肯定数目（即配置文件中的quorum）投票，哨兵会认为该master曾经主观下线（ODOWN），并选举领头的哨兵节点对主从零碎发动故障复原。
  4. 如上文所说，哨兵认为master主观下线后，故障复原的操作须要由选举的领头哨兵执行，选举采纳Raft算法:
    8.1 发现master下线的哨兵节点（咱们称他为A）向每个哨兵发送命令，要求对方选本人为领头哨兵
    8.2 如果指标哨兵节点没有选过其他人，则会批准选举A为领头哨兵
    8.3 如果有超过一半的哨兵批准选举A为领头，则A入选
    8.4 如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点期待一个随机工夫后再次发动参选申请，进行下一轮投票精选，直至选举出领头哨兵
    8.5 选出领头哨兵后，领头者开始对进行故障复原，从呈现故障的master的从数据库slave中筛选一个来入选新的master,抉择规定如下：
    8.5.1 所有在线的slave中抉择优先级最高的，优先级能够通过slave-priority配置
    8.5.2 如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越残缺）的入选
    8.5.3 如果以上条件都一样，选取id最小的slave
  5. 挑选出须要继任的slaver后，领头哨兵向该数据库发送命令使其升格为master，而后再向其余slave发送命令承受新的master，最初更新数据。将曾经进行的旧的master更新为新的master的从数据库，使其复原服务后以slave的身份持续运行。

2.3 哨兵配置

哨兵配置的配置文件为sentinel.conf，设置主机名称，地址，端口，以及选举票数即复原时起码须要几个哨兵节点批准。只有配置须要监控的master就能够了，哨兵会监控连贯该master的slave。

sentinel monitor mymaster 192.168.0.107 6379 1

启动哨兵节点：

redis-server sentinel.conf --sentinel &

呈现以下相似信息即启动哨兵胜利

3072:X 12 Apr 22:40:02.554 ### Sentinel runid is e510bd95d4deba3261de72272130322b2ba650e73072:X 12 Apr 22:40:02.554 ### +monitor master mymaster 192.168.0.107 6379 quorum 13072:X 12 Apr 22:40:03.516 * +slave slave 192.168.0.108:6379 192.168.0.108 6379 @ mymaster 192.168.0.107 63793072:X 12 Apr 22:40:03.516 * +slave slave 192.168.0.109:6379 192.168.0.109 6379 @ mymaster 192.168.0.107 6379

能够在任何一台服务器上查看指定哨兵节点信息：

bin/redis-cli -h 192.168.0.110 -p 26379 info Sentinel
控制台输入哨兵信息
redis-cli -h 192.168.0.110 -p 26379 info Sentinel

### Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0master0:name=mymaster,status=ok,address=192.168.0.107:6379,slaves=2,sentinels=1

三、集群

3.1 特点

3.0版本之前的redis是不反对集群的，咱们的徐子睿老师说，那个时候，咱们的redis如果想要集群的话，就须要一个中间件，而后这个中间件负责将咱们须要存入redis中的数据的key通过一套算法计算得出一个值。而后依据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。在取值的时候，同样先将key进行计算，失去对应的值，而后就去找对应的redis节点，从对应的节点中取出对应的值。这样做有很多不好的中央，比如说咱们的这些计算都须要在零碎中去进行，所以会减少零碎的累赘。还有就是这种集群模式下，某个节点挂掉，其余的节点无奈晓得。而且也不容易对每个节点进行负载平衡。

从redis 3.0版本开始反对redis-cluster集群，redis-cluster采纳无核心构造，每一个节点都保留有这个集群所有主节点以及从节点的信息，及集群状态，每个节点都和其余节点连贯。所以redis-cluster是一种服务端分片技术。

  1. 每个节点都和n-1个节点通信，这被称为集群总线（cluster bus）。它们应用非凡的端口号，即对外服务端口号加10000。所以要保护好这个集群的每个节点信息，不然会导致整个集群不可用，其外部采纳非凡的二进制协定优化传输速度和带宽。
  2. redis-cluster把所有的物理节点映射到[0,16383]slot（槽）上，cluster负责保护node--slot--value。
  3. 集群事后给所有节点分好16384个桶，每个节点失去局部桶，当须要在redis集群中插入数据时，依据CRC16(KEY) mod 16384的值，决定将一个key放到哪个桶中。
  4. 客户端与redis节点直连，不须要连贯集群所有的节点，连贯集群中任何一个可用节点即可。整个cluster被看做是一个整体，客户端可连贯任意一个节点进行操作，当客户端操作的key没有调配在该节点上时，redis会返回转向指令，指向正确的节点。
  5. redis-trib.rb脚本（rub语言）为集群的管理工具，比方主动增加节点，布局槽位，迁徙数据等一系列操作。
  6. 节点的fail是通过集群中超过半数的节点检测生效时才失效。集群节点之间通过相互的ping-pong判断是否能够连贯上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，而后去连贯它的备用节点。如果某个节点和所有从节点全副挂掉，集群就进入fail状态，也能够了解成集群的slot映射[0-16383]不残缺时进入fail状态。如果有一半以上的主节点宕机，那么无论这些节点有没有从节点，集群同样进入fail状态。这就是redis的投票机制。
  7. 为了减少集群的可拜访性，官网举荐的计划是将node配置成主从构造，即一个master主节点，挂n个slave从节点。如果主节点生效，redis cluster会依据选举算法从slave节点中抉择一个回升为master节点，整个集群持续对外提供服务。

3.2 配置

1.redis集群依赖ruby，需装置ruby环境，ruby版本需高于2.2

yum install rubyyum install rubygemsgem install redis

2.批改配置文件

bind 192.168.0.107### 配置端口port 6380### 配置快照保留门路，6个节点配置不同门路dir /usr/local/redis-cluster/6380/### 开启集群cluster-enabled yes### 为节点设置不同的工作目录，6个节点配置不同目录cluster-config-file nodes-6380.conf### 集群生效工夫cluster-node-timeout 15000

3.开启集群中的所有节点

redis-service …/6380/redis.confredis-service …/6381/redis.confredis-service …/6382/redis.confredis-service …/6383/redis.confredis-service …/6384/redis.confredis-service …/6385/redis.conf

4.将节点退出集群中，中途须要输出yes确定创立集群
redis-trib.rb create --replicas 1 192.168.0.107:6380 192.168.0.107:6381 192.168.0.107:6382 192.168.0.107:6383 192.168.0.107:6384 192.168.0.107:6385

5.进入集群中任何一个节点
redis-cli -c -h 192.168.0.107 -p 6381

6.查看集群中的节点
cluster nodes

[root@buke107 src]### redis-cli -c -h 192.168.0.107 -p 6381192.168.0.107:6381> cluster nodes868456121fa4e6c8e7abe235a88b51d354a944b5 192.168.0.107:6382 master - 0 1523609792598 3 connected 10923-16383d6d01fd8f1e5b9f8fc0c748e08248a358da3638d 192.168.0.107:6385 slave 868456121fa4e6c8e7abe235a88b51d354a944b5 0 1523609795616 6 connected5cd3ed3a84ead41a765abd3781b98950d452c958 192.168.0.107:6380 master - 0 1523609794610 1 connected 0-5460b8e047aeacb9398c3f58f96d0602efbbea2078e2 192.168.0.107:6383 slave 5cd3ed3a84ead41a765abd3781b98950d452c958 0 1523609797629 1 connected68cf66359318b26df16ebf95ba0c00d9f6b2c63e 192.168.0.107:6384 slave 90b4b326d579f9b5e181e3df95578bceba29b204 0 1523609796622 5 connected90b4b326d579f9b5e181e3df95578bceba29b204 192.168.0.107:6381 myself,master - 0 0 2 connected 5461-10922

如上所示，三主三从节点已创立胜利

7.减少集群节点
cluster meet ip port

其余集群实现形式

中间件

一、twemproxy

  1. twemproxy又称nutcracker，起源于推特零碎中redis、memcached集群的轻量级代理。
  2. Redis代理中间件twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的两头，将客户端发来的申请，进行肯定的解决后（sharding），再转发给后端真正的redis服务器。也就是说，客户端不间接拜访redis服务器，而是通过twemproxy代理中间件间接拜访。升高了客户端直连后端服务器的连贯数量，并且反对服务器集群程度扩大。
  3. twemproxy中间件的外部解决是无状态的，它自身能够很轻松地集群，这样能够防止单点压力或故障。
  4. 从上面架构图看到twemproxy是一个单点，很容易对其造成很大的压力，所以通常会联合keepalived来实现twemproy的高可用。这时，通常只有一台twemproxy在工作，另外一台处于备机，当一台挂掉当前，vip主动漂移，备机接替工作。对于keepalived的用法可自行网上查阅材料。

二、codis

codis是一个分布式的Redis解决方案，由豌豆荚开源，对于下层的利用来说，连贯codis proxy和连贯原生的redis server没什么显著的区别，下层利用能够像应用单机的redis一样应用，codis底层会解决申请的转发，不停机的数据迁徙等工作，所有后边的事件，对于后面的客户端来说是通明的，能够简略的认为后边连贯的是一个内存无限大的redis服务。

客户端分片

分区的逻辑在客户端实现，由客户端本人抉择申请到哪个节点。计划可参考一致性哈希，这种计划通常实用于用户对客户端的行为有齐全控制能力的场景。

一、Jedis sharding集群

Redis Sharding能够说是在Redis cluster进去之前业界广泛的采纳形式，其次要思维是采纳hash算法将存储数据的key进行hash散列，这样特定的key会被定为到特定的节点上。

庆幸的是，Java Redis客户端驱动Jedis已反对Redis Sharding性能，即ShardedJedis以及联合缓存池的ShardedJedisPool

Jedis的Redis Sharding实现具备如下特点：

  1. 采纳一致性哈希算法，将key和节点name同时hashing，而后进行映射匹配，采纳的算法是MURMUR_HASH。采纳一致性哈希而不是采纳简略相似哈希求模映射的次要起因是当减少或缩小节点时，不会产生因为从新匹配造成的rehashing。一致性哈希只影响相邻节点key调配，影响量小。
  2. 为了防止一致性哈希只影响相邻节点造成节点调配压力，ShardedJedis会对每个Redis节点依据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚构节点进行散列。依据权重weight，也可虚拟化出160倍数的虚构节点。用虚构节点做映射匹配，能够在减少或缩小Redis节点时，key在各Redis节点挪动再调配更平均，而不是只有相邻节点受影响。
  3. ShardedJedis反对keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过正当命名key，能够将一组相关联的key放入同一个Redis节点，这在防止跨节点拜访相干数据时很重要。
  4. 当然，Redis Sharding这种轻量灵便形式必然在集群其它能力方面做出斗争。比方扩容，当想要减少Redis节点时，只管采纳一致性哈希，毕竟还是会有key匹配不到而失落，这时须要键值迁徙。
  5. 作为轻量级客户端sharding，解决Redis键值迁徙是不事实的，这就要求利用层面容许Redis中数据失落或从后端数据库从新加载数据。但有些时候，击穿缓存层，间接拜访数据库层，会对系统拜访造成很大压力。