spring分布式缓存
1. java目前比较常用的缓存有哪些 集中式缓存与分布式缓存有何区别 它们应用场景是
java目前常用的缓存：
Generic
JCache (JSR-107) (EhCache 3, Hazelcast, Infinispan, etc)
EhCache 2.x
Hazelcast
Infinispan
Couchbase
Redis
Caffeine
Guava (deprecated)
Simple
建议使用spring boot集成方式，可插拔，简单。
集中式缓存适用场景：
1、服务器集群部署。
2、数据高一致性（任何数据变化都能及时的被查询到）
分布式缓存适用场景：
系统需要缓存的数据量大
对数据的可用性较高的情况
需要横向扩展，从而达到缓存的容量无限的要求
2. Eclipse项目里没有j2ee library这么办
eclipse是客户端开发工具，本来就不带有j2ee的jar包，需要容器：比如tomcat来提供这个jar的。
j2EE通用jar包列表：
IKIKAnalyzer3.2.8.jar // 分词器
ant-junit4.jar // ant junit
antlr-2.7.6.jar // 没有此包，hibernate不会执行hql语句。并且会报NoClassDefFoundError: antlr/ANTLRException错误
aopalliance-1.0.jar // 这个包是AOP联盟的API包，里面包含了针对面向切面的接口。通常Spring等其它具备动态织入功能的框架依赖此包。
asm-3.2.jar // spring3用到的asm 生成二进制代理类
asm-analysis-3.2.jar // ASM是一个通用的Java字节码操作和分析框架。它可以用来修改现有的类或动态生成的类，直接以二进制的形式。提供常见的转换和分析算法允许轻松地组装定制的复杂转换和代码分析工具。
asm-commons-3.2.jar //
asm-commons-3.3.jar //
asm-tree-3.2.jar //
asm-tree-3.3.jar //
asm-util-3.2.jar //
aspectjrt.jar // 面向切面编程 Spring
aspectjweaver.jar // 面向切面编程 Spring
backport-util-concurrent.jar // 并发访问处理端口的工具包
bootstrapconnector.jar // 操作openoffice
c3p0-0.9.1.jar // C3P0是一个开放源代码的JDBC连接池，它在lib目录中与Hibernate一起发布,包括了实现jdbc3和jdbc2扩展规范说明的Connection 和Statement 池的DataSources 对象。
cas-client-core-3.2.1.jar // 单点登录客户端
cglib-nodep-2.1_3.jar // cglib代理 实现AOP的一种方式；和他对应的是DynaProxy(java动态代理)
cglib-nodep-2.2.jar //
cobertura.jar // 跑cobertura测试的包
commons-beanutils-1.7.0.jar // 提供对 Java 反射和自省API的包装
commons-codec-1.4.jar // Commons项目中用来处理常用的编码方法的工具类包。编码或者是解码
commons-collections-3.1.jar // 提供一个类包来扩展和增加标准的 Java Collection框架
commons-collections-3.2.jar //
commons-dbcp-1.4.jar // 储存java数据库连接对象的池子
commons-dbcp.jar //
commons-email-1.2.jar // Java发邮件的包
commons-fileupload-1.2.1.jar // Java上传文件用到的包
commons-fileupload-1.2.2.jar //
commons-io-1.3.2.jar // Java实现IO所需要的包
commons-io-2.0.1.jar //
commons-lang-2.3.jar // 提供了许多许多通用的工具类集，提供了一些java.lang中类的扩展功能
commons-lang-2.4.jar //
commons-lang3-3.1.jar //
commons-logging-1.1.1.jar // 一个各种 logging API实现的包裹类
commons-logging-api-1.1.jar // 是一个 LOGGING 的一个简化版,只实现了SimpleLog 及类似的其它部分，只能基本满足系统启动时的日志输出，因为没有日志系统的API ，Tomcat 是不能启动的
commons-pool-1.3.jar // 对象池
commons-pool.jar //
dom4j-1.6.1.jar // Java的XML API，类似于jdom，用来读写XML文件的
easymock-3.1.jar // Junit Test用，Mock对象
ehcache-core-2.4.4.jar // 高可用的缓存系统,纯Java实现,支持本地缓存、分布式缓存和缓存查询,是hibernate默认的二级缓存。
ezmorph-1.0.3.jar // 简单的java类库用于将一种对象转换成另外一种对象
fluent-hc-4.2.1.jar // HttpClient
freemarker-2.3.15.jar // 用Java语言编写的模板引擎，它基于模板来生成文本输出。FreeMarker与Web容器无关，即在Web运行时，它并不知道Servlet或HTTP。它不仅可以用作表现层的实现技术，而且还可以用于生成XML，JSP或Java 等。
freemarker-2.3.19.jar //
geronimo-jms_1.1_spec-1.0.1.jar // Apache Geronimo所带jar包。 Apache服务器用。
geronimo-jpa_3.0_spec-1.0.jar // Apache Geronimo所带jar包
groovy-1.8.6.jar // 是Java平台上设计的面向对象编程语言，可以作为Java 平台的脚本语言使用。
gson-2.2.2.jar // 用来序列化json格式的数据
hamcrest-all-1.1.jar // 辅助测试工具 assertThat
hibernate-annotations.jar // Hibernate 注解
hibernate-commons-annotations-3.2.0.Final.jar //
hibernate-commons-annotations.jar //
hibernate-core-3.6.0.Final.jar // Hibernate核心包
hibernate-jpa-2.0-api-1.0.0.Final.jar // Hibernate 持久化
hibernate-search-3.3.0.Final.jar // Hibernate search
hibernate3.jar // 核心包
httpclient-4.2.1.jar //
httpcore-4.2.1.jar //
iaphelper-v1.5.jar //
jackson-all-1.8.0.jar // 解析json格式数据
jackson-all-1.8.2.jar //
jakarta-oro-2.0.8.jar // 正则表达式
java_uno.jar // openoffice
javassist-3.11.0.GA.jar // 分析、编辑和创建Java字节码的类库
javassist-3.9.0.GA.jar //
jaxen-1.1.1.jar // 开源的XPath库
jcommon-1.0.17.jar // Used for jFreeChart
jfreechart-1.0.14.jar // jfreechart
json-lib-2.1.jar // 解析json
json.jar //
jta-1.1.jar // Java Transaction API
juh.jar // 和jurt.jar unoil 转换pdf文档
junit-4.10.jar // junit
junit-4.8.2.jar //
jurt.jar //
jxl.jar // 操作excel
livetribe-jsr223-2.0.6.jar // jsr223是把其它脚本语言嵌入JAVA的一个规范，这个JAR包是对这个规范的实现
log4j-1.2.14.jar // 日志
log4j-1.2.15.jar //
lucene-core-3.0.3.jar // lucene核心包
mail-1.4.1.jar // 邮件
mybatis-3.1.1.jar // mybatis持久化框架
mysql-connector-java-3.1.12-bin.jar // mysql连接
mysql-connector-java-5.0.4-bin.jar //
ognl-2.7.3.jar // Object-Graph Navigation Language， struts用
ognl-3.0.5.jar //
openjpa-1.2.2.jar // open jpa
org.springframework.aop-3.1.1.RELEASE.jar // Spring
org.springframework.asm-3.1.1.RELEASE.jar //
org.springframework.aspects-3.1.1.RELEASE.jar //
org.springframework.beans-3.1.1.RELEASE.jar //
org.springframework.context-3.1.1.RELEASE.jar //
org.springframework.context.support-3.1.1.RELEASE.jar //
org.springframework.core-3.1.1.RELEASE.jar //
org.springframework.expression-3.1.1.RELEASE.jar //
org.springframework.instrument-3.1.1.RELEASE.jar //
org.springframework.instrument.tomcat-3.1.1.RELEASE.jar //
org.springframework.jdbc-3.1.1.RELEASE.jar //
org.springframework.jms-3.1.1.RELEASE.jar //
org.springframework.orm-3.1.1.RELEASE.jar //
org.springframework.oxm-3.1.1.RELEASE.jar //
org.springframework.test-3.0.1.RELEASE-A.jar //
org.springframework.transaction-3.1.1.RELEASE.jar //
org.springframework.web-3.1.1.RELEASE.jar //
org.springframework.web.portlet-3.1.1.RELEASE.jar //
org.springframework.web.servlet-3.1.1.RELEASE.jar //
org.springframework.web.struts-3.1.1.RELEASE.jar //
persistence-api-1.0.jar // Java持久化
pmd-4.3.jar // 开源分析Java代码错误的工具
quartz-all-1.6.0.jar // Spring quartz定时器
ridl.jar // open office
serp-1.13.1.jar // open jpa
slf4j-api-1.5.8.jar // hibernate
slf4j-log4j12-1.5.6.jar //
sonar-ant-task-1.4.jar //
spring-aop-3.1.2.RELEASE.jar // spring
spring-asm-3.1.2.RELEASE.jar //
spring-beans-3.1.2.RELEASE.jar //
spring-context-3.1.2.RELEASE.jar //
spring-core-3.1.2.RELEASE.jar //
spring-expression-3.1.2.RELEASE.jar //
spring-jdbc-3.1.2.RELEASE.jar //
spring-orm-3.1.2.RELEASE.jar //
spring-test-2.5.6.jar //
spring-test-3.1.2.RELEASE.jar //
3. 常用的缓存技术
第一章 常用的缓存技术
1、常见的两种缓存
本地缓存：不需要序列化，速度快，缓存的数量与大小受限于本机内存
分布式缓存：需要序列化，速度相较于本地缓存较慢，但是理论上缓存的数量与大小无限（因为缓存机器可以不断扩展）
2、本地缓存
Google guava cache：当下最好用的本地缓存
Ehcache：spring默认集成的一个缓存，以spring cache的底层缓存实现类形式去操作缓存的话，非常方便，但是欠缺灵活，如果想要灵活使用，还是要单独使用Ehcache
Oscache：最经典简单的页面缓存
3、分布式缓存
memcached：分布式缓存的标配
Redis：新一代的分布式缓存，有替代memcached的趋势
3.1、memcached
经典的一致性hash算法
基于slab的内存模型有效防止内存碎片的产生（但同时也需要估计好启动参数，否则会浪费很多的内存）
集群中机器之间互不通信（相较于Jboss cache等集群中机器之间的相互通信的缓存，速度更快<--因为少了同步更新缓存的开销，且更适合于大型分布式系统中使用）
使用方便（这一点是相较于Redis在构建客户端的时候而言的，尽管redis的使用也不困难）
很专一（专做缓存，这一点也是相较于Redis而言的）
3.2、Redis
可以存储复杂的数据结构（5种）
strings-->即简单的key-value，就是memcached可以存储的唯一的一种形式，接下来的四种是memcached不能直接存储的四种格式（当然理论上可以先将下面的一些数据结构中的东西封装成对象，然后存入memcached，但是不推荐将大对象存入memcached，因为memcached的单一value的最大存储为1M，可能即使采用了压缩算法也不够，即使够，可能存取的效率也不高，而redis的value最大为1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事实上底层是一个hashTable
sorted sets-->底层是一个skipList
有两种方式可以对缓存数据进行持久化
RDB
AOF
事件调度
发布订阅等
4、集成缓存
专指spring cache，spring cache自己继承了ehcache作为了缓存的实现类，我们也可以使用guava cache、memcached、redis自己来实现spring cache的底层。当然，spring cache可以根据实现类来将缓存存在本地还是存在远程机器上。
5、页面缓存
在使用jsp的时候，我们会将一些复杂的页面使用Oscache进行页面缓存，使用非常简单，就是几个标签的事儿；但是，现在一般的企业，前台都会使用velocity、freemaker这两种模板引擎，本身速度就已经很快了，页面缓存使用的也就很少了。
总结：
在实际生产中，我们通常会使用guava cache做本地缓存+redis做分布式缓存+spring cache就集成缓存（底层使用redis来实现）的形式
guava cache使用在更快的获取缓存数据，同时缓存的数据量并不大的情况
spring cache集成缓存是为了简单便捷的去使用缓存（以注解的方式即可），使用redis做其实现类是为了可以存更多的数据在机器上
redis缓存单独使用是为了弥补spring cache集成缓存的不灵活
就我个人而言，如果需要使用分布式缓存，那么首先redis是必选的，因为在实际开发中，我们会缓存各种各样的数据类型，在使用了redis的同时，memcached就完全可以舍弃了，但是现在还有很多公司在同时使用memcached和redis两种缓存。
4. java框架有哪些常用框架
十大常用框架：
一、SpringMVC
二、Spring
三、Mybatis
四、Dubbo
五、Maven
六、RabbitMQ
七、Log4j
八、Ehcache
九、Redis
十、Shiro
5. Spring本地缓存的使用方法
我们现在在用的Spring Cache，可以直接看Spring Boot提供的缓存枚举类，有如下这些：
EhCache：一个纯Java的进程内缓存框架，所以也是基于本地缓存的。(注意EhCache2.x和EhCache3.x相互不兼容)。
Redis：分布式缓存，只有Client-Server(CS)模式，Java一般使用Jedis/Luttuce来操纵。
Hazelcast：基于内存的数据网格。虽然它基于内存，但是分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。
Guava：它是Google Guava工具包中的一个非常方便易用的本地化缓存实现，基于LRU（最近最少使用）算法实现，支持多种缓存过期策略。在Spring5.X以后的版本已经将他标记为过期了。
Caffeine：是使用Java8对Guava缓存的重写版本，在Spring5中将取代了Guava，支持多种缓存过期策略。
SIMPLE：使用ConcurrentMapCacheManager，因为不支持缓存过期时间，所以做本地缓存基本不考虑该方式。
关于分布式缓存，我们需要后面会专门讨论Redis的用法，这里只看本地缓存。性能从高到低，依次是Caffeine，Guava，ConcurrentMapCacheManager，其中Caffeine在读写上都快了Guava近一倍。
这里我们只讨论在Spring Boot里面怎么整合使用Caffeine和EhCache。
主要有以下几个步骤：
1)加依赖包：
2)配置缓存：
这里有两种方法，通过文件配置或者在配置类里面配置，先看一下文件配置，我们可以写一个properties文件，内容像这样：
然后还要在主类中加上@EnableCaching注解：
另外一种更灵活的方法是在配置类中配置：
应用类：
测试类：
导入依赖包，分为2.x版本和3.x版本。
其中2.x版本做如下导入：
3.x版本做如下导入：
导包完成后，我们使用JCacheManagerFactoryBean + ehcache.xml的方式配置：
参考资料：
https://blog.csdn.net/f641385712/article/details/94982916
http://www.360doc.com/content/17/1017/20/16915_695800687.shtml
6. 软件更新丨Spring Cloud Alibaba发布第二个版本，Spring发来贺电
还是熟悉的面孔，还是熟悉的味道，不同的是，这次的 配方升级 了。
时隔 51天，Spencer Gibb再次在Spring官网的博客页面宣布：Spring Cloud Alibaba发布了其开源后的 第二个版本0.2.1 ，随后，Spring Cloud 官方Twitter也转发了此消息。圣诞节的前一周，Josh Long向他的老朋友许晓斌发来贺电：
视频地址：https://spring.io/blog/2018/12/26/spring-tips-bootiful-alibaba
一、新版本概要
Spring Cloud Alibaba RocketMQ
Spring Cloud Alibaba SchelerX
Spring Cloud Alibaba Nacos Config
Spring Cloud Alibaba Nacos Discovery
Spring Cloud Alibaba Sentinel
二、新版本背后的思考
Spring Cloud Alibaba Nacos Discovery
Nacos Discovery 在这个版本最大的更新就是支持在初始化的时候不使用本地文件缓存，目前初始化的时候已经默认不使用本地文件缓存。
为什么要有缓存？首先我们来了解一下本地缓存的概念，为什么需要这个本地缓存？
我们都知道，服务注册与发现应该只是服务调用中的辅助性的一个环节，而不是一个关键的环节。一个良好的服务注册与发现的设计，需要保证以下两点。
要实现以上两点，缓存就不可或缺，而为了适应不同的场景，缓存又可以分成内存缓存和本地文件缓存，他们的概念和适用场景如下。
内存中的缓存
将服务提供者列表维护在内存中，每次调用时直接从内存中的列表获取节点即可。内存缓存通过定时任务更新，或者在收到服务注册中心的推送之后再更新。确保了即使在服务注册中心宕机的情况下，也能保证服务仍能正常调用。
本地文件缓存
将上述提到的内存中的缓存，保留在本地的某个文件中，这样在调用服务注册中心失败的时候，可以从本机的文件缓存中获取服务提供者列表。这样就保证了在服务注册中心宕机的情况下，应用在重启后也能找到服务提供者。
为什么要关闭
有了以上背景知识后，读者可能会有疑问，既然缓存这么好，你们为什么默认要把它置为默认关闭呢？
我们在发布出第一个版本之后，很多用户反馈，为什么我服务下线之后还是有节点，仍旧可以被查询到呢？这样导致我这个监控数据完全不准，你们这个有 bug，完全不对。其实这是阿里巴巴在多年业务积累的经验，对于服务发现来说，一个即使是已经过时的节点，也比没有任何数据好。而且还有可能其实这个服务只是和服务注册中心失去了心跳，但是应用本身是正常的。
当然，这也暴露了我们设计中存在的一些问题，没有把服务发现本身，以及缓存的分层给做好，两者糅合在一块。所以在这一次的版本更新中我们还是选择适配开源标准，默认关闭了本地文件缓存，留了一个开关给用户自由选择。
Spring Cloud Alibaba Nacos Config
Nacos Config 在这个版本中有两个大的特性，支持了“共享配置”，修正了动态刷新的语义和行为。
共享配置的实现
在第一个版本还没发布到时候，社区里对配置管理中心的讨论就没停止过，其中听到最多的反馈应该就是支持多个应用共享一个配置。我们也通过 github issue 的方式，征集了很多意见，详情见 #12 , #141。
后来我们将这个模型抽象了一下，认清这些需求本质是一个应用可以从多个 DataID 和 GroupID 组合中获取配置，并且这些配置还可以单独指定优先级和是否动态刷新。
最后我们推荐了这种使用方式，既保证了使用场景的灵活性，又保证了业务语义的明确性。更多详情可以参考 WIKI。
注意 data-id 的值必须带文件扩展名，文件扩展名支持 properties、yaml 和 yml。通过这种自定义扩展的配置项，既可以支持一个应用从多个配置项中获取数据，也解决多个应用间配置共享的问题。
头脑风暴，@fudali 同学还提出了更加灵活的一种方式 #161，就是可以通过一个配置项来配置所有的 DataID 的信息，然后可以通过修改这个配置项，可以修改整体配置项的逻辑。
这是一个非常好的想法，只不过这一期中我们没有实现，原因是这种方式太灵活了。我们认为配置管理其实是一件很严肃的事情，太灵活导致生产中变更比较不可控。
虽然目前的逻辑也可以支持这种用法，但是我们并没有把这种模式当做推荐模式，后续如果社区有更多的反馈认为这是一个强烈的需求，欢迎提 PR。
动态刷新的修正
简单好用、实时可监控的动态刷新也许是 Nacos Config 相对于其他开源中间件相比最核心的优势了，不同于 Spring Cloud Config Server 必须使用 Spring Cloud Bus 才能实现动态刷新，Nacos Config 无需依赖其他任何中间件就可以实现实时动态刷新，而且推送成功与否和刷新 历史 还支持实时查询。
但是我们发现在第一个版本中的实现发现两个问题：
在这个版本中，我们修复了这两个问题。
首先，动态刷新不再是直接去调用 ContextRefresher.refresh() 方法，而是 publish 了一个 RefreshEvent，让 spring-cloud-commons 里的 RefreshEventListener 去触发这个 ContextRefresher.refresh() 方法。
其次，我们修正了动态刷新的语义后，这一次是真正做到了，只有 refresh 属性为 true 的配置项，才会在运行的过程中变更为新的值，refresh 属性为 false 的配置项再也不用担心应用在运行的过程中发生莫名其妙的变更了。
更深入一点，在上个月 SpringOne Tour 中，我们和 Spring Cloud 的创始人 Spencer 聊到 Spring Cloud 的 Context.refresh() 成本太高，会刷新整个 Spring Context。他反复强调了两次 Context.refresh() 只对 @RefreshScope 和 @ConfigurationProperties 有效，成本一点也不高。
之前我们接收到很多社区的反馈都是 Nacos Config 动态刷新支不支持 xxxx，支不支持 xxxx。之前我们都是回答只支持 @RefreshScope 和 @ConfigurationProperties ，如果他内置没有支持，那就得自己加上相应的注解。
今天我们可以很愉快地回复，他监听了 RefreshEvent 也能直接支持。而且如果添加 @RefreshScope 和 @ConfigurationProperties 都不满足你的需求时，可以通过实现自己的 RefreshEventListener 更多高级的玩法。
Spring Cloud Alibaba Sentinel
Sentinel 在这个版本中有三个大的特性：全面支持 FeignClient ，完善了 RestTemplate 的支持，添加了热点限流、集群限流。
FeignClient 集成 Sentinel
其实在这之前，Sentinel 支持 FeignClient 已经设计了很久了，之前我们的想法做一个兼容性较强的方案，支持 Sentinel 和 Hystrix 在 FeignClient 中同时使用，尽量做到对原有应用的侵入性做到最小。
这个方案我们也思考调研了很久，但是实现难度确实比较大，需要修改 FeignClient 的代码才能实现两者共存。正好前段时间在 Spring Cloud 届最大的新闻就是 Hystrix 宣布不在维护了，于是我们就换了一个思路，直接使用 Sentinel 替代 Hystrix，不再去追求支持两者共存。
我们实现了自己的 Feign.Builder，在构建的 FeignClient 执行调用的过程中，通过 SentinelInvocationHandler 完成 Sentinel 的流量统计和保护的动作。如果想使用 Sentinel 为 FeignClient 限流降级，首先需要引入 sentinel-starter 的依赖，然后打开 Sentinel 限流降级的开关 feign.sentinel.enabled=true ，就完成了 Sentinel 的接入。如果需要使用更加定制化的功能，则需要在 @FeignClient 添加 fallback 和 configuration 这些属性的配置。
注意 @FeignClient 注解中的所有属性，Sentinel 都做了兼容。
RestTemplate 集成 Sentinel
Spring Cloud Alibaba Sentinel 支持对 RestTemplate 的服务调用使用 Sentinel 进行保护，补全了 Hystrix 这一块的空白。接入的方式也不复杂，在构造 RestTemplate bean 的时候需要加上 @SentinelRestTemplate 注解，然后在控制台配置相应的规则即可。
在触发了限流降级时，默认的处理方式是返回 RestTemplate request block by sentinel 信息。
RestTemplate 的限流降级 ？Sentinel 也承包了！
热点参数限流和集群限流
首先解释一下什么是热点参数限流和集群限流。
热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。
集群流控主要解决的问题是：当我们需要控制整个集群流量总量，但是单机流量可能会不均匀，如果是单机维度去限制的话会无法精确地限制总体流量，因此需要引入集群维度的流量控制。
Sentinel v1.4.0 的 新功能 ，也能第一时间愉快地在 Spring Cloud Alibaba 上使用了。
三、新组件
Spring Cloud Alibaba RocketMQ
Spring Cloud Stream 是一个用于构建基于消息的微服务应用框架，它基于 SpringBoot 来创建具有生产级别的单机 Spring 应用，并且使用 Spring Integration 与 Broker 进行连接。它提供了消息中间件的统一抽象，推出了 publish-subscribe、consumer groups、partition 这些统一的概念。
RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。具有以下特点：能够保证严格的消息顺序、提供丰富的消息拉取模式、高效的订阅者水平扩展能力、实时的消息订阅机制、亿级消息堆积能力。
在这次的 Spring Cloud Stream Binder RocketMQ 的实现中，我们适配了 Spring Cloud Stream 对于 message 抽象的 API，支持了 RocketMQ 的事务消息。消息订阅时支持以 tags、SQL 表达式过滤消息，同时还支持顺序、并发、延迟以及广播消费模式。
Spring Cloud Alibaba SchelerX
SchelerX 是阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务，同时提供分布式的任务执行模型，如网格任务，网格任务支持海量子任务均匀分配到所有 Worker（schelerx-client）上执行。
简单易用的轻量分布式任务调度
您不需要关心调度逻辑，只需要在在 JobProcessor 接口的实现中添加业务逻辑即可，然后在自主运维控制台配置上一个 Job 即可完成使用。
高可用的分布式任务
不管是 SchelerX 服务端还是客户端都是分布式架构设计，任务可以在多台客户端机器里的任何一台机器执行，如果客户端出现宕机的情况，服务端会自动选择正常运行的客户端去执行 Job，每个 Job 在服务端的不同机器均有备份，SchelerX 服务端任意宕掉部分机器仍能保证 Job 正常调度。
友好的用户界面
SchelerX 提供了非常友好的页面方便您创建、删除或修改 Job，提供了立即触发执行一次的功能，方便您测试以及关键时刻手动立即执行一次，还提供了 历史 执行记录查询的功能，您可以看到任何一个 Job 过去 100 次的 历史 执行记录。
功能强大
提供了秒级、精准的定时任务调度服务，且提供了丰富的任务执行模型，包括单机执行，广播执行，以及子任务的分布式执行。
四、What's Next?
Spring Cloud Alibaba Cloud SLS 针对日志类数据的一站式服务，在阿⾥巴巴集团经历大量大数据场景锤炼⽽成。您⽆需开发就能快捷地完成日志数据采集、消费、投递以及查询分析等功能，提升运维、运营效率，建立 DT 时代海量日志处理能力。
Spring Cloud Alibaba Dubbo Dubbo 是一款流行的开源 RPC 框架，我们会把 Dubbo 整合到 Spring Cloud Alibaba 中，让大家在开发 Dubbo 时也能享受到 Spring Cloud 带来的便利。
致谢
Spring Cloud Alibaba 从开源建设以来，受到了很多社区同学的关注。社区的每一个 issue ，每一个 PR，都是对整个项目的帮助，都在为建设更好用的 Spring Cloud 添砖加瓦。
↓↓↓