对Redis的正确使用十技术
redis是当前科技界非常流行。从Antirez的一个小的个人项目的内存数据存储标准，使用了很长的路。1。停止使用键*
好吧，也许不是开始本文与此命令的挑战的一个好方法，但它可能是最重要的。很多时候，当我们注意到一个redis实例的统计，我们将进入键*命令迅速，使关键信息会清晰地显示出来。老实说，从程序的角度倾向于写下面的代码：
关键in'keys *：
DoAllTheThings（）
但是，当你有1300万个键时，执行速度会变慢。因为键命令的时间复杂度是O（n），其中n是返回键的数量，命令的复杂性取决于数据库的大小。在执行该操作时，在您的实例中不能执行任何其他命令。
作为替代，看扫描，它可以让你进行更友好的way.scan采用增量迭代扫描数据库。此操作是基于光标的迭代器，所以你可以停止或继续在任何时间，只要你觉得是正确的。
2、发现慢Redis的罪魁祸首
因为redis没有非常详细的日志，就知道已经在redis实例做得很困难。幸运的是，Redis提供了一个命令统计这样的工具：
127.0.0.1:6379 >信息commandstats
# commandstats
cmdstat_get：电话= 78微秒= 608，usec_per_call = 7.79
cmdstat_setex：电话= 5微秒= 71，usec_per_call = 14.20
cmdstat_keys：电话= 2微秒= 42，usec_per_call = 21
cmdstat_info：电话= 10微秒= 1931，usec_per_call = 193.10
这个工具可以看到所有命令统计快照，例如命令执行了多少次，以及执行命令的毫秒数（每个命令的总时间和平均时间）。
只是一个简单的执行配置resetstat命令可以重置，你可以得到一个新的统计结果。
三.把redis基准测试结果作为参考，而不是一个概括
塞尔瓦托，Redis，父亲说：测试使用通过执行获得/设置命令是测试一个法拉利雨刷清洗在一个下雨天，镜子的效果。很多时候人们向我跑来，他们想知道为什么他们的redis的基准统计小于最佳结果。但我们有把所有不同的因素考虑在内，例如：
哪些客户端运行环境可能受到限制
是同一版本号吗
测试环境的性能与应用程序将要运行的环境一致吗
Redis的基准测试结果，确保你的redis服务器不运行在一个异常状态提供一个基准，但你不应该把它作为一个真正的压力测试，压力测试，需要对应用程序的操作模式，需要一个环境，尽可能尽可能多的。
4、哈希表是你最好的选择
介绍了哈希散列在一个优雅的方式，将带给你前所未有的体验。我见过很多关键结构如下：
福：first_name
福：last_name
福：地址
在上面的例子中，富可能是用户的用户名，每一个都是一个单独的键，这增加了出错的空间和一些不必要的键，而不是使用散列，您会惊讶地发现只有一个键是必需的：
127.0.0.1:6379 > HSET foo first_name乔
（整数）1
127.0.0.1:6379 > HSET foo last_name恩格尔
（整数）1
127.0.0.1:6379 > HSET foo的地址狂热的PL 1
（整数）1
127.0.0.1:6379 > hgetall Foo
1）first_name
2）乔
3）last_name
4）恩格尔
5）地址
6）1狂热
127.0.0.1:6379 > hget foo first_name
乔
5。设置键值的生存时间
只要有可能，就可以利用关键超时。一个很好的例子是储存的东西就像一个临时的认证密钥。当你寻找一个授权密钥采取OAuth为例-通常得到超时时间。这样，当设置键，设定一个超时时间，Redis会自动清理你！不再需要使用键*遍历所有键。如何方便
6。选择适当的恢复策略
现在，我们谈论的是结算的关键，让我们的回收策略的谈话。当redis实例的空间填充，钥匙的一部分将试图恢复。根据你使用它的方式，我强烈建议使用挥发性LRU政策-如果你设置一个超时的关键。但如果你运行类似于缓存，你不设定按键超时机制，你可以考虑使用allkeys LRU回收机制。我的建议是看可行的计划先在这里。
7。如果您的数据很重要，请尝试使用
如果你要确保关键数据可以放在redis实例，我强烈建议付诸尝试/除块。几乎所有的redis客户端使用发送遗忘策略，所以往往需要考虑的一个关键是真正投入使用的数据库。至于把试试在Redis命令期望复杂性不是本文要说的，你只需要知道，这样做可以确保重要的数据是放在的地方，应该把。
8。不要举一个例子。
只要有可能，就有可能分散多个redis实例的工作量。从3.0.0版本，redis支持群集，Redis集群允许你单独的部分重点从主人和奴隶的基于关键范围模式。在整个集群的魔法可以在这里找到。但如果你找一个教程，这是一个地方，很合适。如果你不能选择集群，考虑的命名空间，然后分散你的钥匙插入的多个实例。有一个精彩的评论如何分发数据的redis.io网站。
9。内核越多越好
当然，这是错误的。Redis是一个单线程的过程，只有两芯将消耗即使最大的坚持是启用的。除非你打算运行多个实例在主机-我希望只有在开发测试环境！否则，它不需要超过2芯一个redis实例。
10。高可用性
到目前为止，Redis的前哨已经完全测试，许多用户已经应用到生产环境（包括ObjectRocket）。如果你的应用程序依赖于使用，你需要拿出一个高可用性解决方案，以确保它不会下降。当然，如果你不想管这些事自己，ObjectRocket将提供一个高可用性平台，提供7×24小时的技术支持，如果你想的话，你可以考虑它。
以上是关于Redis的技巧十正确的使用，希望对你有帮助学习，它决定收藏