项目背景：
在线上遇到需要大量重复使用的一些数据，这类数据有以下特点：1,查询频繁;2,更新不频繁;3,数据量较大。
基于以上特点,我刚开始选型使用DB同步到redis中，取得时候直接从redis获取。在生产时发现,某些情况下，在同一事务中反复调用redis获取较大数据时，造成了redis的负载过高，可能出现了redis数据连接池不满的情况。结合这类的数据的特点，设计方案使用本地内存存放此类数据，并需要设计分布式的同步策略，实现更新后每台机器对应内存的更新。
收益：
1,提高系统响应速度；2,降低中间件的负载压力
风险点：
同步机制出现异常时的补偿机制
方案：
1,项目启动时,启动一个线程监听zk相应的节点
2,当更新数据的时候,更新数据库的接受后,更新zk相应的节点（这里一定要先把更新的Tx提交，再去更新节点，否则可能同步到内存的数据还是老数据）
3,当每台机器监听到zk相应节点变化的时候,同步对应的数据到内存中
补偿机制：
每次同步时记录时间戳,取数时判断每个数据时间戳,设置一定的过期时间,过期后重新同步
其他途径：
1，redis的发布订阅功能相对较弱，也没有相应的持久化，平时相对较少使用，没有其他中间件支持的情况下可以考虑使用
2，MQ 广播机制,这个需要每台机器中配置不同队列，不符合分布式系统下对等性原则，部署也相对麻烦，不建议使用
后记
后面测试后发现，由于通知zk更新节点和更新DB放在了一个事务里面，有可能造成update事务可能还没有完成，这边zk节点已经更新，监听zk节点触发的动作依旧把原来的数据刷入内存中，没有达到同步的效果，也算是小小的坑吧（还是对事务的理解不够深呀）
