最近專案一上線，就問題頗多，本地測試，ok，上線後，大使用者量的時候，頂不住。用了乙個禮拜的時間發現的問題，總結下來。
專案是netty4.0，reids2.8,nginx等框架。目前是4臺proxy伺服器，一台核心伺服器，reids只部署在核心伺服器上，各**伺服器共享redis資料。
當大量使用者訪問自己距離較近的proxy伺服器時，proxy同時請求核心伺服器，併發量到1w時，經常請求卡死，網頁請求不回來，開始從netty的http處理併發下手，各種netty的官網，netty的優化，和配置，都修改了，還是沒有起作用，後來遮蔽redis後，發現netty處理20w併發一點問題沒有，問題確定在redis上。
然後，著手redis的優化，redis的池的優化，配置，沒有作用，後台發現，本地訪問redis併發1w，很快，但是，訪問其他伺服器的redis特別卡，發現原因，就在於，跨伺服器訪問redis，可能由於網路，跨伺服器，導致的併發請求redis，回不來的問題，那麼，最後，捨棄了proxy伺服器遠端呼叫核心伺服器reids的方案，nginx改為所有心跳請求，跨過proxy伺服器，直接走核心伺服器，這樣相當於本地訪問redis，最後擔心核心伺服器併發能力，暫時，開啟了2個服務，處理所有併發，reids問題得到解決。
總結：就是reids本身效能沒有問題，處理併發能力ok，就是跨伺服器遠端訪問其他伺服器reids時，併發大了，網路延遲等，會出現取reids卡死。
redis
2015-05-10 09:51:44 發布
您的評價:
0.0收藏 0收藏
redis是乙個非常高效的基於記憶體的nosql資料庫,它提供非常高效的資料讀寫效能.在實際應用中往往是頻寬和client庫讀寫損耗過高導致無法更好地發揮出redis更出色的能力.下面結合一些redis本身的特性和一些client操作上的改變來提高整個redis操作的效能.
上圖是反映平常操作redis的情況,每個執行緒都獨立的發起相應連線對redis的網路讀寫.雖然我們可以通過批操作的方式來把當前多個操作合併成乙個,但這種方式只能針對當單執行緒,而多執行緒相互合併則設計上很少關注.從redis的協議來說其實並沒有限制,只是在client庫的設計一般沒有考慮進去.
如果在多執行緒操作redis的同時如果能夠合併網路操作,那意味著可以減少操作網路讀寫的情況把處理能力提公升到最大化.這樣client總體的效能都會有所提公升,而redis也因表層的網路讀取減少而達到更好的利用率.
以上是設計圖,原理並不複雜,其實就是把每個請求的操作放到乙個佇列中,後面開啟乙個執行緒來把前面的指令進行乙個合併操操作.乙個執行緒在高併發下可以無法更快速地合併起來,可以根據需要進行合理的操作執行緒應用.
這種設計的效果是否真的比較理想呢,以下是乙個簡單的測試
public void anycset()測試結果如下);});
});}
public void set()
);});
});}
以上是10w次的操作測試結果,由於redis在本機所以互動非常可觀.
雖然在多執行緒高併發下這樣的設計可以把吞吐能力和效能有乙個非常不錯的效果,但其也存在缺陷因為每次操作都經過不同執行緒的調處理,如果併發執行緒不多操作密集度不高.那效果並不理想;因為網路操作密集度不高,可得到並合的數量不多,這方面的損耗有可能低於操作跨執行緒排程所帶來的損耗.
cocoa併發訪問Sqlite中的死鎖問題
在實際開發過程中，如果涉及到資料庫的頻繁寫入，更新等操作，在加上連續事件的有序操作，死鎖的問題就可能發生 廢話不多說了 開發中使用最多sqlite三方庫是fmdb，最新版本的fmdb為了支援併發，加入了fmdatabasequeue，其原理就是對乙個databse的訪問，通過內部的乙個serialq...
使用Windows XP訪問共享時出現的問題解決
好多xp系統啟用了guest也無法網路訪問，故障解決如下 啟用了guest為什麼仍然不能訪問 1.預設情況下，xp 禁用guest帳戶 2.預設情況下，xp的本地安全策略禁止guest使用者從網路訪問 3.預設情況下，xp的本地安全策略 使用者許可權指派裡，空密碼使用者只能進行控制台登陸 是啟用的，...
Oracle 資料庫中不同事務併發訪問的問題
現象 以sql helper為例，開啟不同的sql視窗，對同乙個 進行操作，如下所示。視窗1 當執行更新任務 緊接著執行查詢時獲得一組查詢結果。結果是對的。視窗2 而在另外乙個sql查詢視窗中執查詢，卻得到更新前的結果。當關閉視窗1時，執行視窗2，發現出現正確的更新結果。分析 初步分析是資料庫的併發...