This is a creation in Article, where the information may have evolved or changed.
Profile hot update is a basic function of the server program, through the hot update can not stop adjustment program configuration, especially in the production environment can provide great convenience, such as the discovery of log playing too much can dynamically increase the log level, business logic parameter changes, and even a function module switches can be dynamically adjusted.
Each language has its own thermal update implementation, in the Golang I saw someone using a wrong way of implementation, as follows:
type Config struct { Test1 string `json:"Test1"` Test2 int `json:"Test2"`}var ( config *Config)func loadConfig() { f, err := ioutil.ReadFile("config.json") if err != nil { fmt.Println("load config error: ", err) } err = json.Unmarshal(f, &config) if err != nil { fmt.Println("Para config failed: ", err) }}func init() { loadConfig() fmt.Println("Load config: ", *config) s := make(chan os.Signal, 1) signal.Notify(s, syscall.SIGUSR2) go func() { for { <-s loadConfig() fmt.Println("ReLoad config: ", *config) } }()}
The problem with this approach is that the config may be accessed by multiple routine at the same time, so it is problematic to parse directly on config when Loadcofig. In the example above, the simplest JSON configuration is used, and if it is other more complex configuration forms, such as XML, you need to write the parsing function yourself instead of a JSON. Unmarshal) makes it easier to zoom in on problems.
You can use the update to lock config to solve this problem:
Package Mainimport ("Encoding/json" "FMT" "Io/ioutil" "Log" "OS" "Os/signal" "Sync" "syscall")// JSON configuration test Type Config struct {Test1 string ' JSON: ' Test1: ' Test2 int ' json: ' Test1: '}var (Config *config Configlock = new (sync. Rwmutex)) func loadconfig () bool {f, err: = Ioutil. ReadFile ("Config.json") if err! = Nil {fmt. PRINTLN ("Load config error:", err) return false}//different configuration rules, different parsing complexity temp: = new (config) Err = json. Unmarshal (f, &config) if err! = Nil {fmt. Println ("Para config failed:", err) return false} configlock.lock () config = temp Configlock.unlock () return True}func GetConfig () *config {configlock.rlock () defer configlock.runlock () return Config}func init ( ) {if!loadconfig () {OS. Exit (1)}//The hot update configuration may have multiple triggering methods, using the system semaphore SIGUSR1 to implement S: = Make (chan os. Signal, 1) Signal. Notify (S, Syscall. SIGUSR1) go func () {for {<-s Log. Println ("Reloaded config:", Loadconfig ())}} ()}func main () {select {}}
Since the hot load, there may be many unknown routine in the use of config, by switching the configuration when the lock can guarantee the correct operation of multiple routine to config, but it is important to note that the acquisition of the configuration file also need to lock.
Do not know in the Golang, there is no lock-out scheme can be implemented to configure the hot update?