高可用集群技术及补充相关

Bloom Filter

用途:一个元素是否在一个集合中

常规数据结构

  • 数组:增删

  • 链表(局部升级:跳表):随机访问,顺序,查找

  • 哈希表:哈希冲突,利用率低

  • Map(基于红黑树):数据结构复杂

  • 树(B/B+树,平衡二叉树,Trie)

    常规的数据结构组合似乎可以解决大部分查找问题。首先核心需求是判断存在,如果只有查找需求,则不一定需要存储(或者说不需要直接接触数据集合层)

基础概念

  • 一个很长的二进制位数组

  • 一系列哈希函数

  • 空间效率和查询效率高

  • 查询结果为正时有一定的误判率

原理

  • 初始化位数组所有位全为0,集合中每个元素分别经过k个哈希函数计算,得到所有数组编号位的值都置1。

  • 查找时,查找对象经过k个哈希函数计算得到编号,只要有一个编号位置值为0,说明对象一定不在集合中

  • 错判:例如k=3,对象A编号为1/2/3,对象B为3/4/5,查找对象编号为3/4/5的情况

延伸思考

  • 减少了单一表现不良的哈希函数带来的伤害(单纯的哈希在函数结果相同时会退化成顺序搜索

  • 选取的哈希函数之间结果域应当尽量分散,即增加判断点


隧道协议

  • 隧道:源主机和目标主机所在网络类型相同,但是中间却隔着类型不同的网络
  • 利用隧道优势的VPN就是一个提供简单安全措施的简单覆盖(overlay)网络
graph LR
A(源主机) --> |IPV6|B
B --> |IPV4|C
C --> |IPV6|D(目标主机)
  • 隧道协议将其他协议的数据帧或包重新封装然后通过隧道发送。新的帧头提供路由信息,以便通过网络传递被封装的负载数据

IP隧道技术

  • 用IP协议包裹IP协议

  • original

graph TD
A(IP header)
B(IP payload)
  • pack
graph TD
C(Outter IP header)
D(Tunnel header)
E(Inner IP header)
F(IP payload)
  • TLS封装被移除
  • 原始数据报文被隐藏了,常用于绕过简单的防火墙

负载均衡

负载均衡算法

  • (Weighted)Round-Robin:(加权)轮询负载均衡,服务请求会依次被转发到服务器池中的每一个服务器上,不评估当前负载配置能力,加权则参考服务器权重
  • (Weighted)Least-Connection:(加权)最少连接,转发服务到连接次数较少的服务器上
  • Destination Hash Scheduling:目标地址哈希算法,在静态哈希表中查询目标地址来确定请求要转发的
  • Source Hash Scheduling:源地址哈希算法,在静态哈希表中查询源地址来确定请求要转发的
  • Shortest Expected Delay:最小延迟算法

在OpenStack高可用集群部署的示范

  • 基于LVS实现的高伸缩,高可用服务:web,cache,dns,ftp,mail等

  • 负载均衡实现方式

    • 基于DNS域名轮流解析方案
    • 基于客户端调度访问方案
    • 基于应用层系统负载的调度方案
    • 基于IP地址的调度方案(执行效率最高:IP负载均衡技术)
  • HAProxy

    • 实现基于TCP和HTTP协议的服务高可用
    • 适合应用于需要会话保持或七层处理的高负载Web站点
    • 事件驱动、单一进程的架构模型
  • KeepAlived

    • 主要目标:简化LVS项目配置,增强稳定性

    • 功能来源:IPVS(IP Virtual Server)

    • Linux Virtual Server

      • 为集群服务提供软件负载均衡
      • IP负载均衡技术
      • 虚拟服务器的主要任务是监听VIP及相应端口上的请求
    • 负载均衡和基于虚拟路由冗余协议实现故障切换转移(Failover)

    • 多数功能模块都位于用户空间

    • 一个与LVS Router有关的控制进程

      • Active/Master
      • Passive/Master
    • 架构

graph TB
AR(Active Record)
BR(Backup Record)
A(Internet) --> AR
AR --> A
AR --> RealServer
RealServer --> AR
  • IPVS实现负载均衡
    • 本质:解决单IP,多服务器问题
    • 数据路由转发方式实现
      • NAT:网络地址转换,调度器处理能力成为性能瓶颈
      • TUN:IP隧道技术
      • DR(Direct Routing)技术:改写请求报文的MAC地址,没有隧道开销,没有转发压力,综合性能最高
    • 核心技术
graph LR
A(Direct Server) --> | 用户请求转发 |B(Real Server节点)
B --> | 数据返回 |A
  • VRRP
    • 目的:解决局域网中配置静态网关出现单点失效现象的路由协议
    • 本质:主备,多组主备路由虚拟为一个路由,屏蔽切换细节
    • 所有运行在LVS Router下

OpenStack消息队列技术

高级消息队列协议

  • AMPQ(Advanced Message Protocol Queue)
  • OpenStack是由多个开源组件构成的云计算项目,各组件间通过REST接口通信和调用,而组件间的REST接口调用是建立在AMQP上的RPC通信
  • 一种应用层二进制协议开放标准

三层划分

  • 像OSI分层一样,任意一层可独立替换实现不影响与其他层的交互
  • Model:决定了基本域模型,行为被称为Command
  • Session:为模型层的Command提供可靠的传输保障(Peer到Peer)
  • Transport:二进制流传输保障

结构与概念

  • AMQP Broker:服务器端域模型
  • Virtual-Host:虚拟主机,由一组交换机、绑定和队列构成

具体实现RabbitMQ

相关结构

  • Connection/Channel:同一客户端可有多个Channel(多个连接)
  • Queue:一个队列可以有多个Binding,多个队列可以有同一个Binding
  • Message/Acknowledgement:Message由Payload和Label组成
  • Exchange
  • RoutingKey(随消息)/BindingKey(Exchange中):在绑定多个Queue到同一个Exchange的时候,这些Binding操作允许使用相同的BindingKey。并非所有Binding操作都需要使用BindingKey
graph LR
A(Exchange) --> |Binding|B(Queue)
  • ExchangeType
    • Fanout:生产者与队列一对多的关系,发送到Exchange的所有绑定中
    • Direct:完全匹配RoutingKey的指定BindingKey中,一对一
    • Topic:RoutingKey与BindingKey匹配,规则更灵活,两者都多字段(如:A.Rabbit.Dog),模糊匹配(单个*或N个#)
    • Headers:与两种Key无关,提取消息Headers值(键值对),与Exchange绑定Queue时预设的对比,一致则发过去,少用

关键操作

  • Message Durability
  • Prefetch Count
  • ReplyTo/CorrelationId:消息由生产者设置,消费者消费完后根据值返回给生产者端,由生产者确认是否成功消费
  • RabbitMQ Sever = Broker Server
  • 功能结构构成
    • 发送消息:Producer、Exchange
    • Broker Server:Exchange、Queue
    • 接受消息:Queue、Consumer Client
graph LR
a(生产者) --> |ReplyTo<br>CorrelationId| b(Queue)
b --> c(消费者)
c --> |ReplyTo<br>CorrelationId| a

集群

  • RabbitMQ集群中,RabbitMQ Broker运行所需的元数据状态信息会自动在集群节点间复制,即节点都有集群的元数据
  • 消息队列Queues不会在多个节点之间复制(需要镜像复制涉及HeightAvailable功能),即集群Queues通常只位于集群中的某一个节点上
    • 单点故障 --> 队列镜像模式(Master-Slave,Master提供服务) --> 没有将集群负载均衡 --> Policy动态镜像队列转换(可以部分队列镜像而不用全镜像)
  • 集群节点:磁盘(Disk/Disc)节点、内存(RAM)节点
    • 多数情况下默认是磁盘节点
    • 内存节点主要用于具有深度队列和大量Exchanges的集群以提高消息传递性能

Written with StackEdit.