Linux下安装配置redis详细教程，并配置哨兵模式
redis版本为redis-3.2.12。
使用该工具将安装包上传到您的数据目录。
在data目录下创建redis文件夹，并在该目录下安装redis。
第 1 步：解压。
第二步：安装，使用PREFIX=/data/redis设置安装目录。
现在redis已经安装完毕，剩下的就是配置和启动服务了。
进入redis目录并创建四个目录，分别命名为配置文件conf、日志log、数据库转储和进程ID pid来存储这些文件。
这四个目录也可以保存在其他文件夹中。
配置文件的配置必须一致。
否则启动服务时会报错。
bin目录是redis安装成功后的一些命令文件。
redis服务由一主二从，哨兵模式组成。
注意：在实际开发中，如果您不使用哨兵模式，您的Redis服务可能由一主一从组成。
默认Redis配置：redis_6379.conf
从属Redis配置，redis_6380.conf和redis_6381.conf与默认Redis配置基本相同。
区别在于端口和数据库。
，日志和pid文件名都显示为6380或6381。
最重要的是建立主从关系并保证同步。
注意：如果只使用Redis服务，只需要在主Redis上配置requirepass，在从Redis上配置masterauth即可。
密码应尽可能复杂，以免被破解。
攻击。
注意：如果您只是使用Redis服务，需要为从Redis添加访问验证，也可以设置requirepass，密码可能与主Redis密码不同。
将配置文件放在/data/redis/conf目录下，然后启动服务。
启动服务必须按照主从顺序启动。
检查服务启动状态：
您还可以通过查看日志文件来检查服务是否正常启动。
通过客户端登录Redis，验证数据同步：
验证登录主Redis，设置数据：
登录Redis，获取数据：Redis那里没有数据。
设置密码以允许无需身份验证的操作。
Sentinel模式配置：
一个RedisSentinel集群通常由3到5个节点组成。
如果单个节点发生故障，集群仍然可以正常运行。
Sentinel 负责监控 Redis 集群的运行状况。
如果默认Redis出现故障，Sentinel集群会投票选择新的默认Redis。
当原主Redis恢复后，它会重新加入Redis集群，作为新主Redis的从Redis。
设置主从连接密码。
Sentinel 不能为主从设置不同的密码，因此主从的密码必须设置相同。
这意味着主Redis和从Redis都必须设置requirepass和masterauth，并且它们的密码必须相同。
sentinel.conf配置信息：
将配置文件放在/data/redis/conf目录下，启动sentinel服务。
验证sentinel是否存在。
当功能启动时您可以手动关闭默认的Redis。
此时，如果从Redis尝试访问主Redis同步的数据，会出现如下错误信息。
哨兵检测到主Redis宕机后，通过选择一个从Redis作为新的主Redis来选择一个从Redis。
如果查看哨兵日志，可以看到6380被选为新的主Redis，其余两个Redis被选为从Redis。
注意：选择6380为主Redis后，所有配置文件都会被修改，主要是重新建立主从关系。
6379 增加：slaveof127.0.0.16380
6380 删除：slaveof127.0.0.16379
6381 待修改：slaveof127.0.0 .16380
6379 由于服务已终止，Sentinel 我使用6379作为6380的从服务，但实际上并没有部署。
6379 当您重新启动服务时，Sentinel 会重新配置主从关系。
redis 哨兵模式 至少多少个节点
配置Redis从节点时，需要编辑从节点的配置文件，添加以下命令：slaveof192.168.0.1006379。这意味着从节点将连接主节点的IP地址192.168.0.100，端口号6379。
如果主节点启用了密码认证，还需要在配置文件中添加：masterauthadmin。
假设主节点的密码是admin。
配置完成后，重启从节点的Redis服务。
Sentinel模式是Redis集群的高可用解决方案。
在哨兵模式下，Redis实例分为主节点和从节点。
主节点负责数据写入操作，从节点负责数据读取操作。
当主节点出现故障时，Sentinel会自动发现并选举新的主节点，保证系统的高可用性。
配置哨兵模式时，至少需要3个节点。
其中一个作为主节点，另外两个作为哨兵节点。
哨兵节点负责监控主节点的状态。
当主节点出现故障时，哨兵会根据配置的规则选举新的主节点。
Sentinel模式的优点是可以自动检测故障并进行故障转移，无需人工干预。
设置Sentinel模式时，建议将节点分布在不同的网络位置，以提高系统的容灾能力。
同时，为了保证系统的高可用性，建议至少配置3个哨兵节点，因为当节点数小于3个时，哨兵选举可能会出现问题。
在哨兵模式下，节点之间的通信是通过Redis协议进行的。
哨兵节点定期向主节点发送PING命令，检查主节点的状态。
如果主节点变得无响应，哨兵节点将假定主节点已发生故障并启动故障转移过程。
Sentinel模式还支持多master模式，这意味着集群中可以同时运行多个master节点，以提高系统的读写性能。
Sentinel模式提供了自动故障转移、监控主节点状态、故障转移通知等多种功能，大大提高了Redis集群的可用性和可靠性。
玩转Redis的高可用（主从、哨兵、集群）
所谓高可用性，也称为HA（HighAvailability），是分布式系统架构设计必须考虑的因素之一。
这是保证系统SLA的重要指标。
Redis高可用主要有三种模式：主从模式、看门狗模式、集群模式。
Redis提供 Redis提供复制功能，当redis数据库中的数据发生变化时，这种变化会自动同步到其他redis机器上。
当Redis部署在多台机器上时，这些机器节点会分为两种，一种是主节点，一种是从节点。
一般来说，主节点可以进行读写操作，而从节点只能进行读操作。
一个主节点可以有多个从节点，但一个从节点只能有一个主节点，称为一主多从结构。
·支持主从复制，服务器会自动与Slave同步数据，读写可以分离；
·Master以非阻塞的方式为主从提供服务。
因此，在Master-Slave同步过程中，客户端仍然可以发送查询或者请求修改；
·Slave也以非阻塞的方式完成数据同步。
同步过程中，如果客户端发送查询请求，Redis会返回同步前的数据。
·Redis不具备自动容错和恢复功能。
服务器和从机宕机会导致部分前端读写请求失败。
您需要等待设备重新启动或。
手动切换UI IP恢复；
·服务器宕机。
在机器停止工作之前，有些数据无法及时与从机同步。
IP传输后，数据不一致。
将进行介绍。
系统可用性降低；
·Redis几乎不支持在线伸缩，当集群容量达到上限时，在线伸缩变得非常复杂；
·Redis主从节点内部数据相同但内存占用减少了
在实际生产中，我们优先考虑guard模式。
在这种模式下，如果master宕机了，guard会自动选举master，并将其他slave指向新的master。
在主从模式下，redis还提供了redis-sentinel哨兵命令。
Sentinel是一个独立的进程，它会独立运行。
其原理是哨兵进程向所有Redis机器人发送命令并等待Redis服务器响应，从而监控多个正在运行的Redis实例。
一般情况下，使用奇数个警卫来促进决策和选举。
多名守卫组成守卫集群。
哨兵之间会直接通信，检查哨兵是否正常工作。
哨兵模板的作用：
·通过发送命令，让Redis服务器返回监控运行状态其主服务器和辅助服务器；
·但是，当哨兵进程监视Redis服务器时，也会出现问题。
，我们可以使用多个守卫来监控。
每个哨兵也会受到监控，从而形成多种不同的哨兵模式。
Sentinel与kafka集群中zookeeper的功能非常相似。
·Guard模式基于主从模式，Guard模式具有主从模式的所有优点。
·主从自动切换，使系统更加健壮、高可用。
·它的缺点是主从模式，每台机器上的数据都是相同的，内存可用性较低。
·Redis 难以支持在线扩展。
当集群容量达到上限时，在线伸缩变得非常复杂。
Redis集群模式本身并没有使用一致性哈希算法，而是使用了槽。
Redis哨兵模式基本可以实现高可用和读写分离。
但这种模式下，每个Redis服务器存储的数据都是一样的，浪费内存，所以在redis3.0中增加了Cluster。
集群模式实现了Redis数据的分布式分片存储，即每个Redis节点存储不同的； 每个节点通过集群总线与其他节点通信。
使用特殊的端口号进行通信，即外部服务端口号加10000。
例如，如果一个节点的端口号是6379，那么它与其他节点通信的端口号就是16379。
节点之间的通信使用特殊的二进制协议。
对于客户来说，整个集群被视为一个整体。
客户端可以连接到任意节点进行操作，就像操作单个Redis实例一样。
当客户端操作时某个key没有分配给某个节点时，Redis会返回控制指令指向正确的节点。
这有点像浏览器页面上的 302 重定向。
根据官方建议，集群部署至少需要三个主节点，最好采用三主三备的六节点模型。
在每个Redis节点上，有两件事。
一是位置。
它的值范围是：0-16383，你可以从上面的redis-trib.rb中读取它。
执行结果显示分配情况。
这16383个位置原来就三个。
另外一个是cluster，可以理解为集群管理插件，类似于Sentinel。
当我们的Access Key到来时，Redis会根据crc16算法计算出结果，然后计算结果与16384的余数，这样每个key就会对应一个0处的数字。
槽位哈希值介于-16383 利用该值找到对应槽位对应的节点，然后自动跳转到对应节点进行访问操作。
为了保证高可用性，redis-cluster引入了主从模式，一个主节点对应一个或多个从节点。
当其他主节点ping主节点master1时，如果超过一半的主节点超时期间与master1通信，则master1被认为空闲，master1的从节点Slave1将会开启，slave1将成为主节点继续提供服务。
如果master1及其从节点Slav1都宕机了，整个集群会因为集群位置映射不完整而进入错误状态。
如果集群中超过一半的master挂掉，那么无论有没有slave，集群都会进入错误状态。
redis-cluster应用了层次结构的思想。
没有中心按钮。
客户端直接连接到Redis节点，无需中间代理层。
集群中的所有节点，并且可以连接到集群中的任何节点。
只需一个可用按钮就足够了。
redis集群扩容是指向集群中添加机器，缩短是指从集群中移除机器，并将16383槽重新分配给集群中的节点（数据迁移）。
集群管理工具redis-tri.rb也用于扩展和折叠。
扩容时，首先使用redis-tri.rbadd-node向集群添加新机器。
尽管新机器已经在集群中，但它没有分配的插槽并且保持不活动状态。
属于. 新节点只有使用redis-tri.rbreshard重新哈希分片（移动数据）并将旧节点上的slot分配给新节点后才能生效。
缩容时，先使用redis-tri.rbreshard移除机器上的槽位，然后使用redis-tri.rbadd-del移除机器。
采用层次结构的思想，数据按照位置存储分布在多个节点中，节点之间数据共享，数据分布可灵活调整；
可扩展性：线性扩展至1000多个节点，可以灵活添加或删除节点；
高可用性：当部分节点不可用时，集群仍然可用。
通过添加Slave作为备份数据副本，节点之间可以通过Gossip协议自动交换状态信息，并利用投票机制完成从Slave到Master的角色晋升；
减少运维成本，同时提高系统可靠性。
1. RedisCluster是一种没有中心节点的集群架构。
它基于Goss（八卦传播）协议来协作并自动修复集群的状态。
然而，GosSIp存在消息延迟和消息冗余的问题。
当集群节点过多时，节点之间需要持续进行PING/PANG通信，不必要的流量会占用大量网络资源。
虽然Reds4.0对此进行了优化，但是这个问题依然存在。
2. 数据迁移问题
RedisCluster可以动态扩容和缩容节点。
在当前的实施中，该过程仍然是半自动化的，需要人工干预。
当扩容或缩容时，需要进行数据迁移。
为了保证迁移一致性，所有Redis迁移都是同步的。
当进行迁移时，两端的Redis都会切换到不同长度的阻塞状态，可以忽略。
，但如果Key的内存占用太大，在发生临界迁移的情况下会导致集群故障，造成不必要的切换。
主从模式：主节点挂起后，需要手动分配新的主节点。
可用性很差并且基本上未使用。
哨兵模式：主节点崩溃后，哨兵进程会主动选举新的主节点，主节点高可用，但每个节点存储的数据相同，造成内存空间浪费。
数据量不大，簇大小也不是很大。
当需要自动容错和灾难恢复时使用。
集群模式：数据量较大、QPS要求较高时使用。
RedisCluster是在Redis 3.0之后正式推出的。
能够在大规模生产环境中证明其成功的案例并不多。
