Redis 在新浪微博中的应用
1. 支持5种数据结构
支持strings, hashes, lists, sets, sorted setsstring是很好的存储方式，用来做计数存储。sets用于建立索引库非常棒；
2. K-V 存储 vs K-V 缓存
新浪微博目前使用的98%都是持久化的应用，2%的是缓存，用到了600+服务器Redis中持久化的应用和非持久化的方式不会差别很大：非持久化的为8-9万tps，那么持久化在7-8万tps左右；当使用持久化时，需要考虑到持久化和写性能的配比，也就是要考虑redis使用的内存大小和硬盘写的速率的比例计算；
3. 社区活跃
Redis目前有3万多行代码, 代码写的精简，有很多巧妙的实现，作者有技术洁癖Redis的社区活跃度很高，这是衡量开源软件质量的重要指标，开源软件的初期一般都没有商业技术服务支持，如果没有活跃社区做支撑，一旦发生问题都无处求救；
Redis基本原理
redis持久化(aof) append online file：写log(aof), 到一定程度再和内存合并. 追加再追加, 顺序写磁盘, 对性能影响非常小
1. 单实例单进程
Redis使用的是单进程，所以在配置时，一个实例只会用到一个CPU；在配置时，如果需要让CPU使用率最大化，可以配置Redis实例数对应CPU数, Redis实例数对应端口数(8核Cpu, 8个实例, 8个端口), 以提高并发:单机测试时, 单条数据在200字节, 测试的结果为8~9万tps；
2. Replication
过程: 数据写到master--&master存储到slave的rdb中--&slave加载rdb到内存。存储点(save point): 当网络中断了, 连上之后, 继续传.Master-slave下第一次同步是全传，后面是增量同步；、
3. 数据一致性
长期运行后多个结点之间存在不一致的可能性；开发两个工具程序：1.对于数据量大的数据，会周期性的全量检查；2.实时的检查增量数据，是否具有一致性；
对于主库未及时同步从库导致的不一致，称之为延时问题；对于一致性要求不是那么严格的场景，我们只需要要保证最终一致性即可；对于延时问题，需要根据业务场景特点分析，从应用层面增加策略来解决这个问题；例如：1.新注册的用户，必须先查询主库；2.注册成功之后，需要等待3s之后跳转，后台此时就是在做数据同步。
新浪Redis使用历程
2009年, 使用memcache(用于非持久化内容), memcacheDB(用于持久化+计数),memcacheDB是新浪在memcache的基础上，使用BerkeleyDB作为数据持久化的存储实现；
1. 面临的问题
数据结构(Data Structure)需求越来越多, 但memcache中没有, 影响开发效率
性能需求, 随着读操作的量的上升需要解决，经历的过程有:数据库读写分离(M/S)--&数据库使用多个Slave--&增加Cache (memcache)--&转到Redis
解决写的问题：水平拆分，对表的拆分，将有的用户放在这个表，有的用户放在另外一个表；
可靠性需求Cache的"雪崩"问题让人纠结Cache面临着快速恢复的挑战
开发成本需求Cache和DB的一致性维护成本越来越高(先清理DB, 再清理缓存, 不行啊, 太慢了!)开发需要跟上不断涌入的产品需求硬件成本最贵的就是数据库层面的机器，基本上比前端的机器要贵几倍，主要是IO密集型，很耗硬件；
维护性复杂一致性维护成本越来越高；BerkeleyDB使用B树，会一直写新的，内部不会有文件重新组织；这样会导致文件越来越大；大的时候需要进行文件归档，归档的操作要定期做；这样，就需要有一定的down time；
基于以上考虑， 选择了Redis
2. 寻找开源软件的方式及评判标准
对于开源软件，首先看其能做什么，但更多的需要关注它不能做什么，它会有什么问题？
上升到一定规模后，可能会出现什么问题，是否能接受？
google code上, 国外论坛找材料(国内比国外技术水平滞后5年）
观察作者个人的代码水平
Redis应用场景
1. 业务使用方式
hash sets: 关注列表, 粉丝列表, 双向关注列表(key-value(field), 排序)
string(counter): 微博数, 粉丝数, ...(避免了select count(*) from ...)
sort sets(自动排序): TopN, 热门微博等, 自动排序
lists(queue): push/sub提醒,...
上述四种, 从精细化控制方面，hash sets和string(counter)推荐使用, sort sets和lists(queue)不推荐使用还可通过二次开发，进行精简。比如: 存储字符改为存储整形, 16亿数据, 只需要16G内存存储类型保存在3种以内，建议不要超过3种；
将memcache +myaql 替换为Redis：Redis作为存储并提供查询，后台不再使用mysql，解决数据多份之间的一致性问题；
2. 对大数据表的存储
（eg：140字微博的存储）一个库就存唯一性id和140个字；另一个库存id和用户名，发布日期、点击数等信息，用来计算、排序等，等计算出最后需要展示的数据时再到第一个库中提取微博内容；
改进的3个步骤:1）发现现有系统存在问题;2）发现了新东西, 怎么看怎么好, 全面转向新东西;3）理性回归, 判断哪些适合新东西, 哪些不适合, 不合适的回迁到老系统
3. 一些技巧
很多应用, 可以承受数据库连接失败, 但不能承受处理慢
一份数据, 多份索引(针对不同的查询场景)
解决IO瓶颈的唯一途径: 用内存
在数据量变化不大的情况下，优先选用Redis
遇到的问题及解决办法
(注意: 都是量特别大时候会出现的, 量小了怎么都好说)
1.Problem: Replication中断后, 重发--&网络突发流量
Solution: 重写Replication代码, rdb+aof(滚动)
2.Problem: 容量问题
Solution: 容量规划和M/S的sharding功能(share nothing, 抽象出来的数据对象之间的关联数据很小)增加一些配置, 分流, 比如: 1,2,3,4, 机器1处理%2=1的, 机器2处理%2=0的.低于内存的1/2使用量, 否则就扩容（建议Redis实例使用的数据，最大不要超过内存的80%）我们线上96G/128G内存服务器不建议单实例容量大于20/30G。微博应用中单表数据最高的有2T的数据，不过应用起来已经有些力不从心；每个的端口不要超过20G；测试磁盘做save所需要的时间，需要多长时间能够全部写入；内存越大，写的时间也就越长；单实例内存容量较大后，直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长，对于普通硬盘的加载速度而言，我们的经验一般是redis加载1G需要1分钟；（加载的速度依赖于数据量的大小和数据的复杂度）Redis rewrite aof和save rdb时，将会带来非常大且长的系统压力，并占用额外内存，很可能导致系统内存不足等严重影响性能的线上故障。
reblance: 现有数据按照上述配置重新分发。后面使用中间层，路由HA；注：目前官方也正在做这个事，Redis Cluster，解决HA问题；
3. Problem: bgsave or bgwriteaof的冰晶问题
Solution: 磁盘性能规划和限制写入的速度, 比如: 规定磁盘以200M/s的速度写入, 细水长流, 即使到来大量数据. 但是要注意写入速度要满足两个客观限制:符合磁盘速度符合时间限制(保证在高峰到来之前, 就得写完)
4.Problem: 运维问题
1）Inner Crontab: 把Crontab迁移到Redis内部, 减少迁移时候的压力
本机多端口避免同时做 - 能做到
同一业务多端口(分布在多机上), 避免同时做 - 做不到2）动态升级: 先加载.so文件, 再管理配置, 切换到新代码上(Config set命令)把对redis改进的东西都打包成lib.so文件，这样能够支持动态升级自己改的时候要考虑社区的升级。当社区有新的版本，有很好用的新功能时，要能很容易的与我们改进后的版本很好的merge；升级的前提条件: 模块化, 以模块为单位升级加载时间取决于两个方面: 数据大小, 数据结构复杂度. 一般, 40G数据耗时40分钟分布式系统的两个核心问题: A.路由问题 B.HA问题
3）危险命令的处理: 比如: fresh all删除全部数据, 得进行控制运维不能只讲数据备份，还得考虑数据恢复所需要的时间；增加权限认证(管理员才有权限)eg：flashall 权限认证，得有密码才能做；当然，高速数据交互一般都不会在每次都进行权限认证，通用的处理策略是第一次认证，后期都不用再认证；控制hash策略(没有key, 就找不到 不知道hash策略, 就无法得到key)
4）Config Dump:
内存中的配置项动态修改过, 按照一定策略写入到磁盘中(Redis已支持)5）bgsave带来aof写入很慢:
fdatasync在做bgsave时, 不做sync aof(会有数据出入)6）成本问题: (22T内存, 有10T用来计数)Redisscounter(16亿数据占用16G内存) - 全部变为整型存储, 其余(字符串等)全不要Redis+SSD(counterService计数服务)顺序自增, table按照顺序写, 写满10个table就自动落地(到SSD)存储分级: 内存分配问题, 10K和100K写到一块, 会有碎片. Sina已经优化到浪费只占5%以内(已经很好了!)
5.Problem: 分布式问题
1.Config Server: 命名空间, 特别大的告诉访问, 都不适合用代理, 因为代理降低速度, 但是, Sina用了(单机多端口, Redis Cluster, sentinel)Config Server放到Zookeeper上最前面是命名服务，后面跟的是无状态的twmemproxy（twitter的改进的，用C写的） ,后面才是redis；2.twmemproxy应用不必关心连接失败, 由代理负责重连把Hash算法放到代理商代理后边的升级, 前端不关心, 解决了HA的问题无状态, 多台代理无所谓3.AS --& Proxy --&Redis4.Sina的Redis都是单机版, 而Redis-Cluster交互过于复杂，没有使用做HA的话，一定要配合监控来做，如果挂了之后，后续该如何做；并不是追求单机性能，而是集群的吞吐量，从而可以支持无线扩展；
提前做好数据量的规划, 减少sharding(互联网公司一般以年为单位)
只存精细化数据(内存很金贵!)
存储用户维度的数据对象维度的数据要有生命周期特别是数据量特别大的时候，就很有必要来进行划分了；
暴露服务的常见过程: IP--&负载均衡--&域名--&命名服务(一张表: 名字+资源(IP+端口))
对于硬件消耗，IO、网络和CPU相比，Redis最消耗的是CPU，复杂的数据类型必定带来CPU消耗；
新浪微博响应时间超时目前设置为5s；（返回很慢的记录key，需记录下来分析，慢日志）；
备份的数据要定期要跑一下生产的数据；用来检查备份数据的有效性；
slave挂多了肯定会对master造成比较的影响；新浪微博目前使用的M/S是一拖一，主要用来做容灾；同步时，是fork出一个单独进程来和slave进行同步；不会占用查询的进程；
升级到2.6.30以后的linux内核；在2.6.30以上对软中断的问题处理的很好，性能提升效果明显，差不多有15%到30%的差距；
redis不用读写分离，每个请求都是单线程，为什么要进行读写分离。
Posted by: 大CC | 19DEC,2013博客：微博：
阅读(...) 评论()>>>国内外三个领域巨头告诉你Redis怎么用订阅：
国内外三个领域巨头告诉你Redis怎么用
摘要：随着数据体积的激增，MySQL+memcache已经满足不了大型互联网类应用的需求，许多机构也纷纷选择Redis作为其架构上的补充。这里我们将为大家分享社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest带来的Redis实践。
作者：仲浩来源：CSDN
ZDNet至顶网服务器频道 10月08日 ： 随着数据体积的激增，MySQL+memcache已经满足不了大型互联网类应用的需求，许多机构也纷纷选择Redis作为其架构上的补充。这里我们将为大家分享社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest带来的Redis实践。
新浪微博：史上最大的Redis集群
Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King. & Jim Gray
Redis不是比较成熟的memcache或者Mysql的替代品，是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况：
2200+亿 commands/day 5000亿Read/day 500亿Write/day
18TB+ Memory
500+ Servers in 6 IDC 2000+instances
应该是国内外比较大的Redis使用平台，今天主要从应用角度谈谈Redis服务平台。
Redis使用场景
1.Counting（计数）
计数的应用在另外一篇文章里较详细的描述，计数场景的优化 http://www.xdata.me/?p=262这里就不多加描述了。
可以预见的是，有很多同学认为把计数全部存在内存中成本非常高，我在这里用个图表来表达下我的观点：
很多情况大家都会设想纯使用内存的方案会很有很高成本，但实际情况往往会有一些不一样：
COST，对于有一定吞吐需求的应用来说，肯定会单独申请DB、Cache资源，很多担心DB写入性能的同学还会主动将DB更新记入异步队列，而这三块的资源的利用率一般都不会太高。资源算下来，你惊异的发现：反而纯内存的方案会更精简！
KISS原则，这对于开发是非常友好的，我只需要建立一套连接池，不用担心数据一致性的维护，不用维护异步队列。
Cache穿透风险，如果后端使用DB，肯定不会提供很高的吞吐能力，cache宕机如果没有妥善处理，那就悲剧了。
大多数的起始存储需求，容量较小。
2.Reverse cache（反向cache）
面对微博常常出现的热点，如最近出现了较为火爆的短链，短时间有数以万计的人点击、跳转，而这里会常常涌现一些需求，比如我们向快速在跳转时判定用户等级，是否有一些账号绑定，性别爱好什么的，已给其展示不同的内容或者信息。
普通采用memcache+Mysql的解决方案，当调用id合法的情况下，可支撑较大的吞吐。但当调用id不可控，有较多垃圾用户调用时，由于memcache未有命中，会大量的穿透至Mysql服务器，瞬间造成连接数疯长，整体吞吐量降低，响应时间变慢。
这里我们可以用redis记录全量的用户判定信息，如string key:uid int:type，做一次反向的cache，当用户在redis快速获取自己等级等信息后，再去Mc+Mysql层去获取全量信息。如图：
当然这也不是最优化的场景，如用Redis做bloomfilter，可能更加省用内存。
3.Top 10 list
产品运营总会让你展示最近、最热、点击率最高、活跃度最高等等条件的top list。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大，鉴于占用内存较小的情况，使用Redis做存储也是相当不错的。
4.Last Index
用户最近访问记录也是redis list的很好应用场景，lpush lpop自动过期老的登陆记录，对于开发来说还是非常友好的。
5.Relation List/Message Queue
这里把两个功能放在最后，因为这两个功能在现实问题当中遇到了一些困难，但在一定阶段也确实解决了我们很多的问题，故在这里只做说明。
Message Queue就是通过list的lpop及lpush接口进行队列的写入和消费，由于本身性能较好也能解决大部分问题。
6.Fast transaction with Lua
Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景，你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑，如：在收到message推送时，同时1.给自己的增加一个未读的对话 2.给自己的私信增加一个未读消息 3.最后给发送人回执一个完成推送消息，这一层逻辑完全可以在Redis Server端实现。
但是，需要注意的是Redis会将lua script的全部内容记录在aof和传送给slave，这也将是对磁盘，网卡一个不小的开销。
7.Instead of Memcache
很多测试和应用均已证明，
在性能方面Redis并没有落后memcache多少，而单线程的模型给Redis反而带来了很强的扩展性。
在很多场景下，Redis对同一份数据的内存开销是小于memcache的slab分配的。
Redis提供的数据同步功能，其实是对cache的一个强有力功能扩展。
Redis使用的重要点
1.rdb/aof Backup!
我们线上的Redis 95%以上是承担后端存储功能的，我们不仅用作cache，而更为一种k-v存储，他完全替代了后端的存储服务（MySQL），故其数据是非常重要的，如 果出现数据污染和丢失，误操作等情况，将是难以恢复的。所以备份是非常必要的！为此，我们有共享的hdfs资源作为我们的备份池，希望能随时可以还原业务 所需数据。
2.Small item & Small instance!
由于Redis单线程（严格意义上不是单线程，但认为对request的处理是单线程的）的模型，大的数据结构list,sorted set,hash set的批量处理就意味着其他请求的等待，故使用Redis的复杂数据结构一定要控制其单key-struct的大小。
另外，Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后，直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长，而更糟糕的是，Redis rewrite aof和save rdb时，将会带来非常大且长的系统压力，并占用额外内存，很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。
3.Been Available!
业界资料和使用比较多的是Redis sentinel（哨兵）
http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html
/wellflat/items/8935016fdee25d4866d9
2000行C实现了服务器状态检测，自动故障转移等功能。
但由于自身实际架构往往会复杂，或者考虑的角度比较多，为此 @许琦eryk和我一同做了hypnos项目。
hypnos是神话中的睡神，字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)
其工作原理示意如下：
Talk is cheap, show me your code! 稍后将单独写篇博客细致讲下Hypnos的实现。
4.In Memory or not?
发现一种情况，开发在沟通后端资源设计的时候，常常因为习惯使用和错误了解产品定位等原因，而忽视了对真实使用用户的评估。也许这是一份历史数据，只有最近一天的数据才有人进行访问，而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。
所以当你在究竟使用什么样的数据结构存储的时候，请务必先进行成本衡量，有多少数据是需要存储在内存中的？有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的，1G的数据容量和1T的数据容量对于设计思路是完全不一样的
Plans in future?
1.slave sync改造
全部改造线上master-slave数据同步机制，这一点我们借鉴了MySQL Replication的思路，使用rdb+aof+pos作为数据同步的依据，这里简要说明为什么官方提供的psync没有很好的满足我们的需求：
假设A有两个从库B及C，及 A `& B&C，这时我们发现master A服务器有宕机隐患需要重启或者A节点直接宕机，需要切换B为新的主库，如果A、B、C不共享rdb及aof信息，C在作为B的从库时，仍会清除自身数 据，因为C节点只记录了和A节点的同步状况。
故我们需要有一种将A`&B&C 结构切换切换为A`&B`&C结构的同步机制，psync虽然支持断点续传，但仍无法支持master故障的平滑切换。
实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步，效果非常好，解决了运维负担，但仍需向所有Redis服务推广，如果可能我们也会向官方Redis提出相关sync slave的改进。
2.更适合redis的name-system Or proxy
细心的同学发现我们除了使用DNS作为命名系统，也在zookeeper中有一份记录，为什么不让用户直接访问一个系统，zk或者DNS选择其一呢？
其实还是很简单，命名系统是个非常重要的组件，而dns是一套比较完善的命名系统，我们为此做了很多改进和试错，zk的实现还是相对复杂，我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。
3.后端数据存储
大内存的使用肯定是一个重要的成本优化方向，flash盘及分布式的存储也在我们未来计划之中。Pinterest：Reids维护上百亿的相关性
Pinterest已经成为硅谷最疯故事之一，在2012年，他们基于PC的业务增加1047%，移动端采用增加1698%， 该年3月其独立访问数量更飙升至533亿。在Pinterest，人们关注的事物以百亿记&&每个用户界面都会查询某个board或者是用户是否关注的行为促成了异常复杂的工程问题。这也让Redis获得了用武之地。经过数年的发展，Pinterest已经成为媒体、社交等多个领域的佼佼者，其辉煌战绩如下：
获得的推荐流量高于Google+、YouTube及LinkedIn三者的总和
与Facebook及Twitter一起成为最流行的三大社交网络
参考Pinterest进行购买的用户比其它网站更高（ 更多详情）
如您所想，基于其独立访问数，Pinterest的高规模促成了一个非常高的IT基础设施需求。
通过缓存来优化用户体验
近日，Pinterest工程经理Abhi&Khune对其公司的用户体验需求及Redis的使用经验 进行了分享。即使是滋生的应用程序打造者，在分析网站的细节之前也不会理解这些特性，因此先大致的理解一下使用场景：首先，为每个粉丝进行提及到的预检查；其次，UI将准确的显示用户的粉丝及关注列表分页。高效的执行这些操作，每次点击都需要非常高的性能架构。
不能免俗，Pinterest的软件工程师及架构师已经使用了MySQL及memcache，但是缓存解决方案仍然达到了他们的瓶颈；因此 为了拥有更好的用户体验，缓存必须被扩充。而在实际操作过程中，工程团队已然发现缓存只有当用户sub-graph已经在缓存中时才会起到作用。因此。任 何使用这个系统的人都需要被缓存，这就导致了整个图的缓存。同时，最常见的查询&用户A是否关注了用户B&的答案经常是否定的，然而这却被作为了缓存丢 失，从而促成一个数据库查询，因此他们需要一个新的方法来扩展缓存。最终，他们团队决定使用Redis来存储整个图，用以服务众多的列表。
使用Redis存储大量的Pinterest列表
Pinterest使用了Redis作为解决方案，并将性能推至了内存数据库等级，为用户保存多种类型列表：
关注者列表
你所关注的board列表
关注你board的用户列表
某个用户中board中你没有关注的列表
每个board的关注者及非关注者
Redis为其7000万用户存储了以上的所有列表，本质上讲可以说是储存了所有粉丝图，通过用户ID分片。鉴于你可以通过类型来查看以上 列表的数据，分析概要信息被用看起来更像事务的系统储存及访问。Pinterest当下的用户like被限制为10万，初略进行统计：如果每个用户关注 25个board，将会在用户及board间产生17.5亿的关系。同时更加重要的是，这些关系随着系统的使用每天都会增加。
Pinterest的Reids架构及运营
通过Pinterest的一个创始人了解到，Pinterest开始使用Python及订制的Django编写应用程序，并一直持续到其拥 有1800万用户级日410TB用户数据的时候。虽然使用了多个存储对数据进行储存，工程师根据用户id使用了8192个虚拟分片，每个分片都运行在一个 Redis&DB之上，同时1个Redis实例将运行多个Redis&DB。为了对CPU核心的充分使用，同一台主机上同时使用多线程和单线程Redis 实例。
鉴于整个数据集运行在内存当中，Redis在Amazon&EBS上对每秒传输进来的写入都会进行持久化。扩展主要通过两个方面进行：第 一，保持50%的利用率，通过主从转换，机器上运行的Redis实例一半会转译到一个新机器上；第二，扩展节点和分片。整个Redis集群都会使用一个主 从配置，从部分将被当做一个热备份。一旦主节点失败，从部分会立刻完成主的转换，同时一个新的从部分将会被添加，ZooKeeper将完成整个过程。同时 他们每个小时都会在Amazon&S3上运行BGsave做更持久的储存&&这项Reids操作会在后端进行，之后Pinterest会使用这些数据做 MapReduce和分析作业。
Viacom：Redis在系统中的用例盘点
Viacom是全球最大的传媒集体之一，同时也遭遇了当下最大的数据难题之一：如何处理日益剧增的动态视频内容。
着眼这一挑战的上升趋势，我们会发现：2010年世界上所有数据体积达到ZB级，而单单2012这一年，互联网产生的数据就增加了2.8个ZB，其中大部分的数据都是非结构化的，包括了视频和图片。
覆盖MVN（以前称为MTV&Networks、Paramount及BET），Viacom是个名副其实的传媒巨头，支持众多人气站点， 其中包括The&Daily&Show、osh.0、South&Park&Studios、等。作为媒体公司，这些网 站上的文档、图片、视频短片都在无时无刻的更新。长话短说，下面就进入Viacom高级架构师Michael&Venezia&分享的Redis实践：
Viacom的网站架构背景
对于Viacom，横跨多个站点传播内容让必须专注于规模的需求，同时为了将内容竟可能快的传播到相应用户，他们还必须聚焦内容之间的关 系。然而即使The&Daily&Show、Nickelodeon、Spike或者是VH1&这些单独的网站上，日平均PV都可以达到千万，峰值时流量 更会达到平均值的20-30倍。同时基于对实时的需求，动态的规模及速度已成为架构的基础之一。
除去动态规模之外，服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜好。比如说，某个页面可能会将一个独立的视频片段与本地 的促销，视频系列的额外部分，甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间，他们建立了一个能基于详细元数据自动建立页面的软件引擎， 这个引擎可以根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变，数据的类型非常广泛&&类似graph-like，实际上做的是大量的join。
这样做有利于减少类似视频的大体积文件副本数，比如数据存储中一个独立的记录是Southpark片段 &Cartman&gets&an&Anal&Probe&，这个片段可能也会出现在德语的网站上。虽然视频是一样的，但是英语用户搜索的可能就是另一个 不同的词语。元数据的副本转换成搜索结果，并指向相同的视频。因此在美国用户搜索真实标题的情况下，德国浏览者可能会使用转译的标题&&德国网站上的 &Cartman&und&die&Analsonde&。
这些元数据覆盖了其它记录或者是对象，同时还可以根据使用环境来改变内容，通过不同的规则集来限制不同地理位置或者是设备请求的内容。
Viacom的实现方法
尽管许多机构通过使用ORM及传统关系型数据库来解决这个问题，Viacom却使用了一个迥然不同的方法。
本质上，他们完全承担不了对数据库的直接访问。首先，他们处理的大部分都是流数据，他们偏向于使用Akamai从地理上来分配内容。其次， 基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能，因此JSON在1个数据服务中投入了使用。当然，这些JSON对象的缓存将直接影 响到网站性能。同时，当内容或者是内容之间的关系发生改变时，缓存还需要动态的进行更新。
Viacom依靠对象基元和超类解决这个问题，继续以South&Park为例：一个私有的&episode&类包含了所有该片段相关信 息，一个&super&object&将有助于发现实际的视频对象。超类这个思想确实非常有益于建设低延迟页面的自动建设，这些超类可以帮助到基元对象到 缓存的映射及保存。
Viacom为什么要使用Redis
每当Viacom上传一个视频片段，系统将建立一个私有的对象，并于1个超类关联。每一次修改，他们都需要重估私有对象的每个改变，并更新 所有复合对象。同时，系统还需要无效Akamail中的URL请求。系统现有架构的组合及更敏捷的管理方法需求将Viacom推向了Redis。
基于Viacom主要基于PHP，所以这个解决方案必须支持PHP。他们首先选择了memcached做对象存储，但是它并不能很好的支持 hashmap；同时他们还需要一个更有效的进行无效步骤的重估，即更好的理解内容的依赖性。本质上说，他们需要时刻跟进无效步骤中的依赖性改变。因此他 们选择了Redis及Predis的组合来解决这个问题。
他们团队使用Redis给和两个网站建设依赖性图，在取得了很大的成功后他们开始着眼Redis其它适合场景。
Redis的其它使用场景
显而易见，如果有人使用Redis来建设依赖性图，那么使用它来做对象处理也是说得通的。同样，这也成了架构团队为Redis选择的第二使 用场景。Redis的复制及持久化特性同时也征服了Viacom的运营团队，因此在几个开发周期后，Redis成为他们网站的主要数据及依赖性储存。
后两个用例则是行为追踪及浏览计数的缓冲，改变后的架构是Redis每几分钟向MySQL中储存一次，而浏览计数则通过Redis进行存储 及计数。同时Redis还被用来做人气的计算，一个基于访问数及访问时间的得分系统&&如果某个视频最近被访问的次数越多，它的人气就越高。在如此多内容 上每隔10-15分钟做一次计算绝对不是类似MySQL这样传统关系型数据库的强项，Viacom使用Redis的理由也非常简单&&在1个存储浏览信息 的Redis实例上运行Lua批处理作业，计算出所有的得分表。信息被拷贝到另一个Redis实例上，用以支持相关的产品查询。同时还在MySQL上做了 另一个备份，用以以后的分析，这种组合会将这个过程耗费的时间降低60倍。
Viacom还使用Redis存储一步作业信息，这些信息被插入一个列表中，工作人员则使用BLPOP命令行在队列中抓取顶端的任务。同时zsets被用于从众多社交网络（比如Twitter及Tumblr）上综合内容，Viacom通过Brightcove视频播放器来同步多个内容管理系统。
横跨这些用例，几乎所有的Redis命令都被使用&&sets、lists、zlists、hashmaps、scripts、counters等。同时，Redis也成为Viacom可扩展架构中不可或缺的一环。
(没有帐户？)
使用第三方帐号登录:
Viacom相关文章Pinterest相关文章
& CBS Interactive. All rights reserved.
北京智德典康电子商务有限公司（至顶网）版权所有.
京ICP证010391号 京ICP备号-159
京公网安备：
CBSi中国媒体