分布式系统：COPS

COPS

KV存储
整个集群上保证causal dependencies
ALPS（Availability, low Latency, Partition-tolerance, and high Scalability）系统必须牺牲强一致性，在这个约束下实现最强的一致性

handler函数必须是可结合和交换的，replica能以接收顺序处理冲突写。

COPS 通过在写入所有依赖项后才写入版本来在复制期间提供因果+一致性

需要存储版本号
COPS-GT还包含依赖的list

（1）每个集群都维持一份完整的数据
在集群内
使用一致性hash划分keyspace
每个key在少量节点上使用chain replication容错
（2）write局部完成后，primary node将其放入replication queue，发送给remote equivalent nodes（针对某个key而言，primary node集合）。只有其依赖全部满足后，才会在局部进行commit

当在所有replica都提交时，移除依赖
每个client最多有一个未完成的put，因为之后的put必须知道前面put的版本号，才能知道依赖关系

1.1 最终一致性

我们期望在本地处理读写请求
（1）收到写请求后，本地处理完毕后即可向client响应。后台会自动将数据发送给其他数据中心(DC)。
问题：由于网络传输问题，在其他数据中心无法保证执行的顺序。在DC1可能是Wx，Wz，DC2中可能为Wz，Wx；

不同DC对同一数据的写请求顺序问题，通过时间戳保证不会让旧的请求最终存留下来。
处理同一时间戳情况：在实现中需要对写请求附上<时间戳, 机器ID>来进行区分
这样做的前提条件是各DC的时间戳是同步的。

（2）为了提供顺序的保证，可以让系统支持sync(k, #v)操作，其会阻塞后续执行，除非DC中具有至少相同的版本号。
v1 = put(k1, val1)
sync(k1, #v1)
put(k2,val2)
这样就能保证在不同DC中，k1肯定在k2之前执行。

(3)上面的sync会阻塞程序的执行，为了快速处理写请求，可以采用Log的方式
每个DC本地都有LOG发送和接收服务器，client的写请求写入LOG发送服务器即可对client进行响应。LOG发送服务器对执行的顺序提供保障。（队列方式）

1.2 因果一致性

在运行过程中，会一直维护上下文（Context），在向其他DC发送时会将Context一起发送，即下图最后一行。

其他DC收到请求后，会对Context进行验证，看依赖是否满足，只有依赖满足后才会实际写入。

对put请求，会将Context清空，这代表这下一个操作只依赖这个put请求。
级联依赖问题：上图中Z依赖X，可能已经收到了X，但X依赖的其他项还没有满足。

1.3 存在的问题

（1）因果一致性只能捕捉到它涉及到的因果关系，例如你更新数据后，打电话告诉朋友，他再去查看这个数据，那么可能不会看到最新的数据，因为这种因果关系是无法被系统捕捉到的。

（2）下述中是因果一致的，但无论哪种顺序执行都会出现问题
第一种，在中间修改ACL，删除该用户的访问权限后，仍能拿到数据
第二种，在中间添加用户的ACL

证书

（1）为了防止中间人攻击，一些机构会给网站所有者颁发证书
其中包含：域名，公匙，以及私匙的签名。（私匙的签名是只有原网站所有者知道的）
client在访问网站时，会先得到证书，然后用证书中的公匙加密一些随机数，发送回网站，网站用私匙进行解密。从而进行验证。

（2）但为了防止一些恶意的CA机构，使用了CT系统。CA颁发的证书都需要先添加到CT LOG服务器中。
为防止系统删除数据，该系统是append-only，no fork的。即保证了可以联合CA进行伪造，但最终一定会被检测到，证据不会被删除。
client收到证书后，会先在CT中验证是否包含该证书。如果不包含，则终止访问。
（3）如何检测伪造的证书？需要一些网站的监视器获取这些日志，进行检测。

（4）使用Merkle trees处理日志，加快检测速度。
如何检测分支结构？因为如果存在分支的话，可能会将其中一个分支展示给用户，另一个分支展示给监视器，这样就无法检测到伪造证书了。
使用了gossip pool的概念，浏览器会将最近得到的STH (signed tree head)都放入该pool中，如果检测到前面的一些STH不是后面另一些STH的前缀，则出现分支。