未登录用户自定义加密货币价格预警限价数据存储方案咨询

核心思路：平衡存储成本、持久化与可用性 #

1. Session存储的局限性 #

Session确实能存，但有几个硬伤：

• 服务器重启或Session过期后，用户的限价设置直接丢失，体验极差
• 分布式部署场景下，Session共享需要额外配置（比如Redis集群），反而增加复杂度
• 只能绑定当前浏览器会话，用户换设备/清缓存就没了，不符合预警功能的长期需求

2. 优先考虑：浏览器本地存储（LocalStorage/SessionStorage） #

这是最轻量化的方案，完全绕开服务器存储压力：

• LocalStorage：持久化存储，除非用户手动清除，否则一直保留，适合长期预警设置
• SessionStorage：仅当前会话有效，适合临时预警需求
• 实现逻辑：用户设置限价后，直接存在浏览器端，前端通过WebSocket和服务器建立连接时，把限价参数传给服务器；服务器维护一个WebSocket连接池，每个连接绑定对应的限价规则
• 注意：要做前端校验（比如限价范围、格式），避免无效数据传到后端；同时服务器要定期校验连接状态，断开后自动清理对应的预警规则

3. 折中方案：Cookie + 内存缓存 #

如果需要服务器侧保留部分状态，又不想用数据库：

• 给每个未登录用户生成唯一标识（UUID）存在Cookie里，有效期设长一点（比如30天）
• 服务器用内存缓存（如Redis、内存哈希表）存储UUID和对应的限价规则，缓存过期时间和Cookie同步
• 优势：用户清Cookie才会丢失数据，服务器能统一管理预警规则；Redis还支持过期自动清理，避免内存溢出
• 风险：内存缓存容量有限，大流量场景下可能需要做数据淘汰策略（比如LRU）

4. 极端场景：URL参数传递（仅临时预警） #

如果用户只是单次临时预警，不需要持久化：

• 把限价、币种、预警方向（突破/跌破）编码到URL参数里，比如 ?symbol=BTC&price=30000&direction=up
• 用户打开链接后，前端解析参数，直接和服务器WebSocket建立连接并提交规则
• 缺点：URL分享后他人能看到设置，且关闭页面就失效，只适合临时快速预警

关键注意事项 #

• 不管用哪种方案，服务器都要做规则去重：同一个用户（或同一个连接）对同一币种的同方向预警，只保留最新的规则
• 预警触发后，要及时从存储/连接池中删除对应的规则，避免重复推送
• 前端要给用户提示：未登录用户的设置会在什么情况下丢失（比如清缓存、Cookie过期）

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