为什么用Redis 作缓存?
这里拿MySQL 举例，MySQL 数据是存储在硬盘上的，虽然MySQL 有查询缓存，但在查询数据时不可避免的会读盘载入数据，写入数据更是不可避免进行磁盘I/O 这之间的耗时比Redis多得多。在应对海量事务请求时MySQL 自然无法承受，Redis 舍弃MySQL 数据更可靠高持久化的特点直接将所有数据存储在内存中，换来了比MySQL高 数十倍的事务性能(QPS)，所以用Redis 作缓存是一个合理的 方案.
Redis 缓存的几种模式
Cache aside (旁路缓存)
最常见的模式了，直接把Redis 当作 后端数据库的 查询buffer, 客户直接请求 redis 服务查数据. client -> redis
Read through (读穿透)
在旁路缓存的模式上加入一层代理服务(也就所谓的数据服务)，客户不直接请求redis, 而是向代理服务 请求插数据，代理服务从redis 或者从后端数据库(缓存击穿) 拿数据返回给客户
Write through (写穿透)
跟上面读穿一样，只不过是写业务代理，写入顺序和 (write back)异步写入 相反，先写数据库，在同步缓存。客户端写请求不直接给后端数据库或者Redis 而是向代理发送写请求，有代理操作Redis 和 后端数据库.
Write-Behind[write back] (异步写入)
和写穿相反，先写缓存，在异步更新数据库。也是由代理服务器完成，可以说是上面写穿的变种.
异步写入后端数据库可以作写入请求合并、定时写入、批量写入...
优缺点分析
旁路
缺点: 编码工作较其他三种稍复杂一点，因为需要分别与缓存服务和后端数据服务通讯
优点: 直接和数据服务本身通讯对比其他三种省去中间商延迟
代理(读/写穿、异步写回)
优点：资源统一管理，客户只需要找代理服务就行，不用向旁路一样还需要去操作后端数据库
缺点：代理服务很可能为关键节点，出现延迟不可避免。或者说中间多了一层链路传输，延迟会增加。
谁先更新？
这部分说的是，数据变更是先更新后端数据库还是先更新缓存.
这里得看数据一致性要求，如果对数据一致性要求不那么严格，比如排行榜之类的，可以先更缓存，再写后端数据库
要求比较严格的一致性先更新数据库，再更新缓存，但更新缓存可能会出现时序问题，所以还是删除为妙，否则为了保序带来的工作了可能不小。
怎么更新
现在稳妥的方案是先更新数据库，在删缓存【因为先更新缓存会可能会出现缓存挂了，没写后端数据服务，数据没了...或者网络原因的时序问题导致最终出现问题】。
四种模式怎么选
用的最多的是旁路缓存
银行金融类要求高一致性的，不能忍受数据丢失，对缓存要求及时高，用write through