如何在Windows系统下安装多个Redis实例

你好，

下载安装文件,选择稳定版本

wredisio/download 直接安装文件

githubcom/MSOpenTech/redis/ 解压后找到bin目录下的release下的redis-2817

点击安装exe文件，进行安装。选择好路径，一直到安装结束即可。

点击Service查看Redis服务是否正确的安装。Windows--》Servicemsc。默认的端口为6379。服务已启动。

使用客户端工具进行连接，出现如下画面即成功。

使用CMD工具，安装另一个Redis实例服务，端口为6369 需要提前建好6369端口使用的conf文件

如：C:\Users\Gray>E:\redis-2817\redis-serverexe --service-install E:\redis-2817\redis6369conf --service-name RedisServer6369 --port 6369

试验了几次都没有提示成功的信息，但是查看服务成功了，而且用客户端连接也成功了。

查看6369端口的redis服务

使用客户端连接6369 redis服务，出现如下界面表示成功

至此，大功告成。

END

注意事项

安装默认端口外的Redis服务，注意配置文件正确。

互联网需求的3高： 高并发，高可扩，高性能。

Redis 是一种运行速度很快，并发性能很强，并且运行在内存上的NoSql（not only sql）数据库

NoSQL数据库 和 传统数据库 相比的优势：

NoSQL数据库无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。

而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段 简直就是一个噩梦。

Redis的常用使用场景：

缓存 ，毫无疑问这是Redis当今最为人熟知的使用场景。在提升服务器性能方面非常有效；一 些频繁被访问的数据，经常被访问的数据如果放在关系型数据库，每次查询的开销都会很 大，而放在redis中，因为redis 是放在内存中的可以很高效的访问

排行榜 ，在使用传统的关系型数据库（mysql oracle 等）来做这个事儿，非常的麻烦，而利 用Redis的SortSet(有序集合)数据结构能够简单的搞定；

好友关系 ，利用集合的一些命令，比如求交集、并集、差集等。可以方便搞定一些共同好 友、共同爱好之类的功能；

Session共享 ，以jsp为例，默认Session是保存在服务器的文件中，如果是集群服务，同一个 用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用Redis保存Session后，无论 用户落在那台机器上都能够获取到对应的Session信息。

下载： redis：>

或者

更多常用命令-参考连接：

备注：如果一个项目的数据量比较大，就要经常用info来看内存的使用量，这样才能让项目更稳定

你好，Redis哨兵

Redis的主从复制模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用场景这种故障处理的方式是无法接受的。可喜的是Redis从28开始正式提供了Redis Sentinel (哨兵)架构来解决这个问题,本章会对Redis Sentinel进行详细分析。

基本概念

名词 逻辑结构 物理结构 主节点 Redis主服务 一个独立的Redis进程 从节点 Redis从服务 一个独立的Redis进程Redis数据节点 主节点和从节点 主节点和从节点的进程 Sentinel节点 监控Redis数据节点 一个独立的Sentinel进程 Sentinel节点集合 若干个Sentinel节点的抽象组合 若干个Sentinel节点进程 Redis Sentinel Redis高可用方案Sentinel节点集合和Redis数据及诶单进程

主从复制的问题

Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备“顶”上来,并且保证数据尽量不丢失(主从复制是最终一致性)。 第二,从节点可以扩展主节点的读能力,一旦主节点不能支撑住大并发量的读 *** 作,从节点可以在一定程度上帮助主节点分担读压力。 但是主从复制也带来了以下问题: （1）一旦主节点出现故障,需要手动将一个从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令其他从节点去复制新的主节点,整个过程都需要人工干预。 （2）主节点的写能力受到单机的限制。 （3）主节点的存储能力受到单机的限制。

高可用

Redis主从复制模式下,一旦主节点出现了故障不可达,需要人工干预进行故障转移无论对于Redis的应用方还是运维方都带来了很大的不便。对于应用方来说无法及时感知到主节点的变化,必然会造成一定的写数据丢失和读数据错误,甚至可能造成应用方服务不可用。对于Redis的运维方来说,整个故障转移的过程是需要人工来介入的,故障转移实时性和准确性上都无法得到保障，一个1主2从的Redis主从复制模式下的主节点出现故障后,是如何进行故障转移的。 1)主节点发生故障后,客户端(client)连接主节点失败,两个从节点与主节点连接失败造成复制中断。 2)如果主节点无法正常启动,需要选出一个从节点(slave-1),对其执行slaveof no one命令使其成为新的主节点。 3)原来的从节点（slave-1）成为新的主节点后，更新应用方的主节点信息，重新启动应用方 4)客户端命令另一个从节点（slave-2）去复制新的主节点（new-master） 5)待原来的主节点恢复后，让它去复制新的主节点。上述处理过程就可以认为整个服务或者架构的设计不是高可用的,因为整个故障转移的过程需要人为介入。考虑到这点,有些公司把上述流程自动化了,但是仍然存在如下问题:第一，断节点不可达的机制是否健全和标准。第二,如果有多个从节点,怎样保证只有一个被晋升为主节点。第三，通知客户端新的主节点机制是否足够强壮。Redis Sentinel正是用于解决这个问题。

Redis Sentinel的高可用性当主节点出现故障时, Redis Sentinel能自动完成故障发现和故障转移,并通知应用方,从而实现真正的高可用。Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成第六章sentinelmd2020/3/132 / 4自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决了Redis的高可用问题。Redis Sentinel与Redis主从复制模式只是多了若于Sentinel节点,所以Redis Sentinel并没有针对Redis节点做了特殊处理,这里是很多开发和运维人员容易混淆的。从逻辑架构上看, Sentinel节点集合会定期对所有节点进行监控,特别是对主节点的故障实现自动转移。假设我们现在有一个主节点，两个从节点和三个Sentinel节点组成的Redis Sentinel的例。 整个故障转移的处理逻辑有下面4个步骤: 1)主节点出现故障,此时两个从节点与主节点失去连接,主从复制失败 2)每个Sentinel节点通过定期监控发现主节点出现了故障。 3)多个Sentinel节点对主节点的故障达成一致,选举出其中一个sentinel节点作为领导者负责故障转移。 4)Sentinel领导者节点执行了故障转移。通过上面介绍的Redis Sentinel逻辑架构以及故障转移的处理,可以看出Redis Sentinl具有以下几个功能: （1）监控: Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。 （2）通知: Sentinel节点会将故障转移的结果通知给应用方。 （3）主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。 （4）配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节占 集合,从中获取主节点信息。同时看到, Redis Sentinel包含了若干个Sentinel节点,这样做也带来了两个好处: （1）对于节点的故障判断是由多个Sentinel节点共同完成,这样可以有效地防止误判。 （2）Sentinel节点集合是由若干个Sentinel节点组成的,这样即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。 但是Sentinel节点本身就是独立的Redis节点,只不过它们有一些特殊,它们不存储数据,只支持部分命令。

以上就是关于如何在Windows系统下安装多个Redis实例全部的内容，包括:如何在Windows系统下安装多个Redis实例、Redis详解——概述/下载安装、redis实例连接(redis-cli的使用)等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！