易栈网-膘叔

本文来自kakapo的博客，kakapo，如果没有记错，应该是pchome的人吧。。。负载均衡我暂时还没有用到，毕竟我就一台服务器也没必要在服务器上装上17、8个虚拟机来跑这些负载均衡吧。

原文地址：http://www.kakapo.cn/blog/read.php?153

内容：

先罗列一下问题：
1、session会话数据共享问题
2、缓存数据文件共享问题
3、用户数据共享问题
4、上传数据存储问题
5、Log日志文件共享同步问题
6、配置文件管理问题
7、web服务器时间获取不一致问题

这些问题都是从项目经验中总结出来的，接下来在一一讨论解决的办法。
1、session会话数据共享问题    

推荐使用memcached分布式缓存系统来解决，可以参考我之前写一篇文章《Memcached的介绍和应用》。

2、缓存数据文件共享问题解决方案

所谓缓存数据，一般指网站前台程序本身产生的数据，比如，数据库查询类产生的数据对象缓存，缓存类产生的本地缓存数据，远程抓取类产生的本地临时缓存文件等等。    
有 些数据看似不需要共享，就像那些在每台机器上都能自动产生的数据。但是如果刚好碰到某个时刻数据更新了，缓存时间又不同步，就会造成负载均衡上的每台机器 缓存数据不相同。这也会给用户的访问带来一定的困扰。当然针对的解决办法就是想办法让缓存同时过期，保证缓存的内容相同，这就不需要考虑共享的问 题。    
远程抓取经常会涉及到模拟登陆，在本地一般会保存模拟登陆用户的cookie数据，这个就一定得想办法解决共享。否则用户在负载 A机器上执行了模拟登陆程序，在本地产生了cookie文件，但是下次请求被分配到负载B机器上执行抓取程序，却发现需要用上的cookie文件在本地不 存在，马上程序就会被远程服务器拒绝访问。这种cookie的临时文件很多而且改动频繁。目前我们采用了NFS的方案，mount指定的一个缓存目录，让 负载的每台机器都能像本地目录一样访问，暂且还行的通。也可以将这个单独的应用放到一台机器，来避免这个问题。

3、用户数据共享问题    
所谓用户数据，范围比较广。这里一般指在用户的独立目录空间保存的用户独用的数据。比例用户自己的相片，头像等等。    
之 前我们采用的方法是搞一台存储服务器，通过一定的规则为用户创建目录空间，然后存储服务器通过NFS共享到所有负载均衡的web服务器。这种做法在几百万 用户的网站还行得通。主要问题在于NFS在高并发访问下会出现一些不稳定，会丢失文件访问句柄。另外还有mount管理带来的麻烦，以及数据安全等风险。 顺便提起用户目录空间的创建规则，分散均匀是一个最大的原则，采用哈希值切分方式比较合适。 采用用户名或者时间因子虽然方便了一些记忆和查询，但是容易碰到局部目录达到系统最大限制的问题。    
所以，推荐使用分布式文件系统解决方案。国人happy_fish100开发了一个高效的开源的分布式文件系统FastDFS，比较完善，使用简单，功能强大。特别适合解决我当前遇到的问题。自称比国外的Mogilefs还强大。让我更心动的是提供了PHP client API，采用socket访问。在应用中调用也非常方便。

4、上传数据存储问题    

这 个问题再单独拿出来谈是有根据的。在前台用户上传的自己相关的数据可以归属前面一个问题的范畴。前台也有一些用户上传的数据跟用户无关，还有网站后台也会 有很多上传的数据。之前的做法可以是通过FTP服务将这些数据上传到存储静态文件的服务器上，也有通过NFS方式共享静态文件服务器的指定目录到web服 务器。现在除了FTP方案之外，我也推荐尝试使用FastDFS来管理静态文件服务器的数据，但是要修改一下设计，可以在FastDFS的storge服 务器上直接架设http服务器，让静态文件能直接通过URL访问。

5、Log日志文件共享同步问题    

所谓的Log日志也是web服务器程序自动产生的，比如错误日志，访问日志等。在一般情况一下也可以考虑让其不共享，无非是分析日志的时候每台机器都要做一遍。

6、配置文件管理问题&web服务器时间获取不一致问题      

配置文件管理问题严格来讲不属于开发遇到的问题，而是运维人员烦恼的事情。当然，通过合理的将配置文件进行归类和存储，还是可以减少运维人员的困难的。web服务器的配置文件的最好也不用共享，文件的同步可以让系统管理员通过系统命令去自动完成。
web服务器时间不一致虽然可以通过系统定时跟全球的时间服务器同步，但是在开发过程中程序还是要尽量避免使用本地时间函数，特别是跟数据库有关系的数据，可以通过采用数据库的时间函数来解决。

 

原文来自：https://docs.google.com/View?docID=dft4vhq9_22g93szvdd&revision=_latest

例如，你想动态的创建一组列表元素，千万不要这样做,如下所示：

我们应该将整套元素字符串在插入进dom中之前先全部创建好，如下所示：

除非在特殊情况下, 否则每一个js事件(例如:click, mouseover等.)都会冒泡到父级节点。
当我们需要给多个元素调用同个函数时这点会很有用。

代替这种效率很差的多元素事件监听的方法就是, 你只需向它们的父节点绑定一次。

比如, 我们要为一个拥有很多输入框的表单绑定这样的行为: 当输入框被选中时为它添加一个class

传统的做法是，直接选中input，然后绑定focus等，如下所示：

当然上面代码能帮我们完成相应的任务，但如果你要寻求更高效的方法，请使用如下代码：

 

 改进方式：

jQuery对于开发者来说有一个很诱人的东西, 可以把任何东西挂到$(document).ready下。
尽管$(document).rady 确实很有用， 它可以在页面渲染时，其它元素还没下载完成就执行。
如果你发现你的页面一直是载入中的状态，很有可能就是$(document).ready函数引起的。

你可以通过将jQuery函数绑定到$(window).load 事件的方法来减少页面载入时的cpu使用率。
它会在所有的html(包括<iframe>)被下载完成后执行。

 

原文来自：https://docs.google.com/View?docid=dft4vhq9_21hjb7j9fz&revision=_latest

例如有一段HTML代码：

如果采用下面的选择器，那么效率是低效的。
var traffic_button = $("#content .button");

因为button已经有ID了，我们可以直接使用ID选择器。如下所示：
var traffic_button = $("#traffic_button");

当然 这只是对于单一的元素来讲。如果你需要选择多个元素，这必然会涉及到 DOM遍历和循环，
为了提高性能，建议从最近的ID开始继承。
如下所示：
var traffic_lights = $("#traffic_light input");

在jQuery中第二快的选择器是tag(标签)选择器( 比如：$("head") )。
跟ID选择器累时，因为它来自原生的getElementsByTagName() 方法。

继续看刚才那段HTML代码：

比如需要选择 红绿 单选框，
那么可以使用一个tag name来限制(修饰)class ，如下所示：
var active_light = $("input.on");
当然也可以结合 就近的ID，如下所示：
var active_light = $("#traffic_light input.on");

在使用tag来修饰class的时候，我们需要注意以下几点：
 （1） 不要使用tag来修饰ID，如下所示：
  var content = $("div#content");
  这样一来，选择器会先遍历所有的div元素，然后匹配#content。
 （好像jQuery从1.3.1开始改变了选择器核心后，不存在这个问题了。暂时无法考证。）

 （2）不要画蛇添足的使用ID来修饰ID，如下所示：
  var traffic_light = $("#content #traffic_light");

把jQuery对象缓存起来 就是要告诉我们 要养成将jQuery对象缓存进变量的习惯。
下面是一个jQuery新手写的一段代码：

但切记不要这么做。

我们应该先将对象缓存进一个变量然后再操作，如下所示：

记住，永远不要让相同的选择器在你的代码里出现多次.

注：（1）为了区分普通的JavaScript对象和jQuery对象，可以在变量首字母前加上 $ 符号。
 （2）上面代码可以使用jQuery的链式操作加以改善。如下所示：

 

如果你打算在其他函数中使用jQuery对象，那么你必须把它们缓存到全局环境中。
如下代码所示：

jQuery性能优化指南(1)到此结束，请查看指南(2)。

当你需要把分类表显示为树形时，肯定是需要进行一些妥协，就象前面文章中所说的，对数据进行这种处理意味着要无数的SQL查询命令或者复杂的客户端代码打交道。
可供选择的解决方案之一是在分类表中增加两列：sort,deepth,SORT字段负责给出各条数据记录将出现在层次关系树的第几行（假设同一层次的记录将分类名进行排序），DEEPTH字段则负责该分类所在的层次深度。
这种方式的好处是可以通过在MYSQL程序中执行下面这条简单查询的办法得到证明。例如：SELECT CONCAT( SPACE(deepth * 2) ,catename ) as category , sort , deepth FROM categories ORDER BY sort.其中concat函数的功能是把两个字符串并为一个，space函数的功能是生成指定个数的空格字符，AS关键字是给整个表达式起一个新的名字(别名，可能更容易理解一些)。
执行这样的SQL后，可以生成一个简单的树结构，树的尝试都是通过deepth的空格来显示的（这里显示简单的例子）
CATENAME　　　　　　　　　　SORT　　　　DEEPTH
主分类　　　　　　　　　　　　０　　　　　　　０
一级分类　　　　　　　　　　１　　　　　　　１
二级分类　　　　　　　　　２　　　　　　　２
重复一级分类　　　　　　　　　３　　　　　　　１
重复二级分类　　　　　　　　　４　　　　　　　２
三级分类　　　　　　　　　　　５　　　　　　　３
大致结构如上。
那么sort值和deepth的值是怎么来的呢？我们会进行一个简单的演示：
1、新建一个[新的三级分类]，它被插入到[二级分类]下一级。而二级分类有关的数据是sort=2,deepth=2
2、那么我们首先要找到[二级分类]下是否已经有数据插入，SQL为：WHERE parentId = [二级分类]ID
3、将数据追加到二级分类下（即SORT+1,深度=）
4、更新相关数值
在这里面就涉及到一些问题，二级分类下如果有多个三级分类，三级分类还有四级分类，这时候SORT值的取值就比较难以控制。插入值后，它的SORT值其实是覆盖了原来的重复一级分类的SORT，那么，原来的SORT值>＝当前SORT值的，都需要自动加1.
由此可见，虽然SORT值和DEEPTH值简化了查询工作，但实际上他的写操作变得频繁和复杂了。如果需要更新其中的一条记录，所涉及的操作还会更多。因为他必须要相应的调整sort值和deepth值。
因此，在实际情况中，你必须决定是对读操作进行优化还是对写操作进行优化。一般情况下，对于这种分类表，我都比较倾向于一次读出，然后利用 PHP语言进行深度的处理 也就是说，我是一般不会用SORT和DEEPTH字段的。因为大多数情况下，分类表都是一种比较固定的表，不大会读写，而在后台的读写，也不会影响到前台的操作。。

好象有点乱。

分类表是一种典型的层次化关系的表，从数据库设计工作的角度看，让每个分类记录的parentId字段指向它们父分类的Id即可。
把层次关系转化为数据表并不困难，而且层次还相对比较清晰，但在这种表面现象的背后还有许多难题在等待着用户解决。比如，我们无法只用一个简单的SELECT就把指定分类的父分类或者子分类全部查询出来，而必须通过多次查询才能解决这个问题（或者一次查出后，用程序来进行处理）。
事实上，数据库设计和SQL编程有着千丝万缕的联系，很难将他们完全区分开来，再者，如果SQL不足以把想要查询的数据从数据表里提取出来，那么，想拿出一个优秀的数据为设计方案就只能是一句空谈。
想要通过数据表去管理和使用层次关系，得解决很多难题，而这些难题几乎都与SQL语言不能递归查询这一事实有关。以分类表为例：
1、只用一个查询就把指定分类的所有父分类全部查出来是不可能的
2、把完整的数据表还原为层次关系（树状）也是一个难点，还是必须执行多次SQL才能完成。
3、把指定分类下所有子分类全部查询出来
4、设计时，一个分类不能有两个父分类（例如：sql语言既能够放在database分类中，但好象放在programming分类下也行，因此，如果sql语言有两个父分类仿佛才是合理的）
5、层次关系最担心 的是留下循环引用隐患（比如手工删除数据或者添加数据时，很容易导致第4条的情况发生，数据库层次断链或者重复等）
虽然有这些存在的问题，但并非不可解决，而从上面这些难点来说，层次关系往往会导致即使是一个相对简单的问题也需要很多条SQL查询才能得出答案，而且整个过程都相当慢。如果不使用层次关系（或者使用有限的层次关系），上述问题即都可以避免。如果必须使用多级的层次关系，增 加一些数据列或数据表来提供更多关于层次关系的信息，将有助于层次关系的解决方案变得简单一些。
从范式的标准来说，冗余是不对的，它会导致存储空间不必要的浪费，增加数据库内部管理工作的负担，但为了提高应用程序的执行效率，冗余反而是一种相当简明的解决方案，因此，数据库设计其实是一件多方妥协和折中的事。在数据库领域，通往同一个目标的道路往往有好多条，选择其中的任意一条，都意味着作出了这样或那样的妥协。做出什么样的妥协最有利这往往取决于数据库的具体使用情况：什么类型的查询发生的最为频繁？数据需不需要频繁修改？