redis了解，redis学习

今天给各位分享redis学习的知识，其中也会对redis了解进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

为您整合互联网精准答案：

1、多久可以学会redis

2、Redis 学习总结(3) Redis 哨兵模式

3、Redis 实战 —— 10. 实现内容搜索、定向广告和职位搜索

4、Redis哨兵机制原理浅析

多久可以学会redis

Redis是一个远程内存数据库，它不仅性能强劲，而且还具有复制特性以及为解决问题而生的独一无二的数据模型。Redis提供了5种不同类型的数 据结构，各式各样的问题都可以很自然地映射到这些数据结构上：Redis的数据结构致力于帮助用户解决问题，而不会像其他数据库那样，要求用户扭曲问题来 适应数据库。除此之外，通过复制、持久化（persistence）和客户端分片（client-side sharding）等特性，用户可以很方便地将Redis扩展成一个能够包含数百GB数据、每秒处理上百万次请求的系统。

笔者第一次使用Redis是在一家公司里面，这家公司需要对一个保存了6万个客户联系方式的关系数据库进行搜索，搜索可以根据名字、邮件地址、所在 地和电话号码来进行，每次搜索需要花费10～15秒的时间。在花了一周时间学习Redis的基础知识之后，我使用Redis重写了一个新的搜索引擎，然后 又花费了数周时间来仔细测试这个新系统，使它达到生产级别，最终这个新的搜索系统不仅可以根据名字、邮件地址、所在地和电话号码等信息来过滤和排序客户联 系方式，并且每次操作都可以在50毫秒之内完成，这比原来的搜索系统足足快了 200 倍。阅读本书可以让你学到很多小技巧、小窍门以及使用Redis解决某些常见问题的方法。

Redis 学习总结(3) Redis 哨兵模式

在实际开发中不会仅仅部署一个 Redis 服务器，为了获得高可用，Redis 哨兵模式 则是高可用的一种选择。

本文先介绍下 哨兵模式，再介绍了如何在 springboot 项目中使用。

这意味着使用 Sentinel （哨兵模式），您可以创建一个 Redis 部署，它可抵抗某些类型的故障（进行故障迁移）而无需人工干预。

它有这些功能：

Sentinel 的分布式特性

Redis Sentinel 是一个分布式系统，多个 Sentinel 进程协同工作，有这些优势：

部署前需要了解:

三个节点的基本配置

法定人数和仲裁

在配置 哨兵模式时，要指定一个 quorum，它可理解为“法定人数”。

假设有3 个 哨兵，法定人数为2。那么：

哨兵和副本的自动发现

Sentinel 与其他 Sentinel 保持连接，以便相互检查彼此的可用性并交换消息。

但是，您不需要在您运行的每个 Sentinel 实例中配置其他 Sentinel 地址的列表，因为 Sentinel 使用 Redis 实例的 Pub/Sub 功能来发现正在监视相同主节点和副本的其他 Sentinel。

类似地，您不需要配置附加到主服务器的副本地址在哪里，因为 Sentinel 会通过查询 Redis 自动发现它们。

参考我的另一篇文章：

一般需要三个节点，每个节点有一个 redis 和一个哨兵。

下面再分别描述。

我这里按三个 节点，先配置 redis 的主从复制。1个节点作为 master ，2个副本。

配置节点1：master

这里的 redis 作为 master 主redis，其他两个节点作为从节点。

我的文件夹名字叫 box1，这里编辑一个 box1/redis.conf 文件，主要配置内容如下:

配置节点2：副本

编辑一个 box2/redis.conf 文件，主要配置内容如下:

配置节点3：副本

编辑一个 box3/redis.conf 文件，主要配置内容如下:

分别启动这三个redis

命令行执行 redis-server ，并指定 配置文件的路径参数。

如何查看“主从复制”是否配置成功？

使用 info replication命令，操作如下：

副本节点设置为只读？

从 Redis 2.6 开始，副本已被默认设置为 只读，无需额外配置。.

一般情况下，至少会需要三个哨兵对redis 进行监控，我们可以通过修改端口启动多个sentinel 服务。

第一个哨兵：

哨兵的 默认端口是 26379 ，这里不改。

第二个哨兵：

修改哨兵端口。

第三个哨兵：

修改哨兵端口。

启动哨兵

使用 redis-sentinel 命令，分别启动这三个哨兵

哨兵的自动发现

当三个哨兵都启动后，在各个哨兵的打印日志里可以看到， 三个哨兵已互相发现了彼此的存在 。

至此，配置完毕了，我们有三个 redis，和三个哨兵，看下截图。

模拟 master 宕机

按 ctrl+c 停止 master，其位于 6379 。停止后，从日志可以看到，哨兵和 redis副本先努力继续连接 6379，反复几次失败后，开始选举出新的 master。截图如下：

至此，配置完毕。

我们看下 springboot 项目的客户端如何配置 以访问 哨兵模式的 redis。

Redis 哨兵支持

对于处理高可用Redis，Spring Data Redis 已经支持Redis Sentinel，使用RedisSentinelConfiguration，如下例所示：

Jedis 和 Lettuce 两种 redis 驱动都可以支持。

RedisSentinelConfiguration 也可以用可以 通过 PropertySource 来设置，它允许您设置以下属性：

配置application.yml

比如我这里修改我的 application.yml 文件如下：

我的配置文件示例：

我的 springboot 配置实例：

Redis官网 sentinel 介绍

spring-data/data-redis

END

Redis 实战 —— 10. 实现内容搜索、定向广告和职位搜索

通过改变程序搜索数据的方式，并使用 Redis 来减少绝大部分基于单词或者关键字进行的内容搜索操作的执行时间。P154

倒排索引 (inverted indexes) 是互联网上绝大部分搜索引擎使用的底层结构，它类似于书本末尾的索引。倒排索引从每个被索引的文档里面提取一些单词，并记录包含每个单词的文档集合。P154

示例

假设有三个文档：

我们就能得到下面的倒排索引集合：

检索的条件 \”what\”, \”is\” 和 \”it\” 将对应这个集合： {0,1} ∩ {0,1,2} ∩ {0,1,2} = {0,1}

可以发现 Redis 的集合和有序集合非常适合处理倒排索引。

基本索引操作

从文档里面提取单词的过程通常被成为语法分析 (parsing) 和标记化 (tokenization) ，这个过程可以产生一系列用于表示文档的标记 (token) ，有时又被成为单词 (word) 。P155

标记化的一个常见的附加步骤就是移除非用词 (stop word) 。非用词就是那些在文档中频繁出现却没有提供相应信息量的单词，对这些单词进行搜索将返回大量无用的结果。P155

本书中实现方向索引的逻辑非常简单：

如果需要支持中文等，就不能简单进行英文分词，需要分词器进行处理。第一次接触倒排索引是在Elasticsearch中，感兴趣的可以了解Elasticsearch中倒排索引的实现以及IK中文分词器。

基本搜索操作

在索引里面查找一个单词是非常容易的，只需要获取单词集合里面的所有文档即可。根据多个单词查找文档时，就需要根据条件处理对应的集合，再从最终集合中获取所有文档。P156

可以使用 Redis 的集合操作完成对不同条件的处理：

通过以上三类命令，我们基本能实现条件大部分的与或非操作。

分析并执行搜索

我们使用的查询语句进行分词后具有以下特征：

即： \”connect +connection chat -proxy -proxies\” 表示查询的文档需要包含 \”connect\” 或 \”connection\” ，同时也要包含 \”chat\” ，并且不能包含 \”proxy\” 和 \”proxies\” 。

实际处理时，先对同义词组分别取并集，然后与需要查询的单词一起取交集，最后与不希望包含的单词取差集，这样所得到的集合就是用户查询的结果集。

上述搜索功能以及能够搜索出用户查询的所有文档唯一标识的集合，现在我们将根据这个文档唯一标识集合以及每个文档的具体信息进行排序分页。

对于这种情况我们可以使用 Redis 的SORT命令对文档唯一标识集合通过引用每个文档的具体信息进行排序分页。 （ 05. Redis 其他命令简介 ）

上面介绍了使用 Redis 进行搜索，并通过引用存储在HASH里面的数据对搜索结果进行排序分页。接下来将介绍利用集合和有序集合实现基于多个分值的复合排序操作，它能提供比SORT命令更高的灵活性。P162

假设我们目前需要根据文档对更新时间和得票数进行排序，为此我们需要用两个有序集合存储相关信息。这两个有序集合的成员都是文档唯一标识，成员的分值则分别是文档的更新时间和得票数。

设经过搜索后满足搜索条件的文档唯一标识集合为filtered_doc_ids，文档唯一标识及其更新时间对应的有序集合为doc_ids_with_update，文档唯一 标识及其得票数对应的有序集合为doc_ids_with_votes。那么可以通过ZINTERSTORE命令对这三个集合求交集，最后得出的满足搜索条件的文档唯一标识及其排序分值对应的有序集合，再使用ZRANGE ,ZREVRANGE进行分页获取即可。P162

示例：ZINTERSTORE filtered_doc_ids_with_sort_score 3 filtered_doc_ids doc_ids_with_update doc_ids_with_votes WEIGHTS 0 {update_weight} {vote_weight}

其中：

所思

这种利用分值的方法很巧妙，基本可以实现多字段排序，但是优先级可能难以掌控，难以做到先按照某一字段排序，再按照另一字段排序的形式。因为每个字段对应的分值的数量级可能差别比较小，这个时候如果需要有排序字段的优先级，那么可能需要对每个权重进行精巧地设计才行。

上面介绍了使用有序集合对多个数值字段进行排序，由于有序集合的分值只能是浮点数，所以非数值字段不能直接用于排序，需要转换成对应的浮点数。但由于双精度浮点数只有 64 个二进制位，实际能使用 63 个二进制位，所以能表示的字符串并不多，只能使用字符串的前几个字符进行分值估计，不足指定字符数的需要补齐到指定字符数。当然如果字符集缩小的话，可以重新进行编码计算，进而可以对更长的字符串进行分值估计。P165

当这个分值特别大的时候，可能会引发最终计算的分值溢出而出错的问题。

接下来将介绍使用集合和有序集合构建出一个几乎完整的广告服务平台 (ad-serving platform) 。P166

针对广告的索引操作和针对其他内容的索引操作并没有太大的不同，被索引的的广告通常都拥有像位置、年龄和性别这类必需的定向参数，并且往往只会返回单个广告。P167

广告的价格P167

为了尽可能简化广告价格的计算方式，将对所有类型的广告进行转换，使得它们的价格可以基于每千次展示进行计算，产生出一个估算 CPM (estimated CPM, eCPM) 。P168

将广告插入倒排索引P169

我们基本可以复用上面提到的搜索功能，除了会将广告的关键词插入倒排索引，还会将广告的定向参数（位置、年龄和性别等）插入倒排索引中，并记录广告的类型、基本价格和 eCPM 价格。P169

当系统收到广告定向请求的时候，它要做的就是在匹配用户定向参数的一系列广告里面，找出 eCPM 最高的那一个广告。同时，程序还会记录页面内容与广告内容的匹配程度，以及不同匹配程度对广告点击通过率的影响等统计数据。通过使用这些统计数据，广告中与页面相匹配的那些内容就会作为附加值被计入 CPC 和 CPA 的 eCPM 价格，使得那些包含了匹配内容的广告能够更多地被展示出来。P170

计算附加值

计算附加值就是基于页面内容和广告内容两者之间匹配的单词，计算出应该给广告的 eCPM 价格加上多少增量。每个单词都有一个有序集合，成员为广告 id ，成员的分值为当前单词对这则广告的 eCPM 的附加值。P171

在寻找合适的广告时，我们首先会过滤出匹配定位位置且至少包含一个页面单词的广告，然后通过计算附加值的方法替代搜索，以便实现每次投放价值最高的广告，并能够根据用户的行为学习。同时由于每个广告匹配的内容不同，最优方式应该是使用加权平均值来计算单词部分的附加值，但限于 Redis 本身的命令，我们最终采取 (max + min) / 2 的形式计算单词部分的附加值（max 表示所有匹配单词的最大附加值， min 表示所有匹配单词的最小附加值），采用如下命令即可：ZUNIONSTORE final_score 3 base max min WEIGHTS 1 0.5 0.5。

从用户行为中学习P175

首先需要存储用户的浏览记录，包括三部分：（每 100 次就主动更新一次 eCPM ）P175

其次需要存储用户的点击和动作记录，用于计算 点击通过率 = 点击量或动作次数 / 广告展示次数。（每次都更新 eCPM）P176

最后就是更新 eCPM ，包括两部分：

接下来将使用集合和有序集合实现职位搜索功能，并根据求职者拥有技能来为他们寻找合适的职位。P180

第一反应肯定是直接对每一个求职者搜索所有的岗位，从而找到求职者合适的岗位。但这种方法效率极低（大部分岗位肯定是技能对不上的），而且无法进行性能扩展。P181

使用类似上面提到的附加值形式，每次添加一个岗位时，在对应的技能集合中添加这个岗位的 id ( SADD idx:skill:{skill} {job_id} )，再在岗位有序集合中进行添加，成员为岗位 id ，成员的分值为所需的技能数量 ( ZADD job_required_skill_count {job_id} {required_skill_count} )。搜索的时候就先对求职者所有技能对应的集合使用ZUNIONSTORE操作计算每个公司匹配的技能数量 ( ZUNIONSTORE matched {n} idx:skill:{skill} … WEIGHTS 1 … )，然后再与岗位有序集合求交集，并让公司有序集合的权重为 -1 ( ZINTERSTORE result 2 job_required_skill_count matched WEIGHTS -1 1 )，最后获取分值为 0 的所有岗位即可完成搜索。P181

所思

书上的这个方法比较麻烦，其实可以使用文章最开始的无序倒排索引，岗位相当于要搜索的文档，岗位所需的技能相当于单词。

Redis哨兵机制原理浅析

上一篇文章Redis主从复制原理中简要地说明了主从复制的一个基本原理，包含全量复制、复制积压缓冲区与增量复制等内容，有兴趣的同学可以先看下。

利用主从复制，可以实现读写分离、数据备份等功能。但如果主库宕机后，需要运维人员手动地将一个从库提升为新主库，并将其他从库slaveof新主库，以此来实现故障恢复。

因此，主从模式的一个缺点，就在于无法实现自动化地故障恢复。Redis后来引入了哨兵机制，哨兵机制大大提升了系统的高可用性。

哨兵，就是站岗放哨的，时刻监控周围的一举一动，在第一时间发现敌情并发出及时的警报。

Redis中的哨兵（Sentinel），则是一个特殊的Redis实例，不过它并不存储数据。也就是说，哨兵在启动时，不会去加载RDB文件。

关于Redis的持久化，可以参考我的另外一篇文章 谈谈Redis的持久化——AOF日志与RDB快照

上图就是一个典型的哨兵架构，由数据节点与哨兵节点构成，通常会部署多个哨兵节点。

哨兵主要具有三个作用，监控、选主与通知。

监控：哨兵会利用心跳机制，周期性不断地检测主库与从库的存活性

选主：哨兵检测到主库宕机后，选择一个从库将之切换为新主库

通知：哨兵会将新主库的地址通知到所有从库，使得所有从库与旧主库slaveof新主库，也会将新主库的地址通知到客户端上

我会在下文详细讲一下监控与选主的过程

哨兵系统是通过3个定时任务，来完成对主库、从库与哨兵之间的探活。

首先我们会在配置文件中配置主库地址，这样哨兵在启动后，会以每隔10秒的频率向主库发送info命令，从而获得当前的主从拓扑关系，这样就拿到了所有从库的地址。

接着每隔2秒，会使用pub/sub（发布订阅）机制，在主库上的 sentinel :hello的频道上发布消息，消息内容包括哨兵自己的ip、port、runid与主库的配置。

每个哨兵都会订阅该频道，在该频道上发布与消费消息，从而实现哨兵之间的互相感知。

利用启动配置与info命令可以获取到主从库地址，利用发布订阅可以感知到其余的哨兵节点。

在此基础上，哨兵会每隔1秒向主库、从库与其他哨兵节点发送PING命令，因此来进行互相探活。

当某个哨兵在 **down-after-milliseconds（默认是30秒） **配置的连续时间内，仍然没有收到主库的正确响应，则当前哨兵会认为主库主观下线，并将其标记为sdown（subjective down）

为了避免当前哨兵对主库的误判，因此这个时候还需要参考其他哨兵的意见。

接着当前哨兵会向其他哨兵发送sentinel is-master-down-by-addr命令， 如果有半数以上（由quorum参数决定）的哨兵认为主库确实处于主观下线状态，则当前哨兵认为主库客观下线 ，标记为odown（objective down）

一旦某个主库被认定为客观下线时，这个时候需要进行哨兵选举，选举出一个领导者哨兵，来完成主从切换的过程。

哨兵A在向其他哨兵发送sentinel is-master-down-by-addr命令时，同时要求其他哨兵同意将其设置为Leader，也就是想获得其他哨兵的投票。

在每一轮选举中，每个哨兵仅有一票。投票遵循先来先到的原则，如果某个哨兵没有投给别人，就会投给哨兵A。

首先获得半数以上投票的哨兵，将被选举称为Leader。

这里的哨兵选举，采用的是Raft算法。这里不对Raft做详细的探讨，有兴趣的同学，可以参考我的另外一篇文章 22张图，带你入门分布式一致性算法Raft

该文章采用大量的图例，相信你可以从中学习到全新的知识，从而打开分布式一致性算法的大门，大伙们记得等我搞完Paxos与Zab。

过半投票机制也常用于很多算法中，例如RedLock，在半数以上的节点上加锁成功，才代表申请到了分布式锁，具体可参考这篇文章的最后 我用了上万字，走了一遍Redis实现分布式锁的坎坷之路，从单机到主从再到多实例，原来会发生这么多的问题

在Zookeeper选举中，同样也用到了过半投票机制，在这篇文章中 面试官：能给我画个Zookeeper选举的图吗？ 我从源码角度分析了Zookeeper选举的过程。

在选举到领导者哨兵后，将由该哨兵完成故障恢复工作。

故障恢复分为以下两步：

详细说一下第一步，挑选是有条件的。首先要过滤出不健康的节点，再按某种规则排序，最后取第一个从库，我们直接从源码入手：

因此，以下从库会被过滤出：

剩下的节点，就是健康的节点，此时再执行一次快速排序，排序的规则如下：

本文算是Redis哨兵的一个入门文章，主要讲了哨兵的作用，例如监控、选主和通知。

在Redis读写分离的情况下，使用哨兵可以很轻松地做到故障恢复，提升了整体的可用性。

但哨兵无法解决Redis单机写的瓶颈，这就需要引入集群模式，相应的文章也被列为明年的写作计划中。

/article

redis学习的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于redis了解、redis学习的信息别忘了在本站进行查找喔。

本文从网络转载，原文地址：https://ww.hanming.com/13895.html，原作者保留一切权利，若侵权请联系删除。

《redis了解，redis学习》来自互联网同行内容，若有侵权，请联系我们删除！