redis list应用–大型网站缓冲队列服务器

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个脚本负责同步相关操做，队列里面基本没有任何拥堵信息。