新浪微博架构与平台安全
• MPSS (Multi-Port Single Server)
快速成长
• 用户快速增长 • 出现发表延迟现象，尤其是明星用
户
架构演变
• 分发推送是造成发表延迟首因 • 数据规模增大也带来一定延迟
• 规模增大：数据拆分 • 锁表问题：更改引擎 • 发表过慢：异步方式 • 模式改进
第2版
投递模式优化
• 推模式改进，不需要推送到所有用
户
• 存储及发表峰值压力减轻 • 投递延迟减小
数据拆分
• 优先按时间维度拆分 • 内容和索引分开存放 • 内容使用 key-value 方式存储
• 索引由于分页访问，拆分有挑战
(NoSQL)
异步处理
• 发表异步化 • 发表速度及可靠性得到提高 • 使用 MemcacheQ
usually have 1 week of "on call" duty, and the other 5 weeks are spent making improvements to make the on call portion more optimized, automated, and troublefree”
• Multi-Master • Web 应用多地区同步的最佳策略 • 没有现成成熟的产品
微博方案
• 通过消息广播方式将数据多地分
布
• 类似
Yahoo! Message Broker
• “We use YMB for replication for 2
reasons.
• 1. YMB ensure msgs are not lost
• 增加 stats queue，适合大规模运维
技术细节
• InnoDB 引进，避免锁表烦恼 • PHP 中 libmemcached 代替
memcache
• 在高并发下稳定性极大提高
高速发展
• 系统问题
• 数据压力及峰值
• 单点故障、“雪崩” • 访问速度，国内复杂网络环境
• MySQL 复制延迟、慢查询 • 热门事件微博发表量，明星评论及粉丝
书，访问主存就像骑车去社区图书馆拿一本 书。”
- 余锋 @ ecug 2010 淘宝网核心系统专家，Erlang技术专家
微博 cache 设计
高可用
• 好的架构具有高可用性 • 业界
• Amazon S3: 99.9% • Amazon EC2: 99.95% • Facebook: n/a
• 微博平台 ~ 99.95% (5 小时 / 年)
•
PNUTS: Yahoo!’s Hosted Data Serving Platform
新推送架构
现状
• API 大部分请求都是为了获取最新
数据
• 重新思考 Rest API
• 大部分调用都是空返回 • 大部分时间在处理不必要的询问 • 无法实时投递 • 存在请求数限制（rate limit）
cache
• 如何扩展？
思路
• 去状态，可请求服务单元中任意节点 • 去中心化，避免单点及瓶颈 • 可线性扩展，如 • 减少模块耦合
• •
100 万用户，10 台服务器 1000 万用户，100 台服务器
实时性
高性能系统具备低延迟、高实时性 实时性核心是让数据离 CPU 最近，避 免磁盘 IO
“CPU 访问 L1 就像从书桌拿一本书，L2 是 从书架拿一本书，L3 是从客厅桌子上拿一本
如何达到
• 容量规划 • 监控及 admission control...
• 图表 • 接口及资源监控, 7x24 • 业务回环测试, 监测业务逻辑有效性 • 集成测试
图表
通过图表 了解系统容量
接口监控
• curl / 各地请求情况及响应时间 • 流量异常 / access log • non-200 结果 / 失败率 / exceptions • 将监控指标量化
内部细节
• Stream Buffer • 保存用户最近数据 • 保存客户端断线重连之间下行数据
平台安全
• 由于接口开放，需要防范各种恶意
行为
• 垃圾内容 • 垃圾粉丝 • 恶意行为
内容安全
• 微博平台需要 • 为用户提供安全及良好体验的应用 • 为开发者营造公平的环境 • 接口需要清晰的权限控制及安全规
•
- James Hamilton, VP of Amazon
• Designing for automation.”
自动化
• • • • •
大规模互联网系统运作需要尽可能自动化 发布及安装
服务启用、停止
故障处理
前提，去状态化，允许单点故障及重启
• “System administration at Google
• - Jeff Dean, Google Fellow
服务化
• 服务→接口→应用
第3版
平台服务
• 平台服务和应用服务分开，模块隔离 • 新微博引擎，实现 feed cache 分层 • 关系多维度索引结构，性能极大提高 • 计数服务改成基于偏移，更高的一致
性、低延迟
基础服务
• DB 冷热分离等多维度拆分 • 图片等存储去中心化 • 动态内容支持多 IDC 同时更新
before they are applied to the db.
• 2. YMB is designed for wide-area
replication. This isolates individual PNUTS clusters from dealing with update between regions”
微博架构与平台安全
演讲者 @TimYang
微博架构发展
• 新浪微博从 0 ~ 50,000,000 用户 • 技术架构经历了 3 个阶段
第1版
技术特点
• 微博本质是解决发表/订阅问题 • 第 1 版采用推消息模式，将发表/订
阅简化成 insert / select 问题
技术细节
• 典型 LAMP 架构 • MySQL：单库单表, MyISAM
• 类似 mysql seconds behind master
• “Many services are written to alert
operations on failure and to depend upon human intervention for recovery, about 20% of the time they will make mistakes.
• “Break large complex systems
down into many services... search touches 100s of services (ads, web search, books, news, spelling correction...)”
则
接口安全
• Auth层
• 权限层
• 访问需要 AppKey • 需要 OAuth 授权 • 流量控制、权限
• 构就是将复杂问题抽象简单并
解决
• 下一代微博架构，期待您的参与 • Join us! @TimYang
高性能架构
• 50,000,000 用户使用新浪微博 • 最高发表 3,000 条微博 / 秒 • 姚晨发表一条微博，会被 3,689,713
粉丝读到（11 月 10 日 数据）
问题本质
• 解决高访问量、海量数据规模下
• •
易于扩展、低延迟
高可用
异地分布能力
• 每天数十亿次Web及接口请求 • 请求内容随时变化，结果无法
如何解决
• 新一代推送接口(Stream API) • 采用推送的方式
• 有新数据服务器立即推送给调用方 • 无数据则不消耗流量 • 客户端实现更简单
技术特点
• 低延迟，从发表到客户端接收1秒内完成 • 高并发长连接服务
推送架构
• 为什么先持久化
• KISS，Keep It Simple and Stupid • 测试表明持久几乎不增加延迟开销 • batch insert • cursor read
• •
- Tom Limoncelli @ Everything Sysadmin Lumeta Corporation总监，贝尔实验室专家
微博系统运转依赖大量自动化工具
工具在持续改进并增加中⋯⋯
• 高可用性还有异地分布的需求 • 在国内网络环境下，IDC 灾难、机
房检修维护会导致服务中断
• 用户就近访问可提高速度
• 静态内容分布采用 CDN 技术，成
熟
• 动态内容分布是业界难点 • 核心是数据的分布式存储
• 理想的分布式存储产品
延迟、高可用性
• 支持海量规模、可扩展、高性能、低
• 多机房分布，异地容灾 • 调用简单，具备丰富数据库特性
分布式存储 需要解决多对多的数据复制同步 及数据一致性
复制策略
• Master / Slave • 实现简单，master 有单点风险 • Multi-Master • 合并多处写，异步，最终一致性 • 需要应用避免冲突 • Paxos：强一致性，延迟大
如何改进
•
系统方面
• •
• •
允许任意模块失败
静态内容 CDN 加速
• 数据压力及峰值
将数据、功能、部署尽可能拆分
提前容量规划
平台化需求
• Web 系统 • API 系统
• 有用户行为才有请求 • 轮询请求 • 峰值不明显 • 用户行为很难预测
• 系统规模持续增大 • 平台化需求
• 新的架构如何设计？
新浪微博框架
大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。
最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。
很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。
另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。
今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。
首先给大家介绍一下微博架构发展的历程。
新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。
第一版就是是非常快的，我们可以非常快的实现我们的模块。
我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。
我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。
第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。
另外一个是MPSS，就是多个端口可以布置在服务器上。
为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。
我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。
这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。
如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。
我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。
我们技术上碰到几个问题。
第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。
另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。
微博的应用与发展
微博的应用与发展摘要：本文首先介绍了微博的概念及发展历程，然后重点介绍了微博的功能与优势。
在简单地对目前微博发展的现状进行了分析之后，通过对微博的盈利模式与用户行为的研究，展望了微博未来的发展趋势，并针对趋势提出了相应的应对策略。
一、微博简述1、微博的含义与特点微博，即微博客（MicroBlog）的简称，是一个基于用户关系的信息分享、传播以及获取平台，用户可以通过WEB、WAP以及各种客户端组件个人社区，以140字左右的文字更新信息，并实现即时分享。
微博是最近新兴起的一个web2.0表现。
它最大的特点就是集成化和开放化，可以使得用户通过的手机、IM软件（gtalk、MSN、QQ、skype）和外部API接口等途径向微博客发布消息。
2、微博的起源与在中国的发展2006年3月的创始人推出了Twitter,英文原意为小鸟的叽叽喳喳声，用户能用如手机短信等数百种工具更新信息，这就是最早出现的微博。
Twitter 被Alexa网页流量统计评定为最受欢迎的50个网络应用之一，截至2010年1月份，该产品在全球已经拥有7500万注册用户。
2009年8月份中国最大的门户网站新浪网推出“新浪微博”内测版，成为门户网站中第一家提供微博服务的网站，微博正式进入中文上网主流人群视野。
微博作为市场上出现的一种新产品，目前仍然处于起步和成长阶段，微博要作为一种成熟地产品走进用户的生活还需要一个漫长的发展阶段。
如图１所示：美国微博目前正处于快速发展阶段，而中国微博处于起步阶段。
从总体上来看在微博在未来发展的道路上必然会经历被夸大的预期峰值以及预期与现实幻灭的低谷两个阶段，只有进行不断地产品创新才能保证微博产品长久、可持续的生命力，并最终达到稳定与成熟。
图１：微博的发展历程具体从微博在中国的发展阶段来看，虽然微博在中国的诞生时间不长，在将来微博客的整个发展史上可能刚处于导入期阶段，但微博客的发展和流行，迄今可以说已经历了五个关键阶段：1)微博客鼻祖推特(Twitter) 在2006 年3 月由 的创始人伊万•威廉姆斯（Evan Williams）推出，在中国则以饭否2007 年的流行为代表，第一批的中国微博客用户多为Twitter 和饭否等网站的用户。
微博介绍
原创性
• 大量原创内容爆发性地被生产出来。李松 大量原创内容爆发性地被生产出来。 博士认为， 博士认为，微型博客的出现具有划时代的 意义，真正标志着个人互联网时代的到来。 互联网时代的到来 意义，真正标志着个人互联网时代的到来。 博客的出现，已经将互联网上的社会化媒 博客的出现，已经将互联网上的社会化媒 推进了一大步，公众人物纷纷开始建立 体推进了一大步，公众人物纷纷开始建立 自己的网上形象。然而， 自己的网上形象。然而，博客上的形象仍 然是化妆后的表演，博文的创作需要考虑 然是化妆后的表演，博文的创作需要考虑 完整的逻辑 逻辑， 完整的逻辑，这样大的工作量对于博客作 者成为很重的负担。 沉默的大多数” 者成为很重的负担。“沉默的大多数”在 微博客上找到了展示自己的舞台。 微博客上找到了展示自己的舞台。
• 资本和创新的战争 当然，毋庸置疑的是，年轻的微博仍在生长中。 在激烈的市场竞争中，资本和创新成为取胜的关 键。当然，除资本外，对用户需求的把握和创新 更为重要，在这方面，微博竞争已经开始呈现出 差异化。 新浪微博的目标是打造“开放的互联网平台” 新浪微博的目标是打造“开放的互联网平台”。 搜狐微博则明确定位为“纯2.0媒体”。 搜狐微博则明确定位为“ 媒体” 媒体 腾讯则对社交化以及和腾讯其他产品对接重点关注。 经济学名人”则成为网易微博重点打造的吸引力。 “经济学名人”则成为网易微博重点打造的吸引力。
• 微博走向主流化 微博应用的范围不断拓展，信息的发布 与获取、社交拓展、社会事务讨论、政府 问政网民、商业营销、社会公益……微博 …… 开始全面渗透进社会各领域。
• 当微博迈进现实 关注产生力量，围观改变世界。 “关注产生力量，围观改变世界。”当微博 的内容逐渐从娱乐拓展到社会热点， 的内容逐渐从娱乐拓展到社会热点，当微 博走下网络，开始与社会现实广泛对接， 博走下网络，开始与社会现实广泛对接， 它在社会、政治、经济、 它在社会、政治、经济、文化等领域的影 响便开始逐步显现出来。 响便开始逐步显现出来。 “微公益” 聚沙成塔，“微政务”的蔚然成 微公益” 聚沙成塔， 微政务” 风 ，各类“微商务”已开始试水······ 各类“微商务”已开始试水
新浪微博稳定性经验谈
o 快速解决：容灾预案
o 清楚系统健康状况趋势
新浪微博稳定性经验谈
• 容灾预案
o IDC容灾（切换到其它IDC） o 限流（拒绝超出或异常的请求）
o 降级（降级有问题资源、保核心功能）
o 紧急快速扩容 o ……
新浪微博稳定性经验谈
• 所做这些都是有效的吗？是否有遗漏？
在测试环境下已经做了充分测试！ o 线上呢？等待异常出现时来验证系统是否经得起考验？
• 保证系统一直处于稳定状态
o 新系统上线和重大改造前先进行稳定性测试
o 周期性的演练测试
新浪微博稳定性经验谈
• 在线演练一些注意事项
o 避免copy上行接口流量导致写请求被多次处理
o 避免写花缓存数据
o 避免对后端造成很大压力 o 尽量选择在低峰和有工程师在场的时间段进行演练
o 完善的监控报警机制
o …….
新浪微博稳定性经验谈
存在不可避免的影响稳定性的因素， 但是又需要保证系统的稳定性，怎么做到？
新浪微博稳定性经验谈
• 构建稳定的系统？
o 少出问题：Design For Failure
o 快速解决
o 清楚系统健康状况趋势
新浪微博稳定性经验谈
• Design For Failure
o 分层隔离（分离核心和非核心接口、服务化等） o SLA保证（资源、服务等各层面保证）
o 流量限制：保正常请求
新浪微博稳定性经验谈
• SLA保证
o 超时控制
o 谨慎重试
o 容量规划 o Failover策略
新浪微博稳定性经验谈
不能保证系统方方面面都能自动Failover， 但是又需要保证系统的稳定性，怎么做到？
新浪拆为门户板块与微博板块,门户板块由杜红负责
前段时间关于杜红将接任曹国伟新浪CEO之职的传言四起。
随着今天曹国伟一封CEO来信发出，该传言被证明至少在相当一段时期内不会为真了。
而这封信也表明，新浪前段时间，的确是在进行紧密集中的高层分工与架构调整。
曹国伟表明，这是“新浪多年来第一次根据战略发展的需要进行的架构重建”。
调整的总体思路是，新浪拆为门户板块与微博板块，门户板块由杜红负责（这可能就是杜红将任新浪CEO传言的由来），微博板块由曹国伟负责，王高飞任总经理。
For personal use only in study and research; not for commercial use可以说，杜红接管了老新浪。
这个动作，可以被看作是新浪加大微博与门户、移动与传统互联网的切分力度，也可以看作是对微博商业化更决绝的尝试。
此前，微博商业化的一个难题就是微博广告客户很大程度是由门户客户迁移过来，这实际上不利于微博广告产品与客户系统的独立进化，对新浪来说，也像是左手倒右手的无谓游戏。
可以想见，经此切分后，明年新浪营销体系会经受不小的调整与重新磨合。
另外一个亮点是，重建后，新浪新设了独立的产品创新部门，负责创新产品项目的孵化，由公司副总裁彭少彬负责。
另外新浪现在才提出明年将“移动优先”的战略，似乎真心晚了点？以下为曹国伟信的全文：各位同事，2012年即将结束，新的财年马上就要开始，感谢大家在过去一年里的辛勤工作，也借此机会跟大家分享一下公司2013年的战略思考和相关业务和组织架构的调整。
在2012年，我们取得了不少成绩，但也有不小的遗憾。
无论是门户还是微博，无论在移动端还是PC端，我们的用户和流量都在进一步增长，而移动端的增长尤为显著。
微博商业化也有了一个良好的开端。
回顾2012年，移动互联网的发展势头异常迅猛，而围绕移动互联网的产品和模式的创新与迭代正在迅速地改变互联网的竞争格局。
我们原来从PC向移动延伸的业务架构以及按职能线划分的组织架构无论在战略布局还是在执行效率上已经很难适应移动时代的市场竞争。
新浪微博股权结构是否合理
这两年，新浪微博红透半边天，“凡有井水处，必歌微博”。
新浪微博火了，其股权当然也是业内人士、媒体、投资者关心的焦点。
最近这两天，新浪微博的股权结构终于浮出水面。
那么，新浪微博的股权结构是否合理、股权难点在哪里？我们在这里简单探讨探讨。
新浪微博股权结构是否合理？在中国互联网行业，这样的股权结构，比较符合行业的规则，也符合新浪微博未来发展的需要。
首先，从整个互联网行业来看，10-20%是业界通行的股权激励手段，搜狐畅游当初将17.7%的股权给予员工，搜狗员工将获得15%的期权，当当给予员工的期权激励在15%，照此来看，新浪的期权激励的比例应该算是通用做法。
其次，从新浪微博的成长来看，如果没有合适的激励手段，新浪可能难以保持微博团队的稳定，难以应对激烈的市场竞争。
目前新浪微博的核心团队，从运营、市场、产品等各个部门的员工，均遭遇到腾讯和搜狐开出目前薪水的数倍来挖角。
即使是新浪微博绩效最差的员工，腾讯与搜狐开出的薪水也毫不迟疑，让新浪员工对自身价值产生疑问。
股权激励从长远来看，对新浪和新浪微博都是能够持续保持竞争力的好事。
毫无疑问，互联网行业竞争太过激烈，必须提供充足的激励手段，以吸引和维持管理和关键人才。
如果微博要打持久战，这都是所必需的。
新浪微博的股权难点在哪里？新浪微博从一开始就依托新浪，通过新浪员工共同努力打造成现在的规模，新浪微博的股权激励必须要衡量多方面的复杂因素，这是新浪微博的股权最大的难点。
因此，新浪管理层最关心的应该是新浪微博的股权激励如何平衡投资者、员工、新浪微博与新浪的关系上。
对于新浪与新浪微博的关系，现有的投资者大可不必担心，新浪持有微博的100%股权，所有微博期权可在微博IPO前行使。
如果微博启动IPO，新浪届时仍将是微博的多数股东。
按照国际上通行的上市之后出售给公众的流通股在20—30%左右的比例，新浪依然持有新浪微博2/3左右的股份，保证了新浪微博的业绩可以合并到新浪上市公司中，有利于保证现有新浪股东的利益。
新浪微博服务治理框架
SID
PSID Annotation
span ID，调用链中的一个节点，从请求开始到请求结束，生成方式同ReqID。
Caller spanID 该调用节点的类别，有API client/API server/RPC Client/RPC Server/其他中间件定 义 接口名称 开始时间和请求时间
Service Name Start/Process Time
服务化框架
监控平台
监控指标UI呈现 报警子系统 流量切换 服务治理平台 服务扩容 服务发布
RPC 数据聚合平台 Motan Registry 上报 资源日志 Push Motan Client
Cache Service … Config Server
上报
接口日志
上报 RPC日志
Push
Client
调用链标准化日志
ReqID SID PSID Annotation Service Name InterfaceNa me Start Time Process time Node IP 16位UUID RPC Node IP
Field ReqID
Description 请求序列号，在调用链入口生成，考虑使用节点IP地址+IDC机房编码+序列号生 成
10.5.2.1 IDC1: Motan Registry IDC2: 10.6.2.1 10.6.2.2 10.6.2.1 10.5.2.1 10.5.2.2 Push Motan Client 切换后数据流 10.5.2.1
10.6.2.1
问题：基于IDC的流量切换策略是否够用？是否需要增加按20/80比例的流量分发策略？
微博平台服务化框架
卫向军
TUP第二期新浪杨卫华：谈微博Cache设计
杨为华：我们就是时间排序，最简单的方法，我们没有找到更好的算法之前。
提问：不是根据一些热点？
杨为华：我们也考虑过那个方向，但是我们认为挑战性非常大，你认为好的方法用户不一定认可，这个挑战很大。你用算法做一些东西，但是用户认为不重要的东西，如果用户没有展示，用户可能也会有其他看法。为什么用复合模式，我们也不知道为什么叫复合模式，我们根据实时运行情况，发现哪里有瓶颈我们会想到更好的方法解决。这个瓶颈，能不能给在线用户加一个什么东西，减少系统压力，不影响原来的价值，主要处于每个性能模块的角度考虑的。
最早我们新浪曾经有一个DB产品，刚开始做通过我们社区介绍，慢慢让大家知道DB在一些方面用起来更适合大家的地方，后来比如说我们去年发展一种分布式的，现在随着社区大家互相介绍，如果有人单独讲一个DB会觉得很不好意思。微博最早我们只能看国外的，慢慢有不少公司做这个，刚开始我们介绍一些基本技术，比如说微博的东西可以用推和拉做，等到以后经过我们把这个话题讲到以后，有人再讲微博技术光讲推和拉觉得不好意思，要进行一些更深入的话题，慢慢我们就在这个过程当中。今天讲一下cache的设计，我讲过一次微薄扩展设计，那是一个基本话题，刚才也讲了一个架构讲得比上次更深刻，光讲一个推是不够的，我今天演讲主要从是cache进一步补充一下，一部分是Feed架构简介，第二是cache的设计。
cache规划方面一些问题，将不同业务，不同长度KEY存储到不同的MEMcache，不同的业务有不同的更高效的内存利用。
mutex，什么情况会出现这个问题，比如说一个很热的内容，cache里面没有了，因为memcache不是很可靠的东西，你放在里面可能会消失，经常出现这样的情况：一个很热的cache没有了，因为我们系统有很多并发很热数据没有了，非常多的并发如果我们没有一个很好的策略，比如说几十个，几百个加一个内容这会是一个悲剧。我们给每个KEY加载MUTEX，这个并发连接取数据库，然后把mutex删除成规，这个时候我只需要一个连接，数据库加载到BD里面有可以了。
微博系统架构的可信性研究
■ ｄ ｉ１ ．９ ９ ． ｓ ６ １ １２ ０ １０ ０ ｏ ： ０３ ６ ￣ｉ ｎ１ ７ ． １ ２２ １ ８０ ７ ｓ
的可信性研究
庆 轩
（ 清华大学 ，北 京 １ ０ ８ ０ ０ ４）
摘 要 ：文章 对微博 系统 架构进行 了介绍 ，提 出了新 产生的 问题 及改善 方案。 关 键 词 ：微 博 系统；改善 方案 ；可信性
第一版微博服务一经推出，受到了中国广大网民的充分 认可，最早 的人人 网、开心网、博客和播客等各种社会 网络与交互方
式都没有受 到国内大众 的广泛参与，而微博这个 新事物 ，以它小巧灵便 、快捷 时尚的身姿挤入了继 Ｑ Ｑ、飞信后，国人参与人数
最多的网络服务。随着用户迅速攀升，原先 的 Ｌ ＭＰ架构已经不堪重负，最初的微 博发放 的推拉模式也受到了挑 战。 Ａ
‘ ＼ ＼
旺三圊 Ｅ三 五 回 臣三
据 ，更 新的策略是 Ｌ Ｕ（ 近最少使用 ） Ｒ 最 ，以及每 个 Ｋ Ｖ对的 有效时限。Ｋ Ｖ对存储有效 时限是在 ｍｅ 由 Ａ ｐ 置并作为 端 ｐ设
参数传给 ｍｓ 的。同时 ｍ 采用是 偷懒替代法，ＨＳ ｓ Ｉ 不会 开额外 的进程 来实时监测过时的 Ｋ Ｖ对并删除 ，而是 当且仅 当，新来
一
图１ ｍｅ ａ ｈ 的 应 用 ｍｃ ｃ ｅ
需要注 意的是，Ｍｅ ａ ｈ ｄ使用内存管理数 据，所 以它 ｍｃ ｃ ｅ
是易失 的，当服务 器重 启，或者 Ｍｅ ａ ｈ ｄ进程 中止 时，数 ｍｃ ｃ ｅ 据便会 丢失，所以 Ｍｅ ａ ｈ ｄ不能用来保存持久数据。有很 ｍｃ ｃ ｅ 多人都 有错 误理解 ，认为 Ｍｅ ａ ｈ ｄ的性 能非常好 ，相 对于 ｍｃ ｃ ｅ
论新浪微博盈利的几点困难
论新浪微博盈利的几点困难对新浪微博而言，赚钱是迫在眉睫的事情，所以，新浪近期推出了一系列变现的举动，这包括昨日推出的“Promoted Feed”类广告系统，即在用户信息流中插入推广信息。
不过，笔者觉得，新浪微博推出的一系列变现项目要想规模盈利，都不太靠谱。
首先，先来盘点下新浪微博在这一年上线的变现项目：1.微任务。
企业授权微任务发布任务，选择微博帐号发布或转发有偿信息。
新浪分成获益。
2.微博服务商平台。
为企业提供官微运营、活动营销、应用定制、数据分析、培训与咨询服务，获取服务费。
3.微博钱包。
有微博账号=微博钱包，类支付宝服务。
新浪可能藉此获得佣金。
4.新版广告系统。
针对中小企业和普通用户的自助式广告系统，在用户信息中插入推广信息。
当然，新浪收的是广告费。
让我们逐条分析上述四种方式中新浪大规模变现的可能性：1.微任务。
不太靠谱。
首先，有多少大号愿意分成给新浪而不偷偷赚钱呢？又有多少企业愿意抛弃低价、直接与大号沟通的渠道，而选择新浪呢？其次，新浪的门户广告销售们转型微博销售，应该也不靠谱吧？另外，虚假营销已经拉低了微博的价值。
知名互联网人管鹏认为，新浪微博错过了一个机会，已让虚假营销把微博价值拉低了，企业的认可度不像以前那么高。
2，微博服务商平台。
这可能是个好的变现方式，但现在处于初期，短期内获益很难。
新浪有愿意要花多大精力去放水养鱼呢？3，微博钱包。
唉，微博O2O和电商都没做起来，靠这个赚大钱是真心不靠谱。
4，最重要的，广告系统，新浪真的缺乏数据精准挖掘的能力。
引用两位专家的话如下。
IT评论人洪波认为，新版广告系统前提在于需要精准的数据挖掘，不构成对用户的骚扰，否则就是三方受损，而新浪一直是一家媒体公司，技术一直是解决媒体发展需要，而不是发觉新的需求。
管鹏则认为，从新版广告系统来看，推送的广告信息有些“简单粗暴”，对用户的兴趣把握不够准确，强推而不是基于搜索或关注的品牌，伤害了用户体验。
总结：新浪的几项变现措施都有短板，短期内规模变现不可能了。