comet与“更新传播”

《分布式系统原理与泛型》第6.4.2节 更新传播 读后笔记

分布式系统中数据会有复制，导致一份数据会在多处有复件，那么针对这一数据的更新操作应该传播给所有的复件。这一过程即为更新传播。对于comet来说就是服务器上数据的更新传播到用户浏览器上。

更新传播首先面临的设计问题是传播什么样（what）的更新信息，有三种方式：
1. 只传播更新的通知：无效化协议（invalidation protocol）即为此种方式，它传播一个通知，告知有更新操作发生（可以指定那些数据更新了），这样就知道某处的复件过期失效。当有客户对此无效的复件访问时，访问必须等待，直到该复件的数据更新后才可以。这种方式的优点是只占用少量的网络带宽，当更新频繁时（读/写比很小）这种协议比较合适。因为频繁的写操作会很容易出现两次数据更新操作之间没有读操作。那么第一次数据更新其实没有意义，因为后一次更新会覆盖前一次更新，但是更新的数据却连着传输了两遍。而采用这种方式只发送通知告知复件不再有效，数据的传输只在用户请求后才进行，这样就减少了不必要的数据传输。
2.传播更新数据：在副本之间拷贝（传送）数据。在读/写比高时，这种方式比较有利。除了直接传播修改的数据，还有其它手段，如传播修改日志（以节约带宽），或者将多个修改压缩到一个消息中组合传送。
3.传播更新操作：将要执行的操作传播给副本，又叫主动复制（active replication），它假设每个副本有一个进程代表，进程通过执行操作主动更新数据。

comet传播的数据采用第一种方式少见，应该没有，因为Web应用的读/写比还是比较大的。comet应该是第二种方式。第三种方式不是太理解，似乎可以服务器传送一个Javascript函数，客户端执行之？？


然后要解决的设计问题是如何（how）传播更新信息，有两种基本方法以及它们的混合方法。这是comet研究比较多的地方。
更新传播的两种基本方法是：
1.基于推的方法（push-based approach）：又称基于服务器的协议（server-based protocol），不需要其它副本请求更新，更新就被传播到副本那里了。这种方式适用于多个副本要保持较高的一致性。适用于读/写比较高的情况，表现为两次写操作之间夹有很多的读操作，显然基于推的方式效率较高，而且数据更新后能马上在副本上保持一致。基于长连接的Comet即为此种方法。这种方法的缺点是跟踪大量的副本，例如comet中服务器要跟踪数以万计的客户，在有数据更新时要遍历这些客户并传播更新。
2.基于拉的方法（pull-based approach）：又称为基于客户的协议（client-based protocol），服务器或客户主动请求其它服务器发送它持有的复件的更新。该协议场用于客户高速缓存，客户端轮询服务器以查看是否有必要更新，如Web缓存的使用。适用于读/写比较低时，此外也在缓存的数据很少共享时拉的方法也很高效。


更新传播的混合方式─基于租用（lease）的更新传播
租用代表服务器的承诺：在指定时间内服务器会把更新主动推给客户。当租用到期时，客户有两种应对方法：
1.客户开始轮询服务器以实现更新，并在必要时拉出被修改的数据；
2.客户请求一个新的租用以实现更新的推入。
我想第2种方式可能就是 关于server push，the google way一文中分析的google的comet方式。

租用在1989年由Gray和Cherition提出，最早是为基于推和拉的两种方式之间提供一种方便的动态转化机制。
2000年Duvvuri提出一种更灵活租用，它允许租用期限根据不同的租用标准动态调整，分成三种类型的租用：
1. 假设数据长时间未被修改，在将来一段时间被修改的可能性也不大，那么可以基于数据的“年龄”租用：长期保持不变的数据将拥有较长的租用期，这样可以减少更新消息的数量；但是对于comet来说维持一个HTTP长连接代价较高，为一个长久不动弹的客户维持一个HTTP长连接似乎有点划不来。
2.给那些请求频率高的活跃客户（刷屏狂人？）一个长期的租用，给那些请求频率低的客户一个短期的租用。这种方式使得服务器基本只跟踪受欢迎的那些客户，很适合comet的说；
3.基于服务器的状态空间开销：当服务器的负载随访问量加大开始不堪重负时，它就降低分配给客户的新租用的使用期限，这就使得服务器需要跟踪的客户减少（因为租用到期快，服务器需要保持的状态减少），也很适合comet。

comet如果采用基于租用的更新传播，那么它即是 client pull 又是 server push的。这种灵活的策略用到comet服务器上我想应该可以提高服务器的comet能力。