新浪微博开放平台中的 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等。
Sina JPool-微博平台自动化运维实践-王关胜
用户&权限 资源管理
设பைடு நூலகம்管理
APP管理
配置管理 部署管理 任务管理 Nginx变更管理 降级/封杀管理 日志查询平台
Web APP CLI API
Dispatch
Puppet Master
服务器集群
agent puppet agent puppet
- 一键初始化（配置管理）
Step2 服务部署
- 环境部署 - 监控部署 - 服务部署（代码 & confs）
Step3 运维变更
- 系统变更，代码发布 - 服务迁移（动态扩容）
Step4 自动报修&下架
- 服务自动上下线 - 机器置换或下架
2.1 Sina JPool简介
什么是Sina Jpool?
+
系统
运维
KPI
设备：3000+ Docker：53% SLA：99.99% 集群：200+ 扩容：5min RT：150ms 业务模块：50+ 变更：15次/w 故障分：<2/季
强大的运维工具平台
2.纵观自动化运维发展概况
！
阶段4
阶段2 阶段1 工具系统
原始阶段 运维标准化 变更脚本化 工具Web化
产品
APP APP
APP_Pool APP_Pool
N个 设备
Node
APP
APP_Pool
配置管理
Node Node
Node Node
Shell操作
操作
脚本 文件
并发& 回显
任务（子任务）
任务模板
agent agent
基于Redis的微博系统基本功能设计
Ｂａ ｓ ｉ ｃ Ｄｅ ｓ ｉ ｇ ｎ ｏ ｆ Ｍｉ ｃ ｒ ｏ ｂ ｌ ｏ ｇ Ｓ ｙ ｓ ｔ ｅ ｍ Ｂａ ｓ ｅ ｄ ｏ ｎ Ｒｅ ｄ ｉ ｓ
（ Ｄ ｅ ｐ ａ ｒ ａ ｎ ｅ ｎ ｔ ｏ ｆ Ｉ ｎ ｆ ｏ ｒ ｍａ ｔ ｉ ｏ ｎ Ｔ ｅ ｃ ｈ ｎ ｏ ｌ ｏ ｇ ｙ Ｑ ｉ ｏ ｎ ｇ ｔ ａ ｉ Ｔ ｅ ａ ｃ ｈ ｅ ｒ ｓ Ｃ ｏ ｌ ｌ ｅ ｇ ｅ ， Ｈ ａ ｉ ｋ ｏ ｕ ５ ７ １ １ ２ １ ， Ｃ ｈ ｉ ｎ ａ ）
Ｃ ｏ ｍ ｐ ｕ ｔ ｅ ｒ Ｋ ｎ ｏ ｗ ｌ ｅ 内ｅ ａ ｎ ｄ Ｔ ｅ ｃ ｈ ｎ ｏ ｌ ｏ ｇ ｙ 电脯知识与 技术
Ｖｏ １ ． １ ２ ， Ｎபைடு நூலகம் ． ２ ５ ，Ｓ ｅ ｐ ｔ ｅ ｍｂ ｅ ｒ ２ ０ １ ６
基于 Ｒ ｅ ｄ ｉ ｓ 的微博系统基本功能设计
李 磊
（ 琼 台师范学院信 ｇｔ ｔ ＊￥ ， 海南 海 口５ ７ １ １ ２ １ ）
Ａｂ ｓ ｔ ｒ ａ ｃ ｔ ： Ｍｉ ｃ ｒ ｏ ｂ ｌ ｏ ｇ ｓ ｙ ｓ ｔ ｅ ｍ ｒ ｅ ｑ ｕ ｉ ｒ ｅ ｍｅ ｎ ｔ ｓ ｆ ｏ ｒ ｉ ｎ ｆ ｏ ｒ ｍａ ｔ ｉ ｏ ｎ ・ － ｒ ｅ ａ ｌ ・ － ｔ ｉ ｍｅ ｐ ｅ ｒ ｆ ｏ ｍ ａ ｒ ｎ ｃ ｅ ａ ｎ ｄ ｃ ｏ ｎ ｃ ｕ ｒ ｒ ｅ ｎ ｃ ｙ ． Ｔ ｒ ａ ｄ ｉ ｔ ｉ ｏ ｎ ａ ｌ ｒ ｅ ｌ ａ ｔ ｉ ｏ ｎ ａ ｌ ｄ ａ ｔ ａ ｂ ａ ｓ ｅ ｄ ｏ ｅ ｓ ｎ ｏ ｔ ｍｅ ｅ ｔ ｐ ｅ ｆｏ ｒ ｍ ａ ｒ ｎ ｃ ｅ ｒ ｅ ｑ ｕ ｉ ｒ ｅ ｍｅ ｎ ｔ ｓ ． Ｋｅ ｙ － Ｖａ ｌ ｕ ｅ ｍｏ ｄ ｅ ｌ ｍｅ ｍｏ ｒ ｙ ｄ ａ ｔ ａ ｂ ａ ｓ ｅ Ｒｅ ｄ ｉ ｓ ， ｖ ｅ ｙ ｒ ｓ ｕ ｉ ｔ ａ ｂ ｌ ｅ ｏｒ ｆ ｔ ｈ ｅ ｍｉ ｃ ｒ ｏ ｂ ｌ ｏ ｇ ｓ ｙ ｓ ｔ ｅ ｍ ｗｉ ｔ ｈ
微博应用实现的技术原理
微博应用实现的技术原理1. 概述微博应用是一种基于社交媒体的平台，允许用户在其上发布和分享短文、图片、视频等内容。
微博应用实现的技术原理包括前后端技术、数据存储和处理技术等。
本文将介绍微博应用实现的主要技术原理。
2. 前端技术2.1 HTML/CSS前端页面使用 HTML 和 CSS 技术来实现用户界面的展示和样式的定义。
HTML是用于构建页面结构的标记语言，CSS 是用于页面样式设计的样式表语言。
这两种技术结合使用，可以实现微博应用用户界面的布局、颜色、字体、图标等的定义。
2.2 JavaScriptJavaScript 是一种脚本语言，常用于实现网页的交互功能。
在微博应用中，JavaScript 可以用于实现用户在页面上的操作，如刷新、点赞、评论等。
通过与后端服务器的数据交互，JavaScript 可以动态地更新页面上的内容。
3. 后端技术3.1 服务器微博应用的后端使用服务器来处理用户请求和相应的数据处理。
服务器可以是常见的 web 服务器软件，如 Apache 或 Nginx。
服务器能够接收来自前端的请求，并将请求交给后端的应用程序进行处理。
3.2 后端框架后端框架是一种用于快速开发 web 应用程序的软件框架。
在微博应用中，后端框架负责处理用户请求、数据处理、用户认证等任务。
常见的后端框架包括Django、Spring、Ruby on Rails 等。
3.3 数据库微博应用需要将用户的发布内容、关注关系、用户信息等数据进行存储和管理。
数据库是一种用于存储和管理结构化数据的软件系统。
常见的数据库选择包括MySQL、Oracle、MongoDB 等。
数据库可以通过 SQL 或 NoSQL 的方式来操作和查询数据。
4. 数据存储和处理技术4.1 文件存储微博应用中的图片、视频等媒体文件需要进行存储。
可以选择将这些文件存储在服务器本地文件系统中，也可以选择将其存储在云存储服务中，如 Amazon S3、阿里云 OSS 等。
redis核心原理与实践 pdf
redis核心原理与实践pdfRedis（Remote Dictionary Server）是一个开源的高性能键值对存储数据库，被广泛应用于缓存、消息中间件和分布式系统等场景。
本文将介绍Redis的核心原理与实践，帮助读者更好地理解和使用Redis。
一、Redis核心原理1. 数据结构Redis支持多种数据结构，包括字符串、哈希表、列表、集合和有序集合。
这些数据结构使得Redis能够满足各种不同的应用需求。
2. 内存存储Redis将所有数据存储在内存中，这使得Redis具有非常高的读写性能。
同时，Redis也支持将数据定期写入磁盘，以保证数据的持久性。
3. 事务处理Redis支持事务处理，通过MULTI、EXEC和WATCH等命令，可以实现多条命令的原子性执行。
4. 发布/订阅模型Redis支持发布/订阅模型，用户可以订阅指定频道，获取发布者的消息。
这种模型可以用于实现实时消息推送等功能。
5. Lua脚本Redis支持Lua脚本，用户可以在服务器端执行Lua脚本，以实现更复杂的业务逻辑。
二、Redis实践1. 缓存应用Redis作为缓存数据库，可以大大提高系统的读写性能。
通过合理设置过期时间、缓存策略等参数，可以有效地降低数据库的负载。
2. 消息中间件Redis可以作为消息中间件，实现消息的发布/订阅和广播等功能。
与传统的消息中间件相比，Redis具有更高的性能和易用性。
3. 分布式锁Redis可以作为分布式锁的实现，保证多个节点之间的操作原子性。
通过SETNX 和expire等命令，可以实现分布式锁的加锁和解锁操作。
4. 排行榜应用Redis的有序集合数据结构可以用于实现排行榜功能。
通过ZADD命令添加分数，ZRANGEBYSCORE命令获取排名等操作，可以快速地完成排行榜的查询和更新。
5. 数据库迁移当需要将数据从传统的关系型数据库迁移到Redis时，需要考虑数据结构的转换、索引的建立以及查询优化等问题。
一种基于Scrapy-Redis的分布式微博数据采集方案
㊀㊀文章编号:１００９－２５５２(２０１８)１１－００５９－０４㊀㊀ＤＯＩ:１０ １３２７４/ｊ ｃｎｋｉ ｈｄｚｊ ２０１８ １１ ０１３一种基于Ｓｃｒａｐｙ￣Ｒｅｄｉｓ的分布式微博数据采集方案邓万宇ꎬ刘光达ꎬ董莹莹(西安邮电大学计算机学院ꎬ西安７１０１２１)摘㊀要:作为向网民展示世界和汇聚民意的重要渠道ꎬ微博正日益成为网络舆情的传播高地ꎮ如何对微博数据进行灵活高效地采集并存储ꎬ对后续的数据挖掘与分析工作起到重要作用ꎮ文中在分析新浪微博站点特征结构的基础上设计了一种局部最佳搜索策略ꎬ采用Ｐｙｔｈｏｎ开源框架Ｓｃｒａｐｙ搭配Ｒｅｄｉｓ数据库ꎬ设计实现了一套抓取速度快㊁定制性强㊁扩展性高的分布式爬虫系统ꎬ获取的数据具有良好的实时性和准确性ꎬ为后续工作提供了有力的数据支撑ꎮ关键词:Ｓｃｒａｐｙ￣Ｒｅｄｉｓꎻ局部最佳搜索ꎻ分布式ꎻ微博数据采集中图分类号:ＴＰ３９１㊀㊀文献标识码:ＡＡｄｉｓｔｒｉｂｕｔｅｄｍｉｃｒｏｂｌｏｇｄａｔａｃｏｌｌｅｃｔｉｏｎｍｅｔｈｏｄｂａｓｅｄｏｎｓｃｒａｐｙ￣ｒｅｄｉｓＤＥＮＧＷａｎ￣ｙｕꎬＬＩＵＧｕａｎｇ￣ｄａꎬＤＯＮＧＹｉｎｇ￣ｙｉｎｇ(ＳｃｈｏｏｌｏｆＣｏｍｐｕｔｅｒꎬＸｉ ａｎＵｎｉｖｅｒｓｉｔｙｏｆＰｏｓｔ＆ＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓꎬＸｉ ａｎ７１０１２１ꎬＣｈｉｎａ)Ａｂｓｔｒａｃｔ:ＡｓａｎｉｍｐｏｒｔａｎｔｃｈａｎｎｅｌｆｏｒｔｈｅＩｎｔｅｒｎｅｔｕｓｅｒｓｔｏｄｉｓｐｌａｙｔｈｅｗｏｒｌｄａｎｄｇａｔｈｅｒｐｕｂｌｉｃｏｐｉｎｉｏｎｓꎬｍｉｃｒｏｂｌｏｇｉｓｉｎｃｒｅａｓｉｎｇｌｙｂｅｃｏｍｉｎｇａｈｉｇｈｇｒｏｕｎｄｆｏｒｔｈｅｓｐｒｅａｄｏｆＩｎｔｅｒｎｅｔｐｕｂｌｉｃｏｐｉｎｉｏｎ.Ｈｏｗｔｏｃｏｌｌｅｃｔａｎｄｓｔｏｒｅｍｉｏｒｏｂｌｏｇｄａｔａｆｌｅｘｉｂｌｙａｎｄｅｆｆｉｃｉｅｎｔｌｙｐｌａｙｓａｎｉｍｐｏｒｔａｎｔｒｏｌｅｉｎｔｈｅｓｕｂｓｅｑｕｅｎｔｄａｔａｍｉｎｉｎｇａｎｄａｎａｌｙｓｉｓ.Ｔｈｉｓｐａｐｅｒｄｅｓｉｇｎｓａｌｏｃａｌｏｐｔｉｍａｌｓｅａｒｃｈｓｔｒａｔｅｇｙｂａｓｅｄｏｎａｎａｌｙｚｉｎｇｔｈｅｆｅａｔｕｒｅｓｔｒｕｃｔｕｒｅｏｆｗｅｉｂｏ.ｃｏｍꎬｕｓｉｎｇｔｈｅＰｙｔｈｏｎｏｐｅｎｓｏｕｒｃｅｆｒａｍｅｗｏｒｋＳｃｒａｐｙａｎｄＲｅｄｉｓｄａｔａｂａｓｅｔｏｄｅｓｉｇｎａｎｄｉｍｐｌｅｍｅｎｔａｄｉｓｔｒｉｂｕｔｅｄｃｒａｗｌｅｒｓｙｓｔｅｍｗｉｔｈｆａｓｔｃｒａｗｌｉｎｇｓｐｅｅｄꎬｈｉｇｈｃｕｓｔｏｍｉｚａｔｉｏｎꎬａｎｄｇｏｏｄｓｃａｌａｂｉｌｉｔｙ.Ｔｈｅｃｒａｗｌｅｒｓｙｓｔｅｍｈａｓｇｏｏｄｒｅａｌ￣ｔｉｍｅａｎｄａｃｃｕｒａｃｙｄａｔａꎬｗｈｉｃｈｐｒｏｖｉｄｅｓｐｏｗｅｒｆｕｌｄａｔａｓｕｐｐｏｒｔｆｏｒｆｏｌｌｏｗ￣ｕｐｗｏｒｋ.Ｋｅｙｗｏｒｄｓ:Ｓｃｒａｐｙ￣Ｒｅｄｉｓꎻｌｏｃａｌｏｐｔｉｍａｌｓｅａｒｃｈꎻｄｉｓｔｒｉｂｕｔｅｄꎻｍｉｃｒｏｂｌｏｇｄａｔａｃｒａｗｌｉｎｇ收稿日期:２０１８－０７－１６基金项目:国家自然科学基金项目(６１５７２３９９)ꎻ西安邮电大学研究生创新基金(ＣＸＪＪ２０１７０４２)作者简介:邓万宇(１９７９－)ꎬ男ꎬ教授ꎬ硕士研究生导师ꎬ研究方向为数据挖掘㊁机器学习与知识服务ꎮ０㊀引言随着公众参与互联网的热情越来越高ꎬ微博用户的数量呈快速增长的态势ꎬ微博已经成为了网络舆情中最具影响力的传播载体之一ꎬ微博的发展引起了人们的广泛关注[１－５]ꎮ针对微博环境下的舆情分析需要大量的数据支撑ꎬ鉴于官方提供的ＡＰＩ相关限制造成的数据获取困难ꎬ针对其开发一套专用的网络爬虫系统变得具有实际意义ꎮ目前国内外在网络爬虫领域已经有了很多研究[６－９]ꎮＬａｒｂｉｎ㊁Ｎｕｔｃｈ㊁Ｈｅｒｉｔｒｉｘ等已经是比较成熟的网络爬虫项目ꎬ经过调研ꎬ发现它们在用户亲和性㊁分布式扩展㊁以及开发复杂度上存在着一些问题ꎮ综合考虑开发成本及工作比重ꎬ本着快速㊁简便㊁可配置的原则ꎬ为后续分析挖掘工作提供可靠的数据支撑ꎬ我们选择基于ｐｙｔｈｏｎ开源框架Ｓｃｒａｐｙ搭配基于内存的数据库Ｒｅｄｉｓ来开发一套部署方便㊁可定制性高的中小规模分布式网络爬虫来完成微博数据的采集工作ꎮ１㊀结构设计１.１㊀Ｓｃｒａｐｙ￣ＲｅｄｉｓＳｃｒａｐｙ是一款基于Ｐｙｔｈｏｎ开发的开源ｗｅｂ爬虫框架ꎬ可快速抓取Ｗｅｂ站点并提取页面中的结构化数据ꎬ具有高度的扩展性和鲁棒性ꎮ而Ｒｅｄｉｓ作为一个基于内存的Ｋｅｙ￣Ｖａｌｕｅ数据库ꎬ以高性能著９５称ꎬ其读写频率可以超１０５每秒[１０－１１]ꎮ通过周期性的把更新的数据或者把修改操作写入磁盘和写入追加的记录文件ꎬ实现了主从同步机制ꎮＳｃｒａｐｙ￣Ｒｅｄｉｓ是使用Ｓｃｒａｐｙ框架与Ｒｅｄｉｓ数据库工具组合实现的一个网络分布式抓取开源项目ꎮ其分布式体现在多个Ｓｐｉｄｅｒ同时工作时产生的ＵＲＬ及ｒｅｑｕｅｓｔｓ请求ꎬ将存入统一的ＲｅｄｉｓＱｕｅｕｅ队列ꎬ然后通过布隆过滤器ＢｌｏｏｍＦｉｌｔｅｒ去重ꎬ再分配给各爬虫进行抓取ꎮ其整体框架及内部运行流程如图１所示ꎮ图１㊀Ｓｃｒａｐｙ￣Ｒｅｄｉｓ框架结构及内部数据流首先ꎬＳｐｉｄｅｒ从Ｒｅｄｉｓ中获取初始ＵＲＬꎬ引擎从Ｓｐｉｄｅｒ中获取初始爬取请求Ｒｅｑｕｅｓｔｓꎮ引擎安排请求Ｒｅｑｕｅｓｔｓ到调度器Ｓｃｈｅｄｕｌｅｒ中ꎬ并向调度器请求下一个要爬取的Ｒｅｑｕｅｓｔｓꎮ期间本地的Ｓｌａｖｅ调度器会通过网络先将获取的Ｒｅｑｕｅｓｔｓ请求插入到Ｒｅ￣ｄｉｓ中ꎬ经过内部去重后ꎬ再从Ｒｅｄｉｓ获取一个Ｒｅ￣ｑｕｅｓｔｓꎮ然后调度器将Ｒｅｑｕｅｓｔｓ返回给引擎ꎬ引擎将得到的Ｒｅｑｕｅｓｔｓ通过下载器中间件ＤｏｗｎｌｏａｄｅｒＭｉｄ￣ｄｌｅｗａｒｅｓ发送给下载器进行页面下载ꎮ一旦下载完毕ꎬ下载器会生成一个该页面的Ｒｅｓｐｏｎｓｅ返回给引擎ꎮ引擎从下载器中得到该Ｒｅｓｐｏｎｓｅ并通过爬虫中间件ＳｐｉｄｅｒＭｉｄｄｌｅｗａｒｅｓ发送给Ｓｐｉｄｅｒ处理ꎮＳｐｉ￣ｄｅｒ处理Ｒｅｓｐｏｎｓｅ并通过爬虫中间件ＳｐｉｄｅｒＭｉｄｄｌｅ￣ｗａｒｅｓ返回爬取到的Ｉｔｅｍ以及新的Ｒｅｑｕｅｓｔ给引擎ꎮ引擎将上步中Ｓｐｉｄｅｒ爬取到的Ｉｔｅｍ发送给管道ＩｔｅｍＰｉｐｅｌｉｎｅｓꎬ将新的Ｒｅｑｕｅｓｔ继续发送给调度器ꎬ并向调度器请求可能存在的下一个要爬取的请求Ｒｅｑｕｅｓｔｓꎮ至此ꎬ循环执行上述步骤直至调度器中不再有更多的请求Ｒｅｑｕｅｓｔｓꎮ１.２㊀分布式架构采用主从式架构ꎬ有一台独立的Ｍａｓｔｅｒ服务器来负责管理待抓取的ＵＲＬ队列以及Ｒｅｑｕｅｓｔｓ请求ꎬ每次将ＵＲＬ分发至各个Ｓｌａｖｅ客户端ꎬ然后由Ｓｌａｖｅ客户端启动爬虫主程序对目标站点进行爬取ꎮ系统物理架构如图２所示ꎮ２㊀微博爬虫设计本文设计的微博爬虫是一类主题爬虫[１２－１６]ꎬ具图２㊀分布式物理架构有目标单一ꎬ布局较小ꎬ占用资源少等特点ꎬ只专注于解决微博领域的一些问题ꎮ通过分析微博站点结构ꎬ利用微博用户间的 关注 与 粉丝 关系ꎬ采用局部最佳搜索策略ꎬ实验证明抓取的数据带有一定的天然相关性ꎮ２.１㊀爬行策略设计本文在设计微博爬虫系统时ꎬ充分考虑了微博站点ＵＲＬ的结构特点ꎬ并在此基础上着重分析并利用了用户与用户之间ꎬ用户与博文之间的关联关系ꎬ设计了一种最佳优先爬行策略ꎬ能够引导爬虫抓取具有一定相关性的用户信息与微博内容数据ꎮ爬虫根据预先设定的一个或若干初始种子ＵＲＬ开始ꎬ直接访问并下载页面ꎬ经页面解析器去掉页面上的ＨＴＭＬ标签得到页面内容ꎬ通过用户关注列表㊁粉丝列表获取新的目标用户ＩＤꎬ经过字符串拼接ꎬ构造新的网页ＵＲＬ放入ＲｅｄｉｓＱｕｅｕｅ队列ꎬ期间经过去重和排序操作ꎮ然后将筛选通过的ＵＲＬ加入待爬队列进而供爬虫抽取进行下一步的下载和页面解析操作ꎮ此过程将一直循环执行ꎬ直到列表队列为空ꎬ则整个抓取过程结束ꎮ整个流程如图３所示ꎮ２.２㊀定义抓取对象微博页面中包含多种内容ꎬ通过定义Ｉｔｅｍ来选择需要抓取的对象信息ꎮ我们定义了两种数据的字段信息如表１－２所示ꎮ表１㊀ｕｓｅｒｉｎｆｏ数据方法定义名称字段名称字段说明定义ＩｔｅｍＵｓｅｒＩｎｆｏＩｔｅｍＩｄ用户ＩＤＮｉｃｋＮａｍｅ昵称Ｇｅｎｄｅｒ性别Ｌｏｃａｔｉｏｎ所在地区ＢｒｉｅｆＩｎｔｒｏｄｕｃｔｉｏｎ个人简介Ｂｉｒｔｈｄａｙ生日Ａｕｔｈｅｎｔｉｃａｔｉｏｎ微博认证Ｔｗｅｅｔｓ微博数Ｆｏｌｌｏｗｅｒ关注数Ｆａｎｓ粉丝数０６图３㊀基于用户ＩＤ的最佳爬行策略表２㊀ｔｗｅｅｔｓ信息数据方法定义名称字段名称字段说明定义ＩｔｅｍＴｗｅｅｔｓＩｔｅｍＷＩｄ微博ＩＤＣｏｎｔｅｎｔ微博内容ＩｓＴｒａｎｓｆｅｒ是否为转发ＴｒａｎｓｆｅｒＲｅａｓｏｎ转发理由Ｔｒａｎｓｆｅｒ转发数Ｌｉｋｅ点赞数Ｃｏｍｍｅｎｔ评论数ＰｕｂＴｉｍｅ发表时间Ｔｏｏｌｓ设备来源２.３㊀编写Ｓｐｉｄｅｒ类区别于单机爬虫Ｓｐｉｄｅｒ类的编写ꎬ分布式Ｗｅｉ￣ｂｏＳｐｉｄｅｒ是自定义编写的针对微博页面解析的Ｓｐｉ￣ｄｅｒ类ꎬ它不再继承原始的ｓｃｒａｐｙ.Ｓｐｉｄｅｒ类ꎬ而是继承了ＲｅｄｉｓＳｐｉｄｅｒ类ꎬ用来从ｒｅｄｉｓ读取ｕｒｌꎮ同样也不再使用ｓｔａｒｔ＿ｕｒｌｓꎬ取而代之的是ｒｅｄｉｓ＿ｋｅｙꎬｓｃｒａｐｙ￣ｒｅｄｉｓ将ｋｅｙ从Ｒｅｄｉｓ中ｐｏｐ出来ꎬ成为请求的ｕｒｌ地址ꎮ关键代码如下:ｒｅｄｉｓ＿ｋｅｙ＝ ＷｅｉｂｏＳｐｉｄｅｒ.ｓｔａｒｔ＿ｕｒｌｓʊＳｐｅｃｉｆｙｔｈｅｉｎｉｔｉａｌｕｒｌａｄｄｒｅｓｓａｌｌｏｗｅｄ＿ｄｏｍａｉｎｅｄ＝[ ｈｔｔｐｓ:ʊｗｅｉｂｏ.ｃｎ ]ʊＡｌｌｏｗｅｄｃｒａｗｌｅｄｐａｇｅｒａｎｇｅ爬虫正常启动进入到解析页面阶段ꎬ首先解析到的是用户的资料页面ꎬ使用Ｘｐａｔｈ获取页面标签中所有ｔｅｘｔꎬ添加以下代码:Ｉｎｆｏｔｅｘｔ＝ :ｅｎｄ .ｊｏｉｎ(ｓｅｌｅｃｔｏｒ.ｘｐａｔｈ( ｂｏｄｙ/ｄｉｖ[＠ｃｌａｓｓ＝ ｃ ]ʊｔｅｘｔ() )).ｅｘｔｒａｃｔ()ʊＧｅｔｔｏｔａｌｕｓｅｒｐｅｒｓｏｎａｌｉｎｆｏｒｍａｔｉｏｎ获取ｉｎｆｏｔｅｘｔ后ꎬ再通过ｐｙｔｈｏｎ正则表达式工具包ｒｅ匹配获取拟定的用户个人信息数据ꎮ处理完个人信息页面后ꎬ使用ｙｉｅｌｄ返回请求Ｒｅｑｕｅｓｔ分别指向三个ｕｒｌꎬ即ｔｗｅｅｔｓ㊁ｆｏｌｌｏｗ和ｆａｎｓꎬ基于当前用户ＩＤ使用ｃａｌｌｂａｃｋ回调函数分别执行三个不同页面的解析工作ꎬ代码如下:ｙｉｅｌｄＲｅｑｕｅｓｔ(ｕｒｌ＝ ｈｔｔｐｓ:ʊｗｅｉｂｏ.ｃｎ/ｕ/{}?ｐａｇｅ＝１ .ｆｏｒｍａｔ(ＩＤ))ꎬｃａｌｌｂａｃｋ＝ｓｅｌｆ.ｐａｒｓｅ＿ｔｗｅｅｔｓꎬｍｅｔａ＝{ ｂａｓｅｉｔｅｍ :ｕｓｅｒｉｎｆｏꎬｄｏｎ ｔ＿ｆｉｌｔｅｒ＝Ｔｒｕｅ}ʊＧｏｉｎｇｔｏｒｅｑｕｅｓｔｕｓｅｒｗｅｉｂｏｃｏｎｔｅｎｔｈｏｍｅｐａｇｅｙｉｅｌｄＲｅｑｕｅｓｔ(ｕｒｌ＝ ｈｔｔｐｓ:ʊｗｅｉｂｏ.ｃｎ/ｕ/{}ｆｏｌｌｏｗ .ｆｏｒｍａｔ(ＩＤ))ꎬｃａｌｌｂａｃｋ＝ｓｅｌｆ.ｐａｒｓｅ＿ｒｅｌａｔｉｏｎｓｈｉｐꎬｄｏｎ ｔ＿ｆｉｌｔｅｒ＝Ｔｒｕｅ}ʊＧｏｉｎｇｔｏｒｅｑｕｅｓｔｕｓｅｒｆｏｌｌｏｗｅｒｐａｇｅｙｉｅｌｄＲｅｑｕｅｓｔ(ｕｒｌ＝ ｈｔｔｐｓ:ʊｗｅｉｂｏ.ｃｎ/ｕ/{}ｆａｎｓ .ｆｏｒｍａｔ(ＩＤ))ꎬｃａｌｌｂａｃｋ＝ｓｅｌｆ.ｐａｒｓｅ＿ｒｅｌａｔｉｏｎｓｈｉｐꎬｄｏｎ ｔ＿ｆｉｌｔｅｒ＝Ｔｒｕｅ}ʊＧｏｉｎｇｔｏｒｅｑｕｅｓｔｕｓｅｒｆａｎｓｐａｇｅ在完成Ｓｐｉｄｅｒ类的编写后ꎬ需要在Ｓｃｒａｐｙ的ｓｅｔｔｉｎｇ中配置连接参数ꎮ除去单机爬虫所需的基本的配置项外ꎬ实现分布式还需修改配置以下信息:ＳＣＨＥＤＵＬＥＲ＝ ｓｃｒａｐｙ＿ｒｅｄｉｓ.ｓｃｈｅｄｕｌｅｒ.Ｓｃｈｅｄｕｌｅｒ ʊＬｏａｄｉｎｇｍｉｄｄｌｅｗａｒｅＤＵＰＥＦＩＬＴＥＲ＿ＣＬＡＳＳ＝ ｓｃｒａｐｙ＿ｒｅｄｉｓ.ｄｕｐｅｆｉｌｔｅｒ.ＲＦ￣ＰＤｕｐｅＦｉｌｔｅｒ ʊＬｏａｄｕｒｌｆｉｌｔｅｒ２.４㊀数据存储Ｓｃｒａｐｙ支持多种文本存储格式ꎬ比如ｊｓｏｎꎬｃｓｖ和ｘｍｌ等ꎮ此外Ｓｃｒａｐｙ还提供了多种数据库的ＡＰＩ来支持数据库存储ꎬ比如ＭｙＳＱＬ㊁ＭｏｎｇｏＤＢ等ꎮ本文引入ｐｙｍｏｎｇｏ工具包ꎬ修改Ｐｉｐｅｌｉｎｅ文件实现了数据保存到ＭｏｎｇｏＤＢ数据库当中ꎮ主要代码如下:启动爬虫时ꎬ初始化ＭｏｎｇｏＤＢ连接:ｓｅｌｆ.ｃｌｉｅｎｔ＝ｐｙｍｏｎｇｏ.ＭｏｎｇｏＣｌｉｅｎｔ(ｓｅｌｆ.ｍｏｎｇｏ＿ｕｒｌ)ʊＧｅｔｓｅｒｖｅｒａｄｄｒｅｓｓａｎｄｅｓｔａｂｌｉｓｈｃｏｎｎｅｃｔｉｏｎｓｅｌｅ.ｄｂ＝ｓｅｌｆ.ｃｌｉｅｎｔ(ｓｅｌｆ.ｍｏｎｇｏ＿ｄｂ)ʊＣｏｎｎｅｃｔｔｏｔｈｅｄａｔａｂａｓｅ执行插入操作:ｓｅｌｆ.ｄｂ(ｓｅｌｆ.ｕｓｅｒｉｎｆｏ.ｉｎｓｅｒｔ(ｄｉｃｔ(ｉｔｅｍ))ʊＩｎｓｅｒｔｉｎｔｏｕｓｅｒｉｎｆｏｔａｂｌｅ１６ｓｅｌｆ.ｄｂ(ｓｅｌｆ.ｔｗｅｅｔｓ.ｉｎｓｅｒｔ(ｄｉｃｔ(ｉｔｅｍ))ʊＩｎｓｅｒｔｉｎｔｏｔｗｅｅｔｓｔａｂｌｅ关闭爬虫同时关闭数据库连接:ｓｅｌｆ.ｃｌｉｅｎｔ.ｃｌｏｓｅ()ʊＣｌｏｓｅｔｈｅｃｏｎｎｅｃｔｉｏｎ２.５㊀系统测试系统由三台物理节点组成ꎬ一台Ｍａｓｔｅｒ服务器ꎬ两台Ｓｌａｖｅ服务器ꎮ由Ｍａｓｔｅｒ管理Ｕｒｌ队列和分发下载任务ꎬ两台Ｓａｌｖｅ同时下载网页提取数据ꎮ以新浪微博ｗａｐ端作为抓取目标ꎬ运行８小时后ꎬ抓取用户信息３４Ｗ项ꎬ微博１６８０Ｗ条ꎮ将抓取到的微博数据存储到基于分布式文件存储的ＭｏｎｇｏＤＢ数据库中ꎬ为下一步的数据扩展应用提供一个可扩展的高性能数据存储解决方案ꎮ使用ＭｏｎｇｏＤＢ可视化工具ＭｏｎｇｏＢｏｏｓｔｅｒ展示部分所获数据ꎬ如图４所示ꎮ图４㊀抓取的ＵｓｅｒＩｎｆｏ存储在ＭｏｎｇｏＤＢ３㊀结束语本文立足于快速㊁灵活抓取微博数据这一目的ꎬ设计实现了一套面向微博数据采集的高效分布式爬虫系统ꎮ采用Ｓｃｒａｐｙ￣Ｒｅｄｉｓ分布式设计思想对目标数据进行加速爬取ꎬ并通过对微博站点的结构分析ꎬ设计了一种适用于微博站点的爬虫爬行策略ꎬ使得获取的源数据带有一定的天然相关性ꎮ此外ꎬ还介绍了框架支持的多种持久化存储方式以及Ｍｏｎ￣ｇｏＤＢ数据库存储的具体实现ꎮ本文实现的分布式微博爬虫可为后续的微博数据挖掘与分析工作提供精准可靠的源数据支持ꎮ参考文献:[１]李洋ꎬ陈毅恒ꎬ刘挺.微博信息传播预测研究综述[Ｊ].软件学报ꎬ２０１６ꎬ２７(２):２４７－２６３.[２]ＷａｎｇＲｕꎬＳｅｕｎｇｍｉｎＲｈｏꎬＣｈｅｎＢｏ￣ｗｅｉꎬｅｔａｌ.Ｍｏｄｅｌｉｎｇｏｆｌａｒｇｅ￣ｓｃａｌｅｓｏｃｉａｌｎｅｔｗｏｒｋｓｅｒｖｉｃｅｓｂａｓｅｄｏｎｍｅｃｈａｎｉｓｍｓｏｆｉｎｆｏｒｍａｔｉｏｎｄｉｆ￣ｆｕｓｉｏｎ:ＳｉｎａＷｅｉｂｏａｓａｃａｓｅｓｔｕｄｙ[Ｊ].ＦｕｔｕｒｅＧｅｎｅｒａｔｉｏｎＣｏｍｐｕｔ￣ｅｒＳｙｓｔｅｍｓꎬ２０１７ꎬ７４(Ｃ):２９１－３０１.[３]ＹｕＤｉｎｇ￣ｇｕｏꎬＣｈｅｎＮａｎꎬＲａｎＸｕ.ＣｏｍｐｕｔａｔｉｏｎａｌｍｏｄｅｌｉｎｇｏｆＷｅｉｂｏｕｓｅｒｉｎｆｌｕｅｎｃｅｂａｓｅｄｏｎｉｎｆｏｒｍａｔｉｏｎｉｎｔｅｒａｃｔｉｖｅｎｅｔｗｏｒｋ[Ｊ].ＯｎｌｉｎｅＩｎｆｏｒｍａｔｉｏｎＲｅｖｉｅｗꎬ２０１６ꎬ４０(７):８６７－８８１.[４]ＢｅｌａＦｌｏｒｅｎｔｈａｌꎬＭｉｋｅＣｈｅｎ￣ＨｏＣｈａｏ.ＡＣｒｏｓｓ￣ＣｕｌｔｕｒａｌＣｏｍｐａｒｉｓｏｎｏｆａＧｌｏｂａｌＢｒａｎｄ ｓＳｔｒａｔｅｇｉｅｓｏｎＭｉｃｒｏ￣ＢｌｏｇｇｉｎｇＳｉｔｅｓ:ＳｉｎａＷｅｉｂｏ￣ｖｓ.Ｔｗｉｔｔｅｒ[Ｊ].ＩｎｔｅｒｎａｔｉｏｎａｌＪｏｕｒｎａｌｏｆＯｎｌｉｎｅＭａｒｋｅｔｉｎｇ(ＩＪＯＭ)ꎬ２０１７ꎬ６(４):５４－７２.[５]ＪｉａｎｇꎬＬｅｅｍａｎꎬＦｕ.ＮｅｔｗｏｒｋｅｄＦｒａｍｉｎｇ:ＣｈｉｎｅｓｅＭｉｃｒｏｂｌｏｇｇｅｒｓＦｒａｍｉｎｇｏｆｔｈｅＰｏｌｉｔｉｃａｌＤｉｓｃｏｕｒｓｅａｔｔｈｅ２０１２ＤｅｍｏｃｒａｔｉｃＮａｔｉｏｎａｌＣｏｎｖｅｎｔｉｏｎ[Ｊ].ＣｏｍｍｕｎｉｃａｔｉｏｎＲｅｐｏｒｔｓꎬ２０１６ꎬ２９(２):１－１３.[６]ＣａｒｌｏｓＣａｓｔｉｌｌｏ.Ｅｆｆｅｃｔｉｖｅｗｅｂｃｒａｗｌｉｎｇ[Ｊ].ＡＣＭＳＩＧＩＲＦｏｒｕｍꎬ２００５ꎬ３９(１):５５－５６.[７]许笑ꎬ张伟哲ꎬ张宏莉ꎬ等.广域网分布式Ｗｅｂ爬虫[Ｊ].软件学报ꎬ２０１０ꎬ２１(５):１０６７－１０８２.[８]ＣｈｅｎＸｉｎｇꎬＬｉＷｅｉ￣ｊｉａｎｇꎬＺｈａｏＴｉｅ￣ｊｕｎꎬｅｔａｌ.ＤｅｓｉｇｎｏｆｔｈｅＤｉｓｔｒｉｂｕ￣ｔｅｄＷｅｂＣｒａｗｌｅｒ[Ｊ].ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌｓＲｅｓｅａｒｃｈꎬ２０１１ꎬ２０１－２０４:１４５４－１４５８.[９]ＸｉｅＤｏｎｇ￣ｘｉａｎｇꎬＸｉａＷｅｎ￣ｆｅｎｇ.ＤｅｓｉｇｎａｎｄＩｍｐｌｅｍｅｎｔａｔｉｏｎｏｆｔｈｅＴｏｐｉｃ￣ＦｏｃｕｓｅｄＣｒａｗｌｅｒＢａｓｅｄｏｎＳｃｒａｐｙ[Ｊ].ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌｓＲｅｓｅａｒｃｈꎬ２０１４ꎬ８５０－８５１:４８７－４９０.[１０]曾超宇ꎬ李金香.Ｒｅｄｉｓ在高速缓存系统中的应用[Ｊ].微型机与应用ꎬ２０１３ꎬ３２(１２):１１－１３.[１１]ＧａｏＸｉａｏ￣ｂｏꎬＦａｎｇＸｉａｎ￣ｍｅｉ.Ｈｉｇｈ￣ＰｅｒｆｏｒｍａｎｃｅＤｉｓｔｒｉｂｕｔｅｄＣａｃｈｅＡｒｃｈｉｔｅｃｔｕｒｅＢａｓｅｄｏｎＲｅｄｉｓ[Ｍ].ＳｐｒｉｎｇｅｒＢｅｒｌｉｎＨｅｉｄｅｌｂｅｒｇ:２０１４.[１２]汪涛ꎬ樊孝忠.主题爬虫的设计与实现[Ｊ].计算机应用ꎬ２００４(Ｓ１):２７０－２７２.[１３]刘玮玮.搜索引擎中主题爬虫的研究与实现[Ｄ].南京:南京理工大学ꎬ２００６.[１４]ＣｈｅｎＸｉｕ￣ｘｉａꎬＳｈａｎｇＷｅｎ￣ｑｉａｎ.ＲｅｓｅａｒｃｈａｎＤｅｓｉｇｎｏｆＷｅｂＣｒａｗｌ￣ｅｒｆｏｒＭｕｓｉｃＲｅｓｏｕｒｃｅｓＦｉｎｄｉｎｇ[Ｊ].ＡｐｐｌｉｅｄＭｅｃｈａｎｉｃｓａｎｄＭａｔｅ￣ｒｉａｌｓꎬ２０１４ꎬ５４３－５４７:２９５７－２９６０.[１５]ＺｈａｏＱｉｕꎬＣｅｎｇＪｕｎＤａｉꎬＴａｏＬｉｕ.ＤｅｓｉｇｎｏｆＴｈｅｍｅＣｒａｗｌｅｒｆｏｒＷｅｂＦｏｒｕｍ[Ｊ].ＡｐｐｌｉｅｄＭｅｃｈａｎｉｃｓａｎｄＭａｔｅｒｉａｌｓꎬ２０１４ꎬ５４８－５４９:１３３０－１３３３.[１６]ＨｕＨꎬＧｅＹＪ.ＵｓｉｎｇＷｅｂＣｒａｗｌｅｒＴｅｃｈｎｏｌｏｇｙｆｏｒＴｅｘｔＡｎａｌｙｓｉｓｏｆＧｅｏ￣Ｅｖｅｎｔｓ:ＡＣａｓｅＳｔｕｄｙｏｆｔｈｅＨｕａｎｇｙａｎＩｓｌａｎｄＩｎｃｉｄｅｎｔ[Ｊ].ＩＳＰＲＳ￣ＩｎｔｅｒｎａｔｉｏｎａｌＡｒｃｈｉｖｅｓｏｆｔｈｅＰｈｏｔｏｇｒａｍｍｅｔｒｙꎬＲｅｍｏｔｅＳｅｎｓｉｎｇａｎｄＳｐａｔｉａｌＩｎｆｏｒｍａｔｉｏｎＳｃｉｅｎｃｅｓꎬ２０１３ꎬＸＬ￣４/Ｗ３(４):７１－７８.责任编辑:丁玥２６。
新浪微博应用开发的一个解决方案
新浪微博应用开发的一个简易方案PHP+新浪微博开放平台+新浪云平台(SAE)贺利坚2012.2.25目 录一、必须交待的几个问题 (1)二、PHP+新浪微博开放平台+新浪云平台（SAE）方案的基础 (2)三、建立微博应用的过程 (4)四、PHP SDK中Demo程序简析 (18)五、进一步学习的走向和有用的资源 (27)附录1：新浪微博旧版API中的PHP例程 (29)附录2：新浪微博开放平台WeiboClient类的公共方法 (59)一、必须交待的几个问题这是一个不严肃的册子，主要因为：（1）作者不精通PHP，对PHP涉及的内容早有了解，但没有专门学习，之前更没有做过程序。
在决定试着体验用PHP开发微博应用后，也仅用半个上午的时间，浏览了PHP的一般语法；（2）这本册子是匆忙完成的，学习时间一天半，写作时间一天。
主要是因为并不打算在此方面深入做下去，也没有那么多的时间；（3）册子中除了作者自写的文字，其他材料全部来自新浪微博开放平台（/）和新浪云平台（/），有拼凑之嫌。
但是，这是一本很实用的册子，起码作者这样认为。
以作者飞速的学习进度，有力地说明这是快速了解微博应用开发的最好材料，给出的解决方案也是最适合初学者构建微博应用开发的。
一旦能够在浏览器中看到自己的代码操纵着微博中的信息，微博应用开发中不少概念将生动起来，再进一步做一些工作将不再那样艰苦。
尽管不严肃，还是决定写出来。
针对零基础的开发者，现在还没有一个适合的资料。
我的贡献在于为刚起步开发的读者整理出了个头绪，提出了一种最简便的学习方案。
从初学者的角度，凭着自己尚热乎的初学者感觉，帮其他初学者一把。
因为不精通，很多相应平台上能说清楚的事情，直接给出链接，而不再多言。
平台上的文字有些太多，初学者没看几个字，就被绕糊涂了。
我的贡献是指出看这些庞杂文档的一个建议，并尽量引导读者动手做，早些找到感觉。
所以，这本小册子仅是在微博应用开发上帮助读者起步的。
Redis核心原理与应用实践
Redis核心原理与应用实践概念介绍Redis 是互联网技术架构在存储系统中使用最为广泛的中间件，它也是中高级后端工程师技术面试中面试官最喜欢问的工程技能之一，特别是那些优秀的、竞争激烈的大型互联网公司（比如Twitter、新浪微博、阿里云、腾讯云、淘宝、知乎等），通常要求面试者不仅仅掌握Redis 基础使用，更要求深层理解Redis 内部实现的细节原理。
毫不夸张地说，能把Redis 的知识点全部吃透，你的半只脚就已经踏进心仪大公司的技术研发部。
但在平时经历的很多面试中，老钱发现大多数同学只会拿Redis 做数据缓存，使用最简单的get/set 方法，除此之外几乎一片茫然。
也有小部分同学知道Redis 的分布式锁，但也不清楚其内部实现机制，甚至在使用上就不标准，导致生产环境中出现意想不到的问题。
还有很多同学没认识到Redis 是个单线程结构，也不理解Redis 缘何单线程还可以支持高并发等等。
这也是老钱撰写这本小册的初衷，通过梳理总结自己的实践经验，帮助更多后端开发者更快更深入的掌握Redis 技能。
企业一般为了支撑海量（亿级）的用户服务，使用了上千个Redis 实例，包含大约100 个Redis 集群(Codis) 以及很多独立的Redis 节点，因此，在使用Redis 作为缓存和持久存储中间件上积累了较为丰富的实战经验，这些都将毫无保留的分享到这本小册中。
Redis 涉及到的知识点是非常繁多的，本文将主要讲解其中最常见的Redis 核心原理和应用实践经验，让读者在阅读之后可以快速武装自己并落地到平时的Redis 项目开发中。
除此之外，还会回顾一些底层的至关重要的计算机科学基础原理，以及技术应用的思考方式，这些基础的知识和技能将最终决定你的技术人生道路可以走多快走多远。
本文结构本文在内容结构上分为Redis 基础应用、原理、集群、拓展学习和源码分析5 个版块：∙Redis 基础应用占据篇幅最长，这也是对读者最有价值的内容，可以直接应用到实际工作中。
Redis在新浪微博中的应用
内容目录：••••••Redis 在新浪微博中的应用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 存储服务在微博的演化和实践
食品生产执行标准食品生产执行标准是指在食品生产过程中，制定并执行的一系列规范和要求，旨在确保食品生产的安全、卫生和质量。
食品生产执行标准是食品生产企业的生产经营活动的基本依据，对于保障食品安全、提高食品质量、增强企业竞争力具有重要意义。
首先，食品生产执行标准应当包括生产设施、设备和生产环境的要求。
生产设施和设备应当符合国家相关标准，并经过定期的维护和检修，确保其正常运行和生产卫生。
生产环境应当保持清洁，消毒和防虫防鼠，确保食品生产过程的卫生和安全。
其次，食品生产执行标准应当包括原料的采购和使用要求。
食品生产企业应当选择合格的供应商，对原料进行严格的验收和检验，确保原料的质量安全。
在使用原料时，应当按照配方要求进行精确称量和混合，严禁使用过期、变质或者不符合卫生标准的原料。
另外，食品生产执行标准还应包括生产工艺和操作规程的要求。
生产工艺应当符合国家标准，确保食品生产过程中的加工、储存、包装等环节达到卫生标准。
操作规程应当明确，操作人员应当经过专业培训，严格按照操作规程进行操作，确保生产过程的安全和卫生。
此外，食品生产执行标准还应包括产品质量检验和监控的要求。
食品生产企业应当建立完善的质量检验体系，对生产过程中的关键环节进行监控和检测，确保产品质量符合国家标准。
对于已经生产的成品，应当进行全面的检验和抽检，确保产品的质量安全。
最后，食品生产执行标准还应包括产品包装、储存和运输的要求。
产品包装应当符合国家标准，包装材料应当符合食品包装卫生标准，确保产品在包装过程中不受到污染。
产品储存和运输应当符合卫生标准，确保产品在储存和运输过程中不受到污染和变质。
总之，食品生产执行标准对于保障食品安全、提高食品质量具有重要意义。
食品生产企业应当严格执行食品生产执行标准，确保食品生产过程的安全、卫生和质量，为消费者提供安全、放心的食品产品。
redis数据库操作实验心得
redis数据库操作实验心得
在这次实验中，我接触到了Redis这一高性能的键值数据库。
Redis以其快速、稳定和灵活的特点，在现代的Web应用和数据处理中得到了广泛的应用。
学习过程中，我首先了解了Redis的基本数据类型，如字符串、哈希表、列表、集合和有序集合。
这些数据类型为我提供了丰富的数据存储和操作方式。
例如，哈希表让我可以存储具有多个字段的对象，而列表则提供了列表操作，非常适合进行消息队列等操作。
在实验中，我尝试了使用Redis进行缓存、会话管理以及排行榜的实现。
通过这些实践，我深刻体会到了Redis的强大和灵活。
尤其是缓存功能，它极大地提高了应用的响应速度和性能。
不过，学习过程中也并非一帆风顺。
开始时，我对Redis的某些命令和特性感到困惑。
但随着不断的学习和实践，我逐渐理解并掌握了它们。
未来，我打算更深入地研究Redis的高级特性和最佳实践。
同时，我也希望能够在实际项目中，应用所学到的知识和技能，让Redis发挥出更大的价值。
这次学习Redis的经历让我对数据库技术有了更深入的理解。
我相信，随着经验的积累和技术的进步，我将更好地掌握这一强大的工具。
- 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+关系+数字