今天大家的眼球一定是聚焦在了百度被黑一事上，用户的需求也是我们作为客观搜索引擎的工作之一，准备了一个小TIP~~
有道搜索教你如何在百度被黑后访问百度
在今天早晨百度被黑后，有道搜索的工程师一方面第一时间观察到有道搜索流量成倍上涨，但大多数用户都在搜索“百度被黑怎么回事？”“百度被黑怎么办？”“百度上不去怎么办？”，针对用户的查询和访问需求，有道搜索的工程师总结了通过修改host访问百度各个服务的办法，现在通过在有道上搜索“百度”就可以查询通过修改host文件访问百度的办法。
另外其实帖子中还给出了百度各个服务的ip，用户可以通过直接在浏览器中输入ip临时访问百度服务。
基于我们的判断，这次事情很有可能是REGISTER.COM的程序有漏洞，导致百度的DNS服务器和whois信息被强行修改。
最初是被改到了yahoo的DNS服务器，但yahoo反应比较快（或者百度公关做得好），给百度做了一个反向代理，所以在后来访问百度的时候，虽然DNS还是yahoo的，但好歹还能正常访问。之后黑客把DNS改到hostgator后，百度就没这么幸运了，直接被指向了127.0.0.1。
这件事情其实并不是外界所说的，百度的域名到期。要印证这个说法，很简单。国内知名的域名注册商万网的whois查询程序有一个缓存，具体缓存多长时间我不知道，但肯定不短。通过这个机制，我们可以查看百度出事前的whois缓存，baidu.com最后修改的时间是2008年12月3号，到期日期是2014年8月11号。而出事后最后修改的时间是2010年的1月11号（非CST）。
同时，REGISTER.COM为了避免事态扩大，还给baidu.com的域名加了几个状态，clientUpdateProhibited、clientDeleteProhibited、clientRenewProhibited，直白说这几个状态就是禁止更新这个域名、禁止删除这个域名、禁止这个域名续费。特别是clientUpdateProhibited，加上后这个域名别说DNS，连whois信息都不允许修改。对于通过漏洞来修改域名信息的，这个方法的确能起到一定的作用，至少黑客一时半刻是没法再改东西了。等REGISTER.COM自身的漏洞修复后，可以把这些状态再去掉。
原雅虎首席性能官、现任 Google Web 性能专家 Steve Souders，近期在 LA 隆重举行的 SpeedGeeks 会议上发表重要讲话：In Search of Speed（slides, video)，以下为学习笔记：
1. 以 iGoogle 为例，前端页面组件渲染的时间占了整个页面打开时间的 91%，前端优化的重要性不言而喻。
2. 前端优化十四条原则，是个人都知道，不必多说了。
3. 如果想要更快一点，可以参考新书 Even Faster Web Sites。
ACID性质是数据库理论中的奠基石，它定义了一个理论上可靠数据库所必须具备的四个性质：原子性，一致性，隔离性和持久性。虽然这四个性质都很重要，但是隔离性最为灵活。大部分数据库都提供了一些可供选择的隔离级别，且现在许多库都增加了附加层来创建颗粒度更细的隔离。隔离级别应用范围如此之广主要是因为放宽隔离约束往往会使得可扩展性和性能提高几个数量级。
串行一致性是可用的最古老最高的隔离级别之一，它之所以倍受青睐是因为其提供的简单编程模型，即每次仅能有一个事务对给定的资源进行操作，这就避免了很多潜在的资源问题。尽管如此，大部分应用程序（尤其是Web应用程序）都不采用这种级别非常高的隔离，因为从终端用户的角度来看这是不切实际的-任何一个拥有大量用户群的应用程序在访问共享资源时都将会有几分钟的延迟，而这会使得用户量迅速减少。弱一致性和最终一致性在大规模分布式数据源中，例如Web中，随处可见。好几个成功的大型Web应用（例如，eBay和Amazon）都显示出乐观的（optimistic）弱一致性要比传统悲观的（pessimistic）机制在扩展性方面好得多。本文将一窥八种不同的隔离级别。学会适当的放宽数据一致性的约束，你可以在自己的应用程序中使用这八种隔离级别来获得更好的性能和可扩展性。
并发控制的主要目标是为了确保事务被隔离且不会影响到其他事务。要达到高级别的隔离需以牺牲性能为代价。并发控制可以用悲观或者乐观的机制来实现。大部分关系型数据库都使用了悲观机制来实现写入优化。悲观机制采用了锁，通过使用锁它可以阻塞一些操作或者进行某些形式的冲突检测。当一个表格，页面或是行被修改后，悲观机制中的锁可以用来阻塞其他潜在的访问修改资源的事务。然而，乐观机制并不采用任何锁，它仅仅依赖于冲突检测来维护事务隔离。乐观机制采用的冲突检测可以允许所有的读操作，并在事务结束时检验其一致性。如果检测到冲突，那么事务会进行回滚或重做。大部分web服务器都是读入优化，因此使用了乐观机制。通过允许所有的读入操作，乐观机制既可以保证很高的读写吞吐量，也可以在资源不是一直改变的情况下保证数据的一致性。
下面列出的隔离级别是用来帮助Web开发人员更好的理解他们编程模型中放置的约束，帮助系统架构师和开发人员共同讨论如何在保持必要的数据完整性的同时选择最有效的隔离级别。它们按照最少隔离（未提交读）到最多隔离（串行化）的顺序列出。
