缓存层建立

野性酷女 2022-05-06 03:05 157阅读 0赞

# 缓存层设计规范 #

## 一.什么是缓存 ##

> 通常是为了解决数据时效性问题，使用redis来缓存热点数据

`我们的缓存层应该用redis吗?`

> 肯定要使用redis，但是却不全是使用redis，还使用到了mongodb

`它们之间怎么协调工作呢?`

> 热数据先通过redis查询，如果数据失效则走mongodb强制缓存，最后才是最差方案走mysql查询

--------------------

## 二.缓存层能解决什么问题? ##

##### 说到缓存层能做什么，就要先说说遇到的问题 #####

*  **微服务跨库查询的问题**  
    在微服务中，通常不相干的业务数据分布在不同的数据库，隔离在不同的物理机甚至数据中心。在中小型公司中盲目分库已经成为了阻碍微服务发展的巨大因素。当一些查询需要跨多个库进行联合筛选过滤分页的时候暴露出了问题  
    ![图片没有描述][format_png]
 *  **面对超大量数据时的问题**  
    在传统的业务系统里，通常会选择建立mysql索引的方式来提高查询效率，但是这仅仅是应对百万级，千万级数据，当面对亿级别的数据的时候就显得无能为力。不得不提到nysql索引，维护索引对mysql来说也是一笔很大的开销，当索引过重的时候会影响插入删除效率，因为每次更新数据表都会修补索引，甚至导致索引重建，索引面对亿级别数据是杯水车薪的，甚至会适得其反
 *  **其他问题**

--------------------

#### 传统解决方案 ####

*  **微服务跨库查询的传统解决方案**
    
    1.  **放弃微服务**。在中小型公司中盲目选择微服务会适得其反，所以回归传统项目
    2.  选择微服务的红利，**屏蔽大量产品需求**
    3.  **数据冗余**。数据冗余也是大部分微服务系统的做法，如果用户库和订单库分布在不同的物理机，订单服务里的订单服务还需要根据用户名称进行检索的时候，意味着订单和用户需要联合查询过滤分页。把用户数据维护到订单库，订单里直接left join临时的用户表。当用户新增或者更新的时候，通过约定的restful，rpc或者消息队列来同步用户数据。当微服务的服务数量过多的时候，往往一个用户新增需要同步几百个甚至几千个数据库，订单数据库里会大量充斥着用户，商品等等不必要的数据，同步间产生的数据时效性问题也会拖慢整个微服务甚至是拖垮
    4.  **数据库合并**。但是随之而来的又是时效性问题，面对超大量数据又成了新的挑战
 *  **面对超大量数据时的解决方案**

--------------------

#### 新的解决方案 ####

*  **微服务跨库查询的解决方案**  
      `微服务分库是为了规范等，盲目分库的时候产生了一个问题，就是跨库联表分页，它的本质问题也是如此`  
      `如果解决了跨库联表分页的问题，响应的一系列问题也将会得到解决`  
    怎么去解决这个问题呢?

> 集中建立全局索引

**建立全局索引的规范:**

1.  全局索引可以分为不同的维度(对象维度和业务维度)
    
     *  业务维度: 不同的业务单独组织全局索引
     *  对象维度: 为用户建立全局索引
2.  全局索引的更新必须要和mysql同步，当mysql更新了用户手机号以后，需要立即通知缓存层的用户全局索引，或者和用户有关的业务索引，强制保证时效性
3.  缓存层可以分多层，在mongodb上面建立redis索引，但不是必须的
4.  缓存层必须保证高可用，99.9999%可用
5.  为用户对象建立的索引一但建立便不能停止维护。通俗的讲，一但注册了一个新用户，就要为该用户建立索引，当用户登陆业务系统的时候，各自维护和自己有关的索引(对象索引或者业务索引)
6.  通常来说对象索引是力度大的，膨胀的，业务索引是力度小的
7.  对象索引可以降级为多个业务索引，多个业务系统也可以升级成一个对象索引，当对象索引过于庞大的时候还可以拆分成多个业务索引。比如:10个业务系统的索引条件组成对象索引1,剩下的9个业务系统的索引条件组成对象索引2，当再增加2个业务系统的时候就开辟对象索引3
8.  根据条件7来说，当一个对象索引中的业务增加急剧膨胀的时候，可以考虑拆分出一个业务索引，并且不用考虑索引合并

**索引示例:**

*  对象索引(mongodb宽表)

<table> 
 <thead> 
  <tr> 
   <th>用户id</th> 
   <th>keyword</th> 
   <th>状态</th> 
   <th>是否登陆过业务系统1</th> 
   <th>是否登陆过业务系统2</th> 
   <th>创建时间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>194212316</td> 
   <td>张三,15086806334</td> 
   <td>0</td> 
   <td>登陆过</td> 
   <td>未陆过</td> 
   <td>2020-11-11 11:11:11</td> 
  </tr> 
 </tbody> 
</table>

`需求1: 业务系统1里需要查询用户列表，并且筛选条件里带有是否今日登陆过业务系统1，这个时候直接使用对象索引 ：用户id，keyword，状态，创建时间，是否登陆过业务系统1`  
`需求2: 业务系统2里需要查询用户列表，并且筛选条件里带有是否今日登陆过业务系统2，这个时候直接使用对象索引 ：用户id，keyword，状态，创建时间，是否登陆过业务系统2`

> 实际上对象索引就是把所有的业务系统需要分页联表查询的字段统一存放，在业务系统里进行筛选的时候，根据查询条件去mongodb筛选分页，并且得到10个用户id，然后再根据10个用户id去业务系统的mysql数据库中进行by id in(1,2,3,4,5,6,7,8,9,10)操作

*  业务索引

<table> 
 <thead> 
  <tr> 
   <th>用户id</th> 
   <th>keyword</th> 
   <th>状态</th> 
   <th>是否登陆过业务系统1</th> 
   <th>创建时间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>194212316</td> 
   <td>张三,15086806334</td> 
   <td>0</td> 
   <td>登陆过</td> 
   <td>2020-11-11 11:11:11</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <thead> 
  <tr> 
   <th>用户id</th> 
   <th>keyword</th> 
   <th>状态</th> 
   <th>是否登陆过业务系统2</th> 
   <th>创建时间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>194212316</td> 
   <td>张三,15086806334</td> 
   <td>0</td> 
   <td>登陆过</td> 
   <td>2020-11-11 11:11:11</td> 
  </tr> 
 </tbody> 
</table>

`实质上就是把对象索引拆分成更小的粒度，和对象索引的区别比较细微`

--------------------

#### 传统分页伪代码 ####

public 分页数据 分页查询方法(分页参数,筛选条件){
      //如果跨库联表过滤只能冗余数据,并且面对大量数据的时候超过1000ms
     return  mysql直接查询数据
    }

#### 建立缓存层的伪代码 ####

public 分页数据 分页查询方法(分页参数,筛选条件){
     //mongodb无疑的快速的，通常此类查询不会超过100ms
     idList =  mongodb通过筛选条件查询(对象索引或者业务索引)出一批用户ID
     //数据库里根据id ranage范围索引查询，最坏的情况在300ms左右
     return  mysql: select user where id in (idList)
    }

--------------------

#### 缓存层的好处是毋庸置疑的，需要建立的，它目前解决了两个问题，但是在将来会解决更多问题。 ####

1.  通过缓存层缓存了数据索引以后，数据库不再需要为查询条件建立过多索引，为mysql提高查询插入修改删除速度
2.  通过缓存层缓存的数据可以先查询mongodb，如果mongodb失效则再走mysql，能解决redis雪崩和缓存传统的问题
3.  思考中…

--------------------

待续…

[format_png]: /images/20220506/f894c4e03b9f48458e4738b8ed448c1c.png