所以你应该考虑编写自己的抽象层来提供分片 。基本上想象一下，你已经实现了一个一致的散列方法……在使用它之前，你通过它运行每个合成的密钥 。虽然您只有一个 Redis 服务器，但哈希到服务器的映射最终总是指向您唯一的服务器 。稍后，如果您需要添加更多服务器，则可以调整映射，以便将一半或三分之一的密钥解析到其他服务器 。当然，您会希望实现这一点，以便主服务器上的故障导致您的库/服务模块在辅助服务器和可能的任何第三级服务器上自动重试 。根据您的应用程序，您甚至可能会尝试从另一个数据源（例如您的 SQL RDBMS）完全获取某些类型的数据 。
这是一个领域，特别是，我希望看到一个强大的第三方（或 antirez 创建）库编写来处理所有繁琐地位置 。一致的散列并不难……但它确实需要相当多的精心编写的代码来实现——而且它应该远离大多数应用程序编码人员 。您想要一些可以正常工作并继续工作的东西，即使您添加了额外的服务器容量（需要为所有受影响的密钥迁移实用程序）和故障（要求您已经处理了将数据复制到二级和/或三级服务器） .
将您的 Redis 操作与您的应用程序分离：
我希望你已经看到了这个建议对我提出的所有其他建议的重要性的预示 。如果有人只是将 Redis 基础设施用作临时的、无底的资源，那么这些都将不起作用 。
不要将您的应用程序视为使用 Redis！
您正在编写一个使用一组服务的应用程序 。碰巧的是，（部分）这些服务是由 Redis 服务器提供的 。但是，您应该将其视为实现细节，并专注于您需要哪些服务以及您向应用程序开发人员提供哪些 API 来提供这些服务 。
Redis 提供的任何东西都不是您通过众多替代方案无法完成的 。如果您编写正确类型的代码（可能包括存储过程、触发器等和/或单独的守护程序）并实现正确的模式，则可以在某种程度上使用 SQL/RDBMS 后端来近似或提供 Redis 的每个功能它 。
如果您专注于需要提供给应用程序开发人员的 API，那么您就有希望更换那些不可避免地需要在以后更换（无论出于何种原因）的部分 。您还可以在开发需要与现有数据库交互的其他应用程序和模块时提供更大的灵活性 。
【使用Redis时要避免的5个错误】
推荐阅读
- Linux进程管理
- Linux内核：虚拟地址到物理地址，是什么时候开始映射
- 白帽黑客如何使用Dirbuster网站目录扫描神器
- windows下通过多网卡和路由实现同时在多网络环境工作
- Windows命令行包管理工具scoop使用教程
- 通常鱼在一年四季中什么时候长得最慢？
- 孤男寡女容易“出事儿”的时刻
- ?中小学夏季作息时间
- 儿童营养与生长发育
- 十一个月宝宝作息时间