21 | Megastore（三）：让Paxos跨越“国界”

徐老师好，学完Megastore我还是没想明白为什么它的写入吞吐量只有每秒几次。论文第2.2.3节Physical Layout提到，为了降低延迟，提高吞吐量，Megastore允许应用把数据放在靠近用户的地方，让数据的多个副本处于临近的数据中心，同时让一个EntityGroup的数据连续存储，尽量由一个TabletServer提供服务。唯一看起来有影响的是，写操作需要同步给所有副本，相关副本要么写入数据，要么标记自己的数据不是最新。 不过我在Spanner论文第6节Related Work中找到了答案，Megastore does not achieve high performance. It is layered on top of Bigtable, which imposes high communication costs. It also does not support long-lived leaders: multiple replicas may initiate writes. All writes from different replicas necessarily conflict in the Paxos protocol, even if they do not logically conflict: throughput collapses on a Paxos group at several writes per second. 主要原因有两个，一个是Bigtable带来高昂的通信成本，另一个是没有租期的Paxos Leader导致没有必要的写冲突。

徐老师好，学完Megastore这三讲，我觉得Megastore的性能提升在于将数据拆分打包成很小的实体组，在实体组内实现事务，在实体组间允许并发。读和写都尽可能在离用户最近的数据中心完成，读的时候采用只要没收到invalidate，数据中心就认为自己的数据是最新的，其实分布式环境下自己无法确认自己的数据是不是最新的，必须要通过集群中的其他多数节点确认，但是这种假装自己是最新的模式，加快了读操作的速度，写的时候要严格一些，先在集群中确认最新的事务日志位置。 Megastore 的写入的吞吐量慢就慢在向集群确认最新的事务日志位置。这是一种悲观的写入方式，认为对同一个实体组的写入会发生冲突，所以先确认别的数据中心中有没有新的写入。要提升吞吐量，可以采用乐观的写入方式，认为写入冲突是小概率事件，先写入，有冲突再回滚，或者解决冲突。

有个问题，就是副本的追赶。这里只说了查询会同步一次。如果长期没有查询。突然来了一次查询，那岂不是要同步很久？

徐老师，关于这句：第一步，是查询本地的协同服务器，看看想要查询的实体组是否是最新的。 中的最新是怎么判断的？这点一直没弄明白。

还有一点不明白，Leader 是一个实体组的leader，如果一个用户ID可以看作一个实体组，那么整个数据库中会有千万上亿的实体组，也会对应上亿个Leader映射关系，我这样理解对么？如果对的话，请问这些关系是在哪儿维护的？

徐老师好，bigtable论文在figure 6中说，单个tabletserver随机读取1000-byte数据，每秒大概1200次，magestore论文在第4.10节说读操作的延迟是几十毫秒，两者差距怎么这么大？如果能够命中第4.4.1节所说的Fast Reads，相比bigtable，magestore的读操作只是多了coordinator的查询，查询性能不至于差这么大啊。

在读数据时，如果本地数据不是最新的，直接找有最新数据的副本拿不可以吗，为什么需要等待本地的数据更新完成再去响应？这块设计是因为其他副本的数据也不一定是最新有效的么，是因为存在空洞吗？