如各位所看到,目前網站右側的新鮮事列表出現了些異常,這是由於我們使用的redis驅動的某個錯誤造成的。現在這個錯誤已經被排除,但是由此引申了我對Redis使用場合的一些思考
以上是我想到的一些應用場景,這種使用是否合理。還有其它應用場景嗎?
走同样的路,发现不同的人生
我們使用sorted set來做排名系統 比傳統的實作方式簡單非常多
我們使用redis來統計文章的訪問量,產生昨天點擊排行,本月點擊排行等數據. 性能非常好,缺點就是機器內在迅速不夠用了.我們的解決方案是,同時往寫兩台,每過一段時間將其中一台的數據清零.
redis現在的發展受作者的影響太大。他的milestone沒有規劃的特別好,導致每個版本之間的差異很大,沒有一致性。 使用下來覺得queue很有用。然後做一些計數器確實不錯。 覺得redis應該要改進的地方: 分散式的支持,其實只用跟memcached一樣在客服端支援就行。 VM這些特性到底有沒有用? redis的php驅動下來感覺不錯phpredis。
最近在專案中使用redis 1.List做訊息隊列 2.Sorted Sets做一些交/並集運算(兩個使用者的好友列表 交集 得出共同好友等)
我們在效能要求高的應用中大量的使用了redis,而且主要用了redis的sorted set、hastset、pub/sub這些資料結構。 基本上在前台(面向最終用戶的應用)中替代關係型資料作為資料持久化的儲存服務,當然在redis後面還是有其他的資料儲存產品作為最終資料備份。
說說我用到的Redis幾個特性:bitset, hashset, sorted set, pub/sub, k-v快取
這是由於我們使用的redis驅動的某個錯誤造成的。現在這個錯誤已經被排除,
方便談談這個錯誤嗎? 想具體了解一下。
我們使用sorted set來做排名系統 比傳統的實作方式簡單非常多
我們使用redis來統計文章的訪問量,產生昨天點擊排行,本月點擊排行等數據.
性能非常好,缺點就是機器內在迅速不夠用了.我們的解決方案是,同時往寫兩台,每過一段時間將其中一台的數據清零.
redis現在的發展受作者的影響太大。他的milestone沒有規劃的特別好,導致每個版本之間的差異很大,沒有一致性。
使用下來覺得queue很有用。然後做一些計數器確實不錯。
覺得redis應該要改進的地方:
分散式的支持,其實只用跟memcached一樣在客服端支援就行。
VM這些特性到底有沒有用?
redis的php驅動下來感覺不錯phpredis。
最近在專案中使用redis
1.List做訊息隊列
2.Sorted Sets做一些交/並集運算(兩個使用者的好友列表 交集 得出共同好友等)
我們在效能要求高的應用中大量的使用了redis,而且主要用了redis的sorted set、hastset、pub/sub這些資料結構。
基本上在前台(面向最終用戶的應用)中替代關係型資料作為資料持久化的儲存服務,當然在redis後面還是有其他的資料儲存產品作為最終資料備份。
說說我用到的Redis幾個特性:bitset, hashset, sorted set, pub/sub, k-v快取
方便談談這個錯誤嗎? 想具體了解一下。