DTLS集群负载均衡场景下会话状态共享及实现可行性问询

这确实是DTLS在负载均衡集群里绕不开的经典痛点——毕竟DTLS天生是端到端绑定会话状态的，默认情况下节点没存对应状态的话，收到加密包根本解不开。结合你提到的需求：不想给负载均衡器加严格的源IP绑定限制、要尽可能延长DTLS状态的存续时间，还已经有安全分布式存储的基础，我来拆解下可行的方案，以及你关心的Scandium扩展和JDK9+兼容性问题：

先从不用修改库的基础优化入手，能先解决一部分问题：

• 优先启用DTLS会话复用：DTLS本身支持会话复用（RFC 6347定义的Session ID或Ticket机制），默认的Session ID是节点本地存储的，如果你能把Session ID对应的会话状态同步到分布式存储，就能实现跨节点复用。这比从头做全量状态共享更轻量，既能减少新会话的创建，也能间接延长状态的有效时间。
• 调整会话超时策略：默认DTLS会话的超时时间通常比较短（比如几分钟），你可以根据业务场景适当调长（比如几小时），但要注意安全权衡——长会话意味着密钥暴露的窗口更大，得结合你的安全要求来定。
• 减少不必要的握手：尽量引导客户端在会话有效期内保持复用，避免频繁发起新的DTLS握手。这样即使负载均衡把包转发到新节点，只要节点能拿到会话状态，就能直接解密，不用重新握手。

你的思路完全正确——给Scandium扩展分布式会话缓存是解决这个问题的核心方案，而且非常值得做，尤其是你已经有安全分布式存储的基础：

• Scandium的现有状态存储逻辑：Scandium（基于Netty的Scala DTLS库）默认用InMemorySessionCache做本地会话存储，这是单机的。你只需要实现自定义的SessionCache接口，把存储逻辑替换成你的安全分布式存储（比如加密的Redis、集群数据库，或者你现有的分布式存储系统）就行。
• 需要同步的核心会话参数：DTLS会话里必须跨节点共享的核心数据包括：会话ID、会话密钥（加密/解密密钥、初始化向量IV等）、会话超时时间、客户端身份信息（如果有身份认证的话）。这些数据一定要加密后存储——刚好你有安全分布式存储，这部分可以直接复用现有能力。
• 负载均衡的配合（可选）：不需要强制绑定源IP，但如果负载均衡器能尽量把同一个会话的包转发到同一个节点（比如基于会话ID做哈希转发），能减少跨节点的缓存读取次数，提升性能。但即使做不到，只要节点能从分布式缓存拿到状态，就能正常解密，完全满足你的需求。

完全可行，而且JDK9+的特性还能帮到你：

• DTLS API的增强：JDK9对SSLEngine和DTLS相关的API做了不少优化，比如更灵活的会话管理支持。Scandium基于Netty开发，Netty在JDK9+下完全兼容，还能利用这些新特性提升效率。
• 模块化支持：JDK9的模块化系统不会影响Scandium的使用，只要你的项目配置好模块依赖（比如requires org.eclipse.californium.scandium;）就行，没有兼容性问题。
• 加密算法支持：JDK9+默认支持更多现代加密算法（比如TLS 1.3，Scandium如果支持DTLS 1.3的话也能用上），对DTLS的安全性和性能都有帮助。

• 缓存一致性：分布式缓存要保证会话状态的一致性，比如当某个节点更新了会话状态（比如超时时间、密钥轮换），要同步到所有节点的缓存，或者用分布式锁避免并发修改的冲突。
• 性能平衡：每次解密都从分布式缓存读状态会有一定开销，建议在节点本地做二级缓存——把高频访问的会话状态存在本地内存，定期从分布式缓存同步，平衡性能和一致性。
• 安全防护：分布式存储的会话状态必须加密存储，还要限制访问权限，只有集群内的节点能读取，避免密钥泄露。另外，长会话要定期做密钥轮换，降低密钥泄露的风险。

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