多服务器实例场景下Singleton模式的处理方案及适用性探讨

首先明确：单实例里的Singleton在多服务器部署时肯定会失效。就像你说的5台实例，每台都会自己创建一个Client单例，各自维护token，结果就是每到30分钟，5台可能同时去刷新token，直接触发每小时2次的限流限制，完全达不到你要的效果。

针对这类需要全局共享、严格控制操作频率的场景，有几个标准解决方案：

一、用分布式缓存+分布式锁统一管理 #

把token和对应的刷新时间戳存在Redis这类分布式缓存里，所有实例都从缓存取token。当需要刷新时，先尝试用分布式锁（比如Redis的SETNX命令）抢占刷新权限，只有拿到锁的实例才去执行刷新逻辑，更新缓存里的token和过期时间；没拿到锁的实例要么等一会儿再取新token，要么继续用旧token撑到新token更新完成。这样能确保全局只有一个token，刷新次数严格受控。

二、搞个中心化的token管理服务 #

单独部署一个专门管token的服务，所有业务实例都通过调用这个服务来拿token。这个中心化服务内部可以用单例模式维护token（毕竟它自己可以是单实例，或者集群内部用共享锁控制），对外只提供获取token的接口，从根源上避免多实例重复刷新的问题。

三、借助配置中心推送更新 #

把token存在Nacos、Apollo这类配置中心里，专门写个小服务负责定时刷新token，更新后推送给所有业务实例。业务实例只需要监听配置变化，更新本地缓存的token就行，完全不用自己处理刷新逻辑，自然不会有冲突。

至于Singleton模式在现代多服务器架构下的实用性：它并没有过时，只是得选对场景。

• 如果你要管理的是单实例内部的资源，比如每个实例自己的日志工具、本地配置加载器，用Singleton能避免重复创建对象，省资源，这时候很实用。
• 但像token这种需要多实例一致的全局共享资源，单实例Singleton就完全不适用，必须用上面说的分布式方案替代。
• 另外要注意，像Spring里的默认Bean单例，是每个Spring容器内的单例，多实例部署时每个容器还是各自的单例，别把这个和全局单例搞混了。

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