1. 起因， 随着twitter sina微博，腾讯微博的开放平台相继推出, 大部分和互联网相关的公司又多了一个营销的手段：信息同步。也即是用户把自己的新浪微博账号或者腾讯微博账号和你的网站关联起来了，用户在你的网站产生的 任何信息都可以同步发送到sina微博，qq微博上去（前提是经过用户的允许，这样用户既可以不需要同样的信息复制到多个网站， 又可以相应的推广你的网站的入口曝光率）。目前同步比较好的例子是：微博通，街旁，切客等。

2. 为什么要用缓冲队列服务，我们举个例子。如果你做了一个网站，用户在你的网站上关联了sina微博，QQ微博，开心网，人人网， 豆瓣，twitter, facebook（可能还要在国外设置代理）等等第三方平台，用户产生了一个动作后（比如发了一条心情状态），你的网站要同时同步到这些网站去，每个第三 方平台都要经过多次外网http请求，所有的这些请求加起来是可能是很长的时间(几秒， 甚至几十秒)，这对于前段用户肯定肯定是无法忍受的。所以这个时候同步信息的话必须采取异步的方式，也就是用户在你的网站发表一个状态服务端只是把这条状 体对应的信息存储起来， 然后就提示用户发表成功， 具体的信息同步是后端以脚本的方式异步运行的。用户通俗的话来说就是用户先发表后同步，由于校本执行速度很快， 用户几乎感觉不出来同步的时间差。你也许会问我怎么知道哪些信息要同步到第三方平台去呢，这也就是使用redis使用缓冲队列服务器的原因，当用户发表信 息后，我们同事把信息写入缓冲队列服务器，后台脚本会不停的去检查缓冲队列服务器是否有数据，如果有数据则取出发送到第三方开放平台。

3. 系统扩展性
a). 如果脚本处理过慢，可能造成缓冲队列拥堵，我们可能通过扩展后台脚本个数来加快同步到第三方平台的处理速度。
b). 如果需要同步的信息量过大, 造成写入队列的并发数极大，肯能通过扩展队列服务来达到分散减压的目的(基本不会出现)。

5. 效率如何 假设你的网站每天产生100W条信息 需要同步到第三方平台。
redis官方测试数据（SET操作每秒钟 110000 次，GET操作每秒钟 81000 次）。
一个脚本每天的同步量, 86400/2 = 43200, (假设平均每同步一条信息花费时间为2s，) 一个脚本每天大概可以同步4W条数据。
平均每秒同步的数据 100W/86400 < 12个 高峰时期扩大十倍也就是每秒 120条信息。由此可见每天100W 甚至 1000W的信息同步量对redis来说都是没有任何压力的。
我们只需要加快脚本处理的速度即可， 100W数据只需要同事25个脚本负责同步即可，（数据量增加了，扩展起来非常方面）。

总结，此方式已经应用于国内某LBS社区，每天的PV大概300W，产生的信息同步量每天大概2W左右。当前是2个脚本负责同步相关操作，队列里面基本没有任何拥堵信息。