上海访问的百度是同一个服务器吗答案肯定是不是的每一个应用可以部署在不同的地方但是我们提供的服务是相同的也就是说我每一个节点上跑的都是相同的业务但是我对用户而言是透明的我要保证我这个服务不出故障高可用现在我全球分布了很多台机器每一台机器上跑的都是百度的业务对用户而言你在北京我就给你分发到离北京最近的一个服务器上在上海就分发到离上海最近的一个服务器上这其中的每一个计算服务器就是集群中的节点

集群的性能不限于单一的服务实体新的服务实体可以动态的加入到集群从而增强了集群的性能

把这些节点服务器发生故障的时候这台服务器上所运行的应用程序可以在另一台服务器上被自动接管消除单点故障增强了数据的可用性可达性可靠性

负载均衡

负载均衡能把这些任务比较均匀的分散到集群环境下的这些服务器上在全球有很多服务器但是我请求的时候把这些请求全部都集中的分发到一个机器上那我搭集群的意义何在呢所以说它还有负载均衡的特性

错误恢复

就是我们集群中的某一台服务器由于故障或者说无法使用了我们要把它的资源对应的这些应用程序要转移到一个可用的节点上这个转移的过程让它继续可用就把它叫做错误恢复

分布式和集群又有什么区别和联系呢

这个集中在一起不是说就部署在一个地方比如说我在北京我在上海无所谓的我布在哪都行但是我们实现的是同一业务这就是集群

比如我们有一个商城业务的网站如果我把其中的每一个服务因为用到微服务开发其中的每一个服务都是可以单独部署单独开发的我把每一个服务分别部署在不同的服务器上这就叫分布式我们每一个服务都有自己的责任和职责不同的服务部署在不同的服务器上一起完成了一个大的功能就是我们对外提供的是一个完整的功能但是我们是要分开独立开发独立部署的其实这个就是分布式再比如我们拿到其中的一个服务比如说授权认证它可以做集群因为一开始它是单一的节点如果你想要它高可用那就来35,

7台所以说分布式的每一个节点都是可以做集群的但集群不一定就是分布式即使不用这种微服务的架构我就用传统的单体应用都写在一个服务里面没有拆分这样的单体应用想让其高可用就来上多个机器这个只能是集群而非分布式

集群主要分为三大类

高可用集群其实指的是以减少服务中断时间为目的的服务器集群技术通过保护用户的业务程序对外不间断的提供服务把因为一些软件、硬件人为造成的故障对业务影响降到最低这就是高可用性集群

LBC负载均衡集群/负载均衡系统

它采用的是将计算任务分配到集群不同的计算节点上提高计算能力主要应用在科学计算领域

我们倾向于

并发量大了通过主从复制解决主从稳定性通过哨兵解决单节点存储能力通过集群Cluster解决

Redis,

单机的问题上此时通过主从复制解决这个问题实现系统的高并发这就是并发量大了主从复制解决主从模式中主节点宕机之后从节点是可以作为主节点顶上来继续提供服务的但是我们需要修改应用方的主节点地址还需要命令所有的从节点去复制新的主节点这一系列的过程都是需要要人工完成比较复杂于是在Redis2.8版本开始引入了哨兵

在主从复制的基础上哨兵实现了自动化故障恢复哨兵模式中单个节点的写能力存储能力还是受到单机的限制的而且动态扩容是相对而言困难复杂于是

Redis3.0

Cluster集群的架构采用的是无中心结构就是我们经常所说的去中心化每个节点都可以保存数据和整个集群的状态而且每个节点都和其他的节连连接这些虚线和其他的节点连接起来了数据保存在主节点中从节点只是主节点的一个复制就是容灾备份使用的集群一般是由多个节点组成官方建议至少六个才能保证组成完整的高可用集群

其中三个是主节点三个是从节点三个主节点会分配插槽它们分配插槽之后每一个key比如说

set

username这个key会经过哈希运算之后会对应到一个插槽的索引上然后插到这个插槽里边比如说M1(0-3000),

M2(3000-6000),

M3(6000-9000)而实际上它的插槽是16384个使用上面假设的例子set

username

M2你的一个key的运算会对应到一个索引的插槽上所如说三个主节点会分配槽来存储数据处理客户端的命令请求而从节点是主节点的一个复制就是在主节点故障之后顶替主节点的一个作用

9个节点(3主6从)总结一下

主从模式其实就是为了保证数据高可用性而存在的而集群其实准确的讲它没有上图的右边Slave节点M1~M3

才是集群分片但是我们要保证它的高可用性就需要主从容灾备份Redis

Cluster

为了保证数据的高可用性加入了主从模式一个主节点对应一个或多个从节点主节点提供数据的存取从节点复制主节点数据备份当这个主节点挂掉后就会通过主节点的从节点选取一个来充当新的主节点保证集群的高可用在上图例子中有3个主节点若其中一个挂掉了如果它还没有从节点那整个环境就没法用了因为每个主节点都提供这个中间槽的功能比如上面的

username对应主节点挂掉了怎么去获取这个槽对应的值所以说我们在创建集群的时候一定要为每个主节点都添加对应的从节点

是数据是按照槽存储分配在多个节点上的节点间的数据共享节点可以动态的添加或删除可以动态的调整

部分节点不能用的时候集群仍然是可用的因为我们可以通过增加slave从节点做备份来充当数据的副本

自动故障转移

然后它出了故障之后从节点可以顶上来就是自动故障转移节点之间通过留言协议交换状态信息再采用投票机制完成

任何事物都是一把双刃剑数据通过异步复制没有办法保证数据强一致性但保证最终一致性集群环境的搭建复杂

在之前的版本要用ruby脚本去创建集群目前最新的模式去创建集群就简单了很多

数据分区

集群模式是把数据分别存储在多个节点上的因为随着请求量和数据量的增加一台机器满足不了我们的需求了主从模式主节点仍然有写的压力问题和存储压力的问题所以我们需要把数据和请求分散到多台机器这时候需要引入分布式存储那分布式存储有哪些特性

如果数据库的某个节点出现了故障。

在其他节点的数据仍然是可用的增强了可用性不会说一个节点出了问题可能就是其他节点全部都用不了只是说当前这个节点数据可能暂时性的不可用了其他节点的数据仍然可用

维护方便

分布式存储首先要解决的就是数据集是如何按照什么样的分区规则映射到多个节点上的

常见数据分区算法

范围分区在关系型数据库用的比较多它指的就是把数据基于范围映射到每一个分区这个范围是你自己在创建分区时候指定的这个分区键决定的分区键也经常会采用以日期的方式来做分区它的优点就是同一范围内的范围查询不需要跨节点提升了查询速度应用场景就是

mysql

是取余N是节点数就是对一个key取余比如说现在我们有三台机器那么对这个key做一个哈希处理运算然后对3取于取余的余数是多少我们就放到一二三对应的那个节点上去优点是实现起来非常简单

你有几个节点哈希运算完就对这个节点取余就行了。

然后把这个值就分配到这个节点上去了

如果扩容/收缩节点的时候你做的这个数据迁移量会很大大概得有百分之七八十这样子,

这个key,

余数是1我这里有三个节点它就放到1那个节点上去了现在我增加了一个节点现在4个节点了刚才10对3取余余数是1现在你增加一个节点之后就相当于分配这个key那

再对4

这个key就要从第一个节点上转移到第二个节点上类似这种需要做的这个数据迁移量会非常的大建议就是翻倍扩容相对减少迁移量但仍旧很大基本上在百分之四五十的迁移量这种算法现在用的比较少了它的出现就是因为一致性哈希、虚拟槽这种概念还没有提出来就像我们的

Redis

区间这些token会构成一个哈希环数据读写执行节点查询操作的时候就是先根据key的计算计算到一个哈希值然后顺时针找到第一个大于等于该哈希的token节点优点

这种方式相比我们刚才节点取余最大的好处就是在加入和删除节点的时候它只会影响相邻的节点

你使用少量节点的时候节点的变化还是大范围的影响所以说它是不适合少量数据节点的分布式方案它更多的是那种规模比较大的这种数据节点的一种分布式的缓存方案

Memcached

虚拟槽分区你可以理解为就是在一致性哈希分区的基础上加入了虚拟槽的概念它把这个分割的力度变得更小了让每一个节点持有固定的槽当你去添加一个节点的时候它不会对这里边的每一个重新去分配你只需要给它的分配指定的槽这里边的这些槽我们可以选择自动的分配或者说手动的去分配你可以自己去进行分配管理影响可以说是非常非常的小这就是Redis

Cluster

取余以后这里就会有我们的槽的范围这里大概有5个节点如上图我对这个key,

比如说username做完处理之后它映射到这个区间了比如节点2上面是节点2的一个详细图我现在新增一个节点我新增一个节点之后可以把原先一个节点的部分范围取出来重新分配给另一个节点它的影响极小这是关于虚拟槽分区的一个方式它也是

Redis

我们的每一个节点都要去存储nodes和槽对应的信息因为我们知道客户端来访问的时候肯定是不是说指定访问到某一个节点上假如说,

key