大型网站技术架构梳理

  • 前言
  • 概述
    • 演化历程
    • 架构模式
    • 核心要素
  • 架构
    • 高性能
    • 高可用
    • 伸缩性
    • 可扩展
    • 网站的安全架构

概述

  • 三个纬度：演化、模式、要素
  • 五个要素： 性能，可用性，伸缩性，扩展性，安全

演化历程

图例可参考 大型网站架构演化历程：

  1. 初始阶段的网站架构：一台服务器，上面同时拥有应用程序，数据库，文件，等所有资源。例如 LAMP 架构
  2. 应用和数据服务分离：三台服务器（硬件资源各不相同），分别是应用服务器，文件服务器和数据库服务器
  3. 使用缓存改善网站性能：分为两种，缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
  4. 使用应用服务器集群改善网站并发处理能力：通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
  5. 数据库读写分离：数据库采用主从热备，应用服务器在写数据时访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
  6. 使用反向代理和 CDN 加速网站响应：这两者基本原理都是缓存。反向代理部署在网站的中心机房，CDN 部署在网络提供商的机房
  7. 使用分布式文件系统和分布式数据库系统：数据库拆分的最后手段，更常用的是业务分库
  8. 使用 NoSQL 和搜索引擎：对可伸缩的分布式有更好的支持
  9. 业务拆分：将整个网站业务拆分成不同的应用，每个应用独立部署维护，应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
  10. 分布式服务：公共业务提取出来独立部署

架构演化-分布式服务

演化的价值观

  • 大型网站架构的核心价值是随网站所需灵活应对
  • 驱动大型网站技术发展的主要力量是网站的业务发展

误区

  • 一味追随大公司的解决方案
  • 为了技术而技术
  • 企图用技术解决所有问题

架构模式

模式的关键在于模式的可重复性

  • 分层：横向切分
  • 分割：纵向切分
  • 分布式：分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案：
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 分布式配置，分布式锁，分布式文件，等等
  • 集群：多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务
  • 缓存：将数据放距离计算最近的位置加快处理速度，改善性能第一手段，可以加快访问速度，减小后端负载压力。使用缓存 两个前提条件 ：1.数据访问热点不均衡；2.数据某时段内有效，不会很快过期
    • CDN
    • 反向代理
    • 本地缓存
    • 分布式缓存
  • 异步：旨在系统解耦。异步架构是典型的消费者生产者模式，特性如下：
    • 提高系统可用性
    • 加快网站访问速度
    • 消除并发访问高峰
  • 冗余：实现高可用。数据库的冷备份和热备份
  • 自动化：包括发布过程自动化，自动化代码管理，自动化测试，自动化安全检测，自动化部署，自动化监控，自动化报警，自动化失效转移，自动化失效恢复，自动化降级，自动化分配资源
  • 安全：密码，手机校验码，加密，验证码，过滤，风险控制

核心要素

架构是“最高层次的规划，难以改变的规定”。主要关注五个要素：

  • 性能
  • 可用性(Availability)
  • 伸缩性(Scalability)
  • 扩展性(Extensibility)
  • 安全性

架构

下面依次对这五个要素进行归纳

高性能

性能的测试指标主要有：

  • 响应时间：指应用执行一个操作需要的时间
  • 并发数：指系统能够同时处理请求的数目
  • 吞吐量：指单位时间内系统处理的请求数量
  • 性能计数器：描述服务器或者操作系统性能的一些数据指标

性能测试方法：

  • 性能测试
  • 负载测试
  • 压力测试
  • 稳定性测试

性能测试曲线

性能优化,根据网站分层架构，可以分为三大类：

  • Web 前端性能优化
    • 浏览器访问优化
      • 减少 http 请求
      • 使用浏览器缓存
      • 启用压缩
      • CSS 放在页面最上面，JavaScript 放在页面最下面
      • 减少 Cookie 传输
    • CDN 加速：本质是一个缓存，一般缓存静态资源
    • 反向代理
      • 保护网站安全
      • 通过配置缓存功能加速 Web 请求
      • 实现负载均衡
  • 应用服务器性能优化：主要手段有 缓存、集群、异步
    • 分布式缓存(网站性能优化第一定律：优化考虑使用缓存优化性能)
    • 异步操作(消息队列，削峰作用)
    • 使用集群
    • 代码优化
      • 多线程(设计为无状态，使用局部对象，并发访问资源使用锁)
      • 资源复用(单例，对象池)
      • 数据结构
      • 垃圾回收
  • 存储服务器性能优化
    • 机械硬盘 vs. 固态硬盘
    • B+ 树 vs. LSM 树
    • RAID vs. HDFS

高可用

  • 高可用的网站架构：目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问，主要手段数据和服务的冗余备份及失效转移
  • 高可用的应用：显著特点是应用的无状态性
    • 通过负载均衡进行无状态服务的失效转移
    • 应用服务器集群的 Session 管理
      • Session 复制
      • Session 绑定
      • 利用 Cookie 记录 Session
      • Session 服务器
  • 高可用的服务：无状态的服务，可使用类似负载均衡的失效转移策略，此外还有如下策略
    • 分级管理
    • 超时设置
    • 异步调用
    • 服务降级
    • 幂等性设计
  • 高可用的数据：主要手段是数据备份和失效转移机制
    • CAP 原理
      • 数据一致性(Consisitency)
      • 数据可用性(Availibility)
      • 分区耐受性(Partition Tolerance)
    • 数据备份
      • 冷备：缺点是不能保证数据最终一致和数据可用性
      • 热备：分为异步热备和同步热备
    • 失效转移：由以下三部分组成
      • 失效确认
      • 访问转移
      • 数据恢复
  • 高可用网站的软件质量保证
    • 网站发布
    • 自动化测试
    • 预发布验证
    • 代码控制
      • 主干开发、分支发布
      • 分支开发、主干发布
    • 自动化发布
    • 灰度发布
  • 网站运行监控
    • 监控数据采集
      • 用户行为日志采集（服务器端和客户端）
      • 服务器性能监控
      • 运行数据报告
    • 监控管理
      • 警报系统
      • 失效转移
      • 自动优雅降级

伸缩性

大型网站的“大型”是指：

  • 用户层面：大量用户及大量访问
  • 功能方面：功能庞杂，产品众多
  • 技术层面：网站需要部署大量的服务器

伸缩性的分为如下几个方面

  • 网站架构的伸缩性设计
    • 不同功能进行物理分离实现伸缩
      • 纵向分离(分层后分离)
      • 横向分离(业务分割后分离)
    • 单一功能通过集群规模实现伸缩
  • 应用服务器集群的伸缩性设计
    • HTTP 重定向负载均衡
    • DNS 域名解析负载均衡
    • 反向代理负载均衡(在 HTTP 协议层面，应用层负载均衡)
    • IP 负载均衡(在内核进程完成数据分发)
    • 数据链路层负载均衡(数据链路层修改 mac 地址，三角传输模式，LVS)
    • 负载均衡算法
      • 轮询(Round Robin, RR)
      • 加权轮询(Weighted Round Robin, WRR)
      • 随机(Random)
      • 最少链接(Least Connections)
      • 源地址散列(Source Hashing)
  • 分布式缓存集群的伸缩性设计
    • Memcached 分布式缓存集群的访问模型
      • Memcached 客户端（包括 API，路由算法，服务器列表，通信模块）
      • Memcached 服务器集群
    • Memcached 分布式缓存集群的伸缩性挑战
    • 分布式缓存的一致性 Hash 算法(一致性 Hash 环，虚拟层)
  • 数据存储服务集群的伸缩性设计
    • 关系数据库集群的伸缩性设计
    • NoSQL 数据库的伸缩性设计

可扩展

系统架构设计层面的“开闭原则”

  • 构建可扩展的网站架构
  • 利用分布式消息队列降低耦合性
    • 事件驱动架构(Event Driven Architecture)
    • 分布式消息队列
  • 利用分布式服务打造可复用的业务平台
    • Web Service 与企业级分布式服务
    • 大型网站分布式服务的特点
    • 分布式服务框架设计(Thrift, Dubbo)
  • 可扩展的数据结构(如 ColumnFamily 设计)
  • 利用开放平台建设网站生态圈

网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段，此外还包括 CSRF,Session 劫持等手段。

  • 攻击与防御
    • XSS 攻击：跨站点脚本攻击（Cross Site Script）
      • 反射型
      • 持久型
    • XSS 防御手段
      • 消毒(即对某些 html 危险字符转义)
      • HttpOnly
    • 注入攻击
      • SQL 注入攻击
      • OS 注入攻击
    • 注入防御
      • 避免被猜到数据库表结构信息
      • 消毒
      • 参数绑定
    • CSRF 攻击：跨站点请求伪造（Cross Site Request Forgery）
    • CSRF 防御：主要手段是识别请求者身份
      • 表单 Token
      • 验证码
      • Referer Check
    • 其他攻击和漏洞
      • Error Code
      • HTML 注释
      • 文件上传
      • 路径遍历
    • Web 应用防火墙（ModSecurity）
    • 网站安全漏洞扫描
  • 信息加密技术及密钥安全管理
    • 单向散列加密：不同输入长度的信息通过散列计算得到固定长度的输出
      • 不可逆，非明文
      • 可加盐(salt)增加安全性
      • 输入的微小变化会导致输出完全不同
    • 对称加密：加密和解密使用同一个密钥
    • 非对称加密
      • 信息传输：公钥加密，私钥解密
      • 数字签名：私钥加密，公钥解密
    • 密钥安全管理：信息安全传输是靠密钥保证的，改善手段有：
      • 把密钥和算法放在一个独立的服务器上
      • 将加解密算法放在应用系统中，密钥放在独立服务器
  • 信息过滤与反垃圾
    • 文本匹配
    • 分类算法
    • 黑名单
网站架构

HEAD DETACHED push origin失败

###HEAD DETACHED push origin失败问题

原文：http://www.cnblogs.com/iwangzc/p/4073117.html

先说HEAD

HEAD是一个头指针，通常情况下指向不同的分支，每个分支对应一个commit（准确的说，每个分支对应多个commit，但是只有一个顶层的commit，而commit之间是简单的线性关系。）

git checkout 其实是修改HEAD文件的内容，让它指向不同的分支。

下面是一个一般的情况：

HEAD (refers to branch 'master')
           |
           v
   a---b---c  branch 'master' (refers to commit 'c')

既然checkout是修改HEAD，所以可以出现下面的情况：

HEAD (refers to commit 'b')
     |
     v
 a---b---c  branch 'master' (refers to commit 'c')

HEAD指向b，用git branch看看有几个分支：

×HEAD detached from b
master

发现有两个分支，可是我们没有创建除了master以外的任何分支啊～

可以把HEAD detached from b理解为一个临时的分支，并且这时候HEAD指针是游离普通分支之的。

在这个临时分支上可以进行git的一切操作：add commit 等等，像这样：

HEAD (refers to commit 'f')
                  |
                  v
             e---f
            /
       a---b---c  branch 'master' (refers to commit 'c')

假如远程库中有一个master分支，一个用来开发的develop分支，这时候如果我们要向远程库推送，会发现无法推送。

因为HEAD不知道要把内容推送到哪个远程分支上去。

那么问题来了，怎么把修改的内容提交到远程库呢？

由于本地没有develop分支，所以需要先这样：

git fetch origin develop:develop

在本地创建一个develop分支，并且把它和远程develop关联起来。现在再看看本地有哪些分支：

git branch

×develop
master

刚才的HEAD detached from b分支消失了！ 在这个分支下修改的内容也不见了！

没关系，进行下一步。

git reflog show HEAD@{now} -10

这个命令会把HEAD指针所有的动作显示出来。从中可以清楚的看到，在指针中提交对应的commit id

找到需要恢复的commit ，记下前面的commit id

git branch temp efa64f5

新建一个名字叫temp的分支，用这个分支代替之前的临时分支并且拥有想要恢复的commit，现在切换到temp下会发现一切都回来了

但是还是不能推送啊。原因是temp是我们本地的分支，远程库中并没有这个分支。

git checkout develop

切换到从远程库拉取到的develop分支

git merge temp

将temp分支合并到develop分支上，有冲突就解决冲突。

最后：

git push origin develop

CAP理论

CAP理论

CAP理论的定义很简单，CAP三个字母分别代表了分布式系统中三个相互矛盾的属性：

Consistency (一致性)：CAP理论中的副本一致性特指强一致性（1.3.4 ）

Availiablity(可用性)：指系统在出现异常时已经可以提供服务；

Toleranceto the partition of network (分区容忍)：指系统可以对网络分区，这种异常情况进行容错处理。

java foreach实现方式

java中有三种遍历集合的方式:

System.out.println("----------method1-----------");
for (int i = 0; i < list.size(); i++) {
    System.out.println(list.get(i));
}
System.out.println("----------method2-----------");
for (String s : list) {
    System.out.println(s);
    //ConcurrentModificationException,其实JAVA中的增强for循环底层是通过迭代器模式来实现的。
    //list.remove(s);
}
System.out.println("----------method3-----------");
Iterator iterator=list.iterator();
while(iterator.hasNext()){
    String s= (String) iterator.next();
    if(s.equals("value1")){
        //安全删除
        iterator.remove();
    }else{
        System.out.println(s);    
    }
}

运行方法2的时候，如果调用list.foreach方法，会报ConcurrentModificationException异常，
对以下代码反编译：

for (Integer i : list) { 
    System.out.println(i); 
}

编译后的结果：

Integer i; 
for(Iterator iterator = list.iterator(); iterator.hasNext(); System.out.println(i)){ 
    i = (Integer)iterator.next();         
}

可以看到foreach的实现其实是用了迭代器,利用迭代器在集合遍历是删除会报ConcurrentModificationException异常,所以需要使用迭代器自带的删除方法操作，如果遍历时候需要删除操作，使用第三种（method3）遍历方式。

Iterator是工作在一个独立的线程中，并且拥有一个 mutex 锁。 Iterator被创建之后会建立一个指向原来对象的单链索引表，当原来的对象数量发生变化时，这个索引表的内容不会同步改变，所以当索引指针往后移动的时候就找不到要迭代的对象，所以按照 fail-fast 原则 Iterator 会马上抛出java.util.ConcurrentModificationException异常。

所以 Iterator 在工作的时候是不允许被迭代的对象被改变的。但你可以使用 Iterator 本身的方法 remove() 来删除对象，Iterator.remove() 方法会在删除当前迭代对象的同时维护索引的一致性。

Java问题整理

java基础

Arrays.sort实现原理和Collection实现原理
foreach和while的区别(编译之后)
线程池的种类，区别和使用场景
分析线程池的实现原理和线程的调度过程
线程池如何调优
线程池的最大线程数目根据什么确定
动态代理的几种方式
HashMap的并发问题
了解LinkedHashMap的应用吗
反射的原理，反射创建类实例的三种方式是什么？
cloneable接口实现原理，浅拷贝or深拷贝
Java NIO使用
hashtable和hashmap的区别及实现原理，hashmap会问到数组索引，hash碰撞怎么解决
arraylist和linkedlist区别及实现原理
反射中，Class.forName和ClassLoader区别
String，Stringbuffer，StringBuilder的区别？
有没有可能2个不相等的对象有相同的hashcode
简述NIO的最佳实践，比如netty，mina
TreeMap的实现原理

JVM相关

类的实例化顺序，比如父类静态数据，构造函数，字段，子类静态数据，构造函数，字段，他们的执行顺序
JVM内存分代
Java 8的内存分代改进
JVM垃圾回收机制，何时触发MinorGC等操作
jvm中一次完整的GC流程（从ygc到fgc）是怎样的，重点讲讲对象如何晋升到老年代，几种主要的jvm参数等
你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms，g1
新生代和老生代的内存回收策略
Eden和Survivor的比例分配等
深入分析了Classloader，双亲委派机制
JVM的编译优化
对Java内存模型的理解，以及其在并发中的应用
指令重排序，内存栅栏等
OOM错误，stackoverflow错误，permgen space错误
JVM常用参数
tomcat结构，类加载器流程
volatile的语义，它修饰的变量一定线程安全吗
g1和cms区别,吞吐量优先和响应优先的垃圾收集器选择
说一说你对环境变量classpath的理解？如果一个类不在classpath下，为什么会抛出ClassNotFoundException异常，如果在不改变这个类路径的前期下，怎样才能正确加载这个类？
说一下强引用、软引用、弱引用、虚引用以及他们之间和gc的关系

JUC/并发相关

ThreadLocal用过么，原理是什么，用的时候要注意什么
Synchronized和Lock的区别
synchronized 的原理，什么是自旋锁，偏向锁，轻量级锁，什么叫可重入锁，什么叫公平锁和非公平锁
concurrenthashmap具体实现及其原理，jdk8下的改版
用过哪些原子类，他们的参数以及原理是什么
cas是什么，他会产生什么问题（ABA问题的解决，如加入修改次数、版本号）
如果让你实现一个并发安全的链表，你会怎么做
简述ConcurrentLinkedQueue和LinkedBlockingQueue的用处和不同之处
简述AQS的实现原理
countdowlatch和cyclicbarrier的用法，以及相互之间的差别?
concurrent包中使用过哪些类？分别说说使用在什么场景？为什么要使用？
LockSupport工具
Condition接口及其实现原理
Fork/Join框架的理解
jdk8的parallelStream的理解
分段锁的原理,锁力度减小的思考

Spring

Spring AOP与IOC的实现原理
Spring的beanFactory和factoryBean的区别
为什么CGlib方式可以对接口实现代理？
RMI与代理模式
Spring的事务隔离级别，实现原理
对Spring的理解，非单例注入的原理？它的生命周期？循环注入的原理，aop的实现原理，说说aop中的几个术语，它们是怎么相互工作的？
Mybatis的底层实现原理
MVC框架原理，他们都是怎么做url路由的
spring boot特性，优势，适用场景等
quartz和timer对比
spring的controller是单例还是多例，怎么保证并发的安全

分布式相关

Dubbo的底层实现原理和机制
描述一个服务从发布到被消费的详细过程
分布式系统怎么做服务治理
接口的幂等性的概念
消息中间件如何解决消息丢失问题
Dubbo的服务请求失败怎么处理
重连机制会不会造成错误
对分布式事务的理解
如何实现负载均衡，有哪些算法可以实现？
Zookeeper的用途，选举的原理是什么？
数据的垂直拆分水平拆分。
zookeeper原理和适用场景
zookeeper watch机制
redis/zk节点宕机如何处理
分布式集群下如何做到唯一序列号
如何做一个分布式锁
用过哪些MQ，怎么用的，和其他mq比较有什么优缺点，MQ的连接是线程安全的吗
MQ系统的数据如何保证不丢失
列举出你能想到的数据库分库分表策略；分库分表后，如何解决全表查询的问题。

算法&数据结构&设计模式

海量url去重类问题（布隆过滤器）
数组和链表数据结构描述，各自的时间复杂度
二叉树遍历
快速排序
BTree相关的操作
在工作中遇到过哪些设计模式，是如何应用的
hash算法的有哪几种，优缺点，使用场景
什么是一致性hash
paxos算法
在装饰器模式和代理模式之间，你如何抉择，请结合自身实际情况聊聊
代码重构的步骤和原因，如果理解重构到模式？

数据库

MySQL InnoDB存储的文件结构
索引树是如何维护的？
数据库自增主键可能的问题
MySQL的几种优化
mysql索引为什么使用B+树
数据库锁表的相关处理
索引失效场景
高并发下如何做到安全的修改同一行数据，乐观锁和悲观锁是什么，INNODB的行级锁有哪2种，解释其含义
数据库会死锁吗，举一个死锁的例子，mysql怎么解决死锁

Redis&缓存相关

Redis的并发竞争问题如何解决了解Redis事务的CAS操作吗
缓存机器增删如何对系统影响最小，一致性哈希的实现
Redis持久化的几种方式，优缺点是什么，怎么实现的
Redis的缓存失效策略
缓存穿透的解决办法
redis集群，高可用，原理
mySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据
用Redis和任意语言实现一段恶意登录保护的代码，限制1小时内每用户Id最多只能登录5次
redis的数据淘汰策略

网络相关

http1.0和http1.1有什么区别
TCP/IP协议
TCP三次握手和四次挥手的流程，为什么断开连接要4次,如果握手只有两次，会出现什么
TIME_WAIT和CLOSE_WAIT的区别
说说你知道的几种HTTP响应码
当你用浏览器打开一个链接的时候，计算机做了哪些工作步骤
TCP/IP如何保证可靠性，数据包有哪些数据组成
长连接与短连接
Http请求get和post的区别以及数据包格式
简述tcp建立连接3次握手，和断开连接4次握手的过程；关闭连接时，出现TIMEWAIT过多是由什么原因引起，是出现在主动断开方还是被动断开方。

其他

maven解决依赖冲突,快照版和发行版的区别
Linux下IO模型有几种，各自的含义是什么
实际场景问题，海量登录日志如何排序和处理SQL操作，主要是索引和聚合函数的应用
实际场景问题解决，典型的TOP K问题
线上bug处理流程
如何从线上日志发现问题
linux利用哪些命令，查找哪里出了问题（例如io密集任务，cpu过度）
场景问题，有一个第三方接口，有很多个线程去调用获取数据，现在规定每秒钟最多有10个线程同时调用它，如何做到。
用三个线程按顺序循环打印abc三个字母，比如abcabcabc。
常见的缓存策略有哪些，你们项目中用到了什么缓存系统，如何设计的
设计一个秒杀系统，30分钟没付款就自动关闭交易（并发会很高）
请列出你所了解的性能测试工具
后台系统怎么防止请求重复提交？
有多个相同的接口，我想客户端同时请求，然后只需要在第一个请求返回结果的时候返回给客户端

Java的初始化块、静态初始化块、构造函数的执行顺序及用途探究

Java的初始化块、静态初始化块、构造函数的执行顺序及用途探究

　　Java与C++有一个不同之处在于，Java不但有构造函数，还有一个”初始化块“(Initialization Block)的概念。下面探究一下它的执行顺序与可能的用途。
执行顺序

　　首先定义A, B, C三个类用作测试，其中B继承了A，C又继承了B，并分别给它们加上静态初始化块、非静态初始化块和构造函数，里面都是一句简单的输出。

　　主类Main里面也如法炮制。

class A {
    static {
        System.out.println("Static init A.");
    }

    {
        System.out.println("Instance init A.");
    }

    A() {
        System.out.println("Constructor A.");
    }
}

class B extends A {
    static {
        System.out.println("Static init B.");
    }

    {
        System.out.println("Instance init B.");
    }

    B() {
        System.out.println("Constructor B.");
    }
}

class C extends B {

    static {
        System.out.println("Static init C.");
    }

    {
        System.out.println("Instance init C.");
    }

    C() {
        System.out.println("Constructor C.");
    }
}

public class Main {

    static {
        System.out.println("Static init Main.");
    }

    {
        System.out.println("Instance init Main.");
    }

    public Main() {
        System.out.println("Constructor Main.");
    }

    public static void main(String[] args) {
        C c = new C();
        //B b = new B();
    }
}

测试代码

　　当然这里不使用内部类，因为内部类不能使用静态的定义；而用静态内部类就失去了一般性。

　　那么可以看到，当程序进入了main函数，并创建了一个类C的对象之后，输出是这样子的：

Static init Main.
Static init A.
Static init B.
Static init C.
Instance init A.
Constructor A.
Instance init B.
Constructor B.
Instance init C.
Constructor C.

　　观察上面的输出，可以观察到两个有趣的现象：

Main类是肯定没有被实例化过的，但是由于执行main入口函数用到了Main类，于是static初始化块也被执行了；
所有的静态初始化块都优先执行，其次才是非静态的初始化块和构造函数，它们的执行顺序是：
    父类的静态初始化块
    子类的静态初始化块
    父类的初始化块
    父类的构造函数
    子类的初始化块
    子类的构造函数

　　那么如果有多个实例化对象，又会不会发生变化呢？于是在第一个C类的对象后面，再实例化一个B类的对象，再观察输出：

Static init Main.
Static init A.
Static init B.
Static init C.
Instance init A.
Constructor A.
Instance init B.
Constructor B.
Instance init C.
Constructor C.
Instance init A.
Constructor A.
Instance init B.
Constructor B.

　　可以发现这输出跟前面的基本长得一样对吧？只是在后面多了4行，那是新的B类对象实例化时产生的信息，同样也是父类A的初始化块和构造函数先执行，再轮到子类B的初始化块和构造函数执行；同时还发现，静态初始化块的输出只出现了一次，也就是说每个类的静态初始化块都只在第一次实例化该类对象时执行一次。

　　无论如何，初始化块和构造函数总在一起执行是件有趣的事情，让我们反编译一下看看吧！

　　查看生成目录发现已经生成了4个.class文件，分别是A.class, B.class, C.class, Main.class，先看看Main.class的结构（这里重新注释了new B）：

1 javap -c Main

Compiled from "Main.java"
public class Main {
  public Main();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       7: ldc           #3                  // String Instance init Main.
       9: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      12: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
      15: ldc           #5                  // String Constructor Main.
      17: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      20: return

  public static void main(java.lang.String[]);
    Code:
       0: new           #6                  // class C
       3: dup
       4: invokespecial #7                  // Method C."<init>":()V
       7: astore_1
       8: return

  static {};
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #8                  // String Static init Main.
       5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
}

Main.class的反编译结果

　　可以看到整个Main类被分成三个部分，static {}部分很显然，就是我们的static初始化块，在里面调用了println并输出了String“Static init Main.”；而main入口函数也很清晰，首先新实例化了一个类C的对象，然后调用了类C的构造函数，最后返回；而上面public Main();的部分就很有意思了，这是类Main的构造函数，但我们看到里面调用了两次println，分别输出了String“Instance init Main.”和String“Constructor Main.”。难道初始化块和构造函数被合并到一起了？

　　我们再看看C类的反编译结果吧：

1 javap -c C

Compiled from "Main.java"
class C extends B {
  C();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method B."<init>":()V
       4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       7: ldc           #3                  // String Instance init C.
       9: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      12: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
      15: ldc           #5                  // String Constructor C.
      17: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      20: return

  static {};
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #6                  // String Static init C.
       5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
}

C.class的反编译结果

　　静态初始化块仍然单独分出一部分，输出了我们的调试语句。而另一部分，仍然还是类C的构造函数C();，可以看到它先调用了父类B的构造函数，接着输出了我们初始化块中的语句，然后才输出我们写在构造函数中的语句，最后返回。多次试验也都是如此。于是我们能够推断：初始化块的代码是被加入到子类构造函数的前面，父类初始化的后面了。

可能的用途：

　　既然执行顺序和大概原理都摸清了，那么就要探讨一下初始化块的可能的用途。
　静态初始化块

1.用于初始化静态成员变量

　　比如给类C增加一个静态成员变量sub，我们在static块里面给它赋值为5：
class C extends B {

    static public int a;

    static {
        a = 5;
        System.out.println("Static init C.");
    }

......

}

　　main函数里输出这个静态变量C.sub：

public static void main(String[] args) {
    System.out.println("Value of C.sub: " + C.sub);
}

　　则输出结果：

Static init Main.
Static init A.
Static init B.
Static init C.
Value of C.sub: 5

　　符合类被第一次加载时执行静态初始化块的结论，且C.sub被正确赋值为5并输出了出来。

　　但是乍一看似乎没有什么用，因为静态成员变量在定义时就可以顺便赋值了。因此在赋值方面有点鸡肋。

2. 执行初始化代码

　　比如可以记录第一次访问类的日志，或方便单例模式的初始化等。对于单例模式，可以先用static块初始化一些可能还被其他类访问的基础参数，等到真正需要加载大量资源的时候(getInstance)再构造单体，在构造函数中加载资源。

非静态初始化块

　　这个就没什么好说的了，基本跟构造函数一个功能，但比构造函数先执行。最常见的用法应该还是代码复用，即多个重载构造函数都有若干段相同的代码，那么可以把这些重复的代码拉出来放到初始化块中，但仍然要注意它的执行顺序，对顺序有严格要求的初始化代码就不适合使用了。

总结： 

静态初始化块的优先级最高，也就是最先执行，并且仅在类第一次被加载时执行；
非静态初始化块和构造函数后执行，并且在每次生成对象时执行一次；
非静态初始化块的代码会在类构造函数之前执行。因此若要使用，应当养成把初始化块写在构造函数之前的习惯，便于调试；
静态初始化块既可以用于初始化静态成员变量，也可以执行初始化代码；
非静态初始化块可以针对多个重载构造函数进行代码复用。

intellij idea创建maven项目更新中央仓库archetype元数据太慢

在创建maven项目在第二个向导界面的Properties中添加一个参数archetypeCatalog=internal，不加这个参数，在maven生成骨架的时候将会非常慢，有时候会直接卡住。archetypeCatalog表示插件使用的archetype元数据，不加这个参数时默认为remote，local，即中央仓库archetype元数据，由于中央仓库的archetype太多了，所以导致很慢，指定internal来表示仅使用内部元数据。

HTTP幂等性

原文：http://www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.html

基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式。无论是在大型互联网应用还是企业级架构中，我们都见到了越来越多的SOA或RESTful的Web API。为什么Web API如此流行呢？我认为很大程度上应归功于简单有效的HTTP协议。HTTP协议是一种分布式的面向资源的网络应用层协议，无论是服务器端提供Web服务，还是客户端消费Web服务都非常简单。再加上浏览器、Javascript、AJAX、JSON以及HTML5等技术和工具的发展，互联网应用架构设计表现出了从传统的PHP、JSP、ASP.NET等服务器端动态网页向Web API + RIA（富互联网应用）过渡的趋势。Web API专注于提供业务服务，RIA专注于用户界面和交互设计，从此两个领域的分工更加明晰。在这种趋势下，Web API设计将成为服务器端程序员的必修课。然而，正如简单的Java语言并不意味着高质量的Java程序，简单的HTTP协议也不意味着高质量的Web API。要想设计出高质量的Web API，还需要深入理解分布式系统及HTTP协议的特性。
幂等性定义

本文所要探讨的正是HTTP协议涉及到的一种重要性质：幂等性(Idempotence)。在HTTP/1.1规范中幂等性的定义是：

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性属于语义范畴，正如编译器只能帮助检查语法错误一样，HTTP规范也没有办法通过消息格式等语法手段来定义它，这可能是它不太受到重视的原因之一。但实际上，幂等性是分布式系统设计中十分重要的概念，而HTTP的分布式本质也决定了它在HTTP中具有重要地位。
分布式事务 vs 幂等设计

为什么需要幂等性呢？我们先从一个例子说起，假设有一个从账户取钱的远程API（可以是HTTP的，也可以不是），我们暂时用类函数的方式记为：

bool withdraw(account_id, amount)

withdraw的语义是从account_id对应的账户中扣除amount数额的钱；如果扣除成功则返回true，账户余额减少amount；如果扣除失败则返回false，账户余额不变。值得注意的是：和本地环境相比，我们不能轻易假设分布式环境的可靠性。一种典型的情况是withdraw请求已经被服务器端正确处理，但服务器端的返回结果由于网络等原因被掉丢了，导致客户端无法得知处理结果。如果是在网页上，一些不恰当的设计可能会使用户认为上一次操作失败了，然后刷新页面，这就导致了withdraw被调用两次，账户也被多扣了一次钱。如图1所示：

non-idempotent

图1

这个问题的解决方案一是采用分布式事务，通过引入支持分布式事务的中间件来保证withdraw功能的事务性。分布式事务的优点是对于调用者很简单，复杂性都交给了中间件来管理。缺点则是一方面架构太重量级，容易被绑在特定的中间件上，不利于异构系统的集成；另一方面分布式事务虽然能保证事务的ACID性质，而但却无法提供性能和可用性的保证。

另一种更轻量级的解决方案是幂等设计。我们可以通过一些技巧把withdraw变成幂等的，比如：

int create_ticket()
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket的语义是获取一个服务器端生成的唯一的处理号ticket_id，它将用于标识后续的操作。idempotent_withdraw和withdraw的区别在于关联了一个ticket_id，一个ticket_id表示的操作至多只会被处理一次，每次调用都将返回第一次调用时的处理结果。这样，idempotent_withdraw就符合幂等性了，客户端就可以放心地多次调用。

基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤：1.调用create_ticket()获取ticket_id；2.调用idempotent_withdraw(ticket_id, account_id, amount)。虽然create_ticket不是幂等的，但在这种设计下，它对系统状态的影响可以忽略，加上idempotent_withdraw是幂等的，所以任何一步由于网络等原因失败或超时，客户端都可以重试，直到获得结果。如图2所示：

idempotent

图2

和分布式事务相比，幂等设计的优势在于它的轻量级，容易适应异构环境，以及性能和可用性方面。在某些性能要求比较高的应用，幂等设计往往是唯一的选择。
HTTP的幂等性

HTTP协议本身是一种面向资源的应用层协议，但对HTTP协议的使用实际上存在着两种不同的方式：一种是RESTful的，它把HTTP当成应用层协议，比较忠实地遵守了HTTP协议的各种规定；另一种是SOA的，它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立了自己的应用层协议。本文所讨论的HTTP幂等性主要针对RESTful风格的，不过正如上一节所看到的那样，幂等性并不属于特定的协议，它是分布式系统的一种特性；所以，不论是SOA还是RESTful的Web API设计都应该考虑幂等性。下面将介绍HTTP GET、DELETE、PUT、POST四种主要方法的语义和幂等性。

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性。比如：DELETE http://www.forum.com/article/4231，调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子；因此，调用者可以多次调用或刷新页面而不必担心引起错误。

比较容易混淆的是HTTP POST和PUT。POST和PUT的区别容易被简单地误认为“POST表示创建资源，PUT表示更新资源”；而实际上，二者均可用于创建资源，更为本质的差别是在幂等性方面。在HTTP规范中对POST和PUT是这样定义的：

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line ...... If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

POST所对应的URI并非创建的资源本身，而是资源的接收者。比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。比如：PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。

在介绍了几种操作的语义和幂等性之后，我们来看看如何通过Web API的形式实现前面所提到的取款功能。很简单，用POST /tickets来实现create_ticket；用PUT /accounts/account_id/ticket_id&amount=xxx来实现idempotent_withdraw。值得注意的是严格来讲amount参数不应该作为URI的一部分，真正的URI应该是/accounts/account_id/ticket_id，而amount应该放在请求的body中。这种模式可以应用于很多场合，比如：论坛网站中防止意外的重复发帖。
总结

上面简单介绍了幂等性的概念，用幂等设计取代分布式事务的方法，以及HTTP主要方法的语义和幂等性特征。其实，如果要追根溯源，幂等性是数学中的一个概念，表达的是N次变换与1次变换的结果相同

学习整理

安装配置RabbitMq

安装配置RabbitMq

Rabbit MQ 是建立在强大的Erlang OTP平台上，因此安装Rabbit MQ的前提是安装Erlang。通过下面两个连接下载安装3.2.3 版本：

下载并安装

Eralng OTP For Windows_64http://erlang.org/download/otp_win64_19.2.exe

Rabbit MQ Server Windowshttp://www.rabbitmq.com/releases/rabbitmq-server/v3.6.6/rabbitmq-server-3.6.6.exe

默认安装的Rabbit MQ 监听端口是5672

激活Rabbit MQ’s Management Plugin

使用Rabbit MQ 管理插件，可以更好的可视化方式查看Rabbit MQ 服务器实例的状态，你可以在命令行中使用下面的命令激活：

“C:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin\rabbitmq-plugins.bat” enable rabbitmq_management

要重启服务才能生效，可以执行

net stop RabbitMQ && net start RabbitMQ

下面我们使用rabbitmqctl控制台命令（位于C:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>）来创建用户，密码，绑定权限等。

Microsoft Windows [版本 6.3.9600]
(c) 2013 Microsoft Corporation。保留所有权利。

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin 的目录

2014/11/01  15:04    <DIR>          .
2014/11/01  15:04    <DIR>          ..
2014/01/23  22:57               817 rabbitmq-echopid.bat
2014/01/23  22:57             1,900 rabbitmq-plugins.bat
2014/01/23  22:57             4,356 rabbitmq-server.bat
2014/01/23  22:57             7,123 rabbitmq-service.bat
2014/01/23  22:57             1,621 rabbitmqctl.bat
           5 个文件         15,817 字节
           2 个目录 96,078,618,624 可用字节

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.bat list_users
Listing users ...
guest   [administrator]
...done.

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.bat list_vhosts
Listing vhosts ...
/
...done.

//添加用户名密码
c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.bat add_user birkhoff 123456
Creating user "geffzhang" ...
...done.

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.bat list_users
Listing users ...
geffzhang       []
guest   [administrator]
...done.

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.bat set_user_tags birkhoff administrator
Setting tags for user "geffzhang" to [administrator] ...
...done.

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.bat set_permissions -p /  birkhoff ".*" ".*" ".*"
Setting permissions for user "geffzhang" in vhost "/" ...
...done.

c:\Program Files (x86)\RabbitMQ Server\rabbitmq_server-3.2.3\sbin>rabbitmqctl.ba
t list_users
Listing users ...
geffzhang       [administrator]
guest   [administrator]
...done.

使用浏览器打开http://localhost:15672 访问Rabbit Mq的管理控制台，使用刚才创建的账号登陆系统：

工具

监控服务器Java异常脚本 

tail -f /log/app/app.log|grep -P "(^\tat |Exception|^Caused by: |\t... \d+ more)"

tail -f filename 可以加多个 -f fileName实现同时监控多个

tail -f /log/app/app.log -f /log/app/asyn.log|grep -P "(^\tat |Exception|^Caused by: |\t... \d+ more)"

如果log日志前缀一样也可以这样写

tail -f /log/app/app_*.log|grep -P "(^\tat |Exception|^Caused by: |\t... \d+ more)"

重定向到文件

tail -f /log/app/app.log|grep -P "(^\tat |Exception|^Caused by: |\t... \d+ more)">>birkhoff/error.log
脚本
|