缓存服务探索
更新缓存的四种设计模式(Design Pattern)
- Cache aside
- Read through
- Write through
- Write behind caching
Cache aside pattren
- 添加：应用程序先从cache中取数据，取不到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从cache中取数据，命中则返回。
- 更新：数据库更新数据，成功后，缓存失效。
Read/Write Through Pattern
把更新的操作由缓存代理，从应用程序看只操作了单一的存储。
- Read through: 在查询操作中更新缓存
- Write through：在数据有更新时，如果没有命中缓存，直接更新数据库然后返回；如果命中了缓存，则更新缓存，再由cache自己更新数据库。
Write Behind Caching Pattern
在更新数据的时候，只更新缓存，不更新数据库。由缓存异步的批量更新数据库。
分布式系统的事务处理
要保证数据的高可用 -> 数据备份多个 -> 数据一致性问题 -> 性能问题
一致性模型
简单列有三种：
- Weak弱一致性：写操作后，读操作不一定能读到写入的数据
- Eventually最终一致性：写操作后，读操作可能读不出来，但在一个时间节点后一定能读出来
- Strong强一致性：写操作一旦成功，在任意副本上的读操作都能读出来 弱一致性与最终一致性是异步冗余的，强一致性是同步冗余的。异步意味着性能更高，同步意味着性能降低。但是异步则更复杂，而同步则意味着减单。
技术实现模型
Master-Slave 主从模式
Master-Slave是一种主从结构，slave是master的备份，例如redis的主从模式。读请求由从节点负责，写请求由主节点负责，并由主节点同步到从节点中。 从节点同步主节点的方式有主节点push，或由从节点定期pull。 缺点是当主节点宕机时，从节点还有数据没有pull完，则从节点或产生数据不同步。如果可以忍受数据不一致，则可以让从节点直接变成主节点；否则需要等主节点恢复，且master的数据不丢失，并且从节点能正常pull完数据。 Master-Slave可以是强一致性的，既有写操作时，先写完自己的数据，然后写从节点数据，两边都成功后返回成功；如果从节点返回失败则可以标记从节点不可用，并继续提供服务，等从节点正常，或是回滚自己并返回失败。
Master-Master 多主模式
Master-Master是一个系统存在两个或多个主节点的架构。每一个节点都提供读写服务。不会产生单点故障问题。 缺点是当对同一数据进行修改时，解决冲突合并是比较困难的。
Two/Three Phase Commit
这个协议缩写叫2PC，中文名叫两阶段提交。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
第一阶段：
- 协调者会所有参与者，是否可以执行提交操作。
- 各个参与者开始事务执行的准备工作。如：为资源上锁，预留资源，写undo/redo log……
- 参与者响应协调者，如果事务的准备工作成功，则回应“可以提交”，否则回应“拒绝提交”。
第二阶段：
- 如果所有的参与者都回应“可以提交”，那么，协调者向所有的参与者发送“正式提交”的命令。参与者完成正式提交，并释放所有资源，然后回应“完成”，协调者收集各结点的“完成”回应后结束这个Global Transaction。
- 如果有一个参与者回应“拒绝提交”，那么，协调者向所有的参与者发送“回滚操作”，并释放所有资源，然后回应“回滚完成”，协调者收集各结点的“回滚”回应后，取消这个Global Transaction。
缺点：
- 同步阻塞操作会影响性能。
- 超时后的处理复杂。
- 当完成第一阶段后，参与者在第二阶段没有收到决策。那么数据节点会进入不知所措的状态，这个状态会block整个事务。
引申出三阶段提交，在询问的时候不锁资源，等所有人都同意了才锁资源。