需求：

        假设当前有一个短信服务是多节点集群部署，我们希望每个服务节点在启动时能将服务信息"注册"到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;@Resourceprivate RedisTemplate redisTemplate;/*** 项目启动时自动执行该方法* @param args* @throws Exception*/@Overridepublic 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结构图解：

        （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中注册的所有服务实例idMap 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：

        （2）运行启动类的run方法启动项目：

        （3）测试结果：

        Redis gui工具：

总结：

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

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

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

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