A. EF6 有查詢緩存，怎麼辦
設置好查詢緩存的大小就行了。比如設置個20MB.
SET GLOBAL QUERY_CACHE_SIZE=20000000;
mysql會將查詢SQL和結果集存到緩存中，等下次遇到相同的SQL語句時，結果集從緩存中讀取。
不設置就不用緩存了
B. Redis分布式緩存搭建
花了兩天時間整理了之前記錄的Redis單體與哨兵模式的搭建與使用，又補齊了集群模式的使用和搭建經驗，並對集群的一些個原理做了理解。
筆者安裝中遇到的一些問題：
如果make報錯，可能是沒裝gcc或者gcc++編輯器，安裝之 yum -y install gcc gcc-c++ kernel-devel ，有可能還是提示一些個c文件編譯不過，gcc -v查看下版本，如果不到5.3那麼升級一下gcc：
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
這回編譯通過了，提示讓你最好make test一下/
執行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升級tcl， yum install tcl
重新make test，如果還有error就刪了目錄，重新tar包解壓重新make , make test
o/ All tests passed without errors! ，表示編譯成功。
然後make install即可。
直接運行命令： ./redis-server /usr/redis-6.0.3/redis.conf &
redis.conf 配置文件里 bind 0.0.0.0 設置外部訪問， requirepass xxxx 設置密碼。
redis高可用方案有兩種：
常用搭建方案為1主1從或1主2從+3哨兵監控主節點， 以及3主3從6節點集群。
（1）sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
sentinel2.conf配置：
坑1：master節點也會在故障轉移後成為從節點，也需要配置masterauth
當kill master進程之後，經過sentinel選舉，slave成為了新的master，再次啟動原master，提示如下錯誤：
原因是此時的master再次啟動已經是slave了，需要向現在的新master輸入密碼，所以需要在master.conf
中配置：
坑2：哨兵配置文件要暴露客戶端可以訪問到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置該哨兵對應的master名字、master地址和埠，以及達到多少個哨兵選舉通過認為master掛掉。其中master地址要站在redis訪問者（也就是客戶端）的角度、配置訪問者能訪問的地址，例如sentinel與master在一台伺服器（122.xx.xxx.xxx）上，那麼相對sentinel其master在本機也就是127.0.0.1上，這樣 sentinel monitor mymaster 127.0.0.1 6379 2 邏輯上沒有問題，但是如果另外伺服器上的springboot通過lettuce訪問這個redis哨兵，則得到的master地址為127.0.0.1，也就是springboot所在伺服器本機，這顯然就有問題了。
附springboot2.1 redis哨兵配置：
坑3：要注意配置文件.conf會被哨兵修改
redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。
曾經遇到過這樣一個問題，大致的信息如下
slaves莫名其妙多了一個，master的地址也明明改了真實對外的地址，這里又變成127.0.0.1 !
最後，把5個redis進程都停掉，逐個檢查配置文件，發現redis的配置文件在主從哨兵模式會被修改，master的配置文件最後邊莫名其妙多了一行replicaof 127.0.0.1 7001， 懷疑應該是之前配置錯誤的時候（見坑2）被哨兵動態加上去的！ 總之，實踐中一定要多注意配置文件的變化。
（2）集群
當數據量大到一定程度，比如幾十上百G，哨兵模式不夠用了需要做水平拆分，早些年是使用codis，twemproxy這些第三方中間件來做分片的，即 客戶端 -> 中間件 -> Redis server 這樣的模式，中間件使用一致性Hash演算法來確定key在哪個分片上。後來Redis官方提供了方案，大家就都採用官方的Redis Cluster方案了。
Redis Cluster從邏輯上分16384個hash slot，分片演算法是 CRC16(key) mod 16384 得到key應該對應哪個slot，據此判斷這個slot屬於哪個節點。
每個節點可以設置1或多個從節點，常用的是3主節點3從節點的方案。
reshard，重新分片，可以指定從哪幾個節點移動一些hash槽到另一個節點去。重新分片的過程對客戶端透明，不影響線上業務。
搭建Redis cluster
redis.conf文件關鍵的幾個配置：
啟動6個集群節點
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
這時候這6個節點還是獨立的，要把他們配置成集群：
說明： -a xxxx 是因為筆者在redis.conf中配置了requirepass xxxx密碼，然後 --cluster-replicas 1 中的1表示每個master節點有1個從節點。
上述命令執行完以後會有一個詢問： Can I set the above configuration? yes同意自動做好的分片即可。
最後 All 16384 slots covered. 表示集群中16384個slot中的每一個都有至少有1個master節點在處理，集群啟動成功。
查看集群狀態：
坑1：暴露給客戶端的節點地址不對
使用lettuce連接發現連不上，查看日誌 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里邊配置master地址犯的錯誤一樣，集群啟動的時候帶的地址應該是提供給客戶端訪問的地址。
我們要重建集群：先把6個redis進程停掉，然後刪除 nodes-7001.conf 這些節點配置文件，刪除持久化文件 mp.rdb 、 appendonly.aof ，重新啟動6個進程，在重新建立集群：
然後，還是連不上，這次報錯 connection timed out: /172.xx.0.xx:7004 ，發現連到企鵝雲伺服器的內網地址上了！
解決辦法，修改每個節點的redis.conf配置文件，找到如下說明：
所以增加配置：
然後再重新構建集群，停進程、改配置、刪除節點文件和持久化文件、啟動進程、配置集群。。。再來一套（累死了）
重新使用Lettuce測試，這次終於連上了！
坑2：Lettuce客戶端在master節點故障時沒有自動切換到從節點
name這個key在7002上，kill這個進程模擬master下線，然後Lettuce一直重連。我們期望的是應該能自動切換到其slave 7006上去，如下圖：
重新啟動7002進程，
7006已成為新master，7002成為它的slave，然後Lettuce也能連接上了。
解決辦法，修改Lettuce的配置：
筆者用的是springboot 2.1 spring-boot-starter-data-redis 默認的Lettuce客戶端，當使用Redis cluster集群模式時，需要配置一下 RedisConnectionFactory 開啟自適應刷新來做故障轉移時的自動切換從節點進行連接。
重新測試：停掉master 7006，這次Lettuce可以正常切換連到7002slave上去了。（仍然會不斷的在日誌里報連接錯誤，因為需要一直嘗試重連7006，但因為有7002從節點頂上了、所以應用是可以正常使用的）
Redis不保證數據的強一致性
Redis並不保證數據的強一致性，也就是取CAP定理中的AP
關於一致性Hash演算法，可以參考 一致性Hash演算法 - (jianshu.com)
Redis cluster使用的是hash slot演算法，跟一致性Hash演算法不太一樣，固定16384個hash槽，然後計算key落在哪個slot里邊（計算key的CRC16值再對16384取模），key找的是slot而不是節點，而slot與節點的對應關系可以通過reshard改變並通過gossip協議擴散到集群中的每一個節點、進而可以為客戶端獲知，這樣key的節點定址就跟具體的節點個數沒關系了。也同樣解決了普通hash取模演算法當節點個數發生變化時，大量key對應的定址都發生改動導致緩存失效的問題。
比如集群增加了1個節點，這時候如果不做任何操作，那麼新增加的這個節點上是沒有slot的，所有slot都在原來的節點上且對應關系不變、所以沒有因為節點個數變動而緩存失效，當reshard一部分slot到新節點後，客戶端獲取到新遷移的這部分slot與新節點的對應關系、定址到新節點，而沒遷移的slot仍然定址到原來的節點。
關於熱遷移，猜想，內部應該是先做復制遷移，等遷移完了，再切換slot與節點的對應關系，復制沒有完成之前仍按照原來的slot與節點對應關系去原節點訪問。復制結束之後，再刪除原節點上已經遷移的slot所對應的key。
與哨兵模式比較類似，當1個節點發現某個master節點故障了、會對這個故障節點進行pfail主觀宕機，然後會通過gossip協議通知到集群中的其他節點、其他節點也執行判斷pfail並gossip擴散廣播這一過程，當超過半數節點pfail時那麼故障節點就是fail客觀宕機。接下來所有的master節點會在故障節點的從節點中選出一個新的主節點，此時所有的master節點中超過半數的都投票選舉了故障節點的某個從節點，那麼這個從節點當選新的master節點。
所有節點都持有元數據，節點之間通過gossip這種二進制協議進行通信、發送自己的元數據信息給其他節點、故障檢測、集群配置更新、故障轉移授權等等。
這種去中心化的分布式節點之間內部協調，包括故障識別、故障轉移、選主等等，核心在於gossip擴散協議，能夠支撐這樣的廣播協議在於所有的節點都持有一份完整的集群元數據，即所有的節點都知悉當前集群全局的情況。
Redis高可用方案 - (jianshu.com)
面試題:Redis 集群模式的工作原理能說一下么 - 雲+社區 - 騰訊雲 (tencent.com)
深度圖解Redis Cluster原理 - detectiveHLH - 博客園 (cnblogs.com)
Redis學習筆記之集群重啟和遇到的坑-阿里雲開發者社區 (aliyun.com)
雲伺服器Redis集群部署及客戶端通過公網IP連接問題
C. Web Api及MVC性能提升的幾個小技巧
一、緩存
為了避免每次請求都去訪問後台的資源，我們一般會考慮將一些更新不是很頻繁的，可以重用的數據，通過一定的方式臨時地保存起來，後續的請求根據情況可以直接訪問這些保存起來的數據，這種機制就是所謂的緩存機制。緩存分為頁面輸出緩存，內存數據緩存和緩存依賴等。從設計原則來說，易變性、敏感性的信息不適合進行緩存，同時緩存的內容也是易丟失的，在代碼中不能完全依賴於緩存的數據，需要保證在緩存的數據丟失後也能進行正確的處理。
1、頁面輸出緩存
通過對輸出的頁面進行緩存，每次新的用戶請求調用相同的 Action 時，相同的內容不需要重新創建一次而直接輸出。頁面輸出緩存的使用非常簡單，在 Action 上使用 [OutputCache] 特性標記即可生效。頁面輸出緩存可控制緩存的內容所存儲的位置，例如是在伺服器端存儲緩存的頁面內容還是在客戶端存儲緩存的頁面內容；也可使用 Duration 參數控制緩存的失效絕對時間和間隔時間，甚至能使用 VaryByParam 參數對不同的請求參數分別進行緩存。頁面輸出緩存非常適合於內容比較固定的前端頁面的緩存。
2、內存數據緩存
通常情況下，數據是保存在資料庫、磁碟文件等存儲介質中的，而應用程序訪問這些資源是一項很費時的操作。如果先將這些資源中的數據緩存到內存緩存區中，當應用程序需要這些數據時，直接從緩存區中提取，就可以減少系統開銷，顯著提高可使用的用戶並發數等。內存數據緩存需考慮緩存的內容更改失效後如何清空其他已經被緩存的相關聯的數據問題。
3、EFCache
眾所周知，NHiberate 提供了二級緩存功能。現在，如果你使用的是 Entity Framework 6 或更高版本的 Entity Framework ，你也可考慮使用 EFCache 組件來為 Entity Framework 提供二級緩存支持，其實質上也是屬於內存數據緩存。EFCache 的特點是使用上非常方便，僅需定義如下的代碼無需其他復雜的額外的配置即可實現二級緩存。如需定義特定的緩存策略，如緩存的過期時間，控制數據緩存的范圍，也僅需繼承 CachingPolicy 類並 override 其部分方法即可。你甚至可以通過實現 ICache 介面來實現自定義的緩存模型以替換默認的 InMemoryCache 。
二、Stream壓縮
對響應流進行壓縮，其作用是減少網路開銷，提高系統的響應速度。目前的瀏覽器通常都支持 gzip 和 deflate 壓縮解壓功能，因此你通常無效考慮瀏覽器的兼容性問題。啟用 gzip 和 deflate ，既可通過 IIS 配置實現，在 MVC 中也可通過編寫自定義的 ActionFilter 實現。在壓縮之前和壓縮之後 Stream 的大小差異通常都是驚人的，其壓縮率通常都在5-10倍以上。
三、js和css文件的壓縮和打包
1、js 和 css 文件的壓縮
其實質就是生成較小的文件，減小下載這些文件的網路開銷，提供系統的響應速度。壓縮 js 和 css 文件還有個好處是通常還可以起到代碼混淆的作用。在 YbSoftwareFactory 的 MVC 解決方案中，使用的是 Microsoft Ajax Minifier 組件，可在代碼編譯的過程中自動對所配置的 js 和 css 進行壓縮，基本上文件的大小都可減少一半以上
2、js、css文件的打包
其目的是進行 js 文件和 css 文件的合並，當前主流瀏覽器的並發連接數默認情況下通常都是 6 個，如果前端頁面同時請求的伺服器資源（如 img 文件、js 文件、css 文件以及各類 url 請求等）超過6個，通常就需要進行排隊下載。進行 js 文件、css 文件的打包合並，通常可以在一次請求中就完成未打包之前需多次請求才能完成的工作，通過減少前端瀏覽器的連接請求，在某種意義上也是可提高系統的響應速度的。