问题提出
我最近发现了一个很有意思的问题。常见的业务解决都是拉模型。如，当用户查询其订单，其流程是经过web层，服务层，到数据库，按照层级关系进行组织。上一层主动拉下一层的数据，下一层除非有人拉数据，否则不会执行任何的动作。
这在某些情况下会出现一些问题。比如说有缓存的情况下。常见的即，在同一个服务内，不同的接口修改了底层的数据，但是却没有刷新缓存。
当然，这在我们使用缓存的时候就预计到了会出现这种情况。多数情况下，也不会有什么问题。但是，如果一个业务需求既要求高性能——即要求QPS高，又要求响应时间短，同时还要求数据实时性好，那么这种常见的模式，很难满足了。我举一个例子来说，商家设定的有关价格的信息，是希望能够在客户端得到反馈的，而用户在客户端上访问量是极高的。这就是一个典型的场景。
通常对性能苛刻意味着需要进行缓存，而对数据实时性的要求，又是不好进行缓存的。它并非是不能缓存，可以通过设置缓存过期时间很短，以达到准实时性——如果业务允许的话。且不谈这个准实时是否能达到业务需求，单单一个设置短的缓存过期时间，就会带来缓存频繁刷新的问题。在数据不经常变化，并且高并发的情况下，短的过期时间，会给服务器带来巨大的压力，因为缓存过期还容易导致缓存穿透的问题。尤其是，如果数据不经常变动，那么设置一个短的过期时间，几乎毫无意义。
解决方案
当然，现在也有一种比较成熟的方案，只是没有见到成体系的文字描述，现在我记录于下。我称之为“预计算模型”。它强调的是，在数据变更途径可控的情况下，每次数据变更之后，重新计算各色业务。
这里要区别两个角色，一个是数据变更方，另外一个是业务方。使用到这份数据的业务方会有很多，但并不是所有的业务方都有这种苛刻的需求。所以实际上，这里的业务方仅仅指那些关心数据变动的业务方。数据变更方在数据变更之后需要通知业务方，那些关心这些变动的业务方，则立刻执行重新计算的逻辑。
这里额外讨论一下通知的方式。通知的方式有多种。不论采用何种方式，其核心在于，数据变更方不应该知道有谁关心这个变更。如果变更方必须知道要有几个业务方，以至于每次接入一个新的业务方的时候，都需要变更方更改自身的逻辑，那么这就是典型的反向耦合了。我有两个比较好的建议，第一个建议是采用观察者模式。这种模式要求观察者能够自动注册到被观察者（也就是业务变更方）处，如果需要被观察者主动寻找观察者，那么就陷入了反向耦合；另外一个建议是采用消息通知机制。
该模型最大的困难在于，很多时候无法控制所有的变更入口。更可怕的是，在当下控制住了入口，结果一段时间后，出现了一个新入口，而你却毫不知情。这很显然会出现数据不一致的情况。一种显而易见的缓解方法——它并不能彻底解决这个问题——就是，设置一个缓存过期的时间，或者在间隔一段时间之后执行一些修复操作，由程序检测到数据不一致的地方，并且将其同步到一致的状态。
避免出现这样情况的一种方法是，在数据持久化入口——通常也就是数据库访问层面做控制。举一个例子，使用spring的aop技术，在所有调用里面添加上通知机制的代码。这难免会带来性能的损耗。因此，可以提供异步通知机制。
实际上，在当下微服务盛行的时代，如果微服务划分得好的话，这些入口是很好收拢的。因为这些入口必然是位于微服务的边界之处，只要控制好了这几个地方，就等于控制住了别的地方。我反对的一种常见的错误实践，就是因为好几个微服务都由一个团队维护，因此他们会无意间打破这种边界，比如说A服务访问B服务的数据库，而不是通过B服务提供的服务来访问（不用怀疑，我吐槽的就是我们团队，233333）。
后记
这个模型实际上会有一些违背直觉的感觉。其实不然。如果从分层结构上说，这种举措，相当于底层主动通知上层。这是一种很典型的分层结构下的变更通知机制，有时候也被称为回调机制。它和一般的“底层调用上层”的区别就在于，它并没有直接调用上层，而仅仅是通知了上层。从这个意义上来说，使用观察者模式并不是一个很好的方案，采用消息机制，其耦合程度要更加弱。
