关于消息变更的最佳实践
博客专区 > xpbob 的博客 > 博客详情
关于消息变更的最佳实践
xpbob 发表于7个月前
关于消息变更的最佳实践
  • 发表于 7个月前
  • 阅读 322
  • 收藏 3
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

摘要: java 观察者模式 消息变更

问题描述

      工作中遇到的场景拿出来分享一下:

      最初需求

      程序启动读取配置文件,然后根据这些配置项去做一些任务,具体的任务会多次读取相应的配置项。最初的设计如下。

      

        ConfigProperties主要是读取配置文件的,FileTask(线程任务)就是执行任务的类,在doTask中通过getProperties来获取相应的配置。这个设计本来没什么问题,而且也满足了单一职责的设计。

       需求变更

        想让配置文件改变可以动态生效,没必要重启生效。

        

        MessageChanged是另外一个线程,当有改变时触发去触发configProperties的操作。同事就是这样实现的,变成了一个标准的多线程模式,用锁去锁了临界资源——配置文件的具体项。这就要求读取配置的同时,不能更新配置项。业务需求(filecount,filename,filepath)三者必须用的是同一个版本。这样就要求读写必须是互斥的,加锁是满足了这个需求,但是FileTask获取三个配置的地方特别分散。加锁的范围特别大。这样效率一点也不好。两个线程持有锁的时间都太久了。

        

            于是做了一点更变,那就是把数据存储进行了一层包装,数据都是分组存放的,每个组都是volatile的。这样加锁的操作变成了对一个变量的赋值和取值。

消息通知的套路

        上述的模式已经比较明朗了,当遇到这种消息变更的,处理的方式其实都是相似的,主要就是锁分离。

        1,首先需要本地缓存,就是旧的配置需要一份。

        2,运行任务的整体配置得组装到一起,以便原子性的更新。

        3,消息通知模式

                观察者模式

                事件机制

                队列机制(变更消息写入队列,每次先都去读取一次队列,决定是本地缓存还是新传入的值)

                多次读取(上面使用的情况)

 

        

共有 人打赏支持
粉丝 51
博文 53
码字总数 37646
×
xpbob
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: