在多线程并发编程中Synchronized一直是元老级角色，很多人都会称呼它为重量级锁，但是随着Java SE1.6对Synchronized进行了各种优化之后，有些情况下它并不那么重了，SE1.6中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。

最近了解下基于 Token 的身份验证，跟大伙分享下。很多大型网站也都在用，比如 Facebook，Twitter，Google+，Github 等等，比起传统的身份验证方法，Token 扩展性更强，也更安全点，非常适合用在 Web 应用或者移动应用上。Token 的中文有人翻译成 “令牌”，我觉得挺好，意思就是，你拿着这个令牌，才能过一些关卡。

一、传统身份验证的方法

HTTP 是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。
解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

1. CAS简介

1.1. What is CAS？

CAS（Central Authentication Service） 是 Yale大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于Web SSO）。
CAS开始于2001年， 并在 2004年 12月正式成为JA-SIG的一个项目。

1.2. 主要特性

1、 开源的、多协议的SSO解决方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0等。
2、 支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates等；
3、 安全策略：使用票据（Ticket）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）；
5、 提供高可用性：通过把认证过的状态数据存储在TicketRegistry组件中，这些组件有很多支持分布式环境的实现，如：BerkleyDB、Default 、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry等；
6、 支持多种客户端： Java、 .Net、 PHP、 Perl、 Apache, uPortal等。

1、三层是三层，MVC是MVC，它们毫无关系的。
1） 三层结构
三层是从整个应用程序架构的角度来分的三层（如果程序需要，还可以分多层）。三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题，为了使程序员更加专注的处理某阶段的业务逻辑。比如将数据库操作代码封装到一层中，提供一些方法根据参数直接返回用户需要的相应数据，这样在处理具体的业务逻辑的时候，就不用关心数据的存储问题了。
2）MVC
MVC是在应用程序（BS结构）的视图层划分出来的不同功能的几个模块。
MVC主要是为了解决应用程序用户界面的样式替换问题，把展示数据的 HTML 页面尽可能的和业务代码分离。MVC把纯净的界面展示逻辑（用户界面）独立到一些文件中（Views），把一些和用户交互的程序逻辑（Controller）单独放在一些文件中，在 Views 和 Controller 中传递数据使用一些专门封装数据的实体对象，这些对象，统称为Models。
3）小结
所以说MVC和三层毫无关系，是因为它们二者使用范围不同：三层可以应用于任何语言、任何技术的应用程序；而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突，可以同时存在，也可根据情况使用其中一种。

一、MVC

MVC模式的意思是，软件可以分成三个部分。

视图（View）：用户界面。
控制器（Controller）：业务逻辑
模型（Model）：数据保存

 QPS（Query per second） 每秒查询量
 TPS（Transaction per second）每秒事务量
这是Mysql的两个重要性能指标，需要经常查看，和Mysql基准测试的结果对比，如果值过高，就要尽快处理了

一、计算方法

1、QPS

QPS = Queries / Seconds
Queries 是系统状态值--总查询次数，可以通过 show status 查询得出

Seconds 是监控的时间区间，单位为秒
例如采样10秒内的查询次数，那么先查询一次Queries值（Q1），等待10秒，再查询一次Queries值（Q2）
QPS = (Q2 - Q1) / 10

2、TPS

mysql中没有直接的事务计数器，需要通过事务提交数和事务回滚数来计算
TPS = (Com_commit + Com_rollback) / Seconds
Com_commit、Com_rollback 的值通过 show status 查询得出


计算思路与 QPS 相似

在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。但是，所有的行为，所有的操作，最终施与的对象都是那些实体。这句话怎么理解呢？比如，我们执行填写操作，施与的对象必然是那些表单，最终产生的结果必然是形成一份完整的表单，表单就是那个行为施与的对象。再比如，我们执行查询操作，施与的对象必然是一个报表，最终产生的结果必然是查看到了这个报表的结果。这里的表单、报表，都是存在于系统的静态实体，它们中的大多数也最终以数据结构的形式持久化保存于系统的数据库中。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。

领域建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题：怎么才能保证建模的正确性？
这听起来是个合理的质疑，但实际上却不是那么有道理。首先我们需要明白建模的目的是什么？如果仅仅是为了描画问题，那么并没有什么对错之分——仅仅是立场和角度的差别；而如果是为了企业业务系统而进行建模，那么这个问题应该变为：如何保证模型能够支撑企业的运营？
我想用下面这个例子来简要的回答一下这个问题。
在开始分析和建模之前，我们需要知道企业业务系统的目的是什么；而企业业务系统的目的往往跟决策者或者管理的诉求相关。我们现在需要移情到一位管理者身上，看看他的诉求到底是什么。

一、需求分析

需求分析是指开发人员要进行细致的调查分析，准确理解用户的要求。将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能的过程

1、需求分析的基本原则

• 可以把一个复杂问题按功能进行分解并可逐层细化。
  
• 必须能够表达和理解问题的数据领域和功能领域。
  
• 建立模型。

ModSecurity是一个免费、开源的Web（apache、nginx、IIS）模块，可以充当Web应用防火墙（WAF:Web Application Firewall）。ModSecurity是一个入侵探测与阻止的引擎.它主要是用于Web应用程序所以也可以叫做Web应用程序防火墙.ModSecurity的目的是为增强Web应用程序的安全性和保护Web应用程序避免遭受来自已知与未知的攻击
OWASP是一个安全社区，开发和维护着一套免费的应用程序保护规则，这就是所谓OWASP的ModSecurity的核心规则集（即CRS）。ModSecurity之所以强大就在于OWASP提供的规则，可以根据自己的需求选择不同的规则，当然ModSecurity还有商用的规则
目前ModSecurity正在测试环境测试使用，以下操作是在nginx下添加modsecurity模块来实现WAF的安装配置步骤,