redis每秒只有100次存取怎麼辦?

02-04

剛剛接觸redis，不太了解，請問一個問題。
我需要用redis實現一個分散式id自增的功能。
我用jedis客戶端分片, 然後存取數據的時候發現每秒只能set或get大約100次（100次是因為我筆記本用wifi連的伺服器，ping延遲平均為5ms, 要是連我同一台電腦上的redis則能到達1800次）

就算是1800次存取，感覺速度也不太理想。使用pipeline的話可以輕鬆1秒幾萬。
所以，我的問題就是：
1. 有什麼辦法能提升存取速度嗎？（我翻了一些資料，沒有找到好的解決方案）
2. 使用pipeline之類的技術，可以實現分散式id自增的功能嗎？

自然是可以的，只不過需要一些編程技巧，你現在是被roundtrip time拖慢了，這是很正常的事情，真正的業務環境中也會遇到，解決的方案就是引入並發機制。

有兩種實現方式，簡單的一種是使用多線程，當你業務跑在100個線程的線程池裡的時候，每個線程都會有100左右的請求速率（qps），合計就有上萬，一般來說這也同時意味著要建立100個連接。

另一種是非同步轉接的方式，這種方法可以只使用一個連接，但是需要一些稍複雜的編程技巧。這個技巧在於將redis命令的調用轉換成非同步的方式。用兩個線程處理同一個redis連接，一個線程接收來自程序內部的請求，每個請求由一個redis命令和一個回調對象（callback）組成，將回調存進一個先進先出的隊列里，然後調用sendcommand將請求發出，然後不等待命令返回馬上去處理其他的請求；另一個線程讀取redis連接的返回值，然後從隊列中取出一個回調對象，調用這個回調對象的方法，通知請求方redis命令已經完成。可以在這個回調函數中使用wait/notifyall的方法喚醒請求的線程，實現多線程到非同步回調的轉接，如果業務不複雜的話直接在回調函數里實現剩下的業務也可以。從連接的角度看實際上就是運用了pipeline。

兩種方法的核心思想都在於不要等待上一個請求返回，而是儘可能多發送請求，這樣就不受到roundtrip的限制了。

既然測試環境是奇怪的低端民用設備，而且還是wifi這種奇怪的娛樂通信方式，那麼測試結果性能低地奇怪，這有什麼值得奇怪的？

網路延遲太大，非要測試的話，請使用批量 Set / Get 試試，相信會提升很多，你就會理解為什麼了

靈劍的方法，並且改為使用Incr，不要getset

你好，請問你這個1800是怎麼得出的

延遲五秒，只算來回通信，一秒鐘最多也就200個請求，要想速度快點可以用多線程鏈接池