集群时静态变量的处理

[经常在黑云中出没]

原有系统，会把一些运行时经常会调用的数据，存在静态变量里，普通String的有，Map的也有。启动的时候，会数据库里查出来，后面有变化的时候，会修改静态变量和数据库。

现在做集群了，如果还存静态变量的话，会导致修改了静态变量，几台服务器就会不同步。
如果存到redis，就比较麻烦，如果redis重启了，岂不是要重新全部取过，放置进去。

不知道各位是怎么处理集群时的静态变量的。

[经常在黑云中出没]

顶一下看~~

[tianfang]

我会选择用数据库存储

[经常在黑云中出没]

引用 2 楼 tianfang 的回复:

我会选择用数据库存储

那数据库压力大

[tianfang]

引用 3 楼 cclovescw 的回复:

[quote=引用 2 楼 tianfang 的回复:] 我会选择用数据库存储

那数据库压力大[/quote] mysql/h2内存数据库，压力没那么明显增大；最初不用单独写代码维护，当然，最好有维护系统

[tianfang]

又思考了一下： redis对配置数据做持久化 zookeeper 分发配置数据 http://tonybai.com/2013/08/28/implement-config-sync-for-distributed-system-with-zookeeper-services/ mysql内存表也有重启丢失的问题，压力大可以考虑主从模式并读写分离，主服务器：表记录在磁盘，是是管理界面写入的入口；从服务器采用内存表，从主服务器同步，集群中各个服务器从mysql从服务器读取

[wang4556299]

redis 也持久化操作啊，重启会恢复的。

[tlzjff]

第一：我觉得楼主担心过多了，redis可以做高可用方案的，只要确保redis的容量够用，就可以采用这种方案了。 第二：如果redis发生宕机，那么在几秒钟之内，会导致redis的故障转移，这断时间可以给用户一个友好提示，等故障转移完毕后，就不影响正常业务了。 第三：如果楼主对于业务的可用率要求极高，那么需要些额外的容错逻辑，比如说，redis30秒内还未恢复，则尝试使用数据库查询的方式，提供服务，并且，在redis恢复时，需要重写缓存内容，这样的逻辑，但是如果做这种极端假设，还需要考虑到更多的因素，比如说，如何在这种情况下限流，来保护数据库之类的，因此，如果往这条路上靠的话，设计上就会很复杂了，所以，如果非必要情况，建议楼主直接依赖redis可用率做业务，当redis 高可用发生故障转移，或者高可用全部失效的情况下，放弃业务查询功能，会使得设计变得更简练，在绝大多数情况下，高可用方案是可靠的，没有必要为了1/10000000的概率，把系统直接设计成那么复杂，而应该先满足需求，当业务真的变得那么高要求后，再考虑对其重构的方案会更合理。

[新技术追求者]

最好的是把所有的东西放在一个公共的地方，那么这里我们就选者redis，重启redis，redis钟的数据是不会丢失的，既然选择的集群，那就一定要做到数据的共享！这个要牵扯到很多的，可能你现在至于到了这么一种！

[verejava]

用缓存 分布式缓存

http://www.verejava.com/?section_id=1699236773261

[以专业开发人员为伍]

没有静态数据、全都是共享访问的公共数据。

[游北亮]

静态变量，重启也会丢失啊，不一样也要重新载入。
而且Redis是支持持久化的，重启会自动恢复。

为了后续的业务增长和良好扩展性，避免用静态变量吧，本地做一层内存缓存是可以的。

[k10509806]

存数据库啊，要用的时候存在redis啊