被一个java新人请教关于包的理解和使用，想起了自己当年刚学java时候的体会。

包-Pakage，概念理解和使用不难，但对于刚接触java的人而言，有点抽象和不解。

人人皆知，java中的包主要用于解决类的重名问题，类似于XML、C#，PHP等命名空间的概念，但与这些语言有所区别，它既有命名空间的逻辑分割又有物理上的实际目录划分。

一.使用

pakage mosang.tech //表明A.java 源文件中，所有类都位于mosang.tech包中
public class A{
public static void main(String [] args){
new B().showInfo();
}
}
class B{
public showInfo(){
System.out.print("this a method of how to using pakage");
}
}

假设我们已经将classpath设置为A.java所在的目录：

上述代码运行编译后会自动生成mosang/tech文件夹，同时得到一个B.class字节码文件位于tech文件夹中

javac -d . A.java

这时候，运行B.class文件需要带完整包名，哪怕我们在命令行窗口进入了mosang/tech目录。

java mosang.tech.B

这就是包的基本用法。

二.陷阱一:类名的使用

如果我们在命令行进入mosang/tech目录运行B.class，编译器会提示找不到文件，因为类的名字已是mosang.tech.B而不是B。

二.陷阱二:classpath路径与包名

JVM在加载带包名的路径时候，会先到classpath指定的目录，再从此按照包名结构去查找class文件。如果我们在命令行进入mosang/tech目录运行mosang.tech.B，同样会报错，因为此时的完整路径变成了classpath/mosang/tech/mosang/tech/B.class

三.陷阱三:包名与目录名

java中，包名必须经过程序中pakage语句来指定，而不是靠目录结构来指定的，是先有了包名，才需要相应的目录结构。我们来做个试验：

删除原生成的B.lass文件，在源代码A.java中，将pakage语句注释掉，重新编译得到B.class，将B.class拷贝到mosang/tech文件夹中，classpath目录下运行mosang.tech.B，会出错，因为此时的类名是B而不是mosang.tech.B。

所以，我们常常误以为把一个类文件放到了一个目录中，这个目录结构就自然成了包名，这就大错特错了。这点很多人包含有多年java经验的人都会犯错，绝大部分新手更是有这种自以为是理解。

以前解决过很多异步请求跨域的问题，自认为不会有什么难点，可今天调试一个项目API的时候遇到了之前没遇到的问题，弄了好久才解决，记录如下：

项目中涉及一个主域（以www.abc.com表示），子域（以s.abc.com表示），子域控制器s.abc.com/Action向主域www.abc.com/Reply发异步POST请求，www.abc.com/Reply发出Header参数“Access-Control-Allow-Origin:http://s.abc.com““Access-Control-Allow-Methods:POST”,按理说这应该没什么问题了，但问题来了：
1. 直接访问通过URL：www.abc.com/Reply访问，可以看到添加的“Access-Control-Allow-Origin“等响应头，也能正常传递JSON，如下：

Access-Control-Allow-Methods: POST
Access-Control-Allow-Origin: http://s.abc.com
Access-Control-Expose-Headers: Authorization
Content-Encoding: gzip
Content-Length: 138
Content-Type: text/json; charset=utf-8
Date: Wed, 27 Mar 2019 07:03:09 GMT
Server: Tengine
Vary: Accept-Encoding

2. 但通过子域的AJAX请求，死活就得不到添加的Headers参数，FF及Chrome均提示提示同源错误“原因：头缺少 ‘Access-Control-Allow-Origin’”，明明已经设置，就是没有传递，而之前做的一个接口几乎代码一样，但却能正常返回值，确实让人百思不得其解。
无奈之下，只能检查服务器设置，发现URLrewrite有如下规则：

<rule name="LowerCaseRule1" stopProcessing="true">
                    <match url="[A-Z]" ignoreCase="false" />
                    <action type="Redirect" url="{ToLower:{URL}}" />
</rule>

恍然大悟！

这个是SEO常设规则，用来规避因为URL大小写而带来搜索引擎识别为不同站点的问题，而项目很多CLASS命名都根据大小驼峰规则，Controls也是大小混写，这条重写规则强制将文件名小写返回，而AJAX请求则认为是两个不同请求，导致Headers参数无法正常接收。

取消此规则，问题解决。

近来研究一些开源的前端框架，重拾js，发现一个奇怪问题：
input如果设置为display：none，那么通过$(“#id”).val(“value”);方式赋值，无论是chrome、firefox还是IE都是传值方式失效。
改用$(“#id”).attr(“value”,”value”);却又可以
但是如果设置type=”hidden”，同样使用$(“#id”).val(“value”);方式赋值却又可以。

今天在兆维工业园IDC帮一位朋友迁移web服务器，他将之前拷贝的mysql数据库文件还原到新服务器中，结果有部分表在PHPmyadmin中没显示，而用Navicat 连接，能看到表，却打不开，提示”table doesn’t exist”。web应用显然不能正常运行。为何会这样，明明有表，却不能显示或是doesn’t exist？

我们知道，MySQL备份可直接拷贝datadir下的数据库文件，还原时将拷贝文件放到mysql下的data目录下就可以。但是今天却出现这种情况，是什么原因？

MySQL存储引擎分MyISAM与InnoDB，两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁，而MyISAM不支持。MyISAM类型的表强调的是性能，其执行速度比InnoDB类型快，但是不提供事务支持。

MyISAM类型的表，都对应data下的一个文件夹，文件夹名字就是表名，数据存储在该文件夹下三个”Table.frm”,”Table.MYD”,”Table.MYI”中;InnoDB的表，数据和结构是分别存储的，数据存储在ibdata1文件中（默认），而结构存储于.frm文件中。

我们常用的直接拷贝”Table.frm”,”Table.MYD”,”Table.MYI”方式来备份数据库，对MyISAM类型是有效的。但是对于InnoDB的表，还必须拷贝ibdata1文件。

之所以出现上面提到的问题，原因就是在于有部分是InnoDB表，却没有拷贝ibdata1文件。

出现错误后，直接拷贝ibdata1文件覆盖，还是问题依旧，这时只要删除log文件（ib_logfile*）就可以了。

这其实也是我多年前遇到的问题，当时备份数据库没注意，没有拷贝ibdata1，导致很多数据丢失，是得了教训的。

数据库备份一定要十分小心，不仅要测试，还要多种方式备份，最为稳妥的是导出sql文件，或用专业备份工具，多种形式备份。

转自：http://taobaofed.org/blog/2016/06/02/thing-about-taobao-homepage/

作者：淘宝前端团队阎王       原题《聊一聊淘宝首页和它背后的一套》

一、相关背景介绍

 淘宝首页是淘宝的门面，承载着几乎淘系所有业务的入口，流量很大，量级单位为亿。近几年无线端崛起，业务重点开始向无线终端偏移（目前不能叫偏移，基本以无线为主了），所以淘宝 PC 端首页的流量也有削减，不过即便如此，它的日均 PV 依然相当高。

淘宝首页一向是内部平台和技术的试验田，它一直在变化着。最新的框架和系统都会找淘宝首页试点，可以试想下，如果某一项需要推动的升级或者优化措施在淘宝首页已经上线，并且拿到了良好的数据和稳定性，其他业务还有什么理由不去尝试和更迭呢？同时，去年一年身在淘宝前端的技术架构组，自然而然也会主动去 push 一些实验性的内容到业务上。

淘系的站点页面包括首页、其他频道页和活动页等，这些页面并不都由淘宝前端一行一行的代码码出来，业务如此之多，这种玩法即便人数 double 也忙不过来。事实上，大多数页面都是依托内部的搭建平台——运营或者前端通过模块搭建的方式——构建的，而前端 focus 的重点在于搭建平台的建设自身以及模块的通用性和复用率的保障，当然，还有一些工程化的东西。

使用搭建平台搭建的页面，前端只需要考虑组成页面的原子模块的开发，整体的渲染由搭建平台提供的统一脚本全权负责。而在淘宝首页上，考虑到页面模块数量巨多，加上还有少量跨部门、跨团队的沟通，渲染模型略微不同。

二、淘宝首页的整体变迁

背景中提到，淘宝首页依托于内部搭建平台，它的变迁自然也是跟着搭建系统的变化而变化的。

1. PHP 下的淘宝首页

接手淘宝首页不久，便遇到了一年一度的改版，那时它还运行在 PHP 环境中。这里需要说明的是，淘宝首页的所有代码完全由前端掌控，前端不会直接跟数据库打交道，其数据来源分为两部分。

数据来源

一是 运营填写的数据。 采用前端挖坑的形式，预留坑位让运营获取填写数据，如（伪代码）：

  
<?php $info = Person('name:String:姓名,age:Number:年龄', '个人信息坑位填写');?>

<div>
<?php $info.forEach(index) { ?>
  Name: <?= info[index].name ?>, Age: <?= info[index].age ?>
<?php } ?>
</div>

  
<?php $info = Person('name:String:姓名,age:Number:年龄', '个人信息坑位填写');?>

<div>
<?php $info.forEach(index) { ?>
  Name: <?= info[index].name ?>, Age: <?= info[index].age ?>
<?php } ?>
</div>

今天犯了一个错误，记录一下

mysql_insert_id()返回值的类型为长整型 ，如果auto_increment是bigint类型则不适用这时应该用
last_insert_id()

企业级大型门户，需要高稳定性、高并发处理能力、高安全性的软硬件服务器支持，也需要程序设计性能优化，数据库优化、扩展性优化等诸多措施来保障。综合起来，大型门户的开发、运行、运营是个庞大的工程，缺了其中哪一部分都可能是致命的。

很早就想写些有关大型门户设计、架构、运营方面的系列专题，但苦于了解不深，写不出实质性的见解，经过一段时间学习、摸索和实践，总结出了一些经验，希望对新手和入行不深的同行有所帮助。

本系列将着重就以下几个方面做讲解，陆续发布一些个人体会：

1.  本地负载均衡和全局负载均衡的解决方案。

2.  缓存服务器的解决方案。

3. 单点登录、通行证等系列架构原理和解决方案。

4. 安全认证和事务处理。

5. 数据库优化。

6. 中间件的扩展应用。

……