asp.net core 实战之 redis 负载均衡和quot;高可用quot;实现
1.概述
分布式系統緩存已經變得不可或缺,本文主要闡述如何實現redis主從復制集群的負載均衡,以及 redis的"高可用"實現, 呵呵雙引號的"高可用"并不是傳統意義的高可用哈,而是 redis集群掛了,并不影響asp.net core 的運行, 欲知詳情,請看下文.
注意:?本文主要闡述redis 的復制均衡和"高可用", 故redis 的主從復制搭建略, 請自行百度.
2.負載均衡實現
目前在tcp 負載均衡這塊, haproxy 是官方實現, nginx 是三方實現, 個人偏向haproxy的簡單易用. 故redis的負載均衡采用haproxy實現.
Haproxy配置文件如下:
globallog 127.0.0.1 local2 #log語法:log <address_1>[max_level_1] # 全局的日志配置,使用log關鍵字,指定使用127.0.0.1 上的syslog服務中的local0日志設備,記錄日志等級為info的日志chroot /var/lib/haproxy ? ? ? ? ? #當前工作目錄pidfile /var/run/haproxy.pid ? ? #當前進程id文件maxconn 6000 ? ? ?#最大并發連接數user haproxy ? ? #所屬用戶group haproxy ? ? #所屬組daemon ? ? ? ? ? ? #以守護進程方式運行haproxystats socket /var/lib/haproxy/stats defaultsmode http ? ? #默認的模式mode { tcp|http|health },tcp是4層,http是7層,health只會返回OKlog global ? ?#應用全局的日志配置option httplog ? ?#啟用日志記錄HTTP請求,默認haproxy日志記錄是不記錄HTTP請求日志option dontlognull ? ?# 啟用該項,日志中將不會記錄空連接。所謂空連接就是在上游的負載均衡器或者監控系統為了探測該 服務是否存活可用時,需要定期的連接或者獲取某一固定的組件或頁面,或者探測掃描端口是否在監聽或開放等動作被稱為空連接;官方文檔中標注,如果該服務上游沒有其他的負載均衡器的話,建議不要使用該參數,因為互聯網上的惡意掃描或其他動作就不會被記錄下來option http-server-close ?#每次請求完畢后主動關閉http通道option forwardfor except 127.0.0.0/8 #如果服務器上的應用程序想記錄發起請求的客戶端的IP地址,需要在HAProxy上 配置此選項, 這樣 HAProxy會把客戶端的IP信息發送給服務器,在HTTP請求中添加"X-Forwarded-For"字段。 啟用 X-Forwarded-For,在requests頭部插入客戶端IP發送給后端的server,使后端server獲取到客戶端的真實IP。option redispatch ? # 當使用了cookie時,haproxy將會將其請求的后端服務器的serverID插入到cookie中,以保證會話的SESSION持久性;而此時,如果后端的服務器宕掉了, 但是客戶端的cookie是不會刷新的,如果設置此參數,將會將客戶的請求強制定向到另外一個后端server上,以保證服務的正常。retries 3 ? ? ? # 定義連接后端服務器的失敗重連次數,連接失敗次數超過此值后將會將對應后端服務器標記為不可用timeout http-request 10s ? ? #http請求超時時間timeout queue 1m ? ? ? ? ? ? #一個請求在隊列里的超時時間timeout connect 10s ? ? ? ? ? ?#連接超時timeout client 1m ? ? ? ? ? ?#客戶端超時timeout server 1m ? ? ? ? ? ?#服務器端超時timeout http-keep-alive 10s #設置http-keep-alive的超時時間timeout check 10s ? ? ? ? ? ?#檢測超時maxconn 6000 ? ? ? ? ? ? ? ?#每個進程可用的最大連接數 listen stats ? ? #統計界面mode httpbind *:2080 ? ?stats enable stats refresh 30sstats uri /hastatsstats realm Haproxy\ Statistics ?stats auth admin:adminstats admin if TRUE frontend healthcheckbind :1099 ? ? #定義外部檢測機制mode http ? ?#http 負載均衡option httpcloseoption forwardfordefault_backend AnuoApcNodes frontend http-inbind *:88 #監聽的端口,處理請求的服務器集群為 default_backend 的配置值mode http log globaloption httpcloseoption logasap #不等待響應結束就記錄日志,表示提前記錄日志,一般日志會記錄響應時長,此不記錄響應時長option dontlognull #不記錄空信息capture request header Host len 20 #記錄請求首部的前20個字符capture request header Referer len 60 #referer跳轉引用,就是上一級default_backend AnuoApcNodes #處理請求的服務器集群 backend AnuoApcNodes ? ? #處理請求的服務器集群mode httpbalance roundrobin#check : 下面的check 表示ha 需要檢查此節點的狀態server websrv1 192.168.2.108:9090 check maxconn 6000server websrv2 192.168.1.112:88 check maxconn 6000listen SQLServer :1433 ?#tcp 負載均衡mode tcpbalance roundrobin#weight : 權重, 表示此節點的優先級,值越高(最高256) , 優先執行越高#check port : 檢測是否存活的端口#inter : interval 檢測是否存活的 時間間隔#rise : server 從離線狀態轉為正常狀態后, 需要復查的次數(看是否正常)#fall : server 從正常狀態轉換為不可用狀態需要檢查的次數server SQLServer1 192.168.2.101:1433 weight 1 maxconn 6000 check port 1433 inter 2000 rise 2 fall 2server SQLServer2 192.168.2.203:1433 weight 1 maxconn 6000 check port 1433 inter 2000 rise 2 fall 2listen Redis :6377 ?#tcp 負載均衡mode tcpbalance roundrobin#weight : 權重, 表示此節點的優先級,值越高(最高256) , 優先執行越高#check port : 檢測是否存活的端口#inter : interval 檢測是否存活的 時間間隔#rise : server 從離線狀態轉為正常狀態后, 需要復查的次數(看是否正常)#fall : server 從正常狀態轉換為不可用狀態需要檢查的次數server Redis1 192.168.2.101:6379 weight 1 maxconn 6000 check port 6379 inter 2000 rise 2 fall 2server Redis2 192.168.2.102:6379 weight 1 maxconn 6000 check port 6379 inter 2000 rise 2 fall 2其中最后的配置:
為redis的負載均衡配置, 可以看到負載了兩個redis IP, 101和102 .
在實際運行中, redis的主庫一般用作寫, 從庫用作讀, so , 一般針對redis的從庫進行負載.
只需將上面的兩個IP 替換為自己的ip 即可完成對 redis 從庫的負載.
3. asp.net core 端針對 redis?"高可用"實現
實現思路: 此處的實現不是傳統意義的高可用實現,而是C#端檢測到redis集群掛了, 自動將redis從系統中剔除, 保證asp.net core 能繼續運行
業界問題: redis 的高可用有官方實現叫sentinel , 現在應用案例并不多, 也逮到官方文檔看了哈, 看了半天沒看到, 有sentinel實戰教程推薦的,或其他高可用實現的, 望留言 ^_^
先下載完整源碼:?http://pan.baidu.com/s/1i52ViWP
源碼配置運行步驟如下:
如下圖
?
3.1.配置VIPPort的值為 haproxy 暴露的redis 集群端口,如下圖值
3.2.配置ClusterVIPCom值為 haproxy 所在服務器?的 IP
3.3.配置ClusterMultiIPCom 值為 redis主從復制集群中的全部從庫IP, 用分號分割IP
3.4. 代碼運行起來, 調用 Sample 接口, 如下圖
調用URL: Get方法? http://localhost:9526/api/RedisTest/Sample
運行邏輯如下:
第一次取數據, redis沒得緩存, 制造緩存對象, 緩存到redis,?成功返回.
第二次取數據, redis 有緩存, 從緩存中取, 成功返回.
第三次取數據, 假如redis掛了, 制造緩存對象, 還是成功返回.
第四次取數據, redis恢復了, 重啟 asp.net core , ?程序自動連接上redis, 從redis返回數據, 成功返回.?
至此達到了, redis 和 asp.net core 的完全解耦, 即redis掛了不影響 asp.net core 的繼續運行 .
可以想象哈, 當你半夜收到一個警報說redis掛了的時候, 你可以不慌不忙的去公司慢慢改, 因為asp.net core 還在運行, 只是慢了點而已.
原文地址:http://www.cnblogs.com/anuo/p/6052029.html
.NET社區新聞,深度好文,微信中搜索dotNET跨平臺或掃描二維碼關注
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的asp.net core 实战之 redis 负载均衡和quot;高可用quot;实现的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Stateless 3.0——.NET
- 下一篇: asp.net core 负载均衡集群搭