收集了一些網絡文章，並把一些關注的內容提了出來。
1. 新浪微博：史上最大的Redis集羣
1）Redis平臺實際情況：
2200+億 commands/day 5000億Read/day 500億Write/day
18TB+ Memory
500+ Servers in 6 IDC 2000+instances
2）Redis使用的重要點
1.rdb/aof Backup!
我們線上的Redis 95%以上是承擔後端存儲功能的，我們不僅用作cache，而更爲一種k-v存儲，他完全替代了後端的存儲服務（MySQL），故其數據是非常重要的，如果出現數據污染和丟失，誤操作等情況，將是難以恢復的。所以備份是非常必要的！爲此，我們有共享的hdfs資源作爲我們的備份池，希望能隨時可以還原業務所需數據。
2.Small item & Small instance!
由於Redis單線程（嚴格意義上不是單線程，但認爲對request的處理是單線程的）的模型，大的數據結構list,sorted set,hash set的批量處理就意味着其他請求的等待，故使用Redis的複雜數據結構一定要控制其單key-struct的大小。
另外，Redis單實例的內存容量也應該有嚴格的限制。單實例內存容量較大後，直接帶來的問題就是故障恢復或者Rebuild從庫的時候時間較長，而更糟糕的是，Redis rewrite aof和save rdb時，將會帶來非常大且長的系統壓力，並佔用額外內存，很可能導致系統內存不足等嚴重影響性能的線上故障。我們線上96G/128G內存服務器不建議單實例容量大於20/30G。
二、一些數據
1. In Redis 2.6 this limit is dynamic: by default is set to 10000 clients, unless otherwise stated by the maxmemory directive
in Redis.conf. (From Redis home site)
When Redis is configured in order to handle a specific number of clients it is a good idea to make sure that the operating system limit to the maximum number of file descriptors per process is also set accordingly.
Under Linux these limits can be set both in the current session and as a system-wide setting with the following commands:
- ulimit -Sn 100000 # This will only work if hard limit is big enough.
- sysctl -w fs.file-max=100000
2. 影響性能的因素。（來源：redis的官方網站）
a) 網絡帶寬和延時
b) CPU的性能，由於是單線程，因此最好是快的CPU和大的內存
c) RAM的速度