【可用性】Redis作为注册中心配合Spring Task的高可用案例

需求:

        假设当前有一个短信服务是多节点集群部署,我们希望每个服务节点在启动时能将服务信息"注册"到redis缓存中,所有服务节点每隔3分钟上报一次,表示当前服务可用。每个服务还会作为哨兵节点每隔10分钟查询一次redis,将没有即时上报的服务节点从redis中剔除。

步骤:

        (1)创建一个Springboot工程,由于要使用到Spring Task定时任务,所以在启动类上标注@EnableScheduling注解

@SpringBootApplication
@EnableScheduling//s开启定时功能
public class SmsApplication {
    public static void main(String[] args) {
        SpringApplication.run(SmsApplication.class,args);
    }
}

        (2)定义一个ServerRegister类,实现服务注册、服务上报、服务检查等逻辑

@Component
public class ServerRegister implements CommandLineRunner {
    
    //服务的唯一标识
    public static String SERVER_ID = null;

    @Resource
    private RedisTemplate redisTemplate;

    /**
     * 项目启动时自动执行该方法
     * @param args
     * @throws Exception
     */
    @Override
    public void run(String... args) throws Exception {
        //服务注册方法
        registrationService();
    }
}

        代码解读

        1、ServerRegister需要标注@Component注解配置成bean,装载到Spring容器中。

        2、ServerRegister需要实现CommandLineRunner接口,重写run方法,在项目启动时会自动执行run方法中的逻辑,我们可以在run方法中实现服务注册功能。

        (3)服务注册逻辑

private void registrationService(){
        //通过UUID随机生成服务节点的唯一标识
        SERVER_ID = UUID.randomUUID().toString();
        System.out.println("当前服务实例唯一标识:" + SERVER_ID);
        
        //将服务节点信息以Hash结构存储        
redisTemplate.opsForHash().put(RedisConstants.REGISTRY_CENTER,SERVER_ID,System.currentTimeMillis());
    }

        SERVER_ID服务节点唯一标识,通过UUID随机生成一段字符串作为节点的唯一标识。

        Hash结构图解

【可用性】Redis作为注册中心配合Spring Task的高可用案例_第1张图片

        (4)服务上报逻辑

/**
     * 定时服务上报
     * 每隔三分钟定时上报
     * 上报的逻辑:修改value为当前时间戳
     */
    @Scheduled(initialDelay = 10000,fixedRate = 180000)
    public void keepAlive(){
        System.out.println("定时上报,上报服务唯一标识:" + SERVER_ID);
        redisTemplate.opsForHash().put(RedisConstants.REGISTRY_CENTER,SERVER_ID,System.currentTimeMillis());
    }

        上报逻辑其实就是修改了一下服务节点对应的value时间戳,如果服务挂了那么服务肯定无法执行该逻辑,以此来判断服务是否仍然可用。

        initialDelay属性表示从项目启动后延迟多久开始执行定时任务。

        fixedRate属性表示每次任务执行的时间间隔。

        两个属性都是以ms为单位。

        (5)服务检查逻辑

/**
     * 定时服务检查
     * 每隔十分钟定时检查
     * 检查逻辑:每隔服务的最后一次上报时间与当前时间的差值 > 5分钟则将服务实例从redis中剔除
     */
    @Scheduled(initialDelay = 10000,fixedRate = 600000)
    public void checkServer(){
        System.out.print("进行服务实例的检查,执行当前任务的服务为:" + SERVER_ID);

        String center_key = RedisConstants.REGISTRY_CENTER,SERVER_ID;
        //获得Redis中注册的所有服务实例id
        Map map = redisTemplate.opsForHash().entries(center_key );

        //获取当前系统时间戳
        long current = System.currentTimeMillis();

        //保存没有及时上报的服务节点唯一标识
        List removeKeys = new ArrayList();
        map.forEach((key,value) -> {//key为服务实例id,value为上报的系统时间戳
            long parseLong = Long.parseLong(value.toString());
            if(current - parseLong > (1000 * 60 * 5)){
                //当前服务实例超过5分钟没有上报
                removeKeys.add(key);
            }
        });

        //清理服务实例
        removeKeys.forEach(key ->{
            System.out.print("清理服务实例:"+key);
            redisTemplate.opsForHash().delete(RedisConstants.REGISTRY_CENTER,key);
        });
    }

       检查逻辑其实就是将一些没有及时修改value(时间戳)的服务节点从hash结构中删除,因为服务如果是正常状态,那么它肯定能及时更新value,没有及时更新说明服务已经不可用了,需要从redis中剔除。

        为什么是5五分钟检查以此而不是3分钟检查一次?

        有时候可能会因为网络问题导致服务节点上报不及时,而不是因为服务节点真的挂了,此时我们不应该将服务节点从redis中剔除,多预留的2分钟就是为了避免这种情况发生。

        (6)RedisConstants常量类

public class RedisConstants {

    public static String REGISTRY_CENTER = "Service_REGISTRY_Collection";
}

测试:

        (1)启动redis-server

【可用性】Redis作为注册中心配合Spring Task的高可用案例_第2张图片

        (2)运行启动类的run方法启动项目

【可用性】Redis作为注册中心配合Spring Task的高可用案例_第3张图片

        (3)测试结果

        Redis gui工具:

【可用性】Redis作为注册中心配合Spring Task的高可用案例_第4张图片

总结:

        1、每个服务在启动时都会通过UUID生成随机字符串作为自己的唯一标识,随后基于Hash结构将每个服务的唯一标识和时间戳存储在redis中。

        2、服务上报(保活)实际上就是不断修改value时间戳,以此来表示服务仍可用。

        3、服务检查会对所有保存在Hash结构中的服务节点进行检查,判断上报时间是否在规定范围内,没有及时上报的服务节点会从Hash结构中剔除。

        4、方案缺陷是每个服务间的系统时钟不能偏差太多,否则会存在误判,将一些正常服务从redis中剔除。

你可能感兴趣的:(spring,redis,java)