专家访谈：如何扩展 Django 已翻译 100%

这周，我靠边站让我公司的开发者—Jonathan Freeman主持大局。主题是Django：Python web框架以及如何扩展。不负众望，Jonathan Freman采访了两位在票务服务公司Eventbrite工作的、在Django方面有丰富经验的专家：设计总监Simon Willison和原理系统工程师John Shuping。Shuping在Eventbrite有些年头了，一直在帮助公司成长和转型，而Simon是去年加入这个团队的，当时一家他共同创办的公司—Lanyrd被收购。如果你有兴趣了解更多，请进入 The Lanyrd Blog 和 Eventbrite's Engineering Blog

--Andrew Oliver

Jonathan Freeman：您如何运用Django？

Simon Willison；我们有两个代码库可以谈：Lanyrd和Eventbrite。如你所知，Lanyrd七个多月前被Eventbrite收购。对比这两个库很有趣。Lanyrd是一个新项目开发：三年前，我们从一张白纸开始着手Django部署。Eventbrite代码库更旧些，有七年历史了，三年前采用Django，但里面还有些代码是早于Django的一种自定义Python框架。

【更聪明，而不是更努力地工作——从InfoWorld下载开发者生存指南《程序员需要知道的所有技巧和趋势》。 我通过InfoWorld的开发者世界时事通讯跟进最新的开发者新闻】

它们运作有很大区别。Eventbrite去年售出价值十亿多的门票，所以有大量的通信和现金交易通过堆栈。Lanyrd则小得多，也不需要处理支付操作，因此更灵活。由于不涉及现金交易，我们可以承担代码库风险。

Freeman：“规模”有很多意思，您所说的“规模”是指什么？

Willison：不止一件事要扩展。你的网站处理的是批量增长的通信量，这是一个很直接的定义。每秒能处理的点击越多越好。这也扩展了代码库的复杂度。随着代码库越来越大、越来越复杂，管理其复杂度也就有技巧。最后，还要扩展你的工程团队。Lanyrd团队有6个人，Eventbrite工程团队现在超过80人。当有这么多工程师致力于同一个代码库时，你有很多不同的事情要做。

Freeman：扩展通信量时，你认为最重要的是什么？

Willison：当扩展通信时，重要的是，从Django、PHP以及目前大部分web框架获取的数据—这是一个无共享体系结构概念。应用服务器就是他们谈论的拥有数据库和缓存的后台哑盒，但基本上，通过部署更多的应用服务器，你可以在应用层处理更多的通信量。这把扩展的挑战转移到数据库和缓存层。

扩展数据库总是困难的。在Eventbrite上，我们大量使用MySQL和MySQL复制。我也不确定我们运行了多少从属数据库。

John Shuping：我们的核心基础库有两个主库和10个从库。Django内建的路由是不能够将读写请求发送到特定的数据库。在Eventbrite中我们已经做了一件事情，就是我们能路由插入和更新的请求到主库，选择的请求到从库。

Willison：Django ORM有一些底层的钩子让你切换到不同的数据库连接，但是它不能解决发送插入请求到一个数据库而更新请求到另一个数据库的问题。在Eventbrite中我们写了自定义的代码来解决上述的问题。

另外一个技巧就是我们分离了从库，例如长时间运行的查询。昂贵的SQL查询不会运行在任何生产环境中。

Freeman: 数据库在生产环境中出现问题需要立即更改怎么办？

Shuping: 一个真正有趣的事情大概发生在三年前。当你获得了一个事件的生成，它被写入数据库并且你的后续页面可能想要从数据库中读取信息生成你的确认email。我们被通知如果一个从数据库延迟于后面的主数据库半秒，你可能就不能写入主数据库，从数据库的读取也要延后，实际上，数据还不在那儿。

因此我们围绕数据库的从库滞后问题设计了两层保护。第一层在Django的内部，我们称之为DB阻塞。基本上，这意味着如果你的代码写入主数据库，之后任何的读取在两秒内都会通知主库。

我们一直在我们的数据库从库（Django配置所实际指向的那个从库）前面，使用HAProxy负载均衡器集合。负载均衡器在所有的从库间，做实时的健康检查。如果检测到一个从库超过两秒的延迟，我们就会从可用的从库池中取出，并且不会提供任何通信，直到它获取备份。

Freeman:  关于DB阻塞，你会在会话（session）中存储吗？这听起来像是粘性会话（sticky session）。

Shuping: 我们肯定不能做粘性存储（sticky session），对于Simon's的观点，它真的能易于水平伸缩。你说对了，对于DB阻塞，我们使用高性能缓存。我们有四个高性能缓存服务器构成的群，为了你的访客cookie或者在高性能缓存中的任何东西，我们还考虑了交叉散列和存储DB阻塞令牌（DB pinning token）。

Freeman: 站在Lanyrd（一个聚合会议或活动相关的各种内容的网站）的角度， 你从MySQL转换到PostgreSQL，对吗（好吗）？

Willison: 是的，这是对的。我们大约在一年前，就在想转换的几个原因。人们写了大量的关于MySQL和PostgreSQL的东西，但我们关心的是一个杀手级的特点，在PostgreSQL您可以添加一个新列，而不必锁定整个表。在MySQL中你不能这么做，我们在Lanyrd的观点上，我们的一些大的表足够大，为那些表添加新列是痛苦的。我们从PostgreSQL中得到的好处是，我们能更容易地修改我们的数据库表。

[注释：Lanyrd网站从MySQL到PostgreSQL的过渡，在两小时内完成，不过它是在一个只读的模式下进行的。]

Willison: Eventbrite（一个在线活动策划服务平台）运行在MySQL之上，并使用被叫做pt-online-schema-change的技术去添加新的列。这意味着你可以在运行时修改你的表，不需要任何的停机时间。但是在MySQL中的有些特性你不能使用，例如：在数据库级上的外键约束，因为我们做的那些复制方式和在线架构的变化是不兼容的方式。

Shuping: 在转换之前关于维护的观点，我们的操作目标是不需要任何计划内的维护，或者停机，或者处于只读模式。我们能够做到这一点，pt-online-schema-change技术做出了关键的贡献。