新浪微博开放平台中的 redis 实践
Redis在微博场景的优化实践
Redrocks
适用场景
Redrocks
• 大容量 • 数据冷热区明显 • 数据冷热区别不明显，但是非超大key的场景
Redrocks
Main Thread
Background Thread
Connect Handler Protocol Parse
Command Process
Replication
支 持 mc
redis 协 议
Cache Service 服务化
Cache Service 服务化
• 关键字：弹性扩容 云 内网 峰值流量 应急预案 便捷 省成本 快速部署
• 成功案例：实现春晚1000+台阿里云ECS弹性扩缩容，多次实现无降级 平滑过渡，高峰期支持微博50%核心流量
warden
configService
Lru cache service
Lru cache service
master-l1 master slave slave-l1
master-l1 master slave slave-l1
master-l1 master slave slave-l1
master-l1 master slave slave-l1
io
Data Swap
Bloom Filter
Storage Engine
处理模块
mem disk
Redrocks
RedisDB
“hot” data
swap in/out
hot
LRU
warm
cold
Slot Map
RocksDB
“cold” data
SSD/PCIE
存储模块
Redis数据库在微博系统中的实践
如 Ｍ ｎｏ Ｂ等来保存持久的信息值。除非客户 ｏｇＤ 端需要数据，我们再进行查询和返 回信息。 （ ）微 博 中消息对 象 二 １ ．发 布 的消息和 回复 的评论
发布 的 消 息 具 有 自己 的 唯 一 标 识 ，消 息 内 容 ，发 布人 和创建 时 间等基本 内容 。 回复的评 论 也具有 自己 的唯一 标识 ，消 息 内容 ，以及 回复人 和创 建时 间等基本 内容 。 】 除 了以上两种 ，消息 还 可 以进 行转发 ，也 就 是消 息嵌套 消息 ，但是 可 以把 转发 的 内容 放入 到
一
、
选择适合微博 系统的数据库
二、Ｒ ｄｓ ｅ ｉ的键值的格式定义
Ｒ ｄｓ ｅｉ的数据 在 内存 中始 终 是 以 ｋｙ值 作 为 ｅ
微博系统其实是一个类似群聊的庞大在线聊 天室 ， 由于每 时 每 刻都 有 大 量 的实 时 消 息 产生 ，
并 且需 要 即时反馈 给各个 用户 ，所 以需要 保持更 快 的速 度来读 写数据 。传 统 的关 系 型数据 库在数 据量超 过规模 的时候 ，由于其 自身 的关 系型系统 逻 辑相对 复杂 ，也 就导致 了读 写速度 的下 降 。
第１ ４卷
第３ 期
厦 门城 市职 业学院学报
Ｊ ｕ ｎ ｌｏ ａ ｎ Ｃ ｔ ｃ ｔ ｎ ｌＣｏ ｅ ｅ ｏ ｒ ａ ｆ Ｘｉ ｍｅ ｉ Ｖｏ ａｉ ａ ｌ ｇ ｙ ｏ ｌ
Ｖ０ ． ４ Ｎ ． １１ ｏ ３
Ｓ ｐ． ０１ ｅ ２ ２
２１ ０ ２年 ９月
Ｒ ｄｓ 据 库在 微 博 系统 中 的实践 ｅｉ 数
２ 粉 丝 ．
条新 的 消息 中 ，不用进 行递 归嵌 套 ，只需要 显 综 上所 述 ，需 要设计 ３个。
新浪高级DBA侯军伟《Redis在新浪的大规模运维经验》
坑
2013-5-6 30
自劢化
自劢部署
Redis 7901-1976
自劢扩容
IDC1
前段写入
Redis 7901-1976
Redis 7901-1976
IDC2
Redis 7901-1976
2013-5-6
31 IDC3
信息查询
2013-5-6
32
自劢部署
2013-5-6
33
自劢扩容
2013-5-6
DNS
Manager Slave Failover Logic
00 Master Failover Logic
DNSMasq Client
2013-5-6
48
经验
string -> hash Instagram 100w数据
内存占用
80 70 60
50 40 30 20
10 0
2013-5-6
Open source
2013-5-6
5
存储&cache
string、hash、list、set、sorted set 持久化 高性能
过期时间
2013-5-6
6
持久化
rdb aof
2013-5-6
7
rdb
Fork子进程，copy on write
– rdbcompression yes – dbfilename r7700.rdb
– save <seconds> <changes>
2013-5-6
8
aof
Aof=append only log file
MySQL binlog
redis核心原理和应用实践 pdf
redis核心原理和应用实践pdfRedis是一款高性能的键值存储系统，它采用了内存数据库的方式，数据存储在内存中，具备快速读写的特点。
下面是Redis 的核心原理和应用实践的介绍：1.数据结构：Redis支持多种数据结构，包括字符串、列表、哈希、集合、有序集合等。
这些数据结构都经过优化，以提供高效的操作和查询。
2.内存存储：Redis的数据存储在内存中，这使得它能够快速读写数据。
同时，为了保证数据的持久性，Redis还支持将数据定期或者在特定条件下写入磁盘。
3.单线程模型：Redis采用单线程模型，所有的请求都由一个线程处理。
这样可以避免多线程带来的锁竞争和上下文切换开销，提高了系统的性能。
4.持久化：Redis支持两种持久化方式，分别是RDB（Redis Database）和AOF（Append Only File）。
RDB方式是将数据库的快照保存到磁盘上，AOF方式是将每条写命令追加到文件末尾。
通过这两种方式，可以在系统重启后恢复数据。
5.发布订阅：Redis支持发布订阅模式，可以将消息发布到指定的频道，然后订阅该频道的客户端可以接收到消息。
这种模式在实现消息队列、实时通知等功能时非常有用。
6.缓存应用：Redis的高性能和丰富的数据结构使其成为一个优秀的缓存解决方案。
通过将热点数据存储在Redis中，可以大大提高系统的性能和响应速度。
7.分布式锁：Redis提供了分布式锁的实现，可以避免多个客户端同时对同一资源进行操作。
通过使用Redis的原子操作，可以实现可靠的分布式锁。
8.计数器和排行榜：Redis支持自增和自减操作，可以用来实现计数器和排行榜等功能。
这在统计和排名相关的场景中非常有用。
总之，Redis作为一个高性能的键值存储系统，具备了很多强大的特性和应用场景。
它不仅可以用作缓存解决方案，还可以实现发布订阅、分布式锁、计数器等功能。
对于需要快速读写和高并发的场景，Redis是一个非常好的选择。
Redis大数据之路
• 业务场景 • 用户关注列表
• • •
互相关注 关注备注 关注分组
• 技术难点
12年4月15日星期日
• 用户粉丝列表
DTCC2012
Redis大数据之
好友关系
• 业务场景 • 我和TA的共同关注 • 我关注的人也关注了TA • 特殊分组： “未分组” • 分组中的互相关注/互相关注中的分组 • 技术难点
Redis大数据之
计数器
• 经验教训 • 线上大数据 • 内存中的大数据 • 长尾大数据
DTCC2012
12年4月15日星期日
经验教训
• Redis 适用场景 • 数据量不太大的存储 • 数据量大的缓存
DTCC2012
12年4月15日星期日
经验教训
DTCC2012
12年4月15日星期日
经验教训
通知
DTCC2012
12年4月15日星期日
Redis大数据之
通知
• 业务场景 • 用户通知（通知单个用户） • 公共通知（通知全站所有用户） • 新通知提醒 • 技术难点
DTCC2012
12年4月15日星期日
Redis大数据之
通知
• 存储 by redis • 索引 key - list • uid - notice id list • public notice id list • 内容 key - value • notice id - notice content
Redis大数据之路
• 新浪微博中的Redis大数据之路 • 通知 • 好友关系 • 计数器
DTCC2012
12年4月15日星期日
Redis大数据之
计数器
• 业务场景 • 以用户为维度 • 微博数，关注数，粉丝数，收藏数 • 以微博为维度 • 转发数，评论数 • 技术难点
redis高并发处理例子
redis⾼并发处理例⼦发帖、发微博、点赞、评论等这些操作很频繁的动作如果并发量⼩，直接⼊库是最简单的但是并发量⼀⼤，数据库肯定扛不住，这时可采取延迟发布：先将发布动作保存在队列⾥，后台进程循环获取再⼊库模拟发布微博先进⼊redis队列weibo_redis.php<?php//此处需要安装phpredis扩展$redis = new Redis();$redis->connect('127.0.0.1', 6379);$redis->auth("php001");//连接redis$web_info= array('uid' => $_REQUEST[uid], //发布者id'username' => $_REQUEST[username],//发布者⽤户名'content' =>$_REQUEST[content],//微博内容);//将数组转成json来存储$list = json_encode($web_info);//lpush向KEY对应的头部添加⼀个字符串元素$redis->lpush('weibo_lists',$list);$redis->close();var_dump($list);>模拟后台进程从redis队列获取微博Pdodb.class.php<?phpclass Pdodb{public function post($uid='',$username='',$content=''){try{$dsn = "mysql:localhost;dbname=localhost;dbname=big";$db = new PDO($dsn,'big','123456');$db->exec("SET NAMES UTF8");$sql ="insert into ih_weibo(uid,username,content)values('$uid','$username','$content')";//echo $sql;$db->exec($sql);}catch(PDOException $e){echo $e->getMessage();}}}weibo_mysql.php<?phprequire_once 'Pdodb.class.php';set_time_limit(0); // 取消脚本运⾏时间的超时上限$pdo = new Pdodb();$redis = new Redis();$redis->connect('127.0.0.1', 6379);while (true) {//返回的列表的⼤⼩。
内存作为统一存储实践——尹伟铭+：豆瓣资深研发工程师_IT168文库
案例：微博系统
●
拉模式的 user_timeline
●
查询出关注的人的列表
SELECT id FROM following WHERE follower_id=$UID
●
根据关注的人查询出微博列表
SELECT * FROM weibo WHERE user_id IN $FOLLOWING_LIST ORDER BY created_at LIMIT 0, 20;
案例：数据更新
●
关注很多人
● ●
每个被关注的人说话都会引起数据更新
收听的队列总是无法稳定
案例：微博系统
●
推模式的 user_timeline
●
查询出关注的人的列表
SELECT id FROM following WHERE follower_id=$UID
●
根据关注的人更新收听微博列表
INSERT INTO liestening (user_id, follower_id, weibo_id, created_at) VALUE($UID, $FOLLOWER_ID, $WEIBO_ID, $CREATED_AT)
●
●
使用内存
●
速度对比CPU来自1内存硬盘
10
1,000
使用内存的优点
●
随机访问速度快
●
扩展方便
灵活的数据模型
●
使用内存的限制
●
空间小
●
无法存储全部数据
●
宕机数据丢失 运维难度增加
●
使用内存作为存储
●
命中率
●
非命中情况要构建完整的业务相关数据结构
●
数据填充
全面解读NoSQL数据库Redis的核心技术与应用实践
全⾯解读NoSQL数据库Redis的核⼼技术与应⽤实践互联⽹和Web的蓬勃发展正在改变着我们的世界，随着互联⽹的不断发展和壮⼤，企业数据规模越来越⼤，并发量越来越⾼，关系数据库⽆法应对新的负载压⼒，随着Hadoop，Cassandra，MongoDB，Redis等NoSQL数据库的兴起，因其良好的可扩展性，弱化数据库的设计范式，弱化⼀致性要求，在解决海量数据和⾼并发的问题上明显优于关系型数据库。
因⽽很快⼴泛应⽤于互联⽹业务中。
Redis作为基于K-V的NoSQL数据库，具有⾼性能、丰富的数据结构、持久化、⾼可⽤、分布式、⽀持复制等特性。
从09年⾄今，经历8年多的锤炼，已经⾮常稳定，并且得到业界的⼴泛认可和使⽤，同时社区⾮常活跃。
团队⼯作重⼼微博研发中⼼数据库部门主要负责全微博平台的后端资源的托管和运维，涉及的资源种类⽐较多，数据量⽐较⼤，业务线和资源实例数⽬也是⾮常之多，并发量巨⼤。
⽽这些正是微博这种体量的公司应该具有的，微博作为当今中⽂社交媒体的第⼀品牌，拥有超过3.76亿的⽉活⽤户，也是当前社会热点事件传播的最主要平台，其中包括但不限制于⼤型活动（如：⾥约奥运会、朱⽇和沙场⼤点兵等），春晚，明星动态（如：王宝强离婚事件、⼥排夺冠、乔任梁去世、⽩百合出轨、T FBOYS⽣⽇、⿅晗关晓彤CP等）。
⽽热点事件往往具有不可预见性和突发性，并且伴随着极短时间内流量的数倍增长，甚⾄更多，有时持续时间较长。
如何快速应对突发流量的冲击，确保线上服务的稳定性，是⼀个⾮常巨⼤的挑战和有意义的事情。
为了达到这⼀⽬标，需要有⼀个完善的，稳定可靠的，健壮的数据库运维体系来提供⽀撑和管理，所以我们团队也是在领导的指导下，有⽬标、有计划的开展⼀些数据库⾃动化运维平台的建设⼯作。
重⼤的变化与核⼼变化Redis的版本号命名规则借鉴了Linux的⽅式，版本号第⼆位如果是奇数，则为⾮稳定版本，如果为偶数，则为稳定版本。
稳定版本的⼀些主要改进吧：Redis2.61）键的过期时间⽀持毫秒2）从节点提供只读功能3）服务端⽀持Lua脚本4）放开客户端连接数的硬编码限制5）去掉虚拟内存相关功能等Redis2.81）完善主从复制功能，实现增量复制2）Redis设置明显的进程名，在系统中ps命令即可查看3）发布/订阅添加pub/sub命令4）Redis Sentinel第⼆版发布，较Redis 2.6更加完善，可以线上使⽤5）可以通过config set命令设置maxclients等Redis3.01）推出Redis的分布式集群 Redis Cluster2）全新的embedded string对象编码结果，优化⼩对象的内存访问，在特定的⼯作负载下能⼤幅度提升性能3）LRU算法提升4）config set 设置maxmemory的时候可以设置不⽤的单位5）新的Client pause命令，在指定时间内停⽌处理客户端请求等Redis3.21）添加GEO功能2）新的List编码类型quicklist3）SDS在速度和节省空间上都做了优化4）Lua脚本功能增强5）新的RDB格式，仍兼容旧版RDB，同时加载速度上也有提升6）Cluster nodes命令加速等在Redis4.0版本上，我认为最核⼼的功能应该是⽀持了module，这极⼤的丰富的Redis的功能，使得许多Redis本⾝不具有的，第三⽅开发者拓展的功能也能加载到Redis中当⼀个功能进⾏使⽤，⽐如RediSearch、ReJSON、Redis-ML等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
微博=feed+关系+数字
微博=feed+关系+数字
• redis • cache ? waste too much mem • storage ?
• may lost data • aof r/w too slow, recover too slow • all data in mem, waste money
• HA : master slave ? NO WAY • memory fragment
微博=feed+关系+数字
微博=feed+关系+数字
• 更新 • mysql binlog >> queue >> Java Processor
>> redis
• mysql binlog >> trigger >> redis
微博=feed+关系+数字
微博=feed+关系+数字
• 数字 • 微博，粉丝，关注数 • 评论给我的，@我的，我评论的 • 小黄签提醒：新粉丝，新@，新评论 • 未读微博数
微博=feed+关系+数字
微博=feed+关系+数字
• feed • mysql • mc
微博=feed+关系+数字
• 关系
微博=feed+关系+数字
• 未来 • rediscounter + innodb • auto roll cold data to disk
微博=feed+关系+数字
• 未读微博数
• @TimYang 亲自设计算法 • @XiaoJunHong 实现 • 向量相减 • redis (delay) - mc (throughput) - java hash map
微博=feed+关系+数字
微博=feed+关系+数字
• feed • 看微博，看评论 • 发微博，转发微博，发评论
微博=feed+关系+数字
微博=feed+关系+数字
• 关系 • 关注，取消关注 • 关注列表，粉丝列表
微博=feed+关系+数字
微博=feed+关系+数字
• 数字 • 微博，粉丝，关注数 • 评论给我的，@我的，我评论的 • 小黄签提醒：新粉丝，新@，新评论 • 未读微博数
新浪微博开放平台 Redis 实践
@唐福林 /tangfl
大纲
• Redis 简介 • 新浪微博中的Redis实践 • 好友关系 • 计数器 • 经验教训
Redis
• in memory (database?) • data can dump to disk • many useful data structure • FAST both read and write • we start use from 2.0, now 2.4
微博=feed+关系+数字
• mysql: relation.following
• fromuid, touid, addtime
• 关注列表：select * from following where fromuid=? order by addtime desc
• 粉丝列表：select * from following where touid=? order by addtime desc
• redis • hash : • key : user id • fields : friends ids • value : add time
微博=feed+关系+数字
• redis • hash : • hset fromuid.following touid addtime • hset touid.follower fromuid addtime • hgetAll fromuid. following • hgetAll touid.follower ?
经验教训
• 高延迟 • 持久化 • rehash
经验教训
• HA / Cluster • 当前 Redis 本身支持不完美 • Jedis 客户端支持不完美
经验教训
• CPU 瓶颈 • Redis 单线程 • hset with big hash-max-zip-size • hgetAll • 对策：mc
• 问题：fromuid, touid 都为索引，插入慢
微博=feed+关系+数字
• mysql: relation.following relation.follower
• fromuid, touid, addtime
• 关注列表：select * from following where fromuid=? order by addtime desc
经验教训
• 扬长避短 • 内存操作快 • 磁盘操作慢 • 偶尔高延迟 • 可能费内存
Thanks
@唐福林 /tangfl
Q &A
PS.We are hiring ! contact me via @唐福林
经验教训
• 准确定位 • cache • storage
经验教训
• 适用场景 • 大量写入 • 复杂数据结构 • 简单数据结构+持久化 • 容量小于内存
经验教训
• 容量规划 • 容量增长预估 • 读/写量预估 • 数据结构 • 内存碎片
经验教训
• 持久化 • 是否需要 • rdb or aof ？
• 姚晨粉丝 11,704,598 @Wed Sep 7 21:46:33 CST 2011
微博=feed+关系+数字
• hash-max-zip-size
• 64 -> 256，节省近 1/3 内存 • cpu 消耗增大
• hgetAll cost too much cpu • add mc • high delay
微博=feed+关系+数字
• 数字
微博=feed+关系+数字
• 永久计数 • 用户的 • 微博，粉丝，关注 • @我的，我评论的，评论我的 • 微博 • 转发，评论
微博=feed+关系+数字
微博=feed+关系+数字
• 临时计数 • 小黄签提醒 • 新粉丝，新@，新评论 • 未读微博 • 聚合计算 • 页面js每隔一段时间请求一次
• redis • k-v , 100 byte per k-v
• mc 也一样 • 单个业务十亿量级的数字个数
• hash , hget pipeline slow
微博=feed+关系+数字
• redis • rdb ? may lost data • aof ? grow too fast (4G/day) • bgsave/bgrewriteaof influence parent
微博=feed+关系+数字
• 现状 • redis@weibo for now: • TB 级 • growing fast
微博=feed+关系+数字
• 未来 • @摇摆巴赫 mysql modified + innodb • following list of a user in one column • still under dev
微博=feed+关系+数字
微博=feed+关系+数字
• 数字 • 微博，粉丝，关注数 • 评论给我的，@我的，我评论的 • 小黄签提醒：新粉丝，新@，新评论 • 未读微博数
微博=feed+关系+数字
微博=feed+关系+数字
• 数字 • 微博，粉丝，关注数 • 评论给我的，@我的，我评论的 • 小黄签提醒：新粉丝，新@，新评论 • 未读微博数
• 粉丝列表：select * from follower where touid=? order by addtime desc
• 问题：插入两张表，非事务，一致性
微博=feed+关系+数字
• 双向关系：关注与粉丝的交集 • 实时计算：读的时候计算。 • 问题：效率 • 预先计算：写的时候计算，存储 • 问题：一致性，空间占用
微博=feed+关系+数字
微博=feed+关系+数字
• redis rolling
• 场景：微博的评论数 • 每天写入亿级，每天读取十亿级 • 明显的时间长尾 • 目标：将一段时间前的 key 淘汰出去
微博=feed+关系+数字
• 现状 • rediscounter @果爸果爸 • array , not linked list • malloc all mem when start • hash key to position • write disk: asyn & slow down • add position to aof file
微博=feed+关系+数字
• 我和ta的共同关注 • 我关注的人里有多少关注了ta • 我的粉丝里有多少关注了ta • 。。。
微博=feed+关系+数字
• 我们想要的 • 简单：c/java ，可快速通读代码 • 可靠：经过验证的 • 高效：读写速度满足需要 • 方便实现需求
微博=feed+关系+数字
微博=feed+关系+数字