Redis vs 数据库：缓存、分布式锁及SignalR扩缩容方案选型评估

正在为新系统评估Redis与数据库等替代方案，用于实现缓存、分布式锁及SignalR应用扩缩容功能。技术主管对Redis持怀疑态度，以下是各组件的细节与考量：

1. 缓存 #

核心条件 #

• 数据要求高度实时
• 数据特征：多数键值大小为数百KB，少数可达2-3MB
• 架构：多租户数据库，按[companyname]和[company_name][storeX]分类，单门店含数百个键值，预计1年内增长至数百家门店

实现方案 #

Redis方案

• 键值格式示例：[company][store][group/groups]_specific_name
• 读取逻辑：GET请求先检查Redis键是否存在，存在则返回缓存数据；不存在则从数据库获取解析后存入Redis
• 更新逻辑：POST/PUT/DELETE请求处理并保存数据后，删除受影响企业/门店的相关Redis键值（例如门店设置变更时，删除所有含"Settings"分组的键值）

数据库方案

• 在每个[company_name]数据库中创建专用缓存表
• 键值格式及读写逻辑与Redis方案一致
• 不采用触发器清除缓存，避免企业主数据库与门店数据库相互影响请求结果

2. 分布式锁 #

Redis方案 #

通过RedLock.net等库实现分布式锁

数据库方案 #

• 设计包含[store]、[locked]等字段的锁表
• 操作流程：先检查锁状态，未锁定则设置GUID并验证，处理数据后清除锁；已锁定则延迟重试

3. SignalR（WebSocket通知）扩缩容 #

Redis方案 #

采用微软推荐方案，将Redis作为backplane实现扩缩容

替代方案 #

• 维持SignalR应用单实例部署
• 将WebSocket替换为每隔几秒的周期性轮询

内容的提问来源于stack exchange，提问作者Gersalom