658
Redis開發運維實踐開發者設計規範之延遲考慮
4.5 延遲考慮
1. 盡可能使用批量操作：
- mget、hmget而不是get和hget，對於set也是如此。
- lpush向一個list一次性導入多個元素，而不用lset一個個添加
- LRANGE 一次取出一個範圍的元素，也不用LINDEX一個個取出
2. 盡可能的把redis和APP SERVER部署在一個網段甚至一台機器。
3. 對於數據量較大的集合，不要輕易進行刪除操作，這樣會阻塞服務器，一般采用重命名+批量刪除的策略：
排序集合：
# Rename the key
newkey = "gc:hashes:" + redis.INCR("gc:index")
redis.RENAME("my.zset.key", newkey)
# Delete members from the sorted set in batche of 100s
while redis.ZCARD(newkey) > 0
redis.ZREMRANGEBYRANK(newkey, 0, 99)
end
集合：
# Rename the key
newkey = "gc:hashes:" + redis.INCR("gc:index")
redis.RENAME("my.set.key", newkey)
# Delete members from the set in batches of 100
cursor = 0
loop
cursor, members = redis.SSCAN(newkey, cursor, "COUNT", 100)
if size of members > 0
redis.SREM(newkey, members)
end
if cursor == 0
break
end
end
列表：
# Rename the key
newkey = "gc:hashes:" + redis.INCR("gc:index")
redis.RENAME("my.list.key", newkey)
# Trim off elements in batche of 100s
while redis.LLEN(newkey) > 0
redis.LTRIM(newkey, 0, -99)
end
Hash：
# Rename the key
newkey = "gc:hashes:" + redis.INCR( "gc:index" )
redis.RENAME("my.hash.key", newkey)
# Delete fields from the hash in batche of 100s
cursor = 0
loop
cursor, hash_keys = redis.HSCAN(newkey, cursor, "COUNT", 100)
if hash_keys count > 0
redis.HDEL(newkey, hash_keys)
end
if cursor == 0
break
end
end
4. 盡可能使用不要超過1M大小的kv。
5. 減少對大數據集的高時間複雜度的操作：根據複雜度計算，如下命令可以優化:
6. 盡可能使用pipeline操作：一次性的發送命令比一個個發要減少網絡延遲和單個處理開銷。一個性能測試結果為（注意並不是pipeline越大效率越高，注意最後一個測試結果） :
logger@BIGD1TMP:~> redis-benchmark -q -r 100000 -n 1000000 -c 50 PING_INLINE: 90155.07 requests per second PING_BULK: 92302.02 requests per second SET: 85070.18 requests per second GET: 86184.61 requests per second logger@BIGD1TMP:~> redis-benchmark -q -r 100000 -n 1000000 -c 50 -P 10 PING_INLINE: 558035.69 requests per second PING_BULK: 668002.69 requests per second SET: 275027.50 requests per second GET: 376647.84 requests per second logger@BIGD1TMP:~> redis-benchmark -q -r 100000 -n 1000000 -c 50 -P 20 PING_INLINE: 705716.25 requests per second PING_BULK: 869565.25 requests per second SET: 343406.59 requests per second GET: 459347.72 requests per second logger@BIGD1TMP:~> redis-benchmark -q -r 100000 -n 1000000 -c 50 -P 50 PING_INLINE: 940733.81 requests per second PING_BULK: 1317523.00 requests per second SET: 380807.31 requests per second GET: 523834.47 requests per second logger@BIGD1TMP:~> redis-benchmark -q -r 100000 -n 1000000 -c 50 -P 100 PING_INLINE: 999000.94 requests per second PING_BULK: 1440922.12 requests per second SET: 386996.88 requests per second GET: 602046.94 requests per second logger@BIGD1TMP:~> redis-benchmark -q -r 100000 -n 1000000 -c 50 -P 200 PING_INLINE: 1078748.62 requests per second PING_BULK: 1381215.50 requests per second SET: 379218.81 requests per second GET: 537634.38 requests per second
一個場景是一個購物車的設計，一般的設計思路是：
在獲取購物車內部貨品時，不使用pipeline會很低效： 
可以修改為： 
7. 如果出現頻繁對string進行append操作，則請使用list進行push操作，取出時使用pop。這樣避免string頻繁分配內存導致的延時。
8. 如果要sort的集合非常大的話排序就會消耗很長時間。由於redis單線程的，所以長時間的排序操作會阻塞其他client的 請求。解決辦法是通過主從複製機製將數據複製到多個slave上。然後我們隻在slave上做排序操作。把可能的對排序結果緩存。另外就是一個方案是就是采用sorted set對需要按某個順序訪問的集合建立索引。
最後更新：2017-05-08 10:31:37