分布式系统：Spark和Memcache

1.Spark

缺乏利用分布式内存的抽象
RDD是只读
默认持久化在内存中，可以溢出到硬盘（能指定优先级）

适合批量分析应用，不使用日志，而是记录下操作的关系（族谱），便于后续恢复。
driver跟踪RDDs’ lineage

使用memcache减轻读负载
in-memory hash table

对get请求，client使用UDP协议，并将get error也视为缓存未命中，但不会将得到的值插入到memcache中
对set和delete，使用TCP协议

1.1 Lineage graph

可以看作MapReduce的升级版，非常适合处理大量数据。对小数据、流数据支持不足。输入被分片存储在HDFS中。
Narrow Dependencies：在本地就能完成的计算，可以进行并行计算。
Wide Dependencies：相当于把分布在各个节点的数据分片重新分配，需要和其他节点进行通信。可能需要等待其他节点的计算。

（1）调用Transformations实际上都是在建立Lineage graph。因为一般情况下建立完Lineage graph后才进行计算，可以对Lineage graph中的操作进行优化。调度时会考虑数据局部性。
（2）只有调用Actions后，才会进行计算。每次调用都会重新计算，除非用户调用persist()，默认会将其缓存在内存中，这样就避免重复计算。例如，论文中PageRank中的links。而这在MapReduce是无法实现的。

1.2 fault recovery

（1）当持久化RDD时，程序员可以指定它必须在几台机器上复制。

（2）有Lineage graph的存在，容错处理可以重复计算来实现，或者另分配一个节点来完成。
（3）但对于Wide Dependencies来说，因为中间的计算结果不会保存，如果有一个work出错，如下图所示，那么所有work之前的工作也需要重新执行，这非常麻烦。
论文中的方法是：对Wide Dependencies，采用类似MapReduce方法在持有父分区的节点上存储中间记录或者存储到HDFS中（也可采用检查点的方式）。

2.Memcache

2.1 网站发展框架

（1）前面主要是CPU是限制，可以通过部署多个Front End服务器服务更多客户端

（2）之后，数据库就变成了性能瓶颈。可以部署多个数据库，对数据进行分片（shred）来实现。但这种方式涉及到分布式事务，而且因为某些热点key并不会使得数据库的负载降低

（3）解决方法是，在前端服务器和后端数据库之间加入缓存层。这会使得处理读请求的速度大大加快，可以处理远超DB负载的读请求能力，但需要保证缓存层不会出错，否则会造成DB过载。

（4）论文中的方法：为此，引入了Gutter，如果client没有得到memcached的响应，就会请求Gutter，如果未命中，再向DB请求后，插入到Gutter中。在Gutter中的条目快速消逝，但client不会向其发送delete。

为何不用向Gutter发送delete呢？
这是因为Gutter只有在memcached出错的情况下才会接管其工作，如果需要向其发送delete那么正常情况下，FE或DB无法判断是否有其他memcached出错，因此为保险起见也需要一直向其发送，造成额外负担。

2.2 复制和分片结合

（1）在不同的数据中心，采用的是复制的方式。（DB也是独立的）
（2）在同一个区域内，也分为了不同的集群。每个集群的FE和MC是独立的，但DB是共有的。这样做的好处是，改善某些热点key过度访问问题，而且另一个不需要维护太多的TCP连接（ O ( n 2 ) O(n^2) O(n2)增长）。

（3）上述的问题是会造成一定的资源浪费，因为大多数的数据被访问的并不频繁，在上述方案中也会被复制多份，浪费内存资源。
解决方法是Regional Pools，即不同的集群共享一部分MC，这部分MC存储的不是热点的key。

2.3 缓存一致性

实际上处理写请求时，DB也会发出使Memcache删除的请求。

（1）为什么写请求删除Memcache中的数据，而不是进行更新？
如下图所示，不同客户端可能在不同时刻对Memcache进行更新，但速度不同，这样就造成可能使其仍然留存旧的数据。

（2）lease机制
即使是删除Memcache中的数据，在并发请求下仍然有可能缓存过时的数据，即论文中提到的“stale sets”。
即
删除 x x x后
1.C1读取Memcache，得到miss
2.C1读取，DB响应其值为1
3.其他客户端对 x x x有新的更改，为2
4.MySQL/mcsqueal/mcrouter会发送信号到Memcache
5.C1向Memcache中insert其值为1

上述情况可能会使得Memcache中的旧值存留很长时间，从而被用户察觉。

有了lease后，上述流程变为
删除 x x x后
1.C1读取Memcache，得到miss，Memcache给其lease为L1
2.C1读取，DB响应其值为1
3.其他客户端对 x x x有新的更改，为2
4.MySQL/mcsqueal/mcrouter会发送信号到Memcache，使得L1失效
5.C1使用L1向Memcache中insert其值为1，但其L1失效，则忽略
（3）thundering herd问题
1.对热点k，可能有很多客户端访问它
2.如果有客户端对其write，造成其在Memcache失效
3.client发现在Memcache上miss
4.有很多client都去DB上读取，使得DB负载过大
使用lease，可以只让第一个得到miss的client去读取数据

更充分的理由是，FaceBook想保证对同一客户端来讲，保证该客户端之后的读请求能够看到该客户端对数据之前的修改。