测试相关，上线相关 经验总结odps sqltask（自己看的）

测试相关：

1.诡异的timeout（Solution is to make sure you don't keep-alive(default) the connection. Set it to close after each request/response）
http://stackoverflow.com/questions/22147457/caused-by-java-net-socketexception-unexpected-end-of-file-from-server

2.那个并发drop表的问题, 其中partition数字没有加回来。 rollback没有回滚表中分区的数量。

并发添加分区，对total partitions num 没有做线程处理，导致并发加了10个分区，分区数只有 <10

3.dateformate格式类，不支持并发，需要单独new出实例或作 sync
 * Date formats are not synchronized.
 * It is recommended to create separate format instances for each thread.
 * If multiple threads access a format concurrently, it must be synchronized
 * externally.
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7023180  

    public static Date parse(String date)  throws ParseException {
        System.out.println("date:" + date);
        return DATE_FORMAT.parse(date);
    }   

4.jdk getmethods 不保证顺序

5.nio 服务端回写客户端时，由于没有注册OP_WRITE， 遇到客户端网络问题等，无法发送数据时，服务端 while 空转耗内存

refer to   http://blog.sina.com.cn/s/blog_783ede0301013g5n.html

6.并发添加partition的坑 http://blog.csdn.net/g7n3f/article/details/50325505

7.hbase 表的TTL只有2天，而major compact 周期有7天， 如果大量的数据在2天前导入，但是由于没有做major compact，导致老数据虽然过期却没有清除，导致scan数据时 数据范围特大（含了本该清除的2天前的数据），导致特慢   http://blog.linezing.com/?p=2103

8.

在zk 恢复时，选出新leader后，新leader 和 follower 同步数据， 如ali 同步的上限数据是500M 加载到内存中有3G（不知道怎么搞的），于是在同步中就会 遇到网络IO超时（也遇到过磁盘IO超时）。造成TimeoutException。  导致重新去 选举leader，导致再次TimeoutException 的死循环。  参考本地 html  “阿_里zookeeper服务器不稳定的原因探究”

9.一个看似 很好的单例，此单例为了高效舍弃了方法上的sync，但由于没法在构造方法中传参。导致问题：如果代码走到下边红框时，另一个线程此时进来将拿到一个没有set值的xx实例。 解决办法 1.在用之前 判断下有值否。 2.加上volatile（不确定是否可以，但理论上会影响点效率）

10.为什么要使用SLF4J而不是Log4J

1. 在你的开源或内部类库中使用SLF4J会使得它独立于任何一个特定的日志实现，这意味着不需要管理多个日志配置或者多个日志类库，你的客户端会很感激这点。
2. SLF4J提供了基于占位符的日志方法，这通过去除检查isDebugEnabled(), isInfoEnabled()等等，提高了代码可读性。
3. 通过使用SLF4J的日志方法，你可以延迟构建日志信息（Srting）的开销，直到你真正需要，这对于内存和CPU都是高效的。

11.缓存机制引起老年代增长过快

lru缓存，在几次ygc后promote进入老年代后， 之后缓存强引用因为FIFO 被remove掉了，此时 缓存 成为游离态。 类似的游离态在这种运行模式下越来越多，会造成， S区和 O区 占用增长迅速，从而导致频繁CMS(OR full gc——CMS的backup serial old), O区 内存图上就是 锯齿状  (可参考内部文档——缓存机制引起老年代增长过快)

12.不使用 inotify 使用定时扫描日志造成的问题

收集方式：每隔15秒扫描access.log看看有没有新的内容。

1. log有90条日志
2. 日志收集扫描log，收集这90条日志
3. log有10条日志写入，总共100条
4. log 回滚，重命名成Access.log.1，新建Access.log不含日志
5. log有10条日志写入，总共10条
6. 日志收集器扫描log，收集到10条
7. 这样日志收集器就只能收集到100条日志，原来的第91-100条日志就不会被收集了，数据丢失。

13. jvm ygc 每次时间变长的问题（由于参数 使用 初始类加载器和定义类加载器不同导致）： 因为三种数据结构 StringTable，SymbolTable，SystemDictionary，是算做 gc root的， 不会被作为普通内存dump下来。但扫描它们时，会耗时。 jdk8已改进

14. ES 多个worker 去读一块某块磁盘上的数据，如果该磁盘损坏，则所有worker去访问该盘的线程都会hang住，影响比较恶劣。  ES应该发现某块读某块磁盘频繁hang住后，让之后其他去读该盘的线程去读 备用盘（ES一份数据可以存多个盘，配置决定）。

15.测试中尽量的暴露出 每个模块 每周的情况。

16.docker容器断电后，会多个一样的容器出来（阮生容器），导致网络问题，errno.104 is: Connection reset by peer[l连接被对端重置]

17.docker容器里磁盘只有几M，然而用df -h检测，却报出 空间不够。 docker的bug，如果有很多fd没有关闭，就会出现这样的问题

18.full gc调查http://ifeve.com/case-of-hashmap-in-concurrency/

19.太多的reduce 去拉map作业的临时数据， 而map集中在同一台机器，容易造成那台机器 磁盘util被打成100 ，从而hang住

TBD

上线相关：

1.灰度发布 按表 按project，db  ，按各种可以的类型划分 灰度上线

2.开关，各种回滚开关。  disaster 的灾备等等。  log 垃圾等回收机制应用

设计杂记（自己看得）：

我们所有的PK为什么是这样设计的
58597.testrecyc.table
无论table 还是 partitions 都是这样开头有个hash值
是为了 缓解单点过热
同时保证一个project中 的table 能连续的放在一起，读起来方便，partition也是同理

并发对一张表的操作，成为hive等的 诟病之一，开启锁之后 基本不可以用 加锁范围太大。
通过 meta table id 的打开， 每次创建的表 路径不同，路径带有tableid，再配合DDL的锁机制，
完美解决加锁问题。  15秒超时 自动释放，50个超过自动释放，永远不会死锁
锁分为 WD RD WS RS X
而tableid 的打开可以对 6wpartiton 的表瞬间删除 rename

————————————————

xx sqltask:

首先 worker 去preparse 决定 是sql task（是fu_xijob的 或者如 insert：fu_xi 加 ddltask） 还是 ddltask，还有一些资源情况

如果是纯ddltask 则交给 ddlserver处理 即 hiveserver，可以参考 类hive坑，或者自己pad上记录的ddlserver设计文档

如果是 sql task 则交给 scheduler，scheduler根据 各个executor机器的资源情况，将sql task分配出去

被分配的executor的去真正的parse 该sql task form hiveserver to get 物理执行计pot，再将pot提交给了fuxi去执行（中间有runtime这层再转换）

————————

xx task 状态保存（状态一般以 实体的方式 存在ots中， 有partitionid的打散热点）

sql task分为 fuxi task ,和 ddl task

先说 ddl task 提交后经过xxworker,preparse判断出这是 ddl task，这里是无状态的， 然后提交给 ddl server去处理，ddlserver在处理的时候会将写一个 ddltask到ots中 记录它的状态 以备 failover  （明天看看xiaodai文档）  同时可以参考 hive 是怎么跟踪ddl状态的

再说fuxi task提交后经过xxworker,preparse判断出这是 fuxi task 生成instance 信息,提交到 scheduler，同时写到ots中 实时记录它的信息

xx sql的 AST 物理plan

lot 逻辑树

pot 物理树

都是 protocolbuffer的形式存在。 发送给中间层 runtime去生成 具体的物理执行脚本