title: 微服务架构下的缓存系统设计（一）
date: 2018-12-15 13:25:45
tags:
- 微服务
- 分布式
- 缓存
- Redis
categories: - 微服务
说到互联网时代，可能对于技术人员来说，就是大数据、高并发、分布式等各种代名词。尤其是当下十分火热的微服务，当然微服务的生态过于庞大，我们暂且不讨论，今天来说一下在微服务中如何设计一个缓存系统，这是我在项目中的总结，不对之处还请大家指正。
首先问大家一个问题，为什么要使用缓存系统？
这个问题留给大家去思考。
首先我们要说一下这个缓存系统针对的目标是什么，在我的个人项目中，使用到缓存的地方大概有三处：
- 用户基本信息
- Mybatis的二级缓存
- 一些其他的静态信息
- 当然也使用了Redis做了短信服务的频次控制
我们可以发现这些数据有一些特点：
- 更改频率比较低
- 要求准确率和实时性比较高
当然具体的数据划分还要根据业务的需求来做。
下面我们来看一下我在项目中的缓存系统设计
缓存系统设计图
我们以某个业务服务为例，可以看到我们的核心模块：
- 数据操作入口
- 持久化的队列
- 数据校验服务
- 缓存处理程序
- 数据一致性检查服务
- Redis HA
- MySQL HA
我们来分别说一下他们的作用，
数据操作入口
我们都知道，我们的服务往往跨越了多个终端，移动、web、以及C端，某个业务如果分别对这些终端提供数据操作入口，那么很容易引起数据的一致性问题，另一方面，数据操作的管理及其复杂，重复代码变多，那么这时候提供一个统一的操作入口，对外发布统一的接口就变得尤为重要。
数据校验服务
当然这个服务各有见解，根据不同的业务需求对数据做一些业务上的校验或者数据库约束性的校验，对一些简单的校验可以在Web层提供统一的校验，复杂的业务校验我认为还是要在service层进行。
持久化的队列
我相信大家对微服务中提倡的一个概念一定很熟悉，那就是解耦合，各个服务之间是独立的。
我们来思考一下，去掉队列之后，数据可以直接在更新到mysql之后进行缓存，好像并没有什么影响，但是扩展性好像差了一些。
这里使用队列不仅仅是单独为缓存服务提供的，我以项目中的订单系统为例，给大家看一下，MQ在业务中的作用，
大家可以看到在订单系统下单持久化之后，将订单信息发送到延时队列中，这里为什么要使用延时队列呢？因为用户下单之后有一个支付的时间，所以要有一定的期限供用户支付。MQ在这里另外一方面的作用就是异步操作，大家可以想一下，在高并发下，同步能否抗的住？
好了，我们回到缓存系统，为什么要采用持久化的队列？开头我们说过，这些数据是要求准确性的，所以在这一系列流程中，很有可能因为网络波动，或者业务服务自身问题造成数据的丢失，为了解决这些问题，我们还需要使用MQ的ack机制（缺点是重复数据与性能低（大家可以想一下tcp的ack机制）），当然如何抉择还是根据具体的业务来做。
缓存处理程序
缓存处理程序无非是把我们的业务数据转换成Redis支持的数据类型，项目中，为了方便（懒），我大部分使用的json的序列化机制，Redis客户端我选择的基于Jedis的RedisTemplate，当然也可以选择使用luttuce，luttuce提供了更多优秀的特性，大家可以自己了解。这里有一点希望大家注意的是，对于数值型的字符串，使用json进行序列化时是无法使用Redis的incr操作的，只能选择在业务中进行操作，因为可以选择使用StringRedisSerializer来对数值型的数据进行序列化。
数据一致性检查
为什么需要数据一致性检查？因为我们的DB持久化操作与缓存操作是异步的，难免在DB持久化之后，缓存的过程中出现异常，或者HA集群在主从同步的时候发生异常，这时候一致性检查就显得尤为重要，但是一致性检查同时也带来了新的问题，那就是对DB的压力，所以没有什么方案是最好的，只能在HA与一致性作出抉择。
在一致性检查之外，我们还可以选择另外一种方案，那就是过期策略，过期策略不需要一致性检查，但是他的问题在于过期时间的选择，大量数据过期引发的缓存穿透和雪崩又需要我们在服务中提供新的解决方案，例如：缓存的持久化方案：例如RDB、AOF，服务上线前的缓存预热、服务降级、熔断的策略、采用二级缓存、或者专门针对缓存服务的降级：页面降级、读写降级等。
总结
总的来说，缓存服务是业务中必不可少的一环，我们应该考虑提供统一的缓存服务，并针对不同的业务进行优化和定制。这一篇主要是对缓存整体架构的说明，后面的文章将详细的介绍缓存的实际使用以及Redis的相关知识。
