Pinterest架构：两年内月PV从零到百亿 - 博客 - 伯乐在线
& Pinterest架构：两年内月PV从零到百亿
& 3.5K 阅读
英文原文： 编译:
Pinterest正经历了指数级曲线般的增长，每隔一个半月就翻番。在这两年里，Pinterest，从 每月PV量0增长到100亿，从两名c创始人和一个工程师成长为四十个工程师，从一台MySQL 服务器增长到180台Web 服务器(Web Engine)，240台接口服务器(API Engine), 88台MySQL 数据库 (cc2.8xlarge) ，并且每台DB有一个备份服务器，110台Redis 实例服务（Redis Instance），200台 Memcache 实例服务（Memcache
Instance）。
令人叹为观止的增长。想一探Pinterest的传奇吗？我们请来了Pinterest的两位创始人 和 ，他们将以 为题讲述关于Pinterest架构的充满戏剧化的传奇故事。他们说如果能在一年半前飞速发展时能看到有人做类似题材的演讲的话，他们就会有更多的选择，以避免自己在这一年半里做出的很多错误的决定。
这是一个很不错的演讲，充满了令人惊讶的细节。同时这个演讲也是很务实的，归根结底，它带来了可让大家选择的策略。极度推荐！
这篇演讲中有两个我最为看重的经验：
1.强大的架构在处理增长时通过简单增加相同的东西(服务器)来应对，同时还能保证系统的正确性。当遇到某种（性能）问题时，你想通过砸钱来扩容指的是你可以简单增加服务器(boxes)。如果你的架构能够做到这一点，那它就如金子一般强大而珍贵！
2. 当某些（性能问题）快到极限时大多数技术都会以他们自己的方式失败。这导致他们在审核工具时要考虑以下一些特性：成熟，好且简单，有名气且用的人多，良好的支持，持续的优异性能，很少失败，开源。按照这样的标准，他们选择了：MySQL, Solr, Memcache, and Redis，放弃了Cassandra ，Mongo。
这两点经验是相互联系的。遵循（2）中提到的标准的工具可以在扩容时简单增加服务器(boxes).当负载增加了，成熟的产品更少会有问题。当你遇到问题时，你至少希望它的社区团队能够帮助解决。当你使用的工具过于技巧化和过于讲究时，你会发现你遇到一堵无法逾越的墙。
在这段演讲里，碎片化（sharding）优于集群(clusterting)的观点是我认为最好的一部分。为了应对增长，通过增加资源，更少失败的模式，成熟，简单，良好的支持，最终圆满完成。请注意他们选择的工具以sharding的方式增长，而不是clustering。关于他们为什么选择sharding和他们如何做sharding是很有趣的事，这很可能触及到你以前未考虑过的场景。
现在，让我们看看Pinterest如何扩容：
Pins是一幅关于其他信息的集合的图片，描述了为什么它对于用户来说很重要，可以链回到他们发现它的地方。
Pinterest是一个社交网络。你可以追踪人或者板报(boards).
Database:它包含了拥有pins的板报（boards）和拥有板报（boards）的人 ，可以追踪或重新建立（repin）联系，还包含认证信息。
启动于2010年三月–自我发现时期
此时此刻，你甚至不知道你在做的这个产品将要做什么。你有想法，迭代开发更新产品的频率很高。最终因遇到一些在现实生活中永远不会遇到的奇怪的简短的MySQL查询而结束。
早期的一些数字：
两个创始人
一个工程师
Rackspace托管服务器
一个小型web引擎
一个小型MySQL数据库
扔在潜伏前进中，产品得到了一些用户反馈。以下是数据：
Amazon EC2 + S3 + CloudFront云服务
一台NGinX，4台Web 引擎（作冗余用，不是真正为了负载）
一台MySQL数据库+一台读备份服务器（防止主服务器宕机）
一个任务队列+两个任务处理
一台MongoDB（为了计数）
两个工程师
至2011年9月–试运行阶段
每一个半月翻翻的疯狂增长阶段。
当高速发展时每个晚上每个星期都会有技术失败的情况发生
这时，你阅读大量白皮书，它会告诉你把这个增加进来就行了。当他们添加了大量技术时，毫无例外都失败了。
最终你得到一个极为复杂的架构图：
Amazon EC2 + S3 + CloudFront
2NGinX, 16 Web Engines + 2 API Engines
5 Functionally Sharged MySQL DB + 9 读备份
4 Cassandra 节点
15 Membase 节点(分成三个单独的集群)
8 Memcache 节点
10 Redis 节点
3 任务路由（Task Routers）+ 4 Task Processors
4 ElasticSearch 节点
3 Mongo集群
5种主要的数据库技术只为了应付他们自己的数据
增长极快以至MySQL负载很高，而其他一些技术都快到达极限
当你把某些技术的应用推至极限时，他们又以自己的方式宣告失败。
放弃一些技术并问它们到底能做什么。对每一件事情重新构架，海量工作量。
架构成熟 2012 1月
重新设计的系统架构如下：
Amazon EC2 + S3 + Akamai, ELB
90 Web Engines + 50 API Engines
66 MySQL DBs (m1.xlarge) + 1 slave each
59 Redis Instances
51 Memcache Instances
1 Redis Task Manager + 25 Task Processors
Sharded Solr
6 Engineers .使用Mysql，Redis，Memcache Solr，他们的优势是简单高效并且是成熟的技术。 随着Web流量增加，Iphone的流量也随之开始越来越大。
稳定期 2012 10月 12 仅仅在一月份以后，大概就有4倍的流量增长。 系统架构数据如下： The numbers now looks like:
Amazon EC2 + S3 + Edge Cast,Akamai, Level 3
180 Web Engines + 240 API Engines
88 MySQL DBs (cc2.8xlarge) + 1 slave each
110 Redis Instances
200 Memcache Instances
4 Redis Task Manager + 80 Task Processors
Sharded Solr
40 Engineers (and growing)
注意到，此时的架构应该是合理的，只是通过增加更多的服务器。你认为此时通过更多的投入来应对这么大的规模的流量，投入更多的硬件来解决这个问题， 下一步 迁移到SSDs
为什么是Amazon EC2/S3
相当的可靠。数据中心也会宕机， Multitenancy 加入了不少风险，但不是坏处。
良好的汇报和支持。他们确实有很不错的架构师而且他们知道问题在哪里。
良好的额外服务支持（peripherals），特别是当你的应用处于增长时期。你可能在App Engine中转晕，你不用亲自去实现，只需要简单和他们的服务打交道，例如maged cache，负载均衡，映射和化简，数据库和其他所有方面。Amazon的服务特别适合起步阶段，之后你可以招聘工程师来优化程序。
分秒钟获得新的服务实例。这是云服务的威力。特别是当你只有两名工程师，你不用担心容量规划或者为了10台memcache服务器等上两周。10台memcache服务器几分钟内就能加完。
反对的理由：有限的选择。直到最近你才能用SSD而且还没高内存配置的方案。
赞成的理由：还是有限的选择。你不需要面对一大堆配置迥异的服务器。
为什么是 MySQL？
非常耐用。从不宕机且不会丢失数据。
招聘方便，一大堆工程师懂MySQL.
反应时间和请求数量（requies rate，我认为是request rate参考下面）是线性增长的。有些数据库技术的反应时间在请求飙升时不是很好。
很好的软件支持– XtraBackup, Innotop, Maatkit
很好的社区，问的问题总能轻易获取到答案
很好的厂商支持，譬如Percona
开源–这一点很重要，特别是你刚开始没有很多资金支持时。
为什么选择Memcache?
非常简单。它就是一个socket的哈希表。
性能一直很好
很多人知道并喜欢
为什么选择Redis?
还不成熟，但它是非常好并且相当简单。
提供了各种的数据结构。
可以持久化和复制，并且可以选择如何实现它们。你可以用MySQL风格持久化，或者你可以不要持久化，或者你只要3小时的持久化。
Redis上的数据只保存3个小时，没有3小时以上的复本。他们只保留3个小时的备份。
如果存储数据的设备发生故障，而它们只是备份了几个小时。这不是完全可靠的，但它很简单。你并不需要复杂的持久化和复制。这是一个更简单，更便宜的架构。
很多人知道并喜欢
性能一直很好
很少的一些故障。你需要了解一些小故障，学习并解决它们，使它越来越成熟。
只需要几分钟的安装时间，就可以投入使用
不能扩展到多于一台的机器上（最新版本并非如此）
尝试弹性搜索，但是以Pinterest的规模来说，可能会因为零碎文件和查询太多而产生问题。
选择使用Websolr，但是Pinterest拥有搜索团队，将来可能会开发自己的版本。
集群vs.分片
在迅速扩展的过程中，Pinterest认识到每次负载的增加，都需要均匀的传播他们的数据。
针对问题先确定解决方案的范围，他们选择的范围是集群和分片之间的一系列解决方案。
集群 —— 所有事情都是自动化的
示例: Cassandra, MemBase, HBase
结论: 太可怕了，不是在现在，可能在将来，但现在太复杂了，有非常多的故障点
自动化数据分布
可移动数据
可重新进行分布均衡
节点间可通讯，大量的握手、对话
自动伸缩数据存储，至少白皮书上是这么说的
在空间中分布存储你的数据，可在不同区域有数据中心
没有单点故障
缺点 (来自用户一手的体验):
还是相当年轻不成熟
还是太复杂，一大堆节点必须对称的协议,这是一个在生产环境中难以解决的问题。
很少的社区支持，有一个沿着不同产品线的分裂社区会减少每个阵营的支持。
很少工程师有相关的知识，可能是很多工程师都没用过 Cassandra.
复杂和和可怕的升级机制
集群管理算法是一个 SPOF 单点故障，如果有个 bug 影响每个节点，这可能会宕机 4 次。
集群管理器编码复杂，有如下一些失败的模式：
数据重新均衡中断：当一个新机器加入然后数据开始复制,它被卡住了。你做什么工作?没有工具来找出到底发生了什么。没有社会的帮助,所以他们被困。他们又回到了MySQL。
所有节点的数据损坏. What if there’s a bug that sprays badness into the write log across all of them and compaction or some other mechanism stops? Your read latencies increase. All your data is screwed and the data is gone.
均衡不当而且很难修复. 非常常见，如果你有10个节点，你会注意到所有节点都在一个节点上，有一个手工处理方式，但会将所有负载分布到一个单节点上
权威数据失效. 集群方案是很智能的。In one case they bring in a new secondary. At about 80% the secondary says it’s primary and the primary goes to secondary and you’ve lost 20% of the data. Losing 20% of the data is worse than losing all of it because you don’t know what you’ve lost.
分片(sharding) – 全凭人手
裁决: 分片是赢家。我觉得他们分片的方案与非常相似。
如果去掉集群方式下所有不好的特点，就得到了分片。
人工对数据进行分布。
不移动数据。
通过切分数据来分担负荷。
节点不知道其它节点的存在。某些主节点控制一切。
可以通过切分数据库来扩大容量。
在空间上分布数据。
负载均衡。
放置数据的算法十分简单。这是最主要的原因。虽然存在单点(SPOF)，但只是很小的一段代码，而不是复杂到爆的集群管理器。过了第一天就知道有没有问题。
ID的生成很简单。
无法执行大多数连接。
没有事务功能。可能会出现写入某个数据库失败、而写入其它库成功的情况。
许多约束只能转移到应用层实现。
schema的修改需要更多的规划。
如果要出报表，必须在所有分片上分别执行查询，然后自己把结果合起来。
连接只能转移到应用层实现。
应用必须应付以上所有的问题。
何时选择分片？
当有几TB的数据时，应该尽快分片。
当Pin表行数达到几十亿，索引超出内存容量，被交换到磁盘时。
他们选出一个最大的表，放入单独的数据库。
单个数据库耗尽了空间。
然后，只能分片。
分片的过渡
过渡从一个特性的冻结开始。
确认分片该达到什么样的效果——希望尽少的执行查询以及最少数量的数据库去呈现一个页面。
剔除所有的MySQL join，将要做join的表格加载到一个单独的分片去做查询。
添加大量的缓存，基本上每个查询都需要被缓存。
这个步骤看起来像：
1 DB + Foreign Keys + Joins
1 DB + Denormalized + Cache
1 DB + Read Slaves + Cache
Several functionally sharded DBs+Read Slaves+Cache
ID sharded DBs + Backup slaves + cache
早期的只读奴节点一直都存在问题，因为存在slave lag。读任务分配给了奴节点，然而主节点并没有做任何的备份记录，这样就像一条记录丢失。之后Pinterest使用缓存解决了这个问题。
Pinterest拥有后台脚本，数据库使用它来做备份。检查完整性约束、引用。
用户表并不进行分片。Pinterest只是使用了一个大型的数据库，并在电子邮件和用户名上做了相关的一致性约束。如果插入重复用户，会返回失败。然后他们对分片的数据库做大量的写操作。
如何进行分片?
可以参考Cassandra的ring模型、Membase以及Twitter的Gizzard。
坚信：节点间数据传输的越少，你的架构越稳定。
Cassandra存在数据平衡和所有权问题，因为节点们不知道哪个节点保存了另一部分数据。Pinterest认为应用程序需要决定数据该分配到哪个节点，那么将永远不会存在问题。
预计5年内的增长，并且对其进行预分片思考。
初期可以建立一些虚拟分片。8个物理服务器，每个512DB。所有的数据库都装满表格。
为了高有效性，他们一直都运行着多主节点冗余模式。每个主节点都会分配给一个不同的可用性区域。在故障时，该主节点上的任务会分配给其它的主节点，并且重新部署一个主节点用以代替。
当数据库上的负载加重时：
先着眼节点的任务交付速度，可以清楚是否有问题发生，比如：新特性，缓存等带来的问题。
如果属于单纯的负载增加，Pinterest会分割数据库，并告诉应用程序该在何处寻找新的节点。
在分割数据库之前，Pinterest会给这些主节点加入一些奴节点。然后置换应用程序代码以匹配新的数据库，在过渡的几分钟之内，数据会同时写入到新旧节点，过渡结束后将切断节点之间的通道。
分片ID：16位
Type：10位—— Board、User或者其它对象类型
本地ID——余下的位数用于表中ID，使用MySQL自动递增。
Twitter使用一个映射表来为物理主机映射ID，这将需要备份；鉴于Pinterest使用AWS和MySQL查询，这个过程大约需要3毫秒。Pinterest并没有让这个额外的中间层参与工作，而是将位置信息构建在ID里。
用户被随机分配在分片中间。
每个用户的所有数据（pin、board等）都存放在同一个分片中，这将带来巨大的好处，避免了跨分片的查询可以显著的增加查询速度。
每个board都与用户并列，这样board可以通过一个数据库处理。
分片ID足够65536个分片使用，但是开始Pinterest只使用了4096个，这允许他们轻易的进行横向扩展。一旦用户数据库被填满，他们只需要增加额外的分片，然后让新用户写入新的分片就可以了。
如果存在50个查找，举个例子，他们将ID分割且并行的运行查询，那么延时将达到最高。
每个应用程序都有一个配置文件，它将给物理主机映射一个分片范围。
“sharddb001a”: : (1, 512)
“sharddb001b”: : (513, 1024)——主要备份主节点
如果你想查找一个ID坐落在sharddb003a上的用户：
将ID进行分解
在分片映射中执行查找
连接分片，在数据库中搜寻类型。并使用本地ID去寻找这个用户，然后返回序列化数据。
对象和映射
所有数据都是对象（pin、board、user、comment）或者映射（用户由baord，pin有like）。
针对对象，每个本地ID都映射成MySQL Blob。开始时Blob使用的是JSON格式，之后会给转换成序列化的Thrift。
对于映射来说，这里有一个映射表。你可以为用户读取board，ID包含了是时间戳，这样就可以体现事件的顺序。
同样还存在反向映射，多表对多表，用于查询有哪些用户喜欢某个pin这样的操作。
模式的命名方案是：noun_verb_noun: user_likes_pins, pins_like_user。
只能使用主键或者是索引查找（没有join）。
数据不会向集群中那样跨数据的移动，举个例子：如果某个用户坐落在20分片上，所有他数据都会并列存储，永远不会移动。64位ID包含了分片ID，所以它不可能被移动。你可以移动物理数据到另一个数据库，但是它仍然与相同分片关联。
所有的表都存放在分片上，没有特殊的分片，当然用于检测用户名冲突的巨型表除外。
不需要改变模式，一个新的索引需要一个新的表。
因为键对应的值是blob，所以你不需要破坏模式就可以添加字段。因为blob有不同的版本，所以应用程序将检测它的版本号并且将新记录转换成相应的格式，然后写入。所有的数据不需要立刻的做格式改变，可以在读的时候进行更新。
巨大的胜利，因为改变表格需要在上面加几个小时甚至是几天的锁。如果你需要一个新的索引，你只需要建立一张新的表格，并填入内容；在不需要的时候，丢弃就好。
呈现一个用户文件界面
从URL中取得用户名，然后到单独的巨型数据库中查询用户的ID。
获取用户ID，并进行拆分
选择分片，并进入
SELECT body from users WHERE id = &local_user_id&
SELECT board_id FROM user_has_boards WHERE user_id=&user_id&
SELECT body FROM boards WHERE id IN (&boards_ids&)
SELECT pin_id FROM board_has_pins WHERE board_id=&board_id&
SELECT body FROM pins WHERE id IN (pin_ids)
所有调用都在缓存中进行（Memcache或者Redis），所以在实践中并没有太多连接数据库的后端操作。
当你过渡到一个分片架构，你拥有两个不同的基础设施——没有进行分片的旧系统和进行分片的新系统。脚本成为了新旧系统之间数据传输的桥梁。
移动5亿的pin、16亿的follower行等。
不要轻视项目中的这一部分，Pinterest原认为只需要2个月就可以完成数据的安置，然而他们足足花了4至5个月时间，别忘了期间他们还冻结了一项特性。
应用程序必须同时对两个系统插入数据。
一旦确认所有的数据都在新系统中就位，就可以适当的增加负载来测试新后端。
建立一个脚本农场，雇佣更多的工程师去加速任务的完成。让他们做这些表格的转移工作。
设计一个Pyres副本，一个到GitHub Resque队列的Python的接口，这个队列建立在Redis之上。支持优先级和重试，使用Pyres取代Celery和RabbitMQ更是让他们受益良多。
处理中会产生大量的错误，用户可能会发现类似丢失board的错误；必须重复的运行任务，以保证在数据的处理过程中不会出现暂时性的错误。
最初试图给开发者一个分片系统。每个开发者都能拥有自己的MySQL服务器，但事情发生了快速的变化，导致不能工作。变
去了Facebook的模式：每个人可以获得一切。所以，你不得不非常谨慎
未来发展方向
基于服务的架构。
当他们开始看到了很多的数据库负载，便像产卵一样，导致了很多的应用服务器和其他服务器堆在一起。所有这些服务器连接到MySQL和Memcache。这意味着有30K上的memcache连接了一对夫妇演出的RAM引起的memcache守护进程交换。
作为一个修补程序，这些都是移动的服务架构。有一个跟随服务，例如，将只回答跟随查询。此隔离的机器数目至30访问数据库和高速缓存，从而减少了连接。
帮助隔离功能。帮助组织，解决和支持这些服务的团队。帮助开发人员，为了安全开发人员不能访问其他服务。
学到的知识
为了应对未来的问题，让其保持简单。
让其变的有趣。只要应用程序还在使用，就会有很多的工程师加入，过于复杂的系统将会让工作失去乐趣。让架构保持简单就是大的胜利，新的工程师从入职的第一周起就可以对项目有所贡献。
当你把事物用至极限时，这些技术都会以各自不同的方式发生故障。
如果你的架构应对增长所带来的问题时，只需要简单的投入更多的主机，那么你的架构含金量十足。
集群管理算法本身就用于处理SPOF，如果存在漏洞的话可能就会影响到每个节点。
为了快速的增长，你需要为每次负载增加的数据进行均匀分配。
在节点间传输的数据越少，你的架构越稳定。这也是他们弃集群而选择分片的原因
一个面向服务的架构规则。拆分功能，可以帮助减少连接、组织团队、组织支持以及提升安全性。
搞明白自己究竟需要什么。为了匹配愿景，不要怕丢弃某些技术，甚至是整个系统的重构。
不要害怕丢失一点数据。将用户数据放入内存，定期的进行持久化。失去的只是几个小时的数据，但是换来的却是更简单、更强健的系统！
没怎么阐述为什么Mongo被弃用了
为作者带来更多读者；为读者筛选优质内容；专注IT互联网。
最新评论（期待您也参与评论）
汇集优质的Python技术文章和资源。人生苦短，我用Python！
JavaScript, CSS, HTML5 这里有前端的技术干货！
关注安卓移动开发业界动态，分享技术文章和优秀工具资源。
关注iOS移动开发业界动态，分享技术文章和优秀工具资源。
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线博客团队正试图以我们微薄的力量，把优秀的原创/译文分享给读者，做一个小而精的精选博客，为“快餐”添加一些“营养”元素。
欢迎关注更多频道
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选博客文章
– JavaScript, HTML5, CSS
– 专注Android技术分享
– 专注iOS技术分享
– 专注Java技术分享
– 专注Python技术分享
（加好友请注明来意）
网站使用问题
请在询问或者反馈
& 2015 伯乐在线
赞助云主机为什么太阳的寿命约是100亿年?_百度知道
为什么太阳的寿命约是100亿年?
在过去50亿年的漫长时间里，太阳因核聚变损耗的质量是它本身质量的0.03%。那即使再过50年也还只耗了0.06%,还有足够的氢来进行核聚变那为什么说太阳的寿命只约100亿年,是什么原因让太阳&寿终正寝&不再发光发热了呢?
就是一个科学依据而已。
其他类似问题
为您推荐：
其他2条回答
据恒星演化学说，恒星内部一旦进行热核反应，就进入了相对稳定时期。而且质量大的演化快，稳定期短；质量小的演化慢，稳定期长。太阳的质量大约是2000亿亿亿吨，所以它的稳定期为100亿年。科学家们推算，太阳目前正于它的“中年”50亿岁，也就是说太阳还能再活50亿岁
这个问题这么深奥，可以建议去图书城翻翻看，很全额
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁套现100亿借给乐视网 贾跃亭为什么这么做 _ 财经频道 _ 东方财富网()
||||||||||||||||||||||
套现100亿借给乐视网 贾跃亭为什么这么做
公司实际控制人、董事长贾跃亭宣布将在6个月内减持不超过8%的公司股份，所得将作为借款用于公司日常经营。
　　随着股价的大反转和利好消息的不断发布，随之将2014年的计划“推倒重来”--宣布撤回去年45亿再融资方案，转而将募资额增加至最新的75亿元。与此同时，公司实际控制人、董事长贾跃亭宣布将在6个月内减持不超过8%的公司股份，所得将作为借款用于公司日常经营。
　　据虎嗅网的报道，昨晚(5月25日)，乐视网宣布，贾跃亭要在未来6个月里，减持1.48亿股，外界普遍预计能套现近100亿！
　　这100亿，贾跃亭要全部借给乐视网，用于公司日常经营，借款期限不低于5年，免收利息。100亿，借5年，按照每年5%的利息算，能帮乐视省25亿利息，如果按10%的利息算，就帮乐视网省了50亿财务成本。
　　在此之外，乐视网还宣布了75亿元的再融资计划。
　　“75亿+100亿”，又一个“视频新土豪”诞生了。
　　在视频江湖，优酷土豆、爱奇艺分别有“干爹”阿里和百度，腾讯视频有“亲爹”腾讯。
　　昨晚的乐视网，在A股的泡沫里仰天长啸：“我就是豪门！”
　　贾跃亭为什么这么有钱？因为牛市。今天，乐视网市值已超过1400亿元，贾跃亭持有约45%的股权，价值630亿，这一次他准备减持乐视网总股本的8%，这就有望套现100亿。
　　小娱终于明白了敬爱的李总理推高资本市场的良苦用心，乐视网那白花花的银子，就是来自你，来自我，来自我们这些炒股的“小散”啊！
　　如果这一切能顺利实施，无疑将对整个视频行业，乃至内容产业带来巨大影响。
　　1、长期以来，乐视网在影视圈内口碑不佳，一个重要原因，就是经常欠款，甚至员工工资也偶尔拖欠一下下。当乐视网成为“视频新土豪”，大家该讨债的讨债，该抱大腿的赶紧抱了啊。
　　2、乐视提出2年内要花掉44亿采购内容版权，如此大手笔的内容投入，已经不输给爱奇艺和优酷土豆，乐视还宣布2年内新增350人的专业营销队伍，这也是一线视频巨头的“做派”。
　　如果这件事能做成，乐视几乎一举解决了困扰多年的资金难题，一向不愿意预测股价的小娱这一次要勇敢说一句――
　　根据我们的长期观察，乐视网这家进击的巨头，什么都好，就是缺钱，如果钱的问题能解决，乐视网的未来无可限量。
　　175亿+100亿，“视频新土豪”诞生，未来“买买买”？
　　我们先来看一下，乐视网那75亿元的融资要怎么花。
　　乐视公告是这样写的，75亿元当中，44亿元都要投入到内容上，并且2年内就要花完。
　　第一年：花25亿(6亿买电影+12亿买电视剧+4亿买综艺+1亿其他+2亿自制节目)
　　第二年：花19亿(5亿买电影+8.5亿买电视剧+3.5亿买综艺+1亿其他+1亿自制节目).
　　对比一下，百度2015Q1的内容成本为人民币6.084亿元(基本就是爱奇艺花掉的)，优酷土豆2015Q1为人民币6.69亿元。
　　如果乐视网真的一年要投25亿在内容上，这样的内容投入力度，几乎就是在对标爱奇艺和优酷土豆。
　　更何况，在这75亿之外，贾跃亭减持股票也将获得近100亿的资金，这意味着，在内容上的投入，乐视网只会更多不会更少。
　　在内容端的44亿投入之外，乐视还将在：
　　1、技术端：投入9.91亿元，建设及优化乐视媒资管理系统、开发建设精准广告投放管理系统；
　　2、营销端：投入5.18亿元，两年内新增350人左右的专业营销队伍，并且将投入资金对优质产品和未来的“颠覆性产品”进行宣传；
　　3、财务端：6亿元偿还贷款，10亿元补充流动资金――这笔钱可能用于投资和行业整合。
　　老定增方案受阻，谁料牛市来解围
　　其实，乐视网的定增已经“喊”了大半年。
　　早在去年8月，乐视网就曾抛出一份45亿元的融资计划，准备定向增发新股的方式融资45亿元。这份命途多舛的定增方案，经过了整整9个多月，仍未被证监会批准。
　　这段时间内，乐视网经历了一次巨大的风波――贾跃亭滞留境外，几个月后，归来。
　　但老贾的归来，并未使得这次45亿元的融资方案更快启动，就在贾跃亭回归后不久，证监会原副主任李量被查，有媒体分析称，李量可能涉及令完成案，可能与当年帮助乐视网上市有关。
　　正是在这样的背景之下，乐视网的融资计划“卡”在了证监会，一拖再拖，一直拖到了现在。
　　估计连贾跃亭都想不到的是，就在这段时间内，牛市来了。
　　去年8月的定增方案中，乐视网与各认购方约定，认购方将以34元左右的价格购买乐视网的股票，而到今年5月，乐视网股价最高已经达到179元。
　　股价的飙涨，意味着乐视网无论再也不可能同意之前的融资方案了――如果当初那份方案还继续实施，那几乎是贾跃亭把自己的钱白白地送给参与定增的投资者。
　　于是，今晚乐视网先是宣布撤销此前45亿元的融资方案，接着宣布了新的融资方案――融资75亿元。
　　根据“新计划”，投资者购买乐视网股票的价格将在70元左右，这意味着，乐视网释放出同样多的股权，能融到之前2倍的资金！
　　让人担心的是，这份“新计划”，是否会遭遇之前那份45亿定增方案一样的命运，被“卡”在证监会？这几乎是乐视网最大的不确定性。
　　定增募资增至75亿
　　另据每日经济新闻的报道，乐视网公告显示，公司拟向不超过5名特定对象，非公开发行不超过2亿股，募集资金总额不超过75.09亿元；定增价格为37.5元/股，较市价折价50%。根据定增方案，公司此次募投项目及投资金额分别为：视频内容资源库建设项目(44亿元)；平台应用技术研发项目(9.91亿元)；品牌营销体系建设项目(5.18亿元)；偿还银行借款(6亿元)；补充流动资金(10亿元).
　　值得注意的是，乐视网撤回了公司于2014年8月发布的非公开发行方案，当时公司拟向乐视控股、、蓝巨投资、宁波久元和金泰众和非公开发行1.29亿股，发行价格为34.76元/股，募集资金总额不超过45亿元，扣除发行费用后全部用于补充流动性。在此期间，乐视网经历一次10转12分红扩股，目前股价高达76.04元，市值超过了1400亿元。
　　减持计划引发创业板地震？
　　与定增方案相比，更让人瞠目结舌的，是公司实控人贾跃亭抛出的一份百亿元的减持计划。
　　公告显示，未来6个月(5月29日~11月28日)，贾跃亭将根据上市公司资金需求进行减持，预计减持其个人直接持有股份不超过1.48亿股，即不超过公司股份总数的约8%。按昨日收盘价76.34元计算，贾跃亭套现金额将达到112亿元。
　　对于此次减持的目的，乐视网表示控股股东贾跃亭为了缓解公司资金压力，满足公司日常经营资金需求，拟计划在未来6个月内，部分减持自己所持有的乐视网股票，将其所得全部借给公司作为营运资金使用，借款将用于公司日常经营，公司可在规定期限内根据流动资金需要提取使用，借款期限将不低于60个月，免收利息。《每日经济新闻》记者注意到，目前乐视网的股价为76.04元/股，如果以顶格减持1.48亿股计算，其套现的股票市值约为113亿元。
　　百亿元的减持，在A股市场实属罕见。目前创业板在一片质疑声中仍然连创新高，超过100的平均市盈率在更是让不少投资者担忧其泡沫巨大。此前1月份，中信集团减持114亿元，宣告蓝筹行情告一段落。那么，此次作为创业板“精神领袖”的乐视网，其实控人抛出百亿元的减持计划，会是创业板见顶的信号吗？会不会带动其他公司股东巨量减持呢？
　　对此，著名经济学家宋清辉认为，贾跃亭的百亿元减持计划，肯定会对未来创业板走势产生影响，股东巨量的减持已经成为了创业板强势背后的一大隐忧。目前，创业板受股东减持和估值透支、监管趋严等因素的影响，未来数周内指数可能会出现比较大的波动。套现金额超过百亿元，对创业板单个公司中来说属于猛烈性质的减持，短期内肯定会对创业板的行情会产生一波影响，有可能成为本轮创业板行情的一个标志性时点。
(责任编辑：DF127)
东方财富网(&&或&&)
建议及投诉热线：021-　值班热线：021-5
东方财富产品下载专区
网友点击排行
&&&&&|&&&&|&&&&&&
近日，上市公司密集披露证金、汇金持股情况[]
郑重声明：东方财富网发布此信息目的在于传播更多信息，与本网站立场无关。东方财富网不保证该信息（包括但不限于文字、数据及图表）全部或者部分内容的准确性、真实性、完整性、有效性、及时性、原创性等。相关信息并未经过本网站证实，不对您构成任何投资建议，据此操作，风险自担。