一致性
- 一致性就是数据保持一致, 在分布式系统中, 可以理解为多个节点中数据的值是一致的。
- 强一致性: 这种一致性级别是最符合用户直觉的, 它要求系统写入什么, 读出来的也会是什么, 用户体验好, 但实现起来往往对系统的性能影响大;
- 弱一致性: 这种一致性级别约束了系统在写入成功后, 不承诺立即可以读到写入的值, 也不承诺多久之后数据能够达到一致, 但会尽可能地保证到某个时间级别（比如秒级别）后, 数据能够达到一致状态;
- 最终一致性: 最终一致性是弱一致性的一个特例, 系统会保证在一定时间内, 能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来, 是因为它是弱一致性中非常推崇的一种一致性模型, 也是业界在大型分布式系统的数据一致性上比较推崇的模型;
集中式redis缓存的三个经典的缓存模式
- 缓存可以提升性能、缓解数据库压力, 但是使用缓存也会导致数据不一致性的问题。一般我们是如何使用缓存呢？有三种经典的缓存模式:
- Cache-Aside Pattern
- Read-Through/Write through
- Write behind
1. Cache-Aside Pattern
Cache-Aside Pattern, 即旁路缓存模式, 它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。
- **Cache-Aside的读流程: **
- 读的时候, 先读缓存, 缓存命中的话, 直接返回数据;
- 缓存没有命中的话, 就去读数据库, 从数据库取出数据, 放入缓存后, 同时返回响应。
缓存没有命中的话，就去读数据库，从数据库取出数据，放入缓存后，同时返回响应。
- **Cache-Aside 写流程: **
- 更新的时候, 先更新数据库, 然后再删除缓存;
2. Read-Through/Write-Through（读写穿透）
Read/Write Through模式中, 服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互, 都是通过抽象缓存层完成的。
- Read-Through的读流程
- 从缓存读取数据, 读到直接返回
- 如果读取不到的话, 从数据库加载, 写入缓存后, 再返回响应。
1.读取缓存中是否有相关数据
2.如果缓存中有相关数据value，则返回
3.如果缓存中没有相关数据，则从数据库读取相关数据放入缓存中key->value，再返回
4.如果有更新数据，则先更新数据库，再删除缓存
5.为了保证第四步删除缓存成功，使用binlog异步删除
6.如果是主从数据库，binglog取自于从库
7.如果是一主多从，每个从库都要采集binlog，然后消费端收到最后一台binlog数据才删除缓存，或者为了简单，收到一次更新log，删除一次缓存
