在Write Through模式中，当进行写入操作时，缓存服务内部是先写入缓存、再同步到数据库中。此举显然大大降低了性能，故提出了Write Behind模式，其不同点就在于。执行写操作时，缓存服务是先写入缓存，然后通过异步的方式写入数据库。典型地，数据库的Buffer Pool缓冲池中就使用了该缓存模式
该方案的优点
在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比，因为异步，write Behind模式还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
选择这个方案主要是由于第一个方案较为常规，第二个方案实现太困难，所以选择了第三个方案，查阅资料可知第三个方案其实是Linux文件系统的Page Cache的算法
方案如下：
- 读取：查缓存，缓存没有查数据库，同时更新缓存（保证其中一个必有数据）
- 写入：直接更新缓存，数据库由定时任务持久化
- 持久化：定时持久化进数据库，同时删除持久化进数据库的缓存
写入的更新操作 只有 增加和删除由于redis中我使用的数据类型是 set 同时增加（并发）不会新增同样的记录，同时删除 也不会有问题。这样也保证了并发安全。同时该方案几乎完全是在缓存中获取数据查询数据库的时候相对比较少，所以速度非常快。
缺点：数据不能保证安全，如果在未持久化数据库的时候服务器挂了，那么redis中数据丢失，就没办法持久化进数据库了。而且持久化数据库也可能对服务器造成一定的压力（这个在闲时持久化就行）。最重要的一点其实是 持久化时不分数据的新旧 全部持久化一遍，这样如果在一段时间数据没有更新的情况下 ，持久化操作仍然会全部执行一遍，新增了非常多的不必要操作。
还有就是Write Back实现逻辑比较复杂，因为他需要track有哪数据是被更新了的，需要刷到持久层上。操作系统的write back会在仅当这个cache需要失效的时候，才会被真正持久起来，比如，内存不够了，或是进程退出了等情况，这又叫lazy write。
