领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
NeverBlock和无阻塞数据库适配器
作者 Mirko Stocker 译者 马家宽 发布于 2008年9月15日
NeverBlock是一个使用Ruby 1.9的Filber特性构建的库。使用NeverBlock可以编写non-blocking代码。第一个获益于NeverBlock的数据库是Postgres（可见InfoQ上关于Fibers和 NeverBlock的文章。现在，就在Postgres几天之后，NeverBlock也添加了对于MySQL的支持，并使用了新的MySQLPlus驱动。MySQLPlus构建于Ruby自带的MySQL驱动之上，此外还添加了异步查询处理支持和线程访问支持。
此外，另一个致力于为Ruby的MySQL连接增加异步操作能力的工程是Asymy。InfoQ为此采访了MySQLPlus的一位开发人员Roger Pack。我们特别感兴趣的是MySQLPlus和Asymy的差异，以及为什么要创建一个新的适配器。
首先介绍一些历史：之前我们使用的一般是用C编写的MySQL库，它在任何一次查询时都会进行阻塞。MySQLPlus和Asymy都试图改变这一情况。
MySQLPlus基本上可以算是在标准的MySQL Ruby C库之上增加了一些多线程友好的特性，尤其是在一条查询返回前不阻塞IO。
Asymy则是一个为比较纯粹的异步MySQL适配器。它用Ruby写成，因而解析相对慢的多（大约要慢10倍），而且由于推出不久，尚有一些bug。
让 我来说，二者间的一个差别在于Asymy“只是”事件驱动的，而MySQLPlus则同时兼有线程模式和事件驱动。MySQLPlus的事件驱动特性有一 定的局限，这体现在当一个查询被读入时，用户不能够真正的检测到何时去等待IO——这说明MySQLPlus尚未完善，但这至少是朝着正确方向迈出的一 步。
实际上，最开始的时候我们曾考虑过使用Asymy，后来Muhammed [Ali, NeverBlock的一名工作人员]发现只要对标准的C MySql库稍作修改，就可以使其基本具有多线程能力，所以我们就转到了标准库这边。MySQLPlus库可以看作是对Tomita Masahiro库的一个修改。
所以我想MySQLPlus和Asymy之间可能有一些重复的部分，这主要是C和Ruby两种语言的问题。MySQLPlus的C语言部分并不是我们写的，所以在这部分没有什么重复。
现在NeverBlock可以和MySQLPlus一起工作，那么它会能够和Event Machine一起工作吗？
NeverBlock基本上可以看作是Fiber、EventMachine、Postgres或MySQLPlus驱动的结合体。因此答案是：在应用了一些小补丁后，NeverBlock可以和EventMachine一起工作。因此如果你很喜欢EventMachine的分阶段编程风格，NeverBlock甚至可以与1.8.x版本的MySQL驱动一起工作。
值得注意的是MySQLPlus已经作为相对于1.8.x MySQL驱动来说更加线程友好的代替品而推出。MySQLPlus也可以很好的与 NeverBlock和1.8.x MySQL驱动兼容，这也是它最初的目标。
这个项目未来的计划是什么样的？你们是否打算去适配其它种类的数据库？
Muhammed提到过这一潜在目标。我倒还没有这么想过，因为我觉得我们已经足够好的覆盖了这方面工作最重要的部分。
未来的计划主要是让rails 2.2兼容NeverBlock和MySQLPlus，希望能得到比较好的性能。
Aman Gupta，MySQLPlus的作者之一，将MySQLPlus用在了Aman Gupta所开发的异步Event Machine MySQL客户端中。当然，Postgres和MySQL并不是Ruby仅可用的两个数据库，所以我们也访问了KUBO Takehiro，Oracle数据库接口ruby-oci8的作者之一。我们请教了他关于NeverBlock的看法，以及NeverBlock是否可以方便的与ruby-oci8集成：
我觉得集成不容易。Neverblock-pg使用了PGconn#send_query来登 记一条查询，然后挂起fiber直到查询完成。但ruby-oci8的无阻塞模式则不是这样。当一个查询被执行时，处于无阻塞模式的ruby-oci8等 待结果，但并不阻塞其他线程。在ruby-oci8之外不能够增加挂起fiber的代码。我们不打算通过修改ruby-oci8来适配 NeverBlock。这是因为用户在不用到NeverBlock的fiber池的情况下，透明的使用无阻塞操作。
另外，我不确定要使用无阻塞操作时，是否一定要用到NeverBlock。如果通过使用rb_thread_blocking_region() （ruby 1.9的新特性），让ruby-pg包装那些阻塞性操作，其他线程就不会被阻塞。（可参见Ruby线程机制的未来）。
当然，虽然我有这些看法，我还是很欣赏NeverBlock在为activerecord增加连接池特性方面所做的工作，这些正是我一直想要的。
我们还采访了Jamis Buckis，sqlite3-ruby适配器的负责人。我们想知道，实现一个异步接口对于SQLite是否很重要：
说实话，我觉得并不是那么重要。SQLite是一个内置数据库，而不是像MySQL或PostgreSQL那样使用客户端/服务器架构。为了在 SQLite中支持异步查询，用户得首先将SQLite转换为服务器模式，以使得SQLite运行于用户应用外的一个单独进程。如果用户真的这么做了，那 么也许使用SQLite就不再是一个好的选择。
确实，我个人非常强烈的不主张人们在一个web应用的产品版本中使用SQLite。SQLite非常适合测试阶段和开发阶段，并且能够很好的与内置的各种应用协同工作，但在一个web环境中，SQLite并不能像客户端/服务器模型那样工作。
读到这里，你有什么想法呢？是不是我们为了性能考虑，需要无阻塞的数据库访问呢？
没有回复
关注此讨论 回复