方案致力于实现的是相对静态数据的缓存一致性问题，借鉴思想是用于CPU高速缓存和内存之间同步的MESI协议以及内存屏障的设计思想。在这里我们并不会Push服务去完成每块数据的更新或者删除，数据中间件的职责是发出缓存失效标记且确认缓存失效标记被准确接收，缓存的更新工作应由服务方实现。
数据更新流程如下：
1、各服务启动，并发送监控标记和监听标记至资源注册中心
2、服务节点发送SQL执行请求至MySQL中间件
3、中间件记录日志，并下发请求至MySQL服务器
(注：此处有多种实现，a、请求发送至MySQL中间件，中间件进行请求透传；b、请求发送至MySQL服务器，但是我们可以伪装一个Slave节点，进行主从Dump复制，像阿里的canal即此种思路；c、第三种思路，在框架层接入MyBatis或者JPA拦截器，进行日志记录发送至指定地址进行日志分析即可，可选用logstash)
4、中间件发送记录日志至资源注册中心
5、资源注册中心分析日志，读取固化的资源注册节点并发送缓存失效标记至各注册节点，此处选用RocketMQ作为消息组件发送，保证每个Consumer都可以接收到失效事件
6、注册节点进入预更新姿态，使自身缓存标记失效
7、通知失败节点重复尝试至最大预设置次数，若依然失败标记服务不可用，发出异常告警，通过通知中心即时发送异常给运维人员
8、注册节点下次读取时先预读缓存标记，发现已失效，则更新缓存并重置缓存失效标记
方案注：
1、借助队列实现缓存更新的并发问题，如Disruptor，按照时间戳排序更新
2、热点数据和静态数据的更新方案完全不同，热点数据的实现是单体数据服务缓存+数据持久化+分布式缓存一致性解决方案，原因是更新频繁，读取频繁的数据如果实现的全业务服务下的缓存一致性，那么缓存是没有意义的，假设有两个数据服务实例，十五个业务实例，若采用此种策略，导致的结果是，数据更新一次，更新代价乘十五，而数据实例间的服务一致性只需增加一倍更新代价。这里考量的是远程调用代价和缓存更新代价的平衡。
3、Spring Cloud我们使用了Eureka Server在此处被复用，用来做资源注册中心，原功能保持不变。这里直接在源码上增加定制功能或者使用SPI机制进行功能嵌入均可，不限定实现方式，这里比较推荐SPI机制，因为我个人信奉：做加法容易，做减法难的准则！！！
注：本文中讲述的MESI协议，内存屏障，Spring Cloud框架，TCC协议等概念性术语需自行了解，我不想把这篇博客变成科普文，见谅。
