这里的缓存是指应用程序的缓存，假设你使用 memcached 或 Redis作为大型缓存。

当一个请求到达应用程序缓存中，你需要检查一下数据是否在缓存中，缓存查找通常是根据key。如果数据在缓存中，你可以直接返回到客户端。

如果不在缓存，你需要到数据库中查询，然后放入缓存，下一次再查询同样数据就可以在缓存中找到。

第一个问题是，当然是为什么计算科学中最难的两件事是命名和缓存失效。

如果你想管理缓存失效问题，真的非常棘手，当基础数据库中数据变化，你怎么让缓存的中应该过期或者更新？一个选择是使用过期失效算法，这些算法分辨出数据库改变影响了哪些缓存条目，，但这些算法都是脆弱和容易出错的。此外你可以有一个失效时间的解决办法，但是这容易导致脏数据。

另外一个问题竞争问题，如果你有两个进程并发写入数据库和更新缓存，它们写数据库是一个顺序，而更新缓存是以另外一种顺序，那么就导致缓存中数据和数据库数据不一致了。

其他还有各种不一致并发问题，大部分系统都是假装这些竞争并发不存在，掩耳盗铃而已。

另外一个问题是冷启动，通过缓存清零，加载新的改变数据，这会导致负载突然增加。数据库超载。

LinkedIn在谈话中大量篇幅分析了数据库四种机制原理和问题，有兴趣者可翻看原文，下面提出结论。

LinkedIn认为对传统数据库的如下机制进行重新思考。

重新思考的架构图如下：

这实际是一种EventSourcing架构(本站有大量讨论)，将写操作变成不可变的事件流，输入Apache Kafka，然后通过输出更新各种数据库。

现在，我们可以将所有写操作变成不可变事件（事实），每个不可变事件追加到事务日志或称为事件流中，这个事务日志是真正简单，只能追加append数据的数据结构。Apache Kafka提供append-only日志数据结构，而且以一种可靠的可扩展的方式，它会将一切写到磁盘，跨多个机器复制数据，只要你不丢失服务器，就不会丢失数据，它将流分区到多个服务器能够水平扩展， 每秒处理数百万的写操作。

当这做时，你不需要直接对主数据库进行写操作，你直接将写操作追加到日志中即可。

现在这个系统写入将非常快且可扩展，因为你仅仅将写操作事件追加到日志（Kafka）中，但是如果读数据怎么办？从日志中读数据可是非常慢的，需要扫描整个日志。

解决办法是从事务日志中建立类似数据库的物化视图materialized view。物化视图就像第二索引，其数据来自于日志数据，为快速读取而优化，一个物化视图是日志的一部分子集放入缓存中， 你能从日志中随时重新构建，同样数据有不同的物化视图：key-value存储, 完整文本full-text搜索索引, 图索引, 分析系统等。

（banq注：这里体现ES读写分离，读是从缓存，写直接写入日志）

你可以认为这是一种“分拆unbundling”的数据库，将原先放入数据库这样一个软件中的模块分解为多个可以灵活方式组合的组件。

接着该谈话讨论如何使用Apache Kafka实现日志的具体实现原理，可参考原文。

以上实际是Apache Samza核心原理，也就是为什么它能在大数据架构中替代传统数据库的原理所在。

更多参考：

LinkedIn构建实时流数据平台实践指南

实时流Streaming大数据：Storn,Spark和Samza

[该贴被banq于2015-03-05 15:48修改过]

[该贴被clonalman于2015-04-05 18:56修改过]

聚合查询，不关map-reduce的事，数据分布式存放，不整点大数据技术怎么分析？