是否需要使用Redis取决于你的小项目的具体需求。Redis是一款内存数据存储系统，主要用于提高数据读写速度，支持高速数据操作，如缓存、排行榜、消息队列等场景。

1. 如果你的项目需要频繁进行数据读写，比如需要快速获取用户信息、缓存热门内容等，使用Redis可以大大提高性能。 2. 如果项目涉及到消息队列，Redis的发布/订阅功能可以很好地实现这一需求。 3. 如果项目需要实时更新和查询，如实时统计、计数、排行榜等，Redis的高并发和低延迟特性非常合适。

但是，如果项目规模较小，数据量不大，对性能要求不高，或者上述场景并不适用，那么可能就不需要额外引入Redis，直接使用数据库（如MySQL、SQLite等）就足够了。因此，你需要根据你的项目特点来判断是否需要使用Redis。

大家感觉很有用，请帮忙转发，你的每一次转发就是对老顾的支持

在企业应用中，小伙伴们要经常去思考，业务进行中，如何方便管理，及时发现问题，是非常重要的。这也是很多管理者经常忽略的，都只是先把功能完成了，而不顾管理和监控。希望这篇文章能够帮助大家，从另一个纬度发现问题。谢谢！！！

小项目需要redis么

在上面的发现异常的基础上面，如果发现某些业务应用，不正常，就可以立即发起截断该客户端的请求，这样可以保证其他业务不受影响。这里我们使用客户端方式去实现截断。原理也很简单，在redis二次封装的类中，我们需要判断本机是否在黑名单中，如果存在，则无法操作方法，或报异常。

在可以设置相关的报警规则，如：某个key一直被调用正月十五最适合做的小生意，在一段时间内操作次数太高。这样就可以方便排查哪些key导致cpu负载太高，就可以去看一下设置这个key的代码，有没有什么问题？是不是死循环等问题？

我们可以采用把redis的集群地址配置在zookeeper中，应用在启动的时候，获取zk上的集群地址的值，进行初始化。如果想要改变集群地址，要在zk上面进行设置。

解决这个问题，其实原理比较简单，就是程序如果能够知道redis集群地址产生了变化，重新设置一下jedis客户端的连接配置。现在的问题就是如何知道redis集群地址发生了改变？

如果项目管理中，对业务的划分比较合理的话，可以在外面再封装一个简单的方法，把business业务放在配置文件中，这样就不需要每次都要传business这个参数了。

当我们在生产环境中，发现异常是由哪个业务产生时，或者是哪个应用服务器产生的，那如何很快速截断的让有问题的业务和应用服务器，先不让他们访问我们公共redis集群，等排查出原因在恢复他们的访问权限。

因为不同的业务，不同的团队，不同的开发人员在真实业务场景中，我们管理者是无法避免bug存在的，也无法预测线上会发生什么样的问题？如：发现redis集群有不稳定情况，cpu负载非常高，那我们怎么知道是哪个业务导致的呢？

上面的方式是否太low了，都需要重新启动应用，那么多的应用都需要重启，是不是很麻烦，而且如果在无法区分业务的情况下，还不知道重启哪些业务应用。

我们在开发web服务时，会用类似jedis客户端连接redis服务器，会在配置文件中加入redis集群地址。不过当系统遇到redis负载太高，或者redis的数据需要扩容，就需要增加redis服务器。这时就需要重新把配置文件中的redis集群更改，再重启应用。

redis的key在开发的使用是要合理进行设计规划的，但两个不同的团队，技术和管理都不一样，即使有规范文档，但不同的业务团队间，规范的执行就不得而知。

KEY： user:1000、user:book、book、user:like:book、book:user；甚至会出现key冲突。

在一般企业中，不同的业务线一般我们采用的是公共redis集群，因为业务线都不大，独立集群没有必要。这样虽然对redis资源充分利用了，但会出现一些问题。

这种方案就是不同的业务用不同的redis集群，这种方案针对一些小项目或业务线不复杂，以及用到redis缓存范围不大的话，是对服务器资源的浪费，而且增加了运维的工作量。

现在我们企业中，做的项目产品肯定不止一个；或者一个大的平台中，会有很多业务线。不同的项目和业务线肯定是不同的团队进行开发的。那大家都会用到redis，那怎么去划分？

redis支持多种数据类型，String（字符串）、list（列表）、hash（哈希）、set（集合）、zset（有序集合），不同的类型可以应用到不同的业务需求中。

小伙伴们对redis应该不陌生，redis是系统必备的分布式缓存中间件，主要用来解决高并发下分担DB资源的负载，从而提升系统吞吐量。

推荐语：多名专家联袂推荐，资深专家联合撰写，深入理解Redis 5设计精髓。系统讲解Redis 5设计、数据结构、底层命令实现，以及持久化、主从复制、集群。

推荐语：从开发、运维两个角度总结了Redis实战经验，深入浅出地剖析底层实现，包含大规模集群开发与运维的实际案例、应用技巧。全面覆盖Redis 基本功能及应用，图示丰富，讲解细腻。

推荐语：资深 Redis 技术专家撰写，深入了解 Redis 技术内幕的必读之作。从源码角度解析 Redis 的架构设计、实现原理和工作机制，为高效使用 Redis 提供原理性指导。

此外，包括亚马逊、谷歌、RedisLabs、阿里云和腾讯云在内的多个云服务提供商都提供了基于Redis或兼容Redis的服务，如果你不打算自己搭建Redis服务器，那么上述提供商可能是不错的选择。

正如之前所说，Redis已经在互联网公司得到广泛应用，许多开发者为不同的编程语言开发了相应的客户端（redis.io/clients），大多数编程语言的使用者都可以轻而易举地找到所需的客户端，然后直接开始使用Redis。

Redis的API虽然丰富，但它们大部分都非常简短，并且只需接受几个参数就可以完成用户指定的操作。更棒的是，Redis在官方网站（redis.io）上为每个API以及相关特性都提供了详尽的文档，并且客户端本身也可以在线查询这些文档。

“虽然Redis提供了很多很棒的数据结构和特性，但如果它们使用起来非常困难的话，那么这一切就没有意义。”如果你对此有所担心的话，那么现在可以打消你的顾虑了！Redis API遵循的是UNIX“一次只做一件事，并把它做好”的设计哲学。

但Redis并没有因此放弃在效率方面的追求，相反，Redis的开发者在实现各项数据结构和特性的时候都经过了大量考量，在底层选用了很多非常高效的数据结构和算法，以此来确保每个操作都可以在尽可能短的时间内完成，并且尽可能地节省内存。

Redis是一款内存数据库，它将所有数据存储在内存中。因为计算机访问内存的速度要远远高于访问硬盘的速度，所以与基于硬盘设计的传统数据库相比，Redis在数据的存取速度方面具有天然的优势。

无论你运营的是一个小型的个人网站，还是一个为上千万消费者服务的热门站点，都可以在Redis中找到你想要的功能，并将其部署到你的服务器中。

更重要的是，Redis不仅可以单机使用，还可以多机使用：通过Redis自带的复制、Sentinel和集群功能，用户可以将自己的数据库扩展至任意大小。

在上述数据结构的基础上，Redis提供了很多非常实用的附加功能，比如自动过期、流水线、事务、数据持久化等，这些功能能够帮助用户将Redis应用在更多不同的场景中，或者为用户带来便利。

在有需要的时候，用户还可以通过事务、Lua脚本、模块等特性，扩展已有数据结构的功能，甚至从零实现自己专属的数据结构。通过这些数据结构和特性，Redis能够确保用户可以使用适合的工具去解决问题。

Redis为用户提供了字符串、散列、列表、集合、有序集合、HyperLogLog、位图、流、地理坐标等一系列丰富的数据结构，每种数据结构都适用于解决特定的问题。

Redis是一个主要由Salvatore Sanfilippo（Antirez）开发的开源内存数据结构存储器，经常用作数据库、缓存以及消息代理等。

无论是国内还是国外，从五百强公司到小型初创公司都在使用Redis，很多云服务提供商还以Redis为基础构建了相应的缓存服务、消息队列服务以及内存存储服务，当你使用这些服务时，实际上就是在使用Redis。

Redis从一个不为人熟知、只有少量应用的崭新数据库，逐渐变成了内存数据库领域的事实标准。时至今日，经过大量的实践应用，Redis简洁高效、安全稳定的特性已经深入人心。

Redis也是可以做为消息队列的，对于一些要求不高的运用场景可以使用redis，redis具备发布订阅功能。而如果专门来做消息队列处理或者要求比较，那还是选择更专业一点的Kafka、rabbitMQ等。

redis的数据是存储在内存中的，如果搭载redis的服务器哪天突然心情不好，宕机不干活了，就会导致所有的缓存都丢失了。虽然可以把Redis服务器重新上线，但是由于内存的数据丢失，造成了缓存雪崩，应用服务器和数据库的压力一下子就上来了，对于一些并发很高的应用，说不动此时就导致应用崩溃无法访问。这个时候Redis的持久化功能就派上用场了，可以缓解一下缓存雪崩带来的影响。redis的持久化指的是redis会把内存的中的数据写入到硬盘中，在redis重新启动的时候加载这些数据，从而最大限度的降低缓存丢失带来的影响。

（1）结构简单，key/value型数据库，赋值取值方式简单。但同时它的数据结构又非常丰富，它支持字符串、哈希表、列表、集合、位图等数据类型。

相比于其他的缓存工具，比如Ehcache和Memcached，开源项目使用redis的比例还是要略高一点，redis同这些缓存工具相比，有以下特征或者优势：

redis做为高速缓存，这也是redis应用最广的地方。 对于那些经常被查询,不经常被修改和删除的数据，利用Redis缓存可以提升网站的访问速度,大大降低数据库的压力。redis作为高速缓存，带来这么大的优势的同时也存在一定的弊端，因为Redis是存放在内存中的,就会导致内存占用过高,另外持久化的代价也过高。

（1）Redis只能存储key/value类型，虽然value的类型可以有多种，但是对于关联性的记录查询，没有Oracle/Mysql方便。

Mysql/Oracle等数据库可以将数据保存数据库当中，应用启动以后建立数据库连接就可以通过代码逻辑对数据库进行中增删改查。而Redis也是可以做为数据库来使用的，它可以看做一个key/value型数据库，Redis会根据配置定时将内存中的数据写入到硬盘中，但我们在项目中一般不会将Redis直接当作数据库来使用，主要原因在于：

Redis可用作数据库，高速缓存和消息队列代理，那么当你打算使用它们这些功能的时候，可以考虑一下与其他产品的对比，选出一个更好用的。

综上所诉，主从模式和哨兵模式都不利于扩展，系统的高可用性都依赖于master的内存大小，哨兵模式在redis2.6开始支持，2.8稳定，cluster模式是redis可扩展的模式。

缺点：客户端实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度；slave充当“冷备”，不能缓解读压力；批量操作限制，目前只支持具有相同slot值的key执行批量操作，对其他的如sunion、mset和mget等支持不是很好；

集群中的每个节点都是平等的关系，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据；

Redis Cluster 一般由多个节点组成，节点数量至少为 6 个才能保证组成完整高可用的集群，其中三个为主节点，三个为从节点。三个主节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。单台服务器资源的总是有上限的，CPU资源和IO资源我们可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上。但是内存资源怎么办，主从模式做到的只是相同数据的备份，并不能横向扩充内存；单台机器的内存也只能进行加大处理，但是总有上限的。所以我们就需要一种解决方案，可以让我们横向扩展。cluster模式的出现就是为了解决单机Redis容量有限的问题香薰蜡烛创业小项目男生，将Redis的数据根据一定的规则分配到多台机器。

优点：哨兵集群，基于主从复制模式，所有的主从配置优点，它都有主从可以切换，故障可以转移，高可用性的系统哨兵模式就是主从模式的升级，手动到自动，更加健壮；

若没有足够数量的Sentinel同意master服务器下线，则master的SDOWN状态被移除，若master重新向Sentinel发送ping命令返回了有效回复，则master的SDOWN状态被移除。

在一般情况下，每个Sentinel会每10秒向redis 主服务器和从服务器发送Info命令。但是当master被标记为客观下线时，频率改为1秒一次。

当有足够数量（≥配置文件配置值）的Sentinel在指定的时间内确认了master进入了SDOWN状态，则master被标记为ODOWN(客观下线状态)。

如是是master主服务器被标记为SDOWN，则正在监控这个服务器的所有Sentinel都要以每秒一次的频率确认服务器是否真的已经进入SDOWN(主观下线状态)。

每个Sentinel（哨兵）进程以每秒钟一次的频率向整个redis集群中的master主服务器、slave从服务器以及其他的Sentinel（哨兵）进程发送一个ping命令。

专题： 农村做创业   农村创业难   农村创业低