标签:自动 nginx负载均衡 构造函数 部门 注意 存储 需要 ini 分布式锁
最近工作中遇到一个问题,我们会调用业务部门提供的HTTP接口获取所有的音视频任务信息,这些任务会被分发到各个机器节点进行处理。有两个方案:
为每台机器编号,比如有5台机器,编号为0,1,2,3,4,然后每台机器读取全量任务信息,将每个任务ID用机器总数量取余,然后和机器编号比较,相等的表示这个任务在此机器上执行。
我们使用其中一台机器将任务投递到Kafka中,然后所有机器消费这些任务。
但是需要做到以下2点:
第一个问题是本文的重点,我们采用了Redis的分布式锁,下面要详细介绍。关于Kafka任务均匀投递的问题,需要自己实现调度模块,根据机器性能来投递到不同机器消费的partition中。
方案二解决了方案一的所有缺点,下面详细说一下分布式锁,做一个记录。
主备是高可用集群中绕不开的问题,服务端一般使用nginx反向代理做一次负载均衡,但是如果nginx挂了呢,这就需要做主备(或者主主也可以),网上这个帖子很详细Nginx负载均衡高可用(keepalived+nginx实现主备)。但是我们遇到的问题优点特殊,我们做的是客户端的负载均衡,每次主动调用任务接口获取任务数据来进行处理。并且只能做主备,不能主主,不然会造成任务的重复投递。
第一次在工作中接触到redis,发现redis真是个好东西。分布式锁原理
我们的主备方案中,使用分布式锁来实现一个类似单例模式的逻辑。
下面是流程图:
注意:一个Redis集群(只有一个Master)有可能出现一个锁被不同服务获取的情况(Master宕机,锁状态还没有来得及同步到Slave就会出现),这样会在不同的机器上启动投递任务,上面的流程中在下一个5秒后会判断,投递任务IP是否为本机IP,只保留本机的服务,其他服务全部停止。
标签:自动 nginx负载均衡 构造函数 部门 注意 存储 需要 ini 分布式锁
原文地址:https://www.cnblogs.com/harlanc/p/12995651.html