5

有人知道用 python 编写的开源 CMS，我可以使用它来制作像 YouTube 这样的网站吗？

4

6 回答 6

19

Django是一个很好的 Python 框架，还有CherryPy和Pylons。但是，框架不是 CMS。

开源视频 CMS 将是：Media Core

以下是有关 YouTube 构建方式的一些信息：

（来源：谷歌视频）

平台：

  1. 阿帕奇
  2. Python
  3. Linux (苏塞)
  4. MySQL
  5. psyco，一个动态的 python->C 编译器
  6. 用于视频而不是 Apache 的 lighttpd

网络服务器：

  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. 使用 aa 集群意味着：

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

  4. 服务器使用 lighttpd 网络服务器进行视频：

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

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

数据中心战略

  1. 最初使用管理托管服务提供商。靠信用卡过活，所以这是唯一的办法。
  2. 托管主机无法随您扩展。您无法控制硬件或制定有利的网络协议。
  3. 所以他们去了一个托管安排。现在他们可以定制一切并协商自己的合同。
  4. 使用 5 或 6 个数据中心以及 CDN。
  5. 视频来自任何数据中心。不是最接近的比赛或任何东西。如果视频足够受欢迎，它将进入 CDN。
  6. 视频带宽依赖，而不是真正的延迟依赖。可以来自任何科罗拉多州。
  7. 对于图像延迟很重要，尤其是当您在页面上有 60 个图像时。
  8. 使用 BigTable 将图像复制到不同的数据中心。代码查看不同的指标以了解谁最接近。
于 2010-11-18T15:51:46.630 回答
2

您还可以查看基于 Plone 的http://plumi.org 。

于 2012-10-07T04:11:30.440 回答
1

MediaCore 有什么好处？

http://getmediacore.com/

“用于集中所有视频和播客需求的开源视频 CMS”

于 2010-11-18T15:49:15.123 回答
1

您可能也想看看 zencoder 进行视频编码.....

于 2010-11-18T15:41:51.507 回答
0

即使不是 CMS，Django也可能非常有用。

于 2010-11-18T15:28:55.037 回答
0

Django 和 Pylons 是两个最流行的 Python 框架，它们可以让您快速构建自己的 CMS 和类似 youtube 的视频托管网站。

Django http://www.djangoproject.com/

塔 http://pylonshq.com/

制作您自己的网站而不是依赖 CMS 确实是您最好的选择，因为您将不得不弄清楚许多其他事情，例如如何将上传的视频转换为 FLV，这不属于核心 CMS 功能的一部分. 还有很多其他考虑因素，例如利用云 CDN 来交付您的视频内容，这些内容在我能想到的任何框架中都不存在，即使是用不同语言编写的框架。

于 2010-11-18T15:34:58.107 回答