Redis 在目今的手艺社区里是很是热门的。历来自 Antirez 一个小小的小我私家项目到成为内存数据存储行业的标准，Redis已经走过了很长的一段路。随之而来的一系列最佳实践，使得大大都人可以准确地使用 Redis。

下面我们将探索准确使用 Redis 的10个履历。

1、阻止使用 KEYS *

Okay，以挑战这个下令最先这篇文章，或许并不是一个好的方法，但其确实可能是最主要的一点。许多时间当我们关注一个redis实例的统计数据，我们会快速地输入”KEYS *”下令，这样key的信息会很显着地展示出来。平心而论，从程序化的角度出发往往倾向于写出下面这样的伪代码：

for key in'keys *':
doAllTheThings()　

登录后复制

可是当你有1300万个key时，执行速率将会变慢。由于KEYS下令的时间重漂后是O(n)，其中n是要返回的keys的个数，这样这个下令的重漂后就取决于数据库的巨细了。并且在这个操作执行时代，其它任何下令在你的实例中都无法执行。

作为一个替换下令，看一下 SCAN 吧，其允许你以一种更友好的方法来执行… SCAN 通过增量迭代的方法来扫描数据库。这一操作基于游标的迭代器来完成的，因此只要你以为合适，你可以随时阻止或继续。

2、找出拖慢 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 下令就可以重置，这样你就可以获得一个全新的统计效果。

3、将 Redis-Benchmark 效果作为参考，而不要一概而论

Redis 之父 Salvatore 就说过：“通过执行GET/SET下令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。许多时间人们跑到我这里，他们想知道为什么自己的Redis-Benchmark统计的效果低于最优效果 。但我们必需要把州差别的真真相形思量进来，例如：

可能受到哪些客户端运行情形的限制？

是统一个版本号吗？

测试情形中的体现与应用将要运行的情形是否一致？

Redis-Benchmark的测试效果提供了一个包管你的 Redis-Server 不会运行在非正常状态下的基准点，可是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方法，并且需要一个尽可能的和生产相似的情形。

4、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'

登录后复制

5、设置 key 值的存活时间

无论什么时间，只要有可能就使用key超时的优势。一个很好的例子就是贮存一些诸如暂时认证key之类的工具。当你去查找一个授权key时——以OAUTH为例——通；峄竦靡桓龀笔奔。这样在设置key的时间，设成同样的超时时间，Redis就会自动为你扫除！而不再需要使用KEYS *来遍历所有的key了，怎么样很利便吧？

6、 选择合适的接纳战略

既然谈到了扫除key这个话题，那我们就来聊聊接纳战略。当 Redis 的实例空间被填满了之后，将会实验接纳一部分key。凭证你的使用方法，我强烈建议使用 volatile-lru 战略——条件是你对key已经设置了超时。但若是你运行的是一些类似于 cache 的工具，并且没有对 key 设置超时机制，可以思量使用 allkeys-lru 接纳机制。我的建议是先在这里审查一下可行的计划。

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

若是必需确保要害性的数据可以被放入到 Redis 的实例中，我强烈建议将其放入 try/except 块中。险些所有的Redis客户端接纳的都是“发送即忘”战略，因此经常需要思量一个 key 是否真正被放到 Redis 数据库中了。至于将 try/expect 放到 Redis 下令中的重大性并不是本文要讲的，你只需要知道这样做可以确保主要的数据放到该放的地方就可以了。

8、不要耗尽一个实例

无论什么时间，只要有可能就疏散多redis实例的事情量。从3.0.0版本最先，Redis就支持集群了。Redis集群允许你基于key规模疏散出部分包括主/从模式的key。完整的集群背后的“邪术”可以在这里找到。但若是你是在找教程，那这里是一个再适合不过的地方了。若是不可选择集群，思量一下命名空间吧，然后将你的key疏散到多个实例之中。关于怎样分派数据，在redis.io网站上有这篇精彩的谈论。

9、内核越多越好吗？！

虽然是错的。Redis 是一个单线程历程，纵然启用了长期化最多也只会消耗两个内核。除非你妄想在一台主机上运行多个实例——希望只会是在开发测试的情形下！——不然的话关于一个 Redis 实例是不需要2个以上内核的。

10、高可用

到现在为止 Redis Sentinel 已经经由了很周全的测试，许多用户已经将其应用到了生产情形中（包括 ObjectRocket ）。若是你的应用重度依赖于 Redis ，那就需要想出一个高可用计划来包管其不会掉线。虽然，若是不想自己治理这些工具，ObjectRocket 提供了一个高可用平台，并提供7×24小时的手艺支持，有意向的话可以思量一下。

以上就是Linux运维需要知道的Redis履历的详细内容，更多请关注本网内其它相关文章！