标签：load 读写分离 做了 计算 打折 disco 应用 主从同步 oql
本文主要讨论这么几个问题：
（1）“缓存与数据库”需求缘起
（2）“淘汰缓存”还是“更新缓存”
（3）缓存和数据库的操作时序
（4）缓存和数据库架构简析
一、需求缘起
场景介绍
缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。
例如对于用户的余额信息表account(uid, money)，业务上的需求是：
（1）查询用户的余额，SELECT money FROM account WHERE uid=XXX，占99%的请求
（2）更改用户余额，UPDATE account SET money=XXX WHERE uid=XXX，占1%的请求
由于大部分的请求是查询，我们在缓存中建立uid到money的键值对，能够极大降低数据库的压力。
读操作流程
有了数据库和缓存两个地方存放数据之后（uid->money），每当需要读取相关数据时（money），操作流程一般是这样的：
（1）读取缓存中是否有相关数据，uid->money
（2）如果缓存中有相关数据money，则返回【这就是所谓的数据命中“hit”】
（3）如果缓存中没有相关数据money，则从数据库读取相关数据money【这就是所谓的数据未命中“miss”】，放入缓存中uid->money，再返回
缓存的命中率 = 命中缓存请求个数/总缓存访问请求个数 = hit/(hit+miss)
上面举例的余额场景，99%的读，1%的写，这个缓存的命中率是非常高的，会在95%以上。
那么问题来了
当数据money发生变化的时候：
（1）是更新缓存中的数据，还是淘汰缓存中的数据呢？
（2）是先操纵数据库中的数据再操纵缓存中的数据，还是先操纵缓存中的数据再操纵数据库中的数据呢？
（3）缓存与数据库的操作，在架构上是否有优化的空间呢？
这是本文关注的三个核心问题。
二、更新缓存 VS 淘汰缓存
什么是更新缓存：数据不但写入数据库，还会写入缓存
什么是淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉
更新缓存的优点：缓存不会增加一次miss，命中率高
淘汰缓存的优点：简单（我去，更新缓存我也觉得很简单呀，楼主你太敷衍了吧）
那到底是选择更新缓存还是淘汰缓存呢，主要取决于“更新缓存的复杂度”。
例如，上述场景，只是简单的把余额money设置成一个值，那么：
（1）淘汰缓存的操作为deleteCache(uid)
（2）更新缓存的操作为setCache(uid, money)
更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率
如果余额是通过很复杂的数据计算得出来的，例如业务上除了账户表account，还有商品表product，折扣表discount
account(uid, money)
product(pid, type, price, pinfo)
discount(type, zhekou)
业务场景是用户买了一个商品product，这个商品的价格是price，这个商品从属于type类商品，type类商品在做促销活动要打折扣zhekou，购买了商品过后，这个余额的计算就复杂了，需要：
（1）先把商品的品类，价格取出来：SELECT type, price FROM product WHERE pid=XXX
（2）再把这个品类的折扣取出来：SELECT zhekou FROM discount WHERE type=XXX
（3）再把原有余额从缓存中查询出来money = getCache(uid)
（4）再把新的余额写入到缓存中去setCache(uid, money-price*zhekou)
更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。
however，淘汰缓存操作简单，并且带来的副作用只是增加了一次cache miss，建议作为通用的处理方式。
三、先操作数据库 vs 先操作缓存
OK，当写操作发生时，假设淘汰缓存作为对缓存通用的处理方式，又面临两种抉择：
（1）先写数据库，再淘汰缓存
（2）先淘汰缓存，再写数据库
究竟采用哪种时序呢？
还记得在《冗余表如何保证数据一致性》文章（点击查看）里“究竟先写正表还是先写反表”的结论么？
对于一个不能保证事务性的操作，一定涉及“哪个任务先做，哪个任务后做”的问题，解决这个问题的方向是：
如果出现不一致，谁先做对业务的影响较小，就谁先执行。
由于写数据库与淘汰缓存不能保证原子性，谁先谁后同样要遵循上述原则。
假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致。
假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次Cache miss。
结论：数据和缓存的操作时序，结论是清楚的：先淘汰缓存，再写数据库。
四、缓存架构优化
上述缓存架构有一个缺点：业务方需要同时关注缓存与DB，有没有进一步的优化空间呢？有两种常见的方案，一种主流方案，一种非主流方案（一家之言，勿拍）。
主流优化方案是服务化：加入一个服务层，向上游提供帅气的数据访问接口，向上游屏蔽底层数据存储的细节，这样业务线不需要关注数据是来自于cache还是DB。
非主流方案是异步缓存更新：业务线所有的写操作都走数据库，所有的读操作都总缓存，由一个异步的工具来做数据库与缓存之间数据的同步，具体细节是：
（1）要有一个init cache的过程，将需要缓存的数据全量写入cache
（2）如果DB有写操作，异步更新程序读取binlog，更新cache
在（1）和（2）的合作下，cache中有全部的数据，这样：
（a）业务线读cache，一定能够hit（很短的时间内，可能有脏数据），无需关注数据库
（b）业务线写DB，cache中能得到异步更新，无需关注缓存
这样将大大简化业务线的调用逻辑，存在的缺点是，如果缓存的数据业务逻辑比较复杂，async-update异步更新的逻辑可能也会比较复杂。
五、其他未尽事宜
本文只讨论了缓存架构设计中需要注意的几个细节点，如果数据库架构采用了一主多从，读写分离的架构，在特殊时序下，还很可能引发数据库与缓存的不一致，这个不一致如何优化，后续的文章再讨论吧。
六、结论强调
（1）淘汰缓存是一种通用的缓存处理方式
（2）先淘汰缓存，再写数据库的时序是毋庸置疑的
（3）服务化是向业务方屏蔽底层数据库与缓存复杂性的一种通用方式
本文主要讨论这么几个问题：
（1）数据库主从延时为何会导致缓存数据不一致
（2）优化思路与方案
一、需求缘起
上一篇《缓存架构设计细节二三事》中有一个小优化点，在只有主库时，通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步，读写分离的数据库架构下，有可能出现脏数据入缓存的情况，此时串行化方案不再适用了”，这就是本文要讨论的主题。
二、为什么数据会不一致
为什么会读到脏数据，有这么几种情况：
（1）单库情况下，服务层的并发读写，缓存与数据库的操作交叉进行
虽然只有一个DB，在上述诡异异常时序下，也可能脏数据入缓存：
1）请求A发起一个写操作，第一步淘汰了cache，然后这个请求因为各种原因在服务层卡住了（进行大量的业务逻辑计算，例如计算了1秒钟），如上图步骤1
2）请求B发起一个读操作，读cache，cache miss，如上图步骤2
3）请求B继续读DB，读出来一个脏数据，然后脏数据入cache，如上图步骤3
4）请求A卡了很久后终于写数据库了，写入了最新的数据，如上图步骤4
这种情况虽然少见，但理论上是存在的，后发起的请求B在先发起的请求A中间完成了。
（2）主从同步，读写分离的情况下，读从库读到旧数据
在数据库架构做了一主多从，读写分离时，更多的脏数据入缓存是下面这种情况：
1）请求A发起一个写操作，第一步淘汰了cache，如上图步骤1
2）请求A写数据库了，写入了最新的数据，如上图步骤2
3）请求B发起一个读操作，读cache，cache miss，如上图步骤3
4）请求B继续读DB，读的是从库，此时主从同步还没有完成，读出来一个脏数据，然后脏数据入cache，如上图步4
5）最后数据库的主从同步完成了，如上图步骤5
这种情况请求A和请求B的时序是完全没有问题的，是主动同步的时延（假设延时1秒钟）中间有读请求读从库读到脏数据导致的不一致。
那怎么来进行优化呢？
三、不一致优化思路
有同学说“那能不能先操作数据库，再淘汰缓存”，这个是不行的，在《缓存和数据库先操作谁》的文章中介绍过。
出现不一致的根本原因：
（1）单库情况下，服务层在进行1s的逻辑计算过程中，可能读到旧数据入缓存
（2）主从库+读写分离情况下，在1s钟主从同步延时过程中，可能读到旧数据入缓存
既然旧数据就是在那1s的间隙中入缓存的，是不是可以在写请求完成后，再休眠1s，再次淘汰缓存，就能将这1s内写入的脏数据再次淘汰掉呢？
答案是可以的。
写请求的步骤由2步升级为3步：
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（3）休眠1秒，再次淘汰缓存
这样的话，1秒内有脏数据如缓存，也会被再次淘汰掉，但带来的问题是：
（1）所有的写请求都阻塞了1秒，大大降低了写请求的吞吐量，增长了处理时间，业务上是接受不了的
再次分析，其实第二次淘汰缓存是“为了保证缓存一致”而做的操作，而不是“业务要求”，所以其实无需等待，用一个异步的timer，或者利用消息总线异步的来做这个事情即可：
写请求由2步升级为2.5步：
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（2.5）不再休眠1s，而是往消息总线esb发送一个消息，发送完成之后马上就能返回
这样的话，写请求的处理时间几乎没有增加，这个方法淘汰了缓存两次，因此被称为“缓存双淘汰”法。这个方法付出的代价是，缓存会增加1次cache miss（代价几乎可以忽略）。
而在下游，有一个异步淘汰缓存的消费者，在接收到消息之后，asy-expire在1s之后淘汰缓存。这样，即使1s内有脏数据入缓存，也有机会再次被淘汰掉。
上述方案有一个缺点，需要业务线的写操作增加一个步骤，有没有方案对业务线的代码没有任何入侵呢，是有的，这个方案在《细聊冗余表数据一致性》中也提到过，通过分析线下的binlog来异步淘汰缓存：
业务线的代码就不需要动了，新增一个线下的读binlog的异步淘汰模块，读取到binlog中的数据，异步的淘汰缓存。
提问：为什么上文总是说1s，这个1s是怎么来的？
回答：1s只是一个举例，需要根据业务的数据量与并发量，观察主从同步的时延来设定这个值。例如主从同步的时延为200ms，这个异步淘汰cache设置为258ms就是OK的。
四、总结
在“异常时序”或者“读从库”导致脏数据入缓存时，可以用二次异步淘汰的“缓存双淘汰”法来解决缓存与数据库中数据不一致的问题，具体实施至少有三种方案：
（1）timer异步淘汰（本文没有细讲，本质就是起个线程专门异步二次淘汰缓存）
（2）总线异步淘汰
（3）读binlog异步淘汰
LinkedHashMap维护着一个运行于所有条目的双重链接列表。此链接列表定义了迭代顺序，该迭代顺序可以是插入顺序（insert-order）或者是访问顺序，其中默认的迭代访问顺序就是插入顺序，即可以按插入的顺序遍历元素。基于LinkedHashMap的访问顺序的特点，可构造一个LRU（Least Recently Used）最近最少使用简单缓存。也有一些开源的缓存产品如ehcache的淘汰策略（LRU）就是在LinkedHashMap上扩展的。
public class LruCache<K, V> extends LinkedHashMap<K, V> {
/** 最大容量 */
private int maxCapacity;
public LruCache(int maxCapacity) {
super(16, 0.75f, true);
this.maxCapacity = maxCapacity;
}
public int getMaxCapacity() {
return this.maxCapacity;
}
public void setMaxCapacity(int maxCapacity) {
this.maxCapacity = maxCapacity;
}
/**
* 当列表中的元素个数大于指定的最大容量时，返回true,并将最老的元素删除。
*/
@Override
protected boolean removeEldestEntry(java.util.Map.Entry<K, V> eldest) {
if (super.size() > maxCapacity) {
return true;
}
return false;
}
}
public class LruCacheTest {
public static void main(String[] args) {
LruCache<String, Object> cache = new LruCache<String, Object>(10);
for (int i = 1; i <= 15; i++) {
cache.put(i + "", i);
}
// 此时访问指定KEY的元素
cache.get("10");
Iterator<Entry<String, Object>> iterator = cache.entrySet().iterator();
for (; iterator.hasNext();) {
Entry<String, Object> entry = iterator.next();
System.out.println("key=" + entry.getKey() + ",value=" + entry.getValue());
}
}
}
输出如下：
key=7,value=7 key=8,value=8 key=9,value=9 key=11,value=11 key=12,value=12 key=13,value=13 key=14,value=14 key=15,value=15 key=10,value=10
标签：load 读写分离 做了 计算 打折 disco 应用 主从同步 oql
原文地址：http://www.cnblogs.com/extjs4/p/6431141.html
