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上。