分布式和集群
-
分布式和集群是不一样的, 分布式一定是集群, 集群不一定是分布式
- 分布式 : 把一个系统拆分为多个子系统, 每个子系统负责各自的那部分功能, 独立部署, 各司其职
- 集群 : 多个实例共同工作, 最简单/最常见的集群是把一个应用复制多份部署
一致性的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的交互代码
-
网友评论