分布式集群架构场景化解决方案

分布式和集群

• 分布式和集群是不一样的, 分布式一定是集群, 集群不一定是分布式

• • 分布式 : 把一个系统拆分为多个子系统, 每个子系统负责各自的那部分功能, 独立部署, 各司其职
  • 集群 : 多个实例共同工作, 最简单/最常见的集群是把一个应用复制多份部署

一致性的Hash算法

Hash算法的应用

• Hash算法一般应用在数据存储和查找领域, 最经典的就是Hash表, 它的查询效率非常之高, 其中的哈希算法如果设计的比较OK, 那么它的时间复杂度可以接近于O(1); 其次在安全加密领域MD5、SHA等加密算法中也有体现

• 算法上的体现 : 直接寻址法、取模算法以及拉链法

Hash算法应用场景

• Hash算法在很多分布式集群产品中都用应用, 比如 Redis、hadoop、ElasticSearch、Mysql分库分表、Nginx负载均衡等

• 主要的应用场景

• • 请求的负载均衡(Nginx的IP_Hash策略) : Nginx的IP_hash策略可以在客户端ip不变的情况下，将其发出的请求始终路由到同一个目标服务器上，实现会话粘滞，避免处理session共享问题
  • 分布式存储 : 那么,在进行数据存储时,<key1,value1>数据存储到哪个服务器当中呢?针对key进行hash处理 hash(key1)%3=index, 使用余数index锁定存储的具体服务器节点

• 普通的Hash算法存在的问题

• • 当其负载均衡服务器与分布式存储服务器, 出现宕机现象时回存在客户端需重新计算hash值去指向目标服务器. 同时使其扩容性很差, 影响范围较广.

• 一致性Hash算法

• • 首先有一条直线，直线开头和结尾分别定为为1和2的32次方减1，这相当于一个地址，对于这样一条线，弯过来构成一个圆环形成闭环，这样的一个圆环称为hash环. 由于客户端的请求后都是采用的就近原则, 所以服务器的扩容性影响范围小.
  • 通过增加虚拟节点, 减少数据倾斜现象

集群时钟同步问题

• 时钟不同步导致的问题 : 比如我们的订单子系统是集群化部署，或者我们的数据库也是分库分表的集群化部署， 然而他们的系统时钟缺不一致，比如有一台服务器的时间是昨天，那么这个时候下单时间就成了昨天， 那我们的数据将会混乱

• 集群时钟同步配置

• • 分布式集群中各个服务器节点都可以连接互联网 : 可以通过npt/ nptdate
  • 分布式集群中各个服务器节点部分不连互联网 : 可以设定某一台服务器为时间同步服务器.
  • 其次通过服务器的定时功能, 按照一定的规律实现时间校验

分布式ID解决方案

• UUID 是指Universally Unique Identifier，翻译为中文是通用唯一识别码, 产生重复 UUID 并造成错误的情况非常低，是故大可不必考虑此问题。

• 独立数据库的自增ID :

• • 这里的createtime字段无实际意义，是为了随便插入一条数据以至于能够自增id。
  • 使用独立的Mysql实例生成分布式id，虽然可行，但是性能和可靠性都不够好，因为你需要代 码连接到数据库才能获取到id，性能无法保障，另外mysql数据库实例挂掉了，那么就无法获取分 布式id了。
  • 有一些开发者又针对上述的情况将用于生成分布式id的mysql数据库设计成了一个集群架构， 那么其实这种方式现在基本不用，因为过于麻烦了。

• SnowFlake 雪花算法

• 借助Redis的Incr命令获取全局唯一ID

分布式调度问题

• 定时任务的场景

• • 订单审核、出库
  • 订单超时自动取消、支付退款
  • 礼券同步、生成、发放作业
  • 物流信息推送、抓取作业、退换货处理作业
  • 数据积压监控、日志监控、服务可用性探测作业
  • 定时备份数据
  • 金融系统每天的定时结算
  • 数据归档、清理作业
  • 报表、离线数据分析作业

• 什么是分布式调度

• • 运行在分布式集群环境下的调度任务(同一个定时任务程序部署多份, 只应该有一个定时任务在执行)
  • 分布式调度->定时任务的分布式->定时任务的拆分(即为把一个大的作业任务拆分为多个小的作业任务, 同时执行)

• 定时任务与消息队列的区别

• • 共同点

  • • 异步处理 : 注册与下单事件
    • 应用解耦
    • 流量削峰

  • 本质不同

  • • 定时任务作业是时间驱动, 而MQ是事件驱动
    • 时间驱动是不可代替的, 所以定时任务倾向于批处理, MQ倾向于逐条处理

分布式调度框架Elastic-Job

• Elastic-Job 介绍

    当当网开源的一个分布式调度解决方案, 基于Quartz二次开发的, 由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成. Elastic-Job-Lite, 它定位为轻量级无中心化解决方案, 使用Jar包的形式提供分布式任务的协调服务, 而Elastic-Job-Cloud子项目需要结合Mesos以及Docker在云环境下使用

• 主要功能

• • 分布式调度协调
  • 丰富的调度策略
  • 弹性扩容缩容
  • 失效转移
  • 错过执行作业重触发
  • 支持并行调度
  • 作业分片一致性

• 特点 : 去中心化及其轻量级

• 任务分片 : 一个大的非常耗时的作业Job , 可以把作业分为多个Task, 每一个Task交给具体的一个机器实例去处理, 但是具体每个Task执行什么逻辑由我们自己来制定

Session一致性的解决方案

• Nginx的IP_Hash策略

  同一个客户端IP的请求都会被路由到同一个目标服务器, 也叫做会话粘滞

• • 优点

  • • 配置简单、不入侵应用, 不需要额外修改代码

  • 缺点

  • • 服务器重启session消失
    • 存在单点负载高的风险
    • 单点故障问题

• Session复制

  多个Tomcat之间通过修改配置文件, 达到Session之间的复制

• • 优点

  • • 不入侵应用
    • 便于服务器水平扩展
    • 能适应各种负载均衡
    • 服务器重启或者宕机不会造成Session丢失

  • 缺点

  • • 性能低
    • 内存消耗大
    • 不能存储太多数据, 否则数据越多越影响性能
    • 延迟性

• Session共享, Session集中存储

  使用消息中间件存储Session信息

• • 优点

  • • 能适应各种负载均衡策略
    • 服务器重启或宕机不会造成Session丢失
    • 扩展能力强
    • 适合大集群使用

  • 缺点

  • • 对应用入侵, 引入了和Redis的交互代码