Redis 使用的 10 个小技巧

Redis 在当前的技术社区里是很是热门的。历来自 Antirez 一个小小的我的项目到成为内存数据存储行业的标准，Redis已经走过了很长的一段路。

随之而来的一系列最佳实践，使得大多数人能够正确地使用 Redis。

下面咱们将探索正确使用 Redis 的10个技巧。

一、中止使用 KEYS *

Okay，以挑战这个命令开始这篇文章，或许并非一个好的方式，但其确实多是最重要的一点。

不少时候当咱们关注一个redis实例的统计数据，咱们会快速地输入”KEYS *”命令，这样key的信息会很明显地展现出来。平心而论，从程序化的角度出发每每倾向于写出下面这样的伪代码：

for key in 'keys *':  doAllTheThings() 

可是当你有1300万个key时，执行速度将会变慢。由于KEYS命令的时间复杂度是O(n)，其中n是要返回的keys的个数，这样这个命令的复杂度就取决于数据库的大小了。而且在这个操做执行期间，其它任何命令在你的实例中都没法执行。

做为一个替代命令，看一下 SCAN 吧，其容许你以一种更友好的方式来执行… SCAN 经过增量迭代的方式来扫描数据库。这一操做基于游标的迭代器来完成的，所以只要你以为合适，你能够随时中止或继续。

二、找出拖慢 Redis 的罪魁祸首

因为 Redis 没有很是详细的日志，要想知道在 Redis 实例内部都作了些什么是很是困难的。幸运的是 Redis 提供了一个下面这样的命令统计工具：

127.0.0.1:6379> INFO commandstats # Commandstats cmdstat_get:calls=78,usec=608,usec_per_call=7.79  cmdstat_setex:calls=5,usec=71,usec_per_call=14.20  cmdstat_keys:calls=2,usec=42,usec_per_call=21.00  cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

经过这个工具能够查看全部命令统计的快照，好比命令执行了多少次，执行命令所耗费的毫秒数(每一个命令的总时间和平均时间)

只须要简单地执行 CONFIG RESETSTAT 命令就能够重置，这样你就能够获得一个全新的统计结果。

三、 将 Redis-Benchmark 结果做为参考，而不要一律而论

Redis 之父 Salvatore 就说过：“经过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。不少时候人们跑到我这里，他们想知道为何本身的Redis-Benchmark统计的结果低于最优结果 。但咱们必需要把各类不一样的真实状况考虑进来，例如：

• 可能受到哪些客户端运行环境的限制？
• 是同一个版本号吗？
• 测试环境中的表现与应用将要运行的环境是否一致？

Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点，可是你永远不要把它做为一个真实的“压力测试”。压力测试须要反应出应用的运行方式，而且须要一个尽量的和生产类似的环境。

四、Hashes 是你的最佳选择

以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种史无前例的体验。以前我曾看到过许多相似于下面这样的key结构：

foo:first_name foo:last_name foo:address 

上面的例子中，foo 多是一个用户的用户名，其中的每一项都是一个单独的 key。这就增长了 犯错的空间，和一些没必要要的 key。使用 hash 代替吧，你会惊奇地发现居然只须要一个 key ：

127.0.0.1:6379> HSET foo first_name "Joe"  (integer) 1  127.0.0.1:6379> HSET foo last_name "Engel"  (integer) 1  127.0.0.1:6379> HSET foo address "1 Fanatical Pl"  (integer) 1  127.0.0.1:6379> HGETALL foo 1) "first_name"  2) "Joe"  3) "last_name"  4) "Engel"  5) "address"  6) "1 Fanatical Pl"  127.0.0.1:6379> HGET foo first_name "Joe" 

五、设置 key 值的存活时间

不管何时，只要有可能就利用key超时的优点。一个很好的例子就是储存一些诸如临时认证key之类的东西。

当你去查找一个受权key时——以OAUTH为例——一般会获得一个超时时间。这样在设置key的时候，设成一样的超时时间，Redis就会自动为你清除！而再也不须要使用KEYS *来遍历全部的key了，怎么样很方便吧？

六、 选择合适的回收策略

既然谈到了清除key这个话题，那咱们就来聊聊回收策略。当 Redis 的实例空间被填满了以后，将会尝试回收一部分key。根据你的使用方式，我强烈建议使用 volatile-lru 策略——前提是你对key已经设置了超时。

但若是你运行的是一些相似于 cache 的东西，而且没有对 key 设置超时机制，能够考虑使用 allkeys-lru 回收机制。个人建议是先在这里查看一下可行的方案。

七、若是你的数据很重要，请使用 Try/Except

若是必须确保关键性的数据能够被放入到 Redis 的实例中，我强烈建议将其放入 try/except 块中。几乎全部的Redis客户端采用的都是“发送即忘”策略，所以常常须要考虑一个 key 是否真正被放到 Redis 数据库中了。至于将 try/expect 放到 Redis 命令中的复杂性并非本文要讲的，你只须要知道这样作能够确保重要的数据放到该放的地方就能够了。

八、不要耗尽一个实例

不管何时，只要有可能就分散多redis实例的工做量。从3.0.0版本开始，Redis就支持集群了。Redis集群容许你基于key范围分离出部分包含主/从模式的key。完整的集群背后的“魔法”能够在这里找到。

但若是你是在找教程，那这里是一个再适合不过的地方了。若是不能选择集群，考虑一下命名空间吧，而后将你的key分散到多个实例之中。关于怎样分配数据，在redis.io网站上有这篇精彩的评论。

九、内核越多越好吗？！

固然是错的。Redis 是一个单线程进程，即便启用了持久化最多也只会消耗两个内核。除非你计划在一台主机上运行多个实例——但愿只会是在开发测试的环境下！——不然的话对于一个 Redis 实例是不须要2个以上内核的。

十、高可用

到目前为止 Redis Sentinel 已经通过了很全面的测试，不少用户已经将其应用到了生产环境中（包括 ObjectRocket ）。若是你的应用重度依赖于 Redis ，那就须要想出一个高可用方案来保证其不会掉线。

来源： http://objectrocket.com/blog/...