前言

緩存要解決的問題是速度的問題，使用緩存的目的是為了減少對物理資源的訪問，緩存大量的應用在軟硬件的方方面面，從 CPU 到硬盤，就應用了 一級緩存、二級緩存，少部分高速緩存和大量低速緩存相結合，以提高 CPU 的計算能力，本文講的主要是系統集成項目中的軟件級別的緩存。

緩存因果圖

緩存在現代系統中的位置可以說是舉足輕重，不是可有可無的問題了，而是怎麼樣用好的問題。怎麼樣講好緩存這個話題，我思考了很久；如果是生搬硬套，我估計我肯定是涼涼，但要是上來就一頓代碼操作，顯得字太多，各位看官老爺也是要噴死我的（你們噴我算我贏）。各位看官就當故事隨便看看就好了。

客戶端緩存

小明同學是一個大學生，每個月都會從爸爸那裡領取生活費，由於爸爸給的生活費比較充裕，他就將一部分存了起來，周而復始，固定頻率，這就是瀏覽器網頁緩存；有一天，他接到爸爸的一個電話，說每個月給現金，我總是從銀行拿也不方便，這樣，咱給存銀行卡裡頭，但是說好了，每個月1號的時候轉1000塊進去，3號之前可以領取，過時不侯。這就是 Cookie！小明說爸，這時間太緊迫了，我萬一太過於專心學習忘記取錢那你兒子可是要餓死的吖，到時候沒人給你養老送終事兒就大了。他爸爸經過深思熟慮后，決定放開取現時間的限制：行，你想什麼時候取都成，就是別把卡給弄掉了就行。這就是LocalStorage/IndexDB，瀏覽器本地存儲。如果銀行卡掉了（瀏覽器重裝，刪庫跑路），那還得找爸爸。

服務器緩存

我們本次討論的重點就是服務器緩存，對於小明的爸爸來說，每次給小明生活費之前都要到銀行（數據庫）去取錢出來，實在是太麻煩，不如提前把錢取出來準備好，每次取半年的錢出來放家裡保險箱里（緩存），小明申請生活費的時候，直接給他就好了，節約時間效率又高，唯一的問題就是可能沒那麼安全，有可能被小偷把錢給偷了（緩存更新），然後就是半年時間過後再重新取一筆出來（緩存過期策略）。

靜態對象緩存

靜態對象也是一種特殊的緩存，靜態對象作用於程序的整個生命周期中。需要注意的是，靜態對象不會被 GC 回收 ，但是，如果靜態對象被多次引用覆蓋，那麼之前的引用就有可能被 GC 回收。這就好像，小明在向爸爸領取生活費的時候，發現這次領到手的錢實在是太破舊了，都不好意思花出去，爸爸只好重新給了另一份。

會話級緩存

在 Web 站點中，Session 是私有制的，各個 Session 之間是不會共享內存對象的，我們可以利用這個特性（在Asp.NET 時代常用）來暫時保存一些數據，例如用戶購物車。還是以小明的需求為例子，小明下面還有一個妹妹，妹妹每個月都可以從爸爸那裡多領取200元生活費，看到妹妹的資源這麼好，小明憤憤不平，就像妹妹提議共享生活費，一家人一起用，多好吖！結果小明被爸爸揍了一頓，還收回了部分生活費。

進程級別緩存

基本上每個應用程序都具有本地緩存的能力，在 Asp.NET 中就有 MemoryCache ，也叫做進程級緩存（本地緩存），MemoryCache 和 分佈式緩存的作用基本一致，所不同的是，本地緩存在應用程序停止后就會被釋放掉，無法進行持久存儲。就好像，小明在上大學期間，每個月都是生活費的，但是到暑假的時候就沒有了（只能靠苦逼的暑期工掙點生活費啊）。

分佈式緩存

分佈式緩存是個好東西，目前市場上出現了非常多的 nosql 數據庫，都可用作緩存數據庫，有時候，這些緩存數據庫也提供持久化的能力。

小明家的生活條件，在經過爸爸的不懈努力之後，生活水平漸漸提高了；有一天，爸爸對小明說：明仔吖，咱們家現在生活水平提高了，但是爸爸也越來越忙了，這樣，如果我忙的時候，你問媽媽或者爺爺奶奶，也是可以拿到生活費的，咱們家這幾位長輩手裡都有錢了，這就是分佈式緩存。

但是分佈式緩存又分為主從模式和集群模式，上面說的是集群模式，爸爸媽媽爺爺奶奶都可以拿錢，但是主從模式就不同了，主從模式就是錢都在爸爸手裡，爸爸會把錢分給每個長輩一份，如果當時正好爸爸太忙了，沒來得及分給媽媽，而小明又恰好問媽媽要生活費的話；媽媽只能對他說：小命呀，不好意思，媽媽這裏也沒有，你看看再問問其它人（客戶端自己輪詢），在問了媽媽、爺爺后（引用指向），終於知道，錢在爸爸那裡，還得問爸爸要生活費。而且爸爸給其它人分錢的時候，還要佔用他工作的時間。

緩存雪崩

緩存雪崩就是在某一個時刻，大量的緩存同時失效，造成數據庫訪問壓力倍增。小明的爸爸最近壓力比較大，因為收入減少了，他爸爸做的一個工程因為種種原因，貨款只能分期付清，為了防止小明和妹妹同時申請生活費，造成資金周轉困難；爸爸規定妹妹 1 號領取生活費，而小明在 5 號才能領取，小明心裏的苦啊！

緩存穿透

緩存穿透就是客戶端總是嘗試訪問某個不存在的緩存，造成了每次都要取請求數據庫讀取數據。就好像小明吧，本來生活挺平靜的，這剛上大二，就交了個女朋友，每個月的 1000 元生活費有點捉襟見肘，然後他又不能讓爸爸知道，就在申請生活費的時候，每次都多要一點；這樣就搞得爸爸很被動，本來計劃得好好的，每個月都是 1000 塊，這沒次都不夠，老是要跑銀行取現金，終於在3個月後，爸爸發現了這個問題，想著兒子也大了，為了早日抱上孫子，就提高了小明的生活費，解決了每次都要跑銀行的問題。

緩存擊穿

緩存擊穿和緩存雪崩有點類似，其中不同的是；緩存雪崩是大量緩存 key 同時過期，而緩存擊穿是大量的請求指向同一個緩存key，在這個 key 過期的時候，大量的請求湧入數據庫中，造成了瞬間巨大的壓力。舉個栗子，因為小明交了女朋友的原因，他的生活費總是很快用完了；這種情況下，他也必須在 1 號的時候拿到生活費，不然就要吃土了，但是媽媽不允許他們一起取打擾爸爸，媽媽就指定了妹妹去問，在妹妹沒有回來之前，小明只能等着，這就是為了解決緩存擊穿而採用的策略：互斥鎖(mutex key)

運維級別緩存

除了在應用程序中可以接入緩存以外，部分運維工具也集成了緩存服務，比如 Nginx、IIS。

代理緩存

Nginx 就是反向代理緩存，通過配置 Nginx 的緩存功能，在客戶端請求到來到時候去加載緩存內容，用以提高響應能力，IIS 緩存又分為用戶緩存和內核緩存。IIS 的輸出緩存設置中，內核模式緩存不會對驗證等用戶信息進行檢查，就好像小明等爸爸因為太趕時間，把錢放門衛大媽那裡了，結果隨便來了個學生就把小明等生活費給領走了，但是加上用戶模式緩存后，就可以添加對身份的檢查（請求標頭），這樣大媽就會知道誰是小明而不會隨便把生活費交給別人了。

網頁靜態化

這種技術，在 Web1.0 時代非常的流行，我還記得那些個年頭的網站開發項目中的要求，大部分項目的需求分析文檔裏面就明晃晃的寫着：網頁靜態化！，而靜態化常見於各種企業型、論壇帖子，在發表這些信息后就將其生成靜態網頁，客戶端訪問的時候，直接重定向到該靜態網頁，基本無需訪問數據庫。

CDN 緩存

CDN 緩存類似於上面提到的分佈式緩存，但是實際上 CDN 緩存服務目前來說，主要說針對靜態資源的，比如圖片、視頻、文件等等；大家經常可以看到，很多站點都號稱提供了 CDN 加速服務，這些站點就像一個個代辦信用卡的銷售中介，實際上拿的都是銀行的資源。

更形象一些的說法，就是大家的錢都是中國人民銀行發行的，我們可以通過各個不同的銀行（CDN節點）查詢我們的銀行卡餘額（我怎麼可能有餘額），在以前沒有手機銀行的時候，大家就可以到附近的銀行去查詢，然後取款（CDN緩存），如果附近的銀行的櫃員機沒有現金，那麼可能就需要到總行去取了（回源），如果發生了太多回源的事件，就會造成 CDN 的擁堵，所以 CDN 服務商也不敢打包票自己的基礎服務沒有問題，反正我是沒見到哪家 CDN 服務商敢註明服務穩定性 100%，基本上都是 99.99%

結束語

緩存的理論知識，其實是非常宏大的，我這裏只是拋磚引玉，希望能給入門的朋友帶來一點幫助，如果你喜歡這篇文章，請給我點贊，讓更多同學可以看到。

【精選推薦文章】

智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

帶您來看台北網站建置，台北網頁設計，各種案例分享

廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

SpringBoot系列文章簡介

SpringBoot源碼閱讀輔助篇：

　　Spring IoC容器與應用上下文的設計與實現

SpringBoot啟動流程源碼分析：

1. SpringBoot啟動流程分析（一）：SpringApplication類初始化過程
2. SpringBoot啟動流程分析（二）：SpringApplication的run方法
3. SpringBoot啟動流程分析（三）：SpringApplication的run方法之prepareContext()方法
4. SpringBoot啟動流程分析（四）：IoC容器的初始化過程
5. SpringBoot啟動流程分析（五）：SpringBoot自動裝配原理實現
6. SpringBoot啟動流程分析（六）：IoC容器依賴注入

筆者註釋版Spring Framework與SpringBoot源碼git傳送門：請不要吝嗇小星星

1. spring-framework-5.0.8.RELEASE
2. SpringBoot-2.0.4.RELEASE

自定義Starter：

　　SpringBoot應用篇（一）：自定義starter

一、前言

　　上一篇文章，通過分析refresh()方法中的invokeBeanFactoryPostProcessors()方法，分析了IoC容器的初始化過程，這一節從代碼上如下所示，接上一節ConfigurationClassParser類中的parse()方法，接着分析SpringBoot的自動裝配原理。

 1 // ConfigurationClassParser類
 2 public void parse(Set<BeanDefinitionHolder> configCandidates) {
 3     this.deferredImportSelectors = new LinkedList<>();
 4     for (BeanDefinitionHolder holder : configCandidates) {
 5         BeanDefinition bd = holder.getBeanDefinition();
 6         try {
 7             // 如果是SpringBoot項目進來的，bd其實就是前面主類封裝成的 AnnotatedGenericBeanDefinition（AnnotatedBeanDefinition接口的實現類）
 8             if (bd instanceof AnnotatedBeanDefinition) {
 9                 parse(((AnnotatedBeanDefinition) bd).getMetadata(), holder.getBeanName());
10             } else if (bd instanceof AbstractBeanDefinition && ((AbstractBeanDefinition) bd).hasBeanClass()) {
11                 parse(((AbstractBeanDefinition) bd).getBeanClass(), holder.getBeanName());
12             } else {
13                 parse(bd.getBeanClassName(), holder.getBeanName());
14             }
15         } catch (BeanDefinitionStoreException ex) {
16             throw ex;
17         } catch (Throwable ex) {
18             throw new BeanDefinitionStoreException(
19                     "Failed to parse configuration class [" + bd.getBeanClassName() + "]", ex);
20         }
21     }
22     // 加載默認的配置---》（對springboot項目來說這裏就是自動裝配的入口了）
23     processDeferredImportSelectors();
24 }

二、SpringBoot自動裝配原理。

2.1、@SpringBootApplication註解

　　對這個註解詳細大家一定非常熟悉了。再來好好看看這個註解。

 1 @Target(ElementType.TYPE)
 2 @Retention(RetentionPolicy.RUNTIME)
 3 @Documented
 4 @Inherited
 5 @SpringBootConfiguration
 6 @EnableAutoConfiguration
 7 @ComponentScan(excludeFilters = {
 8         @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
 9         @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
10 public @interface SpringBootApplication {
11     ...
12 }

　　接着看@EnableAutoConfiguration

1 @Target(ElementType.TYPE)
2 @Retention(RetentionPolicy.RUNTIME)
3 @Documented
4 @Inherited
5 @AutoConfigurationPackage
6 @Import(AutoConfigurationImportSelector.class)
7 public @interface EnableAutoConfiguration {
8     ...
9 }

　　OK，看到@Import(AutoConfigurationImportSelector.class)導入了一個重要的類AutoConfigurationImportSelector。

2.2、AutoConfigurationImportSelector

 1 // AutoConfigurationImportSelector類
 2 //自動裝配
 3 @Override
 4 public String[] selectImports(AnnotationMetadata annotationMetadata) {
 5     if (!isEnabled(annotationMetadata)) {
 6         return NO_IMPORTS;
 7     }
 8     AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
 9             .loadMetadata(this.beanClassLoader);
10     AnnotationAttributes attributes = getAttributes(annotationMetadata);
11     //獲取所有的自動配置類（META-INF/spring.factories中配置的key為org.springframework.boot.autoconfigure.EnableAutoConfiguration的類）
12     List<String> configurations = getCandidateConfigurations(annotationMetadata,
13             attributes);
14     configurations = removeDuplicates(configurations);
15     //需要排除的自動裝配類（springboot的主類上 @SpringBootApplication(exclude = {com.demo.starter.config.DemoConfig.class})指定的排除的自動裝配類）
16     Set<String> exclusions = getExclusions(annotationMetadata, attributes);
17     checkExcludedClasses(configurations, exclusions);
18     //將需要排除的類從 configurations remove掉
19     configurations.removeAll(exclusions);
20     configurations = filter(configurations, autoConfigurationMetadata);
21     fireAutoConfigurationImportEvents(configurations, exclusions);
22     return StringUtils.toStringArray(configurations);
23 }

　　至於怎麼從章節一中提到的ConfigurationClassParser類中的parse()===>processDeferredImportSelectors()==>AutoConfigurationImportSelector#selectImports()，篇幅有限不做過多介紹。

　　 List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes); 

　　我們來看一下getCandidateConfigurations()方法是怎麼拿到這些自動配置類的。

// AutoConfigurationImportSelector類
1 protected List<String> getCandidateConfigurations(AnnotationMetadata metadata,
2                                                   AnnotationAttributes attributes) {
3     List<String> configurations = SpringFactoriesLoader.loadFactoryNames(
4             getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader());
5     Assert.notEmpty(configurations,
6             "No auto configuration classes found in META-INF/spring.factories. If you "
7                     + "are using a custom packaging, make sure that file is correct.");
8     return configurations;
9 }

　　是不是又看到一個十分熟悉的方法loadFactoryNames()，沒錯，其實我們在分析SpringBoot啟動流程的第一篇文章的時候，就已經分析了，SpringBoot是如何從META-INF/spring.factories中加載指定key的value的。ok，我們在這裏再次回顧一遍。

　　看看loadFactoryNames()方法

// SpringFactoriesLoader類
1 public static List<String> loadFactoryNames(Class<?> factoryClass, @Nullable ClassLoader classLoader) {
2     String factoryClassName = factoryClass.getName();
3     return loadSpringFactories(classLoader).getOrDefault(factoryClassName, Collections.emptyList());
4 }

　　debug，看看要從META-INF/spring.factories中加載的類的key，如下圖所示：org.springframework.boot.autoconfigure.EnableAutoConfiguration

　　回到selectImports()方法，debug，跳過List<String> configurations = getCandidateConfigurations(annotationMetadata,attributes);看一下configurations

　　竟然有110個，那這些類都在哪裡呢？看spring-boot-autoconfigure（當然在SpringBoot的工程中，也不止這一個依賴包中存在該配置文件）工程下的META-INF/spring.factories，我們能看到org.springframework.boot.autoconfigure.EnableAutoConfiguration定義了一大堆。

　　其中還有一個com.demo.starter.config.DemoConfig是我自定義的starter。如下所示，我在測試工程中添加了自定義starter的依賴，所以SpringBoot就能掃描到。

1 <dependency>
2     <groupId>com.demo</groupId>
3     <artifactId>demo-spring-boot-starter</artifactId>
4     <version>0.0.1-RELEASE</version>
5 </dependency>

 　　繼續看Set<String> exclusions = getExclusions(annotationMetadata, attributes);方法，該方法是排除主類上@SpringBootApplication註解上排除的自動裝配的類。比如我們在該註解上排除我們自定義starter的自動裝配的類，@SpringBootApplication(exclude = {com.demo.starter.config.DemoConfig.class})（當然也可以用excludeName進行排除），那麼在後面的configurations.removeAll(exclusions);方法中將會刪除我們的com.demo.starter.config.DemoConfig.class。

　　configurations = filter(configurations, autoConfigurationMetadata);該行代碼將會過濾掉不需要裝配的類。過濾的邏輯有很多，比如我們常用的@ConditionXXX註解。如下所示：

 1 @ConditionalOnBean:容器中有指定的Bean 
 2 @ConditionalOnClass：當類路徑下有指定的類
 3 @ConditionalOnExpression:基於SpEL表達式作為判斷條件  
 4 @ConditionalOnJava:基於JVM版本作為判斷條件  
 5 @ConditionalOnJndi:在JNDI存在的條件下查找指定的位置  
 6 @ConditionalOnMissingBean:當容器中沒有指定Bean的情況下  
 7 @ConditionalOnMissingClass:當類路徑下沒有指定的類
 8 @ConditionalOnNotWebApplication:當前項目不是Web項目
 9 @ConditionalOnProperty:配置文件中指定的屬性是否有指定的值  
10 @ConditionalOnResource:類路徑下是否有指定的資源  
11 @ConditionalOnSingleCandidate:當指定Bean在容器中只有一個，或者雖然有多個但是指定首選Bean
12 @ConditionalOnWebApplication:當前項目是Web項目的條件下

 　　至於如何將這些類解析成BeanDefinition並註冊進beanDefinition中的，和上一節講的過程是一樣的，不再贅述了。

　　debug，跳過refresh()方法中的invokeBeanFactoryPostProcessors(beanFactory);方法。如下圖所示，最終在beanFactory的BeanDefinitionMap中找到了自定義starter中的自動裝配的類。

　　綜合本文和上一篇博文我們詳細的梳理了IoC容器的初始化過程，到此IoC容器的初始化過程就結束了。

　　原創不易，轉載請註明出處。

　　如有錯誤的地方還請留言指正。

【精選推薦文章】

如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

想要讓你的商品在網路上成為最夯、最多人討論的話題?

網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師"嚨底家"!!