SR采用PubSubHubbub协议实时接收GReaderSharedItems更新
早前写的注意事项。现放出来，也许对 PubSubHubbub 爱好者有帮助。
一、启用 PubSubHubbub 协议更新玩聚SR数据的好处：
快。
几乎是一个Google Reader用户分享一篇文章之后的几秒钟时间，我们就可以把数据入库。
而依靠轮询每一个用户的 Google Reader Shared Items Feed，可能需要十几乃至几十分钟才能让一个更新入库。而且随着监听的用户数越来越多，轮询会越来越慢，而且也会因为某用户分享的某一篇文章有敏感词，导致Socket链接被重置一段时间；另外，请求过于频繁并发过多，Google也会重置你的链接。
但也会存在一些问题，稍后会说明。
二、PubSubHubbub协议入门参考读物：
kangye 的 PubSubHubbub工作原理及使用入门 ；
kangye 的 [教程]如何使用PubSubHubbub协议 ；
Tim 的 PubSubHubbub的价值 。
三、了解Hub Server跟你的交互：
协议中定义，Hub Server 做以下三件事：
1、发送 Verify Subscriber 请求，要求 订阅者 返回 200状态码 以及 challenge挑战码 。
2、推送订阅过的 Google Reader Shareds Items 之更新数据给订阅者。
3、发送过期是否继续续订的请求，要求订阅者确认。
一般来说，你的程序角色就是 订阅者（Subscriber），http:// pubsubhubbub .appspot.com/ 就是Hub Server。
所以，玩聚SR 把这三件事都放在一个 Web Server 上处理，该程序由 Twisted 提供 Web 入口以及处理框架。
四、Callback 地址的设计
虽然 Hub Server 发送过来的数据（XML格式）指明了是哪一个 Shared Items ，通过以下字段：
<id>tag:google.com,2005:reader/user/15221435823542888940/state/com.google/broadcast</id>
，但SR要想按照此id字段匹配到数据库中对应的 User ，还需要做一次 select 查询。
所以，在最开始发出订阅请求时，特别为不同 User 指定了不一样的 Callback 地址。Callback 地址就可以揉入必要参数。
五、为 User 增加订阅状态
某些时候需要将一个 Shared Items 退订（分享文章质量太差等原因），不让 Hub 继续发送更新过来，那么就需要一个特定的用户状态。
退订的流程和订阅一样，只是 hub.mode 值为 'unsubscribe'。
所以 User 要有一个订阅状态，这也是为了第六条考虑。
六、一段时间后要确保订阅不失效
发现 Hub Server 隔若干天就会失去对一些Feed的订阅，也就是，明明用户分享了文章，但 Subscriber 却迟迟接收不到任何更新通知。
这就需要重新发请求订阅。
原因可能有二：Hub发“订阅过期重新确认”请求给订阅者（Subscriber）时，订阅者忙而未能及时应答；Hub Server 丢失了订阅状态。
七、PubSubHubbub 的一些常见问题：
1、更新数据不一定只是最新的那些条目：
Hub Server保存状态也是有一定的时间限制的 ，假如某一个用户长时间没有分享过文章，比如睡觉去了，那么第二天他再次分享文章时，Hub会把所有数据（8条）都推送过来。这说明在一段时间内，比如一小时内，Hub缓存了推送给Subscriber的数据状态，过期就清了 。Hub 不再记得曾经给你发送过哪些数据。
2、订阅者宕机后可能需要重新发送所有订阅请求：
当你的 Subscriber 掉线或者宕机一段时间后（比如一小时无法连线），hub 就认为你不再续订，于是不会再 push 数据给你了。你需要重新发起所有订阅请求。
3、更新速度：
并不是像通常想像的，你一在Google Reader里点击了某篇文章的Shared按钮，hub就立刻推送更新到subscriber。未必 。
多数情况下，几秒钟就Push新数据过来了。但有时，可能是hub的策略设定，是两次shared点击才会触发一次hub推送，推送的数据内容就是这个批次分享的那两篇文章。
郑昀 北京报道
