Moving parameters into database table, read in runtime, not hard code constant

[rexpie]

Already have Param entity.

Question:

how to do version control？

how to roll back when misconfigure?

how to speedup? ( memcached? in mem database as cache? built-in cache from db? )

[tinytitan-xx]

提供前端查看和改配置的接口，可以触发动态加载配置。 配置信息不多的话可以全量保存历史版本信息，Vpost=Vpre+△，配置信息加Version字段，便于回滚。 同样，配置信息不多的话可以不用考虑cache，直接常驻内存就行。 这样可行吗？

[rexpie]

1.Vpost=Vpre+△不适合字符类型，类型考虑也是麻烦的部分之一。可以预设几种基本类型，然后前端设置时检查，后端运行时做转换 2.Version的确需要。问题是可能即使某版本即使只修改了一个变量，那么是不是其他变量都需要增加一个版本，保持版本一致？还是说不同变量有自己的版本，每次取最新？两种各有好坏，自由选择做足测试即可。 3.常驻内存基本等于自己做cache，万一之后做了双服务器就会造成同步问题了，所以使用memcached这种框架会更容易扩展。 4.前端的部分是需要的，如果使用memcached还要提供刷新cache重新灌参数的功能。

[tinytitan-xx]

1.每个版本对应多条配置信息。如Vpre有两条数据a,b,值为1,2.△为所做的操作，可以是增删改，如是将a的值改为2.那Vpost就是两条数据a,b,值为2，2. 2.修改一条数据后，未修改的数据也要更新版本。所以配置信息数据库的增长是线性的，每次增长的数目为上一版本的数据量。 3.没有考虑过多服务器……memcache的话，是相当于每次使用都去读数据库吗？我觉得考虑配置信息的更新次数远少于使用次数。可以全部放入内存，更新配置的时候触发其他服务器去读取配置。

[tinytitan-xx]

memcache这个我再看下吧，感觉还是你说的有道理。

[rexpie]

那么就是说服务器里面刷新的时候要拿到最高版本号。这个没问题，后端更新的时候要保证每个版本里面的数据没有缺失。 memcache这个东西因为之前游戏公司实习的时候他们是用来专门做这个参数缓存的，所以有一定的使用价值。当然这个东西如果花时间太多可以不做，更新参数的时候就要半夜停服更新了。

[tinytitan-xx]

我行新系统是这样做参数版本的😄，memcache需要数据库层的吧，hibernate有cache，应该不适合多服务器的情况，主要是小訾他们用这个cache的时候碰到很多bug……

[rexpie]

原来如此。我自己修改后端数据的时候倒是没有出现过hibernate乱用cache的情况，既然有先例那就小心为上。我们参数跳过hibernate直接写sql或者用spring jdbc template。这样你再看看还有没有别的可能出现问题的地方？

[tinytitan-xx]

那个cache要配置的，不配没有启用。版本控制我就按这样先做。cache后面加吧。

[tinytitan-xx]

那个cache要配置的，不配没有启用。版本控制我就按这样先做。cache后面加吧。