画布 1
缓存更新的设计模式
  Cache Aside Pattern
    失效
      应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
    命中
      应用程序从cache中取数据，取到后返回。
    更新
      先把数据存到数据库中，成功后，再让缓存失效。
        只让缓存失效，并不把缓存更新。
正常的操作是 invalidate，但 facebook 的方案是 delete。
  Read/Write Through Pattern
    Read Through
      而Read Through则用缓存服务自己来加载，从而对应用方是透明的。
    Write Through
      当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己更新数据库（这是一个同步操作）
  Write Behind Caching Pattern
    在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比（因为直接操作内存嘛 ），因为异步，write backg还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
    类似Linux文件系统的Page Cache的算法，数据不是强一致性的，而且可能会丢失（我们知道Unix/Linux非正常关机会导致数据丢失，就是因为这个事）
  population/loading strategy
    manual
    sync
    async
  Eviction strategy
    触发条件
      time-based
      size-based
        weight-based
      reference-based
    淘汰线程
      同步
      异步
    淘汰算法
      LRU（最常用）
      LFU
      FIFO
  只要有两个并发的写操作，缓存就可能被污染，但更新操作不写缓存，降低了写的概率，也就降低了缓存出错的概率。
非强一致性的算法的思路：要么通过2PC或是Paxos协议保证一致性，要么就是拼命的降低并发时脏数据的概率
  。可以理解为，应用认为后端就是一个单一的存储，而存储自己维护自己的Cache。