准备把单机Redis拆成几台丽萨主机VPS时，先把应用里一次要改动的键列出来，比先选节点数更有用。购物车、库存预留和订单状态若原来依靠一次多键操作保持一致，迁入集群后可能直接遇到跨槽错误。增加内存不能改变这个限制；先确定哪些键必须放在同一个槽，才能判断分片能否分散真实负载，以及新增节点的钱是否买到了有效容量。
一条事务涉及的键，决定扩容边界
Redis官方集群规范把键空间划成16384个哈希槽。通常按键名计算CRC16再取模，节点负责其中一部分槽。多键命令所涉及的键需要属于同一个槽，这比“键恰好在同一台机器”更严格。同一节点可以承载许多不同槽，今天碰巧落在一台节点上的两个键，也不能据此当作同槽事务设计。
应从生产调用记录整理键的关系：一次操作读写哪些键，哪些步骤必须一起成功，客户端有没有把批量请求拆成多次独立调用。把批处理拆成逐键请求，只能改变访问方式，不能保留原有的原子性。如果库存扣减成功而订单标记失败需要业务补偿，就应明确补偿记录存在哪里、谁负责执行，以及重复执行的结果。
集群提供哈希标签：在符合规则的键名中，只用第一对有效花括号内的非空内容计算槽位。例如cart:{u42}与reservation:{u42}会使用相同的标签内容。实施前可以在测试集群用CLUSTER KEYSLOT核对实际结果，不能仅靠肉眼判断命名相似。空花括号、嵌套花括号和多段括号的规则不同，迁移工具也必须使用同一套命名约定。
合适的标签是业务一致性的最小范围。例如同一用户的几个键需要一起变更，就按用户建立范围；把全站所有键都放进同一个固定标签，虽然绕开跨槽限制，却也把写入集中到一个槽。此时买更多主节点只能增加闲置资源，最忙节点的处理能力仍是上限。
当前套餐差价，先拿来验证单节点瓶颈
本次实际打开的丽萨主机订购页列出美国9929一期的精简版与基础版，均为KVM、1核CPU和1G内存；精简版68元/月，10G NVMe、50Mbps、1000GB流量，基础版88元/月，20G NVMe、60Mbps、2000GB流量。进阶版158元/月，2核、2G内存、40G NVMe、80Mbps及4000GB流量。这些是当前页面标示，不代表独享处理能力或本次实测结果，最终以下单配置为准。
精简版升基础版每月多20元，CPU与内存并未增加。若热点槽已经耗尽单核执行时间，这次升级没有直接解决算力缺口；若问题是持久化空间或流量额度，差别才更可能相关。进阶版同时改变多个资源，验收时应分别记录热点命令耗时、内存峰值与客户端等待，避免把某一项改善笼统归因于“集群更快”。
上图保留当前官方套餐页面的实际配置区域，用于核对采购选项，不作为Redis性能证据。Redis部署还会消耗系统、客户端连接和持久化所需空间，1G内存也不能全部分配给业务键。先在候选机上恢复一份脱敏数据并跑真实命令组合，再决定是否进入多机阶段，通常比一次性签多台长期订单更容易识别不合适的条件。
节点数量增加后，热点标签仍然留在原地
按租户贴标签时，一个大租户可能占掉绝大部分请求。槽数量均匀不代表请求均匀，键数量均匀也不代表内存均匀。监控至少要把每个节点的业务吞吐、耗时分布和内存占用，与标签代表的业务范围关联。某个租户出现问题时，扩容计划应先解释如何分散这组工作；如果必须跨用户共同扣减的库存仍是一组热点键，用户分片并不能解决它。
可以采用容量不等式作初步门槛：最忙业务范围的峰值负载，必须低于单个承载节点在目标响应期限内的可持续处理能力。能力应由同一客户端、同一命令比例和相同数据规模的验收取得，不能用整套集群总吞吐除以节点数代替。还应留出故障切换后的余量，因为备用副本接管时也会承担访问与恢复工作。
图中集中在一个承载位置的球体只表示热点分布的抽象关系。若业务确实允许进一步拆分标签，仍要先检查原先的多键一致性是否被破坏；若不允许拆分，就优先考虑更强的单节点或业务流程调整。应用必须保留的语义，是决定采购方案的约束条件，不能为迁就便宜节点而事后删掉。
客户端和迁槽过程也要进入验收
集群节点不会替客户端代理到正确节点，而是通过MOVED或ASK等重定向协作。需要确认驱动支持集群模式、能刷新槽映射，并且应用能够到达返回的节点地址。只测最初一个入口连通，不能证明整个集群可用。节点之间还需要集群总线通信；应使用受控网络并核对允许的端口与访问来源，不应把内部通信直接交给任意公网访问。
官方规范提醒，手动重新分片期间，多键操作可能暂时不可用。验收不能只看稳定状态的单键读写，要在迁槽期间执行应用实际依赖的多键调用，记录错误、重试和业务补偿。事务文档说明的执行语义也不能被外推成跨槽分布式事务。客户端拆分请求后看起来“没有报错”，尤其需要核对中途失败是否留下半完成状态。
先形成小规模订单，再决定是否扩大
假设先购买三台68元/月精简版，裸实例月费为204元；三台88元/月基础版为264元，差60元。这个算例只计算页面实例费，没有计算副本、备份、额外流量和维护工时，也没有把三台机器写成完整高可用交付。如果选择每个主节点都配置副本，实例数量和费用会继续变化，应以实际拓扑重算。
付款前向商家确认：实例是否允许持续运行自建Redis，CPU共享和持续负载如何约定；同一地区实例之间有没有可用的私网及独立计费；是否能安排不同宿主机，相关安排是否有明确承诺；重装、备份和故障支持分别覆盖到哪里。页面线路名称和住宅IP描述不能证明节点间带宽、反亲和或数据库服务等级，退款条款也应完整读取后再开始验收。
若业务以独立键访问为主、标签范围能够均匀拆分、团队能维护集群客户端，这类VPS可以进入候选测试。若核心操作必须同时改全局热点键，或无人负责迁槽失败与数据恢复，先保留单机结构更便于核算责任。确认这些条件后，可通过丽萨主机当前套餐入口（推广链接）复核订单；本站可能获得推广收益，不据此承诺性能或库存。
交付记录应保留一组能反驳采购判断的测试：热点范围无法分散、迁槽时关键操作失败，或者故障后期限超标，出现任何一项就暂缓扩大节点数。只有业务语义和最忙节点都通过，才有理由把多台实例作为下一阶段预算。
用户评论