Redis集群原理的核心内容+一步步实现 Redis 搜索引擎
Redis集群原理的核心内容
作者：古霜卡比
原文：www.cnblogs.com/skabyy/p/10013322.html
这几天工作需要研究了一下Redis集群，将其原理的核心内容记录下来以便以后查阅。
集群原理
一个系统建立集群主要需要解决两个问题：数据同步问题和集群容错问题。
Naive方案
一个简单粗暴的方案是部署多台一模一样的Redis服务，再用负载均衡来分摊压力以及监控服务状态。这种方案的优势在于容错简单，只要有一台存活，整个集群就仍然可用。但是它的问题在于保证这些Redis服务的数据一致时，会导致大量数据同步操作，反而影响性能和稳定性。
Redis集群方案
Redis集群方案基于分而治之的思想。Redis中数据都是以Key-Value形式存储的，而不同Key的数据之间是相互独立的。因此可以将Key按照某种规则划分成多个分区，将不同分区的数据存放在不同的节点上。这个方案类似数据结构中哈希表的结构。
在Redis集群的实现中，使用哈希算法（公式是CRC16(Key) mod 16383）将Key映射到0~16383范围的整数。这样每个整数对应存储了若干个Key-Value数据，这样一个整数对应的抽象存储称为一个槽（slot）。每个Redis Cluster的节点——准确讲是master节点——负责一定范围的槽，所有节点组成的集群覆盖了0~16383整个范围的槽。
据说任何计算机问题都可以通过增加一个中间层来解决。槽的概念也是这么一层。它介于数据和节点之间，简化了扩容和收缩操作的难度。数据和槽的映射关系由固定算法完成，不需要维护，节点只需维护自身和槽的映射关系。
槽到节点的映射
Slave
上面的方案只是解决了性能扩展的问题，集群的故障容错能力并没有提升。提高容错能力的方法一般为使用某种备份/冗余手段。负责一定数量的槽的节点被称为master节点。为了增加集群稳定性，每个master节点可以配置若干个备份节点——称为slave节点。Slave节点一般作为冷备份保存master节点的数据，在master节点宕机时替换master节点。在一些数据访问压力比较大的情况下，slave节点也可以提供读取数据的功能，不过slave节点的数据实时性会略差一下。而写数据的操作则只能通过master节点进行。
请求重定向
当Redis节点接收到对某个key的命令时，如果这个key对应的槽不在自己的负责范围内，则返回MOVED重定向错误，通知客户端到正确的节点去访问数据。
如果频繁出现重定向错误，势必会影响访问的性能。由于从key映射到槽的算法是固定公开的，客户端可以在内部维护槽到节点的映射关系，访问数据时可以自己通过key计算出槽，然后找到正确的节点，减少重定向错误。目前大部分开发语言的Redis客户端都会实现这个策略。
节点通信
尽管不同节点存储的数据相互独立，这些节点仍然需要相互通信以同步节点状态信息。Redis集群采用P2P的Gossip协议，节点之间不断地通信交换信息，最终所有节点的状态都会达成一致。常用的Gossip消息有下面几种：
ping消息：每个节点不断地向其他节点发起ping消息，用于检测节点是否在线和交换节点状态信息。
pong消息：收到ping、meet消息时的响应消息。
meet消息：新节点加入消息。
fail消息：节点下线消息。
forget消息：忘记节点消息，使一个节点下线。这个命令必须在60秒内在所有节点执行，否则超过60秒后该节点重新参与消息交换。实践中不建议直接使用forget命令来操作节点下线。
节点下线
当某个节点出现问题时，需要一定的传播时间让多数master节点认为该节点确实不可用，才能标记标记该节点真正下线。Redis集群的节点下线包括两个环节：主观下线（pfail）和客观下线（fail）。
主观下线：当节点A在cluster-node-timeout时间内和节点B通信（ping-pong消息）一直失败，则节点A认为节点B不可用，标记为主观下线，并将状态消息传播给其他节点。
客观下线：当一个节点被集群内多数master节点标记为主观下线后，则触发客观下线流程，标记该节点真正下线。
故障恢复
一个持有槽的master节点客观下线后，集群会从slave节点中选出一个提升为master节点来替换它。Redis集群使用选举-投票的算法来挑选slave节点。一个slave节点必须获得包括故障的master节点在内的多数master节点的投票后才能被提升为master节点。假设集群规模为3主3从，则必须至少有2个主节点存活才能执行故障恢复。如果部署时将2个主节点部署到同一台服务器上，则该服务器不幸宕机后集群无法执行故障恢复。
默认情况下，Redis集群如果有master节点不可用，即有一些槽没有负责的节点，则整个集群不可用。也就是说当一个master节点故障，到故障恢复的这段时间，整个集群都处于不可用的状态。这对于一些业务来说是不可忍受的。可以在配置中将cluster-require-full-coverage配置为no，那么master节点故障时只会影响访问它负责的相关槽的数据，不影响对其他节点的访问。
搭建集群
启动新节点
修改Redis配置文件以启动集群模式：
# 开启集群模式cluster-enabled yes# 节点超时时间，单位毫秒cluster-node-timeout 15000# 集群节点信息文件cluster-config-file "nodes-6379.conf"
然后启动新节点。
发送meet消息将节点组成集群
使用客户端发起命令cluster <ip> <port>，节点会发送meet消息将指定IP和端口的新节点加入集群。
发送meet消息
分配槽
上一步执行完后我们得到的是一个还没有负责任何槽的“空”集群。为了使集群可用，我们需要将16384个槽都分配到master节点数。
在客户端执行cluster add addslots {<a>…<b>}命令，将<a>~<b>范围的槽都分配给当前客户端所连接的节点。将所有的槽都分配给master节点后，执行cluster nodes命令，查看各个节点负责的槽，以及节点的ID。
接下来还需要分配slave节点。使用客户端连接待分配的slave节点，执行cluster replicate <nodeId>命令，将该节点分配为<nodeId>指定的master节点的备份。
使用命令直接创建集群
在Redis 5版本中redis-cli客户端新增了集群操作命令。
如下所示，直接使用命令创建一个3主3从的集群：
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
如果你用的是旧版本的Redis，可以使用官方提供的redis-trib.rb脚本来创建集群:
./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
集群伸缩
扩容
扩容操作与创建集群操作类似，不同的在于最后一步是将槽从已有的节点迁移到新节点。
启动新节点：同创建集群。
将新节点加入到集群：使用redis-cli –cluster add-node命令将新节点加入集群（内部使用meet消息实现）。
迁移槽和数据：添加新节点后，需要将一些槽和数据从旧节点迁移到新节点。使用命令redis-cli –cluster reshard进行槽迁移操作。
收缩
为了安全删除节点，Redis集群只能下线没有负责槽的节点。因此如果要下线有负责槽的master节点，则需要先将它负责的槽迁移到其他节点。
迁移槽。使用命令redis-cli –cluster reshard将待删除节点的槽都迁移到其他节点。
忘记节点。使用命令redis-cli –cluster del-node删除节点（内部使用forget消息实现）。
集群配置工具
如果你的redis-cli版本低于5，那么可以使用redis-trib.rb脚本来完成上面的命令。点击这里查看redis-cli和redis-trib.rb操作集群的命令。
持久化
Redis有RDB和AOF两种持久化策略。这篇文章详细讲解了RDB和AOF持久化原理。
一个RDB持久化的坑
RDB持久化神坑：
即使设置了save “”试图关闭RDB，然而RDB持久化仍然有可能会触发。
从节点全量复制（比如新增从节点时），主节点触发RDB持久化产生RDB文件。然后发送RDB文件给从节点。最后该从节点和对应的主节点都会有RDB文件。
执行shutdown时，如果没有开启AOF，也会触发RDB持久化。
不管save如何设置，只要RDB文件存在，redis启动时就会去加载该文件。
后果：
如果关闭了RDB持久化（以及AOF持久化），那么当Redis重启时，则会加载上一次从节点全量复制或者执行shutdown时保存的RDB文件。而这个RDB文件很可能是一份过时已久的数据。
Cluster模式下，Redis重启并从RDB文件恢复数据后，如果没有读取到cluster-config-file中nodes的配置，则标记自己为单独的master并占用从RDB中恢复的数据的Key对应的槽，导致此节点无法再加入其它集群。
转自：https://mp.weixin.qq.com/s/ZhdZ-RrsurYrTVHrZWSIqw
一步步实现 Redis 搜索引擎
场景
大家如果是做后端开发的，想必都实现过列表查询的接口，当然有的查询条件很简单，一条 SQL 就搞定了，但有的查询条件极其复杂，再加上库表中设计的各种不合理，导致查询接口特别难写，然后加班什么的就不用说了（不知各位有没有这种感受呢~）。
下面以一个例子开始，这是某购物网站的搜索条件，如果让你实现这样的一个搜索接口，你会如何实现？（当然你说借助搜索引擎，像 Elasticsearch 之类的，你完全可以实现。但我这里想说的是，如果要你自己实现呢？）
从上图中可以看出，搜索总共分为6大类，每大类中又分了各个子类。这中间，各大类条件之间是取的交集，各子类中有单选、多选、以及自定义的情况，最终输出符合条件的结果集。
好了，既然需求很明确了，我们就开始来实现。
实现1
率先登场是小A同学，他是写 SQL 方面的“专家”。小A信心满满的说：“不就是一个查询接口吗？看着条件很多，但凭着我丰富的 SQL 经验，这点还是难不倒我的。”
于是乎就写出了下面这段代码（这里以 MYSQL 为例）：
select ... from table_1left join table_2left join table_3left join (select ... from table_x where ...) tmp_1...where ...order by ...limit m,n
代码在测试环境跑了一把，结果好像都匹配上了，于是准备上预发。这一上预发，问题就开始暴露出来。预发为了尽可能的逼真线上环境，所以数据量自然而然要比测试大的多。所以这么一个复杂的 SQL，它的执行效率可想而知。测试同学果断把小A的代码给打了回来。
实现2
总结了小A失败的教训，小B开始对SQL进行了优化，先是通过了explain关键字进行SQL性能分析，对该加索引的地方都加上了索引。同时将一条复杂SQL拆分成了多条SQL，计算结果在程序内存中进行计算。
伪代码如下：
$result_1 = query('select ... from table_1 where ...');$result_2 = query('select ... from table_2 where ...');$result_3 = query('select ... from table_3 where ...');...$result = array_intersect($result_1, $result_2, $result_3, ...);
这种方案从性能上明显比第一种要好很多，可是在功能验收的时候，产品经理还是觉得查询速度不够快。小B自己也知道，每次查询都会向数据库查询多次，而且有些历史原因，部分条件是做不到单表查询的，所以查询等待的时间是避免不了的。
实现3
小C从上面的方案中看到了优化的空间。他发现小B在思路上是没问题的，将复杂条件拆分，计算各个子维度的结果集，最后将所有的子结果集进行一个汇总合并，得到最终想要的结果。
于是他突发奇想，能否事先将各个子维度的结果集给缓存起来，这要查询的时候直接去取想要的子集，而不用每次去查库计算。
这里小C采用 Redis 来存储缓存数据，用它的主要原因是，它提供了多种数据结构，并且在 Redis 中进行集合的交并集操作是一件很容易的事情。
具体方案，如图所示：
这里每个条件都事先将计算好的结果集ID存入对应的key中，选用的数据结构是集合（Set）。查询操作包括：
子类单选：直接根据条件 key，获取对应结果集；
子类多选：根据多个条件 Key，进行并集操作，获取对应结果集；
最终结果：将获取的所有子类结果集进行交集操作，得到最终结果；
这其实就是所谓的反向索引。
这里会发现，漏了一个价格的条件。从需求中可知，价格条件是个区间，并且是无穷举的。所以上述的这种穷举条件的 Key-Value 方式是做不到的。这里我们采用 Redis 的另一种数据结构进行实现，有序集合（Sorted Set）：
将所有商品加入 Key 为价格的有序集合中，值为商品ID，每个值对应的分数为商品价格的数值。这样在 Redis 的有序集合中就可以通过ZRANGEBYSCORE命令，根据分数（价格）区间，获取相应结果集。
至此，方案三的优化已全部结束，将数据的查询与计算通过缓存的手段，进行了分离。在每次查找时，只需要简单的查找 Redis 几次就能得出结果。查询速度上符合了验收的要求。
扩展
分页
这里你或许发现了一个严重的功能缺陷，列表查询怎么能没有分页。是的，我们马上来看 Redis 是如何实现分页的。
分页主要涉及排序，这里简单起见，就以创建时间为例。
如图所示：
图中蓝色部分是以创建时间为分值的商品有序集合，蓝色下方的结果集即为条件计算而得的结果，通过ZINTERSTORE命令，赋结果集权重为0，商品时间结果为1，取交集而得的结果集赋予创建时间分值的新有序集合。对新结果集的操作即能得到分页所需的各个数据：
页面总数为：ZCOUNT命令
当前页内容：ZRANGE命令
若以倒序排列：ZREVRANGE命令
数据更新
关于索引数据更新的问题，有两种方式来进行。一种是通过商品数据的修改，来即时触发更新操作，一种是通过定时脚本来进行批量更新。这里要注意的是，关于索引内容的更新，如果暴力的删除 Key，再重新设置 Key。因为 Redis 中两个操作不会是原子性进行的，所以中间可能存在空白间隙，建议采用仅移除集合中失效元素，添加新元素的方式进行。
性能优化
Redis 是内存级操作，所以单次的查询会很快。但是如果我们的实现中会进行多次的 Redis 操作，Redis 的多次连接时间可能是不必要时间消耗。通过使用MULTI命令，开启一个事务，将 Redis 的多次操作放在一个事务中，最后通过EXEC来进行原子性执行（注意：这里所谓的事务，只是将多个操作在一次连接中执行，如果执行过程中遇到失败，是不会回滚的）。
总结
这里只是一个采用 Redis 优化查询搜索的一个简单 Demo，和现有的开源搜索引擎相比，它更轻量，学习成本页相应低些。其次，它的一些思想与开源搜索引擎是类似的，如果再加上词语解析，也可以实现类似全文检索的功能。