最近實在是不太平，不管是疫情還是學習，實際上都是相通的，都應該對之努力，堅持，纔會有見春天的那一天，疫情已經快到結尾了，想說感謝的太多，人，國家，都值得我爲之驕傲！好了，不說這些矯情話了，還是要學習啊！最近在家重新看了一些東西，發現之前寫的還是有很多漏洞，纔有了這個回顧。
1.redis部分
（1）redis集羣模式：
僞分佈式
客戶端分片（自己定義分片規則，使得key分區域存儲）
哨兵模式：存在選舉時間
集羣模式：也存在slave節點到master節點的過程，但是由於分槽存儲，所以只是某一塊槽內無法使用
集羣中更改一個配置文件，就相當於是更改爲一個不同的節點
更改方式：
daemonize：後臺模式
port：端口號
bind：綁定的ip
dir：可識別的redis文件工作目錄
cluster-enable：開啓集羣模式
cluster-config-file：集羣配置文件的位置
cluster-node-timeout：超時設置
appendonly：開啓aof持久化設置
protected-mode：關閉或開啓保護模式
requirepass：redis密碼
masterauth：集羣通信密碼（要與redis密碼相同）
更改後需要確定主從節點：
redis-cli -a 集羣通信密碼 --cluster create（創建集羣） --cluster-replicas（集羣副本） 1（設置從節點數量，設爲1則爲每1個master均有1個對應的slave） 所有集羣內ip:端口號
redis-cli -a password --cluster create --cluster-replicas 1 192.168.1.201:7001 192.168.1.201:7002 192.168.1.201:7003 192.168.1.201:7004 192.168.1.201:7005 192.168.1.201:7006
集羣中一般主節點和從節點不在同一臺機器上，防止主節點宕機導致該主節點下無從節點，最終導致整個集羣宕機
連接集羣命令：
redis-cli -a 集羣密碼 -c（集羣模式） -h 主機 -p 端口
redis-cli -a password -c -h 192.168.1.203 -p 7003
（2）持久化：
RDB：
原理是Redis會單獨創建（fork）一個與當前進程一模一樣的子進程（因爲Redis是單線程的）來進行持久化，這個子進程的所有數據（變量，環境變量，程序運行數據計數器等）都和原進程一模一樣，會先將數據寫入到一個臨時文件中，待持久化完成後再用這個臨時文件替代上次持久化好的文件，在整個過程中，主進程不進行任何IO操作，確保極好的性能。（save方法使用主線程持久化，bgsave方法異步持久化）保存數據。在主從複製情況下不能關閉RDB，因爲主從複製就是主機將RDB文件發送給從機。否則只需要將配置文件中的save註釋就可以。
AOF：
比RDB丟失數據少。保存的是命令串。AOF文件中保存的是協議。如（*2 $6 select $1 0 *3 $3 set $2 k1 $2 v1）中，*表示幾條命令，$表示幾個字符，所以存在（select 0）選庫操作和（set k1 v1）賦值操作。當文件大小增長到一定大小時，Redis能夠調用bgrewriteaof對日誌文件進行重寫。當AOF文件大小大於默認配置時開啓重寫。（auto-aof-rewrite-min-size:64M和auto-aof-rewrite-percentage 100這裏是百分比，相當於是在翻一倍時重寫）
混合持久化：
通過bgwriteaof完成，不同的是當開啓混合持久化時，fork出的子進程先將共享的內存副本全量以RDB方式寫入aof文件，然後再將緩衝區的增量命令以AOF方式寫入文件，寫入完成後通知主進程更新的信息，並將新的含有RDB格式和AOF格式的AOF文件替換原有的AOF文件。也就是說新的AOF文件前半段會是RDB全量數據，後半段是AOF增量數據。兼容兩者的優點，加載速度快且最大程度保證數據不丟失，但是隻在Redis4.0版本之後。
（3）緩存：
緩存穿透：數據庫本就沒有的數據，緩存也就沒有相應數據，而導致的所有的相關查詢都會通過數據庫查詢。
解決方案：緩存空對象，布隆過濾器
緩存擊穿：數據庫中存在，緩存中數據由於有緩存時間而過期，並且擁有高併發量的訪問，而導致的瞬間的高併發的數據庫查詢
解決方案：互斥鎖，使用jvm鎖或者分佈式鎖
緩存雪崩：指服務器重啓或者大量緩存集中過期，導致的大量的數據庫查詢
解決方案：搭建高可用集羣，對不同數據使用不同過期時間
緩存和數據庫一致性：
先更新數據庫再更新緩存：導致數據庫中是新數據，緩存中由於延時或者錯誤而沒有更新成功，數據不一致。在多線程使用中由於有順序關係導致的數據庫和緩存的更新順序，數據不一致。
解決方案：先刪除緩存，再修改數據庫。
先刪除緩存，再查詢數據庫：由於使用多線程，在刪除緩存後，所有線程都會在數據庫中進行查詢。而此時有一個線程是更新數據庫的操作，由於順序問題缺在數據庫查詢，創建緩存後完成了數據庫更新操作，數據不一致。
解決方案：延時雙刪。只在更新數據庫後再刪除一次緩存內數據。查詢操作不受影響
串行化。將命令插入隊列中，通過隊列保證數據庫更改和查詢等操作的順序。
（4）應用場景：
ehcache直接在jvm虛擬機中緩存，速度快，效率高；但是緩存共享麻煩，集羣分佈式應用不方便。如果是單個應用或者對緩存訪問要求很高的應用，用ehcache。
redis通過socket訪問到緩存服務，效率比ecache低，比數據庫要快很多，處理集羣和分佈式緩存方便，有成熟的方案。
如果是大型系統，存在緩存共享、分佈式部署、緩存內容很大的，建議用redis。
補充下：ehcache也有緩存共享方案，不過是通過RMI或者Jgroup多播方式進行廣播緩存通知更新，緩存共享複雜，維護不方便；簡單的共享可以，但是涉及到緩存恢復，大數據緩存，則不合適
redis和memcached相比的獨特之處：
1、redis可以用來做存儲(storage),而memcached是用來做緩存(cache)
這個特點主要因爲其有持久化功能
2、redis中存儲的數據有多種結構，而memcached存儲的數據只有一種類型“字符串”
2.SpringBoot部分
對於數據訪問層，無論是關係型數據庫還是非關係型數據庫，SpringBoot底層都是採用SpringData方式進行統一訪問
Druid在springboot框架下有更加好用的Druid Spring Boot Starter，可以省去原本寫Druid的一些配置文件或者@Configuration來配置，直接將配置寫在application.yml或者application.properties裏，看起來更簡單一些。
config優先級 默認最低
1.file:/config/
2.file:./
3.classpath:/config/
4.classpath:/
1.springboot在啓動時，從類路徑/META-INF/spring.factories獲取指定的值
2.將自動配置的類導入容器，自動配置就會生效
靜態資源優先級：resources>static>public，很少使用webjars
3.設計模式部分
單例模式：保證一個類只有一個實例，並且提供一個全局訪問點（連接池）
懶漢模式：（存在多線程問題，加synchronized就可以，但是會有性能損耗）
餓漢模式
靜態方法模式
工廠方法模式：定義一個用於創建對象的接口，讓子類決定實例化哪一個類。工廠方法使得一個類的實例化延遲到子類（當你不知道該使用對象的確切類型時或者希望爲庫或框架提供拓展其內部組件的方法時可以使用），能將具體產品和創建者解耦，符合單一職責原則和開閉原則
抽象工廠模式：提供一個創建一系列相關或互相依賴的對象的接口，而無需指定他們具體的類（解釋：只定義一套規範，而不具體實現，相對於不同的實現類有不同的抽象方法的實現）（程序需要處理不同系列的相關產品但是不希望依賴這些產品的具體類）可以確定從工廠中得到的產品是互相兼容的，可以避免具體產品和客戶端代碼之間的緊密耦合，同樣符合單一職責原則和開閉原則
建造者模式：將一個複雜對象的創建與他的表現分離，使得同樣的構建過程可以創建不同的表示（需要生成的對象具有複雜的內部結構，需要生成的對象內部屬性本身相互依賴，與不可變對象配合使用。）建造者獨立，易拓展，便於控制細節風險。
原型模式：指原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。通過序列化的方式完成數據的深拷貝是不被建議的，因爲是在CPU中進行的
享元模式：運用共享技術有效的支持大量細粒度的對象，如果系統中有大量的類似的對象，可以節省大量的內存和CPU資源
門面模式（外掛模式）：爲子系統中的一組接口提供一個一致的接口，門面模式定義了一個高級接口，這個接口使得這一子系統更容易使用controller/service，當需要使用複雜的子系統的有限但直接的接口時或者將子系統組織成層時可以使用Facade
適配器模式：將一個類的接口轉換爲客戶希望的另一個接口，適配器模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作，當希望使用某些現有類，但其接口與其他代碼不兼容時或者當希望重用幾個現有的子類，而這些子類缺少一些不能添加到超類中的公共功能時，可以使用適配器模式。
3.Nginx部分
Nginx是一個高性能的HTTP和反向代理服務器，特點是佔有內存小，併發能力強，能承受高負載測試
支持熱部署，幾乎可以7*24小時
正向代理：在客戶端（瀏覽器）配置代理服務器，通過代理服務器進行互聯網訪問
反向代理：客戶端對代理無感知，客戶端不需要進行任何配置就可以訪問，我們只需要將請求發送到反向代理服務器，由反向 代理服務器選擇目標服務器獲取數據後返回給客戶端，此時反向代理服務器和目標服務器對外就是一個服務器，暴露的是反向代理服務器的地址，隱藏了真實服務器IP地址
負載均衡：
單個服務器解決不了的問題，可以通過增加服務器數量，然後將請求分發到各個服務器上的方式，將原先請求集中到單個服務器的情況，改爲將請求分發到多個服務器上，將負載分發到不同的服務器上的過程，也就是負載均衡。
動靜分離：
爲了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的服務器進行解析，加快解析速度，降低原來單個服務器的壓力。
可以直接進行配置文件的重新加載：
nginx -s -reload
配置文件：
1.全局塊：從配置文件開始到events塊之間的內容，主要會設置一些影響nginx服務器整體運行的配置指令，主要包括配置運行nginx服務器的用戶(組)、允許生成的worker process數量，進程PID存放路徑，日誌存放路徑和類型及配置文件的引入等。
2.events塊：主要影響nginx與用戶的網絡連接，常用的設置包括是否開啓對多work process下的網絡連接進行序列化，是否允許同時接受多個網絡連接，選取哪種事情驅動模型來處理連接請求，每個work process可以同時支持的最大連接數等
3.http塊：nginx配置中最頻繁的部分，代理，緩存，日誌等絕大多數功能和第三方模塊配置都在。http塊內包含http全局塊（包含文件引入，MIME-TYPE定義，日誌自定義，連接超時時間，單鏈接請求數上限等）和server塊（與虛擬主機有關）。每個http塊可以包含多個server塊，而每個server塊相當於是一個虛擬主機。每個server塊也分爲全局server塊，以及可以同時包含多個location塊。全局server塊（本虛擬機主機監聽配置和主機名稱和IP配置）location塊（基於nginx服務器接收到的請求字符串對虛擬主機或IP之外的字符串進行匹配，地址定向，數據緩存和應答控制等）。
負載均衡配置策略：
1.輪詢：默認策略。每個請求按照時間順序逐一分配到不同的後端服務器中，如果後端服務器宕機，自動剔除。
2.weight權重：權重默認爲1，權重越高被分配的客戶端越多。
3.ip_hash：每個請求按照訪問IP的hash結果進行分配，這樣每一個訪客固定訪問一個後端服務器，可以解決session問題。但可能會導致負載不均現象，如果某臺tomcat服務器宕機,則可能影響用戶的使用
4.fair（第三方）：按照後端服務器的響應時間進行分配，響應時間短的優先分配。
動靜分離：動靜分離不應該是物理分離，而應該是將請求分割，動態請求和靜態請求分別訪問不同的服務器。提高效率。
1.將靜態文件獨立爲單獨的域名放在獨立的服務器上（常用方式）
2.動靜文件混合發佈，而後通過nginx進行分離
針對純靜態文件，可以使用expires設定過期時間，適用於不經常變動的資源。發送一個請求，比對服務器上該文件最後更新時間有沒有變化，若沒有則不會再從服務器中抓取，返回狀態碼304，如果有則從服務器中重新下載，返回200。