Python CMS创建像youtube这样的视频网站？

Question

是否有人知道用python编写的开源CMS,我可以使用它创建像YouTube这样的网站？

Answer 1

Django是一个很好的Python框架,以及CherryPy和Pylons.但是,框架不是CMS.

开源视频CMS将是:Media Core

以下是有关YouTube如何构建的一些信息:

(来源:谷歌视频)

平台:

1. 阿帕奇
2. 蟒蛇
3. Linux(SuSe)
4. MySQL的
5. psyco,动态python-> C编译器
6. lighttpd用于视频而不是Apache

Web服务器:

1. NetScalar用于负载平衡和缓存静态内容.
2. 使用mod_fast_cgi运行Apache.
3. 请求被路由以供Python应用程序服务器处理.
4. 应用程序服务器与各种数据库和其他信息源进行通信,以获取html页面的所有数据和格式.
5. 通常可以通过添加更多计算机来扩展Web层.
6. Python Web代码通常不是瓶颈,它将大部分时间都用在RPC上.
7. Python允许快速灵活的开发和部署.鉴于他们面临的竞争,这是至关重要的.
8. 通常小于100毫秒的页面服务时间.
9. 使用psyco,一个动态python-> C编译器,它使用JIT编译器方法来优化内部循环.
10. 对于加密等高CPU密集型活动,它们使用C扩展.
11. 一些预先生成的缓存HTML,用于渲染块的昂贵.
12. 数据库中的行级缓存.
13. 完全形成的Python对象被缓存.
14. 计算一些数据并将其发送到每个应用程序,以便将值缓存在本地内存中.这是一个未充分利用的策略.最快的缓存位于您的应用程序服务器中,并且不需要花费太多时间将预先计算的数据发送到您的所有服务器.只需要一个能够监视变化,预先计算和发送的代理.

视频服务:

1. 成本包括带宽,硬件和功耗.

2. 每个视频由一个迷你集群托管.每个视频由多台计算机提供服务.

3. 使用集群意味着:

   • 更多提供内容的磁盘意味着更快的速度.
   • 净空.如果机器出现故障,其他人可以接管.
   • 有在线备份.

4. 服务器使用lighttpd Web服务器进行视频:

   • Apache有太多的开销.
   • 使用epoll等待多个fds.
   • 从单个进程切换到多个进程配置以处理更多连接.

5. 最受欢迎的内容被转移到CDN(内容分发网络):

   • CDN在多个位置复制内容.内容更接近用户的可能性更大,跳数更少,内容将通过更友好的网络运行.
   • CDN机器主要服务于内存不足,因为内容非常受欢迎,因此内容的内容几乎没有内乱.

6. 不太受欢迎的内容(每天1-20次观看)在各种colo网站中使用YouTube服务器.

   • 有一个长尾效应.视频可能有几个播放,但正在播放大量视频.正在访问随机磁盘块.
   • 在这种情况下,缓存并没有很多好处,因此在更多缓存上花钱可能没有意义.这是一个非常有趣的观点.如果你有长尾产品缓存并不总是你的性能救星.
   • 调整RAID控制器并注意其他较低级别的问题以提供帮助.
   • 在每台机器上调整内存,这样就不会太多而且不会太少.

服务视频要点:

1. 保持简单和便宜.
2. 保持简单的网络路径.内容和用户之间没有太多设备.路由器,交换机和其他设备可能无法跟上这么多负载.
3. 使用商品硬件.更昂贵的硬件得到的其他东西也越贵(支持合同).您也不太可能在网上寻求帮助.
4. 使用简单的常用工具.他们使用大多数工具构建到Linux和层之上.
5. 处理随机搜索(SATA,调整).

服务缩略图:

1. 令人惊讶地难以有效地完成.
2. 每个视频都有4个缩略图,因此缩略图比视频多得多.
3. 缩略图只托管在几台机器上.
4. 看到与提供大量小物件相关的问题:
   • 大量磁盘在操作系统级别寻找inode缓存和页面缓存的问题.
   • 进入每个目录文件限制.特别是Ext3.移动到更加层次结构.2.6内核的最新改进可能会将Ext3大目录处理提高100倍,但在文件系统中存储大量文件仍然不是一个好主意.
   • 大量的请求/秒,因为网页可以在页面上显示60个缩略图.
   • 在如此高的负载下,Apache表现糟糕.
   • 在Apache面前使用squid(反向代理).这工作了一段时间,但随着负载增加,性能最终下降.从300请求/秒到20.
   • 尝试使用lighttpd,但单螺纹停止.遇到多进程模式的问题,因为它们每个都会保留一个单独的缓存.
   • 有这么多图像设置一台新机器需要24小时.
   • 重启机器需要6-10个小时才能使缓存升温到不进入磁盘.
5. 为了解决他们的所有问题,他们开始使用Google的BigTable,一个分布式数据存储:
   • 避免小文件问题,因为它会将文件聚集在一起.
   • 快速,容错.假设它在一个不可靠的网络上工作.
   • 降低延迟,因为它使用分布式多级缓存.此缓存适用于不同的并置站点.

数据库:

1. 早年
   • 使用MySQL存储用户,标签和描述等元数据.
   • 从具有10个磁盘的单片RAID 10卷中提供数据.
   • 靠信用卡住,所以他们租用了硬件.当他们需要更多硬件来处理负载时,需要几天的时间来订购并交付.
   • 他们经历了一个共同的演变:单个服务器,转到具有多个读取从属的单个主服务器,然后对数据库进行分区,然后采用分片方法.
   • 遭受复制滞后.主机是多线程的,可以在大型机器上运行,因此可以处理大量工作.从属是单线程的,通常在较小的机器上运行,并且复制是异步的,因此从属设备可能明显落后于主设备.
   • 更新会导致缓存未命中,这会导致缓慢I/O导致缓慢复制的磁盘.
   • 使用复制架构,您需要花费大量资金来提高写入性能.
   • 他们的解决方案之一是通过将数据分成两个集群来确定流量的优先级:视频观察池和一般集群.这个想法是人们想要观看视频,以便功能应该获得最多的资源.YouTube的社交网络功能不太重要,因此可以将它们路由到功能较弱的群集.
2. 晚年:
   • 去了数据库分区.
   • 拆分为分片,用户分配到不同的分片.
   • 传播写入和读取.
   • 更好的缓存局部性意味着更少的IO.
   • 导致硬件减少30%.
   • 副本延迟减少到0.
   • 现在几乎可以任意扩展数据库.

数据中心战略

1. 首先使用管理托管服务提供商.靠信用卡住,所以这是唯一的方法.
2. 托管主机无法与您扩展.您无法控制硬件或制定有利的网络协议.
3. 所以他们去了一个主机托管安排.现在他们可以自定义所有内容并协商自己的合同.
4. 使用5或6个数据中心加上CDN.
5. 视频来自任何数据中心.最近的匹配或任何东西.如果视频足够流行,它将进入CDN.
6. 视频带宽依赖,而不是真正的延迟依赖.可以来自任何颜色.
7. 对于图像延迟很重要,尤其是当您在页面上有60张图像时.
8. 使用BigTable将图像复制到不同的数据中心.代码查看不同的指标,以了解谁最接近.

Answer 2

尽管Django不是 CMS，但它可能非常有用。