您现在的位置是:Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款 >
02 redis 發布訂閱會自己阻塞嗎(Redis發布訂閱和Stream)
Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款2024-06-27 07:52:07【】0人已围观
简介p>StringjsonStr=object.getString("jsonStr");if(jsonStr!=null&&!"".equals(jsonStr
String jsonStr = object.getString("jsonStr");
if(jsonStr!=null&&!"".equals(jsonStr)){
JSONObject json = JSONObject.parseObject(object.getString("jsonStr"));
for(String key:json.keySet()){
String value = json.getString(key);
SystemConfig systemConfig = SystemConfigContainer.instance().getSystemConfig(key);
if(systemConfig!=null){
systemConfig.setKeyValue(value);
SystemConfigContainer.instance().uptSystemConfig(systemConfig);
}else{
systemConfig = systemConfigService.selectByPrimaryJianMing(key);
systemConfig.setKeyValue(value);
SystemConfigContainer.instance().uptSystemConfig(systemConfig);
}
}
}
}
}
}
redis主要解決了什么問題
Redis 常見的性能問題和解決方法
1.Master寫內存快照
save命令調度rdbSave函數,會阻塞主線程的工作,當快照比較大時對性能影響是非常大的,會間斷性暫停服務,所以Master最好不要寫內存快照。
2.Master AOF持久化
如果不重寫AOF文件,這個持久化方式對性能的影響是最小的,但是AOF文件會不斷增大,AOF文件過大會影響Master重啟的恢復速度。
3.Master調用BGREWRITEAOF
Master調用BGREWRITEAOF重寫AOF文件,AOF在重寫的時候會占大量的CPU和內存資源,導致服務load過高,出現短暫服務暫停現象。
下面是我的一個實際項目的情況,大概情況是這樣的:一個Master,4個Slave,沒有Sharding機制,僅是讀寫分離,Master負責寫入操作和AOF日志備份,AOF文件大概5G,Slave負責讀操作,當Master調用BGREWRITEAOF時,Master和Slave負載會突然陡增,Master的寫入請求基本上都不響應了,持續了大概5分鐘,Slave的讀請求過也半無法及時響應,Master和Slave的服務器負載圖如下:
Master Server load:
Slave server load:
上面的情況本來不會也不應該發生的,是因為以前Master的這個機器是Slave,在上面有一個shell定時任務在每天的上午10點調用BGREWRITEAOF重寫AOF文件,后來由于Master機器down了,就把備份的這個Slave切成Master了,但是這個定時任務忘記刪除了,就導致了上面悲劇情況的發生,原因還是找了幾天才找到的。
將no-appendfsync-on-rewrite的配置設為yes可以緩解這個問題,設置為yes表示rewrite期間對新寫操作不fsync,暫時存在內存中,等rewrite完成后再寫入。最好是不開啟Master的AOF備份功能。
4.Redis主從復制的性能問題
第一次Slave向Master同步的實現是:Slave向Master發出同步請求,Master先mp出rdb文件,然后將rdb文件全量傳輸給slave,然后Master把緩存的命令轉發給Slave,初次同步完成。第二次以及以后的同步實現是:Master將變量的快照直接實時依次發送給各個Slave。不管什么原因導致Slave和Master斷開重連都會重復以上過程。Redis的主從復制是建立在內存快照的持久化基礎上,只要有Slave就一定會有內存快照發生。雖然Redis宣稱主從復制無阻塞,但由于Redis使用單線程服務,如果Master快照文件比較大,那么第一次全量傳輸會耗費比較長時間,且文件傳輸過程中Master可能無法提供服務,也就是說服務會中斷,對于關鍵服務,這個后果也是很可怕的。
以上1.2.3.4根本問題的原因都離不開系統io瓶頸問題,也就是硬盤讀寫速度不夠快,主進程 fsync()/write() 操作被阻塞。
5.單點故障問題
由于目前Redis的主從復制還不夠成熟,所以存在明顯的單點故障問題,這個目前只能自己做方案解決,如:主動復制,Proxy實現Slave對Master的替換等,這個也是Redis作者目前比較優先的任務之一,作者的解決方案思路簡單優雅,詳情可見 Redis Sentinel design draft
總結
Master最好不要做任何持久化工作,包括內存快照和AOF日志文件,特別是不要啟用內存快照做持久化。
如果數據比較關鍵,某個Slave開啟AOF備份數據,策略為每秒同步一次。
為了主從復制的速度和連接的穩定性,Slave和Master最好在同一個局域網內。
盡量避免在壓力較大的主庫上增加從庫
為了Master的穩定性,主從復制不要用圖狀結構,用單向鏈表結構更穩定,即主從關系為:Master<–Slave1<–Slave2<–Slave3…….,這樣的結構也方便解決單點故障問題,實現Slave對Master的替換,也即,如果Master掛了,可以立馬啟用Slave1做Master,其他不變。
redis頻道收到發布者信息后可以只推信息給一個訂閱者嗎
Redis 的 SUBSCRIBE 命令可以讓客戶端訂閱任意數量的頻道, 每當有新信息發送到被訂閱的頻道時, 信息就會被發送給所有訂閱指定頻道的客戶端。
作為例子, 下圖展示了頻道 channel1 , 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關系:
很赞哦!(2)
相关文章
- 02 平安遼寧買粉絲二維碼(買粉絲支付綁定銀行卡支持哪個銀行)
- tiktokbaby歌詞寓意(tiktokbaby歌曲講的是什么)
- 02 幫粉絲在貓市買貓(小貓的資料)
- 02 年貨備貨圖片(你在直播間買東西見過哪些套路?)
- tiktokapp最新版本下載(iphone怎么下載tiktok)
- tiktokbaby歌曲抖音(tiktokbaby歌曲原型)
- 02 干凈治愈ins風的文案(有哪些ins風格的文案?)
- tiktok2023年數據報告(2023年想做Tiktok,請問一下2023Tiktok行業怎么樣?有什么優勢和入門門檻怎么樣?)
- tiktok18+怎么認證(抖音發不了新作品,是不是需要好友輔助驗證?)
- tiktok2021版本(tik tok是什么意思)
Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款的名片
职业:程序员,设计师
现居:黑龙江省双鸭山饶河县
工作室:小组
Email:[email protected]