redis第六课-分布式解决方案概述

前五课，我们已经完成了redis单机版基本可以涉及到的大部分内容。
自此开始，我们将开始redis的集群时代，在此之前，首先要聊聊，为什么后来需要集群时代的来临呢？ 单机版怎么就不够用了？

redis作为一个单机、单节点、单实例的时候，主要有如下问题存在：

1、单点故障。 这是所有的应用在单机时无可避免的问题，当一台机器出现故障时，那意味着整个世界都完蛋了。
2、容量有限。 单台计算机硬件的容量毕竟有限。
3、压力。 单台redis当承担并发稍微高一些的请求时，未免压力有些山大。

拆分准则

因此我们非常有必要在单台redis已经不能满足我们的时候，对它进行改造。
那，应该是这么一种扩法是比较合适呢？
在此之前，我们可以先来了解微服务设计原则：https://www.cnblogs.com/guanghe/p/10978349.html
总结的话，微服务设计尽量遵循四大原则：
1、AKF拆分原则
2、前后端分离原则
3、无状态服务
4、RestFul通讯风格

这里我们主要对AKF拆分原则进行主要了解：

AKF拆分原则，业界对可扩展系统架构设计有一个朴素的概念，就是通过加机器可以解决容量和可用性问题(如果一台不行就两台) 。
用个段子描述就是：世界上没有什么事是一顿烧烤解决不了的,如果有，那就两顿。

拆分主要可以分为三个方向：
X轴：（水平扩展）关注水平扩展通过绝对平等的复制服务与数据，以解决容量与可用性的问题，其实就是将微服务运行多个实例，做集群加负载均衡的模式。
Y轴：（功能）关注应用中功能划分，基于不同的业务拆分
Z轴：（数据分区）关注服务与数据的优先级划分，如按地域划分，我们将一个完整的数据集按一定维度划分出不同的子集。一个分区（Shard），就是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户就可以认为是同一个分区，亦或者比如滴滴打车，你在哪个城市打车，就给你展示哪个城市的司机数据分区。

在redis中也可以遵循这样的拆分原则：

拆分后（一变多）的问题

我们知道了可以遵循AKF从三种维度考虑拆分，拆分后意味着一台变成了多台。
多台自然是解决了我们说的单点时的问题，但多节点还带来了新的问题：数据一致性问题

关于多节点分布我们可以聊一聊两种模型：
主从：主机从机同时提供服务，除了主机，从机业对外提供服务，且可以分担主机的压力。
主备：只有主机提供服务，从机只作为主机瘫痪时的候选机器。

一般来说，企业更倾向于使用主从模型进行分布式多节点布置。

这里我们也聊聊redis基于多节点时，客户端发送一次数据操作时的不同情况：

当客户端发送一条新增k1的指令后，redis主机首先会在自己确认保存完成后，要同步阻塞等待每一个其他机器的同步完成的通知之后，才会返回给客户端成功的响应。
这属于强一致性的操作，而根据CAP定则，强一致性势必会导致可用性无法兼顾，这里也是一样，如果某一台从机出现故障，导致响应一直不返还，我们知道请求一般都是有超时时间的，这样可能导致最终返回失败，从客户端来看，这属于服务的不可用了。

有的人可能说了，那就不要管其他机器好没好了，主机只要接收到了，就直接返回OK给客户端。
这属于弱一致性操作，可能会导致丢失数据。 这不能确保其他从机的接受状态是都是成功的。 但我们一定可以说，这应该是最快的，因此，redis的主从复制就是默认采用的这种方式。

我们可以想一想，有没有比较折中的方式，又快又能让数据不丢？ 也是有的，可以在它们之间多一个中间层，这个中间层自身一定是保证高可用的且可以快速返回的，例如可以是kafka。
我们可以直接让主机向中间层发送成功后，就直接返回OK给客户端，这样即使主机后来挂了，也依然可以保证其他从机接受到信息。
像这样的，只要能让其他机器最终是可以取到消息完成更新，就可以的，我们称为是最终一致性。
最终一致性可能会导致在中间过程中，client去其他从机上取到不一致的消息，但能不能避免这个，就是redis做没做相关策略了（肯定做了呀）

主机的高可用

通过上面，我们已经知道多台机器的分布可以解决单台的窘境了，但无论是主从还是主备，似乎都有一个“主的”概念，那万一，主挂了怎么办？
我们想到的，肯定就是给主机要做高可用，这个备用机可以是来自集群内的某一台从机，也可以是集群外的机器，反正能保证主机挂掉之后能不让这个系统圈崩掉就可以。
当主机崩溃后，我们可以让某一台从机变成主机，这个工作由谁完成呢？
人为切换？ 自然可以， 但是，人是不靠谱的。人也是懒惰的，懒惰促使科技的进步，从而诞生了各种代替人的监测技术或者程序。
但但凡是程序，就会存在单点故障的问题，这个监测程序也理应是高可用的，就需要一变多。
啊，又是一个一变多的趋势，好像回到了最初的起点，记忆中你青涩的脸。。。。
慢着，其实是有所不同的。

假设多个监控程序的集群监控着redis的主机的存活状态，那应该几个机器报告主是挂了的，redis才会认呢？

以三个监测集群为例：

此时几个机器汇报redis是不正常的，才会有效呢？
首先看1个的话，行吗，自然不行，因为你怎么保证你自身就是好的呢？ 如果1个就能决定，那么几个机器就会有几个意见，统计不准确，各执己见，会出现网络分区，或者说脑裂的情况。

网络分区

网络分区：外界访问一个分布式系统时，访问其不同的子系统时，可能返回不同的结果。
网络分区并非是时刻都是坏的，看你的系统能不能容忍。例如springcloud中，是有分区容错性的，client从不同的注册中心拉取注册列表时，有可能出现不同列表情况（有的在这个注册成功，有的没有），但只要存在自己可用的那一个服务，这便是可以接受的。 或者是hbase，有的分区挂了，有的区还活着，只要还有活着的，不会说整个系统都挂掉了。

1个不行，那全部监控节点都汇报redis主机不行了呢？ 这肯定是可以的，但这就又是强一致性了，但凡有一个监控机器出现问题，将都使得监控系统不可用。

过半原则

按照惯例，折中方案了解一下：过半就行。
为什么呢？讲究一个势力范围
以上图的3个节点为例，如果有2个节点可以互相通信，便可以建立势力范围，此时如果都说redis主机挂掉了，听起来算是比较可靠的，而那单独1个不管说什么也不管用。

4个呢？ 需要有3个。

5个呢？ 也只需要3个。

所以这样总结来说，就是我们所说的“过半”了。

奇数台机器

还有一个问题，为什么一般人们会选用奇数的机器作为监控呢？

看这两个3节点和4节点
可以看到，其实3节点和4节点达成的效果是一样的，都是1个机器的容错率
这样的话，自然选择机器更少，成本更低。
其次，台数越少，可能产生故障的几率就越小。