使用redis注意事项,redis详细教程

　　http://www..net/article/73376.htm

　　Redis在当前的技术社区非常流行。Redis已经从Antirez的一个小型个人项目发展成为内存数据存储行业的标准。

　　1.停止使用钥匙*

　　好吧，挑战这个命令可能不是开始这篇文章的好方法，但这可能是最重要的一点。很多时候，我们在关注一个redis实例的统计时，会快速输入“KEYS *”命令，这样关键信息就会清晰的显示出来。平心而论，从程序的角度来看，往往倾向于写以下伪代码：

　　但是当你有1300万个键的时候，执行速度会慢一些。因为KEYS命令的时间复杂度是O(n)，其中n是要返回的键的数量，所以这个命令的复杂度取决于数据库的大小。在此操作过程中，不能在您的实例中执行任何其他命令。

　　作为替代命令，看看SCAN，它允许您以更友好的方式执行它… SCAN通过增量迭代扫描数据库。这个操作是基于游标的迭代器，所以你可以在任何你觉得合适的时候停止或者继续。

　　2.找出拖慢Redis的元凶。

　　因为Redis没有非常详细的日志，所以很难知道Redis实例内部做了什么。幸运的是，Redis提供了如下命令统计工具：

　　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命令来重置它，这样就可以得到一个全新的统计结果。

　　3.以Redis-Benchmark结果为参考，不要一概而论。

　　Redis之父Salvatore曾说过，“通过执行GET/SET命令来测试Redis，就像是测试法拉利的雨刷在雨天清洁镜子的效果”。很多时候人们来找我，他们想知道为什么他们的Redis-Benchmark统计结果低于最优结果。但是我们必须考虑到各种实际情况，例如：

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

　　Redis-Benchmark的测试结果提供了一个基准，保证你的Redis-Server不会运行在异常状态，但你千万不要把它当成真正的“压力测试”。压力测试需要反映应用的运行模式，需要尽可能与生产相似的环境。

　　4.哈希是你的最佳选择。

　　以优雅的方式介绍散列。哈希将给你带来前所未有的体验。我以前见过很多像下面这样的关键结构：

　　在上面的例子中，foo可能是一个用户的用户名，每个用户名都是一个单独的键。这增加了出错的空间，以及一些不必要的键。用hash代替，你会惊讶的发现你只需要一个键：

　　5.设置关键值的生存时间。

　　尽可能利用按键超时。一个很好的例子是存储诸如临时认证密钥之类的东西。在寻找授权密钥时，——以OAUTH为例，——通常会得到一个超时。这样在设置键的时候，设置成同样的超时，Redis会自动为你清除！而不是用KEYS *来遍历所有的键，有多方便？

　　6.选择合适的回收策略。

　　既然说到清除key这个话题，那就来说说回收策略吧。当Redis的实例空间被填满时，它会尝试回收一些密钥。根据您的使用情况，我强烈推荐使用Volatile-lru策略3354，前提是您已经为key设置了超时。但是如果运行的是类似cache的东西，而且key没有超时机制，可以考虑使用allkeys-lru回收机制。我的建议是先在这里查可行方案。

　　7.如果您的数据很重要，请使用Try/Except。

　　如果有必要确保关键数据可以放入Redis的实例中，我强烈建议放在try/except块中。几乎所有的Redis客户端都采用“发送并忘记”的策略，因此经常需要考虑一个键是否实际放入了Redis数据库。至于在Redis命令中放置try/expect的复杂性，本文不做讨论。你只需要知道这样做可以确保重要的数据放在该放的地方。

　　8.不要用完一个实例。

　　尽可能分散多个redis实例的工作负载。Redis从版本3.0.0开始就支持集群。Redis cluster允许您根据键范围来分离一些包含主/从模式的键。完整集群背后的“魔力”可以在这里找到。但是如果你正在寻找一个教程，这是一个完美的地方。如果您不能选择一个集群，请考虑名称空间，然后将您的密钥分布在多个实例中。redis.io网站上有这个关于如何分布数据的精彩评论。

　　9.内核越多越好？

　　当然是错的。Redis是单线程进程，即使启用了持久化，最多也只会消耗两个内核。除非你打算在一台主机上运行——的多个实例，否则我希望只在开发和测试环境下！3354否则，Redis实例不需要2个以上的核心。

　　10、高可用性

　　到目前为止，Redis Sentinel已经过彻底的测试，许多用户已经将其应用到生产环境中(包括ObjectRocket)。如果您的应用程序严重依赖Redis，您需要提出一个高可用性方案来确保它不会被丢弃。当然，如果你不想自己管理这些东西，ObjectRocket提供了一个高可用的平台，并提供724小时的技术支持。有兴趣可以考虑一下。

　　以上就是关于Redis正确使用的十个技巧。希望对大家的学习有帮助。果断收藏。