在redis一致性hash(shard)中使用lua腳本的坑

     redis 2.8以前的版本，爲了實現支持巨量數據緩存或者持久化，通常須要經過redis sharding模式來實現redis集羣，廣泛你們使用的是twitter開源的Twemproxy。

twemproxy不會增長redis的性能指標數據，據業界測算，使用twemproxy相比直接使用redis會帶來~10%的性能降低。   可是單個redis進程的內存管理能力有限。據測算，單個redis進程內存超過20G以後，效率會急劇降低。目前，咱們給出的建議值是單個redis最好配置在8G之內。8G以上的redis緩存需求，經過twemproxy來提供支持。

twemproxy

不會增長

redis

的性能指標數據，

據業界測算，

使用

twemproxy

相比直接使用

redis

會帶來

~10%

的性能降低。

 

 

可是單個

redis

進程的內存管理能力有限。

據測算，

單個

redis

進程內存超過

20G

以後，

效率

會急劇降低。目前，咱們給出的建議值是單個

redis

最好配置在

8G

之內。

8G

以上的

redis

緩存需求，經過

twemproxy

來提供支持。

     twemproxy的配置信息填寫在nutcracker.yml之中，默認的查找位置是在conf目錄下，也能夠經過-c參數指定。舉個栗子：

twem1:

  listen:"127.0.0.1:22121"

  hash:fnv1a_64

  distribution:ketama

  auto_eject_hosts:false

  server_failure_limit:1

  server_retry_timeout:60000

  redis:true

  servers:

   -"IP1:6379:1 shard1-master"

     你編譯或者下載個老版本的ServiceStack.Redis組件（新版本收費了，有貌似1小時6000次的上限，https://servicestack.net/）。而後呢，你能夠安心的讀寫redis了，看起來一切都很美好，某一天發現爲了更新一個值，須要頻繁的讀寫redis，這不科學，因而你繼續發掘，發現redis支持lua腳本，不少事務性的操做能夠直接交給lua腳本一次完成，分分鐘改改代碼，發個新版本，一些看起來又安逸了。

     忽然，客服投訴來啦，說某個數據值不對，查數據庫，數據正確的。查redis，哎~果真不對，redis沒更新（假設redis是用來作緩存的，mysql作持久化），難道刪除redis key更新緩存的方法有問題？你劃拉代碼看看沒啥問題，傳遞一批key讓lua腳本循環刪掉這些key，從而達到過時緩存的目的，代碼簡單，流程清晰。RedisDesktopManager直連redis刪除key，ok的，調試代碼，的確大概有一半的redis key刪除不掉，此時你就掉到redis sharding模型下執行lua腳本的坑裏了。

坑：redis sharding模型下執行lua腳本時，假設key1在shard1，lua+key1可不必定在shard1。

　　即，在proxy上對key1 get/set時，Twemproxy對key1哈希計算後會保證分配到固定的shard上，但經過代理調用lua腳本批量處理redis key時，哈希散列可能落在不一樣的shard上。