Redis在当前的技术社区中非常流行。从Antirez的一个小型个人项目到成为内存数据存储的行业标准，Redis已经走过了漫长的道路。遵循的一系列最佳实践使大多数人能够正确使用Redis。下面我们将探讨正确使用Redis的10个技巧。1.停止使用KEYS*好吧，通过挑战这个命令来开始这篇文章可能不是一个好方法，但这可能确实是最重要的一点。很多时候我们在关注某个redis实例的统计信息时，会快速输入“KEYS*”命令，这样关键的信息就会一目了然。平心而论，从程序的角度来看，我倾向于编写如下伪代码：forkeyin'keys*':doAllTheThings()但是当你有1300万个键时，执行速度会变慢。因为KEYS命令的时间复杂度是O(n)，其中n是要返回的键的数量，所以这个命令的复杂度取决于数据库的大小。并且在执行此操作期间，您的实例中不能执行其他命令。作为替代命令，请查看SCAN，它允许您以更友好的方式执行此操作...SCAN以增量迭代方式扫描数据库。这个操作是基于游标的迭代器完成的，所以你可以在你认为合适的时候停止并继续。2.找出导致Redis变慢的罪魁祸首由于Redis没有非常详细的日志，因此很难知道Redis实例内部正在做什么。幸运的是，Redis提供了类似下面的命令统计工具：127.0.0.1:6379>INFOcommandstats#Commandstatscmdstat_get:calls=78,usec=608,usec_per_call=7.79cmdstat_setex:calls=5,usec=71,usec_per_call=14.20cmdstat_keys:calls=2、usec=42,usec_per_call=21.00cmdstat_info:calls=10,usec=1931,usec_per_call=193.10通过这个工具可以查看所有命令统计的快照，比如命令执行了多少次，耗时多少毫秒执行命令（每个命令的总时间和平均时间）可以通过简单地执行CONFIGRESETSTAT命令来重置，这样就可以得到一个新的统计结果。3.使用Redis-Benchmark结果作为参考而不是一概而论。Redis之父Salvatore说：“通过执行GET/SET命令来测试Redis，就像测试法拉利的雨刷器在下雨天擦镜子的效果。”很多时候人们来找我，他们想知道为什么他们的Redis-Benchmark统计数据低于***结果。但我们必须考虑到各种实际情况，例如：哪些客户端运行环境可能会受到限制？是同一个版本号吗？测试环境中的性能是否与应用程序运行的环境相匹配？Redis-Benchmark的测试结果提供了一个基准来确保你的Redis-Server不会运行在异常状态，但你不应该把它当作真正的“压力测试”。压力测试需要反映应用程序的运行方式，并且需要尽可能接近生产的环境。4.哈希是你最好的选择以一种优雅的方式引入哈希。哈希将为您带来独特的体验。我以前见过很多这样的键结构：foo:first_namefoo:last_namefoo:address在上面的例子中，foo可能是用户的用户名，每个用户名都是一个单独的键。这增加了出错的空间和一些不必要的键。使用哈希代替，你会惊讶地发现只需要一个键：127.0.0.1:6379>HSETfoofirst_name"Joe"(integer)1127.0.0.1:6379>HSETfoolast_name"Engel"(integer)1127.0.0.1:6379>HSETfooaddress“1FanaticalPl”（整数）1127.0.0.1:6379>HGETALLfoo1）“名字”2）“乔”3）“姓氏”4）“恩格尔”5）“地址”6）“1FanaticalPl”127.0.0.1:6379>HGETfoofirst_name“乔“5。设置键值的生存时间只要有可能，就利用键超时时间。一个很好的例子是存储诸如临时身份验证密钥之类的东西。当你去查找授权密钥时——以OAUTH为例——你通常会超时。这样，在设置key的时候，设置成相同的超时时间，Redis会自动帮你清除！不用KEYS*遍历所有key，方便吗？6、选择合适的回收策略说完了清除密钥的话题，我们再来说说回收策略。当Redis的实例空间满了，它会尝试回收一些key。根据您的使用方式，我强烈建议您使用Volatile-lru策略——前提是您已经为密钥设置了超时。但是如果你运行的是缓存之类的东西，没有给key设置超时机制，可以考虑使用allkeys-lru回收机制。我的建议是先看看这里的可能选项。7.如果你的数据非常重要，请使用Try/Except如果你一定要确保关键数据可以放入Redis实例中，我强烈建议将它放在一个try/except块中。几乎所有的Redis客户端都采用“发送后遗忘”的策略，所以往往需要考虑一个键是否真的放在了Redis数据库中。至于在Redis命令中放入try/expect的复杂度，本文不赘述。你只需要知道这样做可以确保重要数据放在它应该在的地方。8.不要耗尽一个实例只要有可能，将工作负载分散到多个redis实例上。从3.0.0版本开始，Redis支持集群。Redis集群允许你根据键范围以主/从模式分离出一些键。完整集群背后的“魔法”可以在这里找到。但是，如果您正在寻找教程，那么这里就是您要去的地方。如果集群不是一个选项，请考虑命名空间并将您的密钥分布在多个实例中。redis.io上有一篇关于数据分布方式的精彩评论。9.核心越多越好吗？！当然是错的。Redis是一个单线程进程，即使启用了持久化，也最多消耗两个内核。除非您计划在单个主机上运行多个实例——希望只在开发测试环境中运行！-否则，一个Redis实例不需要超过2个核心。10.高可用RedisSentinel目前已经经过全面测试，很多用户已经将其应用于生产环境（包括ObjectRocket）。如果你的应用严重依赖Redis，你需要想出一个高可用的方案来保证它不会掉线。当然，如果你不想自己管理这些东西，ObjectRocket提供了一个高可用的平台，并提供7×24的技术支持。有兴趣的可以考虑一下。
