易栈网-膘叔

myisam如果经常insert,update,delete会产生很多的碎片，而且因为表类型的关系，其实它如果使用不当，也会有损坏的情况发生，一般情况下，可以使用repair table来进行修复。老王说，尽量使用 myisamchk来进行修复，因为这是命令行下的，所以，我没有用过。命令行下，我用的也是repair table。
所以，我转载了老王的这篇博客，写完后，老王又来了一篇TableCache设置过小造成MyISAM频繁损坏，看来，myisam表之所以容易损坏，和tablecache的设置还是有关的。

修复表的原文如下：
当我们用PHPMyAdmin浏览数据库时，有时候会发现某些MyISAM表的Collation项显示为“in use”，这多半说明此表已经损坏。即便是没有出现“in use”字样，也不能就此说明表是完好无损的，熟悉检查及修复方法是必须的。

通过语句：

检查表使用CHECK TABLE语句，如下：

CHECK TABLE tbl_name [, tbl_name] ... [option] ...
option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

修复表使用REPAIR TABLE语句，如下：

REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLE
    tbl_name [, tbl_name] ...
    [QUICK] [EXTENDED] [USE_FRM]

通过命令：

检查修复表可以使用myisamchk命令：

myisamchk [options] tbl_name ...

如果没有指定参数，那么myisamchk命令缺省执行的就是检查动作。若是要修复表，可以使用-r或-o参数，应该优先使用-r修复，不行的话再使用-o修复。此外，在修复前应该使用FLUSH TABLES刷新缓存，并关闭数据库服务器或者锁定所有的待修复表，以确保在修复过程中不会有其他写操作。

自动修复：

在my.cnf配置文件中的mysqld部分设定myisam-recover参数，当服务启动时可以自动修复有问题的表（速度快慢视数据多少）：

[mysqld]
myisam-recover [= options]

参数有DEFAULT，BACKUP，FORCE，QUICK，可以设定为BACKUP,FORCE，万万不可单独设置成FORCE，否则数据文件丢了都没处哭去。


应该尽量使用myisamchk命令去修复，不行再用repair语句去修复（慢），还不行就参考下面链接。

参考文档：How to Repair Tables
而对于tablecache的设定，老王建议：如果你比较懒惰，也可以用MySQL Performance Tuning Primer Script来判断参数是否合理

我也来个前言，架构这东西，研究的人越多，我能够做参考的也就越多，哇哈哈哈。不多说，贴copy来的文章，原文见博客园：http://www.cnblogs.com/micronet-lukey/archive/2009/04/14/1435520.html。

当然这个架构和我们传统意义上的WEB架构不太一样，但我想说的是这些问题还是可以作为一定的参考。比如我们在开发的时候，是直接上SVN还是采用传统的目录共享式开发。现在SVN已经成为很多项目开发所必备工具了，但如果我们在部署的时候采用SVN进行分发代码呢？审核关如何过？

程序员->发送到SVN服务器->SVN分发到测试组->测试组分发到正式机

这是一种解决方法，其实也有点象下文的图片。但实际操作中，当然不太会这样操作。不过也差不多是类似的方法。

让我注意的其实是文章的最后一句话。。。

前言：

       目前，公司的呼叫中心程序已经在中国的很多城市运行着。由于受到技术和网络环境的限制，这些呼叫中心程序安装实施完毕后，我们都是采取客户先反映问题，然后我们再安排人员时间进行维护。这种被动的维护机制带了很多问题。

目前存在的问题：

一：客户在描述问题的时候，并不能深入到系统的内部，往往只是描述了一个系统报错的现象。由于公司里已经没有当时的运行环境，在公司内很难做到故障重现，也就很难定位到故障的原因。系统维护和bug修补难度很大。

 二：呼叫中心的程序日志都是分散存放的。哪台计算机中的程序报错，就到那台电脑中找出错日志。这个过程必须人工干预。有时候，有些报错内容非常致命，但由于公司不能及时获取到这些信息，导致很多问题就像一颗定时炸弹一样无法及时排除。

 三：当公司更新了一个版本后，如果不能到现场维护，只能通过远程或者让客户代劳替换新程序。这种更新机制一旦遇到网络中断，或者客户不配合，将给维护工作带来很大障碍。如果由于需求变更较多，需要经常更新版本， 那么面临的问题将很难解决。

 解决的措施：

就第一和第二个问题，可以通过改进目前的日志记录方式来解决。通讯服务器接收客户端程序的错误日志。并且把这些日志内容打包成E_Mail邮件，定时发送到公司指定的邮箱中。

就第三个问题，可以通过自动更新服务来解决。维护人员把最新的软件更新包上传到客户端的通讯服务器中。客户端程序监测到有最新的软件更新包，可以自动更新。

解决问题的核心就是在客户那安装一台通讯服务器。这台通讯服务器既要能能够连接到Internet，同时还要和内部的服务器向连接。这台通讯服务器有两个作用：

1：发送各个程序的错误日志到公司的邮件。

2：接收公司上传的程序更新包，并自动通知各个客户端程序更新。

所有的工作都由服务器自动完成。

 总结：

       任 何一个系统，在现场部署完成，用户正式开始使用后，对于我们开发组来说，那只是万里长征走完了第一步，后期不断地查错，改进，更新，替换也会占用到大量的 人力物力，如果是外省的客户，跑一趟现场还会占用大量的财力。按照现在的技术能力和网络环境，我们完全可以通过技术手段，更高效地对各个系统进行维护。

维护的最高境界是：客户还没有发现问题，我们已经捕捉到bug并在后台悄悄地把程序更新了。

其实关于这方面我并不了解，昨天在“PHP研讨会议群”里，一直有人在问，但，我确实不了解，于是乎，我没有参与

今天一大早翻开google reader，发现Sanotes就给了我一个惊囍，真是说曹操曹操就到啊。头条就是：keepalived权威指南，吓死我了。

我想，我并没有求过签咋的呀。哈哈

本地做了一个备份：keepalived.pdf

最近，好象谈架构比较多了，所以，我也就跟着copy,paste了一把。。原文来自DBA notes，网址为：http://www.dbanotes.net/arch/best_practices_for_scaling_websites_lessons_from_ebay.html，作者：feng。

内容如下：

很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错，但对我来说，其实冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。

不过，eBay 这次的PPT 总算还是有点更新的。

1）数据分片(Partition Everything)

说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文：开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒进。

从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。

2）异步处理(Asynchrony Everywhere)

其实对于任何网站来说，过度追求"同步"化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计，中间可以最大限度用异步来完成。

eBay 的举例的模式有两个，一个是事件队列(Event Queue)，另一个是信息分发(Message Multicast)。前者基本上是个生产者--消费者的模型。后者主要用在搜索的架构上。

（膘叔：不知道怎么回事，我下载总是只显示一半看来是我的RP不好？）

注意到图中的消息总线，这才是 eBay 整个架构中的动脉，估计轻易不会批露技术细节

3）自动化(Automate Everything)

这里的自动化举了两个例子，一个是针对运维方面的，另外举了关于机器学习的东西，这是演讲者 Randy Shoup 的强项所在。

eBay 的自动化，在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视，参见：eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。

4）故障检测与回溯(Remember Everything Fails)

更好的失败检测机制: 监控每天超过 2TB 的日志，根据日志中的相关事件得出判断或者预警。这个看起来简单，但实现起来还是需要一点技巧和策略的，重要的是，需要不断根据结果的反馈去改进。

完美回滚: 任何服务都通过服务配置中的标记来识别，无痛回滚。(个人感觉这个非常有难度，尤其是升级的时候)

优雅降级(Graceful Degradation)：能够相对容易的对应用标记"Marks down（下线）"

5）拥抱不一致性(Embrace Inconsistency)

举了 CAP 原则，程立将其形象描述为帽子戏法，非常准确。说起一致性，自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出，基本上不需要我废话了，这就是事务处理的九阴真经，大家回家慢慢参详好了。

eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性，通过异步事件(消息总线?)达到最终一致性。

--EOF--

另外小道消息：Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。

以前的老帖子：eBay 的Scalability最佳实践

对了，如果想直接看讲了什么内容，请看

InfoQ中文站相关内容：

1. 可伸缩性最佳实践：来自eBay的经验
2. eBay的表示层架构与Eclipse
3. 牺牲一致性来换取分布式架构的可伸缩性
4. ActionScript类库推动mash-up Web2.0平台
5. 从业务角度论证如何采用REST风格架构
6. Engine Yard要接管Ruby 1.8.6的维护？
7. 可伸缩性原则
8. 透过digg.com和Reddit了解mashup应用
9. 使用WCF消费REST服务
10. eBay技术特别专题

jQuery这种轻量级的框架大家使用的都比较多，1.3后效率据说又上升了不少，因此，开发基于jQuery的插件也就显得那么理所当然了。
一般来说，jQuery有两种插件模式，一种是：$.extends({}) ，另一种是：$.fn.extends({})
个人理解：前一种是属于全局性的调用，后一种是针对某个元件的绑定调用。这当然是简单的理解。但事实上，也基本上就是这么做的。

官方的例子也比较简单：

看上去是不是容易？然后就可以直接调用了。 $.min(2,3) 返回2
一般情况下，为了在扩展中使用$，却又担心的页面使用了jQuery.noConflict()而取消了$指向jQuery的引用，则需要这样写

这样写不仅能够将$显式指向jQuery，而且将产生的变量封在function的作用范围内，不会污染window全局。
而基于$.fn.extends({})的扩展又如何开发呢？

在这里我引用Roby的译文：http://www.robysky.com/archives/171
英文原文：http://www.learningjquery.com/2007/10/a-plugin-development-pattern

我认为以下插件开发模式是必须应该掌握的：
1.在JQuery命名空间内声明一个特定的命名；
2.接收参数来控制插件的行为；
3.提供公有方法访问插件的配置项值；
4.提供公有方法来访问插件中其他的方法（如果可能的话）；
5.保证私有方法是私有的；
6.支持元数据插件；

下面，我将逐一讲述上面的内容，并在同时给出相关的简单插件开发代码。
1.在JQuery命名空间内声明一个特定的命名

这意味着开发的是一个单一命名的插件脚本，如果你的脚本包含多个插件或者有补充性质的插件，比如$.fn.doSomething() 和$.fn.undoSomething()，那你得声明多个命名了。但是总体来说，当开发一个插件时，我们应该努力做到用一个单一的命名来搞定整个插件。

在例子中，我们将声明一个名为“hilight”的插件。

我们可以这样调用：
$(’#myDiv’).hilight();
但是假如我们需要打破这种单一的命名和调用方式呢？有很多理由支持我们这么做：设计上的需要；更加简单和可读的配置；而且那样将更加符合OO的要求。

在没有给命名空间来到麻烦的前提下，将插件的部署打破成为多个函数的形式将是十分繁琐的。我们通过认识并利用JavaScript中 functions是最高层的对象，和其他对象一样，functions可以被赋予属性，前面我们已经将hilight命名声明在了JQuery的原型对象上，那么，其实，其他的我们想扩展的属性或对象都能够在hilight上进行声明。稍后将详细讲述此点。
2.接收参数来控制插件的行为；

来为我们的hilight插件添加指定前景和背景色的功能，我们需要在函数中允许一个object类型的选项设置。如下所展示的那样：

现在，我们的插件可以这样来调用：

$(’#myDiv’).hilight({
  foreground: ‘blue’
});
3.提供公有方法访问插件的配置项值；

上面的代码我们可以做一下改进，使得插件的默认值可以在插件之外被设置。这无疑是十分重要的，因为它使得插件用户可以使用最少的代码来修改插件配置，这其实是我们利用函数对象的开始。

 4.提供公有方法来访问插件中其他的方法（如果可能的话）

这里要讲的方法和前面的讲解一脉相承，用此方法来扩展你的插件（而且能够让其他人进行扩展）是件很有意思的事情。例如，在扩展hilight插件时，我们可以定义一个format方法用来格式化高亮显示的文本，原来的hilight插件和扩展了format方法的插件代码如下：

如前面所述，我们已经很容易的通过设置options对象的属性来允许一个回调函数来覆写默认的格式设置。在这里有另外一个非常棒的方法来个性化你的插件，上面展示的方法实际上就是通过暴露format方法，使其可以被重新定义。这种做法使得其他人可以采用他们自己的习惯和方式来重写你的插件，这意味着他们可以为你的插件写额外的扩展插件。
仔细考量一下前面我们用到的插件例子程序，你可能会想“我们究竟应该在什么时候使用这种插件方式来实现需求”的问题。一个来自现实应用中的插件便是“ Cycle Plugin”，它是一个支持多种滑动显示特效的插件，特效包括滚动、滑动和渐变等等。但是，实际上，并没有办法来定义每一个可能会用在滑动变幻上的特效。这就是这种扩展方式的有用之处。“ Cycle Plugin”插件暴露了”transitions”对象，这使得用户只需要按照如下方式便可以添加自己的变幻定义：
$.fn.cycle.transitions = {
…
};
这种技巧使得用户可以定义或者采用自己习惯的方式来扩展“ Cycle Plugin”。
5.保证私有方法是私有的；

上面提到的暴露插件中的公有方法的技巧使得插件能够被覆写，这将使插件变得十分灵活而强大，但至于哪一部分，那些属性和方法应该被暴露出来，你得小心了。一旦使其能够被外界访问到，你就得注意到任何调用参数和语义化的变动都可能使其丧失向前的兼容性。作为一般准则，如果不确定是否应该暴露某个属性或对象的话，那就最好别那样做。
那么我们应该怎样来定义多个方法而不至于使命名空间混乱并且保证不被暴露再外呢？这就是闭包的工作，为了便于演示，我们给插件加入了一个叫做 “debug”的功能，它用来记录firebug控制台所选择的网页元素数目。为了创建一个闭包，我们将整个功能的定义放入在一个function中了（有关这方面的知识，可参见JQuery手册）。

debug方法在这里是无法被在插件以外访问到的，因此，我们称之为它是插件私有的。
6.支持元数据插件；

根据你所写的插件的类型，为你的插件加入元数据插件的支持将使其变得更强大。就我个人来说，喜欢采用元数据插件的重要原因便是它可以让你使用定义之外的标签来覆写你的插件属性设置（这在创建demo和例子时十分有用），而且支持它十分的简单。
更新：这部分内容可以在本文的评论中展开讨论（既然有争议的话）

改动部分的代码会做如下的事情：
*测试metadata插件是否可用
*如果可以，将用metadata扩展options对象
这被加入到jQuery.extend，作为其最后一个参数，所以它可以覆写任何其他参数设置。现在我们可以通过下面的方式控制其行为：

而在调用方面，我们通过一行简单的代码就可以实现预期的效果：
$(’.hilight’).hilight();

将上面所述内容涉及到的代码放在一起，完整的例子程序代码如下：

看完以上的内容，你是不是对jQuery的插件开发加深了一定的了解了呢？
顺便提一下，yhustc在自己的博客上写了一个基于jQuery的软键盘插件，你是不是又可以根据上面的教程来写一个基于$.fn.extends的扩展呢？让yhustc的插件可以绑定在某个元件上？