Linux运维需要知道的Redis履历
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履历的详细内容 ，更多请关注本网内其它相关文章！
