在分布式系统中，特别是最近很火的微服务架构下，有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案，这篇文章将结合一些实际的研发经验，尝试理清其中存在的关键问题以及探寻通用的解决之道。
什么是静态数据这里静态数据是指不经常发生变化或者变化频率比较低的数据，比如车型库、用户基本信息、车辆基本信息等，车型库这种可能每个月会更新一次，用户和车辆基本信息的变化来源于用户注册、修改，这个操作的频率相对也是比较低的。
另外这类数据的另一个特点是要求准确率和实时性都比较高，不能出现丢失、错误，以及过长时间的陈旧读。
具体是不是应该归类为静态数据要看具体的业务，以及对变化频率高低的划分标准。在这里的业务定义中，上边这几类数据都归为静态数据。
为什么需要缓存在面向用户或车联网的业务场景中，车型信息、用户基本信息和车辆基本信息有着广泛而高频的业务需求，很多数据都需要对其进行关联处理。在这里缓存的目的就是为了提高数据查询效率。静态数据通常都保存在关系型数据库中，这类数据库的IO效率普遍不高，应对高并发的查询往往捉襟见肘。使用缓存可以极大的提升读操作的吞吐量，特别是KV类的缓存，没有复杂的关系操作，时间复杂度一般都在O(1)。注意这里说的缓存指内存缓存。
当然除了使用缓存，还可以通过其它手段来提高IO吞吐量，比如读写分离，分库分表，但是这类面向关系型数据库的方案更倾向于同时提高读写效率，对于单纯提升读吞吐量的需求，这类方案不够彻底，不能在有限的资源情况下发挥更好的作用。
通用缓存机制下面将直接给出一个我认为的通用处理机制，然后会对其进行分析。
对于某个具体的业务，其涉及到六个核心程序：
业务服务：提供对某种业务数据的操作接口，比如车辆服务，提供对车辆基本信息的增删改查服务。