Redis在新浪微博中的应用

  • 时间:
  • 浏览:0

基于以上考虑, 选用了Redis

提前做好数据量的规划, 减少sharding(互联网公司一般以年为单位)只存精细化数据(内存很金贵!) 存储用户维度的数据

对象维度的数据要有生命周期有点是数据量有点大的那我,就很有必要来进行划分了;暴露服务的常见过程: IP-->负载均衡-->域名-->命名服务(一张表: 名字+资源(IP+端口))对于硬件消耗,IO、网络和CPU相比,Redis最消耗的是CPU,冗杂的数据类型必定带来CPU消耗;新浪微博响应时间超时目前设置为5s;(返回飞快的记录key,需记录下来分析,慢日志);备份的数据要定期要跑一下生产的数据;用来检查备份数据的有效性;slave挂多了肯定会对master造成比较的影响;新浪微博目前使用的M/S是一拖一,主要用来做容灾;同步时,是fork出另好几个 单独系统应用应用程序来和slave进行同步;不需要占用查询的系统应用应用程序;升级到2.6.80那我的linux内核;在2.6.80以上对软中断的疑问处置的很好,性能提升效果明显,差太少有15%到80%的差距;redis不需要读写分离,每个请求就有单系统应用应用程序,为那些要进行读写分离。

上述并是否生活, 从精细化控制方面,hash sets和string(counter)推荐使用, sort sets和lists(queue)不推荐使用

还可通过二次开发,进行精简。比如: 存储字符改为存储整形, 16亿数据, 只那末 16G内存

存储类型保趋于稳定3种以内,建议太少超过3种;

长期运行后多个结点之间趋于稳定不一致的可能;

    开发另好几个 工具系统应用应用程序:

    1.对于数据量大的数据,会周期性的全量检查;

    2.实时的检查增量数据,是否具有一致性;

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和80K写到一块, 会有碎片. Sina可能优化到浪费只占5%以内(可能很好了!)

可靠性需求

Cache的"雪崩"疑问愿意纠结

Cache面临着快速恢复的挑战

开发成本需求

Cache和DB的一致性维护成本那末 高(先清理DB, 再清理缓存, 不行啊, 太慢了!)

开发那末 跟上不断涌入的产品需求

硬件成本最贵的只是数据库层面的机器,基本上比前端的机器要贵几倍,主只是IO密集型,很耗硬件;

维护性冗杂

一致性维护成本那末 高;

BerkeleyDB使用B树,会经常写新的,内部不需要有文件重新组织;那我会原因分析文件那末 大;大的那我那末 进行文件归档,归档的操作要定期做;那我,就那末 有一定的down time;

Solution: 容量规划和M/S的sharding功能(share nothing, 抽象出来的数据对象之间的关联数据很小)

增加但会 配置, 分流, 比如: 1,2,3,4, 机器1处置%2=1的, 机器2处置%2=0的.

低于内存的1/2使用量, 但会 就扩容(建议Redis实例使用的数据,最大太少超过内存的80%)

让让我们线上96G/128G内存服务器不建议单实例容量大于20/80G。

微博应用中单表数据最高的有2T的数据,不过应用起来可能但会 力不从心;

每个的端口太少超过20G;测试磁盘做save所那末 的时间,那末 多长时间也能完整篇 写入;内存越大,写的时间也就越长;

    单实例内存容量较大后,直接带来的疑问只是故障恢复可能Rebuild从库的那我时间较长,对于普通硬盘的加载强度而言,让让我们的经验一般是redis加载1G那末 1分钟;(加载的强度依赖于数据量的大小和数据的冗杂度)

Redis rewrite aof和save rdb时,可能带来非常大且长的系统压力,并占用额外内存,很可能原因分析系统内存过高 等严重影响性能的线上故障。

对于主库未及时同步从库原因分析的不一致,称之为延时疑问;

    对于一致性要求就有那末 严格的场景,让让我们只必那末 保证最终一致性即可;

    对于延时疑问,那末 根据业务场景特点分析,从应用层面增加策略来处置你你这些 疑问;

类式 :

1.新注册的用户,那末 先查询主库;

2.注册成功那我,那末 停留3s那我跳转,后台此时只是在做数据同步。

    数据形态学 (Data Structure)需求太少, 但memcache中那末 , 影响开发强度性能需求, 随着读操作的量的上升那末 处置,经历的过程有:

数据库读写分离(M/S)-->数据库使用多个Slave-->增加Cache (memcache)-->转到Redis处置写的疑问:水平拆分,对表的拆分,将有的用户装进你你这些 表,有的用户装进另外另好几个 表;

Config Server装进Zookeeper上

最前面是命名服务,中间跟的是无清况 的twmemproxy(twitter的改进的,用C写的) ,中间才是redis;

2.twmemproxy 应用太少关心连接失败, 由代理负责重连

809年, 使用memcache(用于非持久化内容), memcacheDB(用于持久化+计数),

    memcacheDB是新浪在memcache的基础上,使用BerkeleyDB作为数据持久化的存储实现;

运维那末 只讲数据备份,还得考虑数据恢复所那末 的时间;

增加权限认证(管理员才有权限)eg:flashall 权限认证,得有密码也能做;

当然,高速数据交互一般就有会在每次都进行权限认证,通用的处置策略是第一次认证,后期就有用再认证;

控制hash策略(那末 key, 就找那末 value; 我只是知道hash策略, 就无法得到key)

redis持久化(aof) append online file:

    写log(aof), 到一定程度再和内存合并. 追加再追加, 顺序写磁盘, 对性能影响非常小

hash sets: 关注列表, 粉丝列表, 双向关注列表(key-value(field), 排序)string(counter): 微博数, 粉丝数, ...(处置了select count(*) from ...)sort sets(自动排序): TopN, 热门微博等, 自动排序lists(queue): push/sub提醒,...

Solution: 磁盘性能规划和限制写入的强度, 比如: 规定磁盘以80M/s的强度写入, 细水长流, 即使到来多量数据. 但会 要注意写入强度要满足另好几个 客观限制:

符合磁盘强度

符合时间限制(保证在高峰到来那我, 就得写完)

Redis使用的是单系统应用应用程序,太少太少在配置时,另好几个 实例只会用到另好几个 CPU;

    在配置时,可能那末 让CPU使用率最大化,都还都能能 配置Redis实例数对应CPU数, Redis实例数对应端口数(8核Cpu, 8个实例, 8个端口), 以提高并发:

单机测试时, 单条数据在80字节, 测试的结果为8~9万tps;

改进的好几个 步骤:

1)发现现有系统趋于稳定疑问;

2)发现了新东西, 为什么我么我在么在看为什么我么我在么在好, 全面转向新东西;

3)理性回归, 判断那些适合新东西, 那些不适合, 太少花费的回迁到老系统

将memcache +myaql 替换为Redis:

Redis作为存储并提供查询,后台不再使用mysql,处置数据多份之间的一致性疑问;

新浪微博目前使用的98%就有持久化的应用,2%的是缓存,用到了800+服务器,Redis中持久化的应用和非持久化的法律方法不需要差别很大:非持久化的为8-9万tps,那末 持久化在7-10万tps左右;

当使用持久化时,那末 考虑到持久化和写性能的配比,也只是要考虑redis使用的内存大小和硬盘写的强度的比例计算;

支持strings, hashes, lists, sets, sorted sets

    string是很好的存储法律方法,用来做计数存储。sets用于建立索引库非常棒;

Redis目前有3万多行代码, 代码写的精简,有太少太少巧妙的实现,作者有技术洁癖

    Redis的社区活跃度很高,这是衡量开源软件质量的重要指标,开源软件的初期一般都那末 商业技术服务支持,可能那末 活跃社区做支撑,一旦趋于稳定疑问都无处求救;

本文转自    鹏爱   51CTO博客,原文链接:http://blog.51cto.com/pengai/1707709

3.AS --> Proxy -->Redis4.Sina的Redis就有单机版, 而Redis-Cluster交互过于冗杂,那末 使用 做HA一句话,一定要配合监控来做,可能挂了那我,后续该怎么做;

(eg:140字微博的存储)

另好几个 库就存唯一性id和140个字;

那我库存id和用户名,发布日期、点击数等信息,用来计算、排序等,等计算出最后那末 展示的数据时再到第另好几个 库中提取微博内容;

3)危险命令的处置: 比如: fresh all删除完整篇 数据, 得进行控制

本机多端口处置同时做 - 能做到

同一业务多端口(分布在多机上), 处置同时做 - 做那末

   2)动态升级: 先加载.so文件, 再管理配置, 切换到新代码上(Config set命令) 把对redis改进的东西都打包成lib.so文件,那愿意够支持动态升级

reblance: 现有数据按照上述配置重新分发。

中间使用中间层,路由HA;

注:目前官方也正在做你你这些 事,Redis Cluster,处置HA疑问;

过程: 数据写到master-->master存储到slave的rdb中-->slave加载rdb到内存。

    存储点(save point): 当网络中断了, 连上那我, 继续传.

    Master-slave下第一次同步是全传,中间是增量同步;、

    太少太少应用, 都还都能能 承受数据库连接失败, 但那末 承受处置慢一份数据, 多份索引(针对不同的查询场景)处置IO瓶颈的唯一途径: 用内趋于稳定数据量变化不大的清况 下,优先选用Redis

    对于开源软件,首先看其能做那些,但更多的那末 关注它那末 做那些,它会有那些疑问?上升到一定规模后,可能会出現那些疑问,是否能接受?google code上, 国外论坛找材料(国内比国外技术水平滞后5年)观察作者当事人的代码水平

Solution: 重写Replication代码, rdb+aof(滚动)