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 添磚加瓦。
↓↓↓