需求：
程序中的配置，怎么能够实时更新。
其实我想解决的是业务配置的管理，可是想一想，无论业务配置还是服务的配置，
其本质也还都配置的管理，可以参考服务发现那套逻辑。
目前服务发现更多采用的是分布式k/v，直接用redis还是少数，这里只是简单列举思路
方案
- 对外暴露一个接口，用于刷新配置
- 定时加载配置到服务中
- 每次接口调用都实时去加载配置
各方案优缺点
对外暴露一个接口，用于刷新配置
本质上就是进程间通讯
缺点：稍微麻烦：要写接口，还要让对方调用，如果有多个进程，需要多次调用。
优点：- 实时性强
- 对业务系统的消耗最低
定时加载配置到服务中
缺点：- 需要等待刷新的时间，配置人员要等待，不具备实时性
无法很好的把控程序刷新时机，如果要同时改多个配置，可能会有配置改到一半就被刷新的风险
优点：- 开发时省事
每次接口调用都实时去加载配置
缺点：对业务系统的消耗较高
优点：简单，但是配置多或访问量大的情况不适合
优化：- 数据量大的情况：将配置更新时间存在redis中，每次访问redis，和本地的更新时间做比较，不一致则更新。
- 数据量小的情况：将配置存在redis中，做比较，不一致则更新。
- 并发量较大：加上内存过期机制，若实时性较高，可以只保存2-3秒；还是采用多级缓存的思路。
以往的方案
采用第一种。
用的twisted或tornado异步处理请求，每个进程分别对应两个端口，分别对内和对外提供服务。
对内服务主要用于刷新配置和设置临时变量。
如果要刷新配置，只要调用对应的内部端口即可。
新的问题
目前团队用的flask，采用wsgi管理多个进程，而多个进程的端口都是同一个。
怎么样才能让所有的进程都同步到最新的配置呢？
目前的结论
- 方案2是个坑；flask 可以用方案3；并发量特别大的时候，采用方案1。
- 方案1要实现同一端口的多进程调用，只能对wsgi再封装，如非必要，先放弃。
