体系结构

1. 客户端发出一个Http请求，web应用服务器接收到这个请求。如果匹配DispatcherServlet的请求映射路径（在web.xml中指定），则web容器将该请求转交给DispatcherServlet处理。
2. DispatcherSerovlet接收到这个请求后，将根据请求的信息（包括URL，HTTP方法，请求报文头，请求参数，Cokie等）及HandlerMapping的配置找到处理请求的处理器（Handler）。可将HandlerMapping看作路由控制器，将Handler看做目标主机。值得注意的是，在SpringMVC中并没有定义一个Handler接口，实际上，任何一个Object都可以作为请求处理器。
3. 当DispatcherServlet根据HandlerMapping得到对应当前请求的Handler后，通过HandlerAdapter对handler进行封装，再以统一的适配器接口调用Handler。HandlerAdapter是SpringMVC的框架级接口，顾名思义，HandlerAdapter是一个适配器，它用统一的接口对各种Handler方法进行调用
4. 处理器完成业务逻辑的处理之后将返回一个ModelAndView给DispatcherServlet，ModelAndView包含了视图逻辑名和模型数据信息。
5. ModelAndView包含的是“视图逻辑名”而非真正的视图对象，DispatcherServlet借由ViewResolver完成逻辑视图名到真实视图对象的解析工作。
6. 得到真实的视图对象View后，DispatcherServlet就使用这个View对象对ModelAndView中的模型数据进行视图渲染。
7. 最终客户端得到的响应消息可能是一个普通的HTML页面，也可能是一个XML或JSON串，甚至是一张图片或一个PDF文档等不同媒体形式。

DispatcherServlet内部逻辑

    initStrategies()方法将在WebApplicationContext初始化后自动执行，此时Spring上下文中的Bean已经初始化完毕。该方法的工作原理是：通过反射机制查找并装配Spring容器中用户显示自定义的组件Bean，如果找不到，则装配默认的组件实例。

    Spring MVC定义了一套默认的组件实现类，也就是说，即使在Spring容器中没有显示定义组件bean，DispatcherServlet也会装配好一套可用的默认组件。在Spring-webmvc-4.x.jar包的org/springframework/web/servlet类路径下拥有一个DispatcherServlet.propertiesp配置文件，该文件指定了DispatcherServlet所使用的默认组件。

    如果希望采用非默认的组件，则只需要在Spring配置文件中配置自定义的组件Bean即可。Spring MVC一旦发现上下文中有用户自定义的组件，就不会使用默认的组件。





    有些组件最多允许存在一个实例，如MutlipartResolver，LocaleResolver等；而另一些组件允许存在多个实例，如HandlerMapping，HandlerAdapter等。同一类型的组件如果存在多个，可通过order属性确定优先级迅速，值越小优先级越高。

注: 标注了Spring MVC通过@Controller注解的类使其成为一个可处理Http请求的控制器（使用context:component-scan/扫描相应的类包)，DispatcherServlet使用DefaultAnnotationHandlerMapping查找负责处理对应请求的处理器。

注解驱动的控制器

使用@RequestMapping映射请求

    @RequestMapping使用value指定请求URL，在类定义处指定的URL相对于Web应用的部署路径，而在方法定义处指定的URL则相对于类定义处指定的URL。

    @RequestMapping不但支持标准的URL，还支持Ant风格（？、*和**字符）和带{XXX}占位符的URL。例如:

• /user/*/create，匹配/user/aa/create，/user/bb/create
• /user/**/create，匹配/user/create，/user/aa/create，/user/aa/bb/create
• /user/create?，匹配/user/createaa，/user/createbb
• /user/{userId}，匹配/user/123，/user/456
• /company/{companyId}/user/{userId}/detail，匹配/company/123/user/456/detail

    通过@PathVariable可以将URL中的占位符参数绑定到控制器方法入参中。如@PathVariable(“userId”)。

通过请求参数，请求方法或请求头进行映射

    @RequestMapping的value，method，params及headersf分别表示请求URL，请求方法，请求参数及报文头的映射条件，它们之间是与的关系，联合使用多个条件项可让请求映射更加精细化。

• “params1”: 表示请求必须包含名为params1的请求参数
• “!params1”: 表示请求不能包含名为params1的请求参数
• “params1!=value1”: 表示请求必须包含名为params1的请求参数，但其值不能为value1
• {“params1=value1”,”param2”}: 表示请求必须包含名为params1和params2的两个请求参数，且params1必须为value1

请求处理方法签名

方法入参使用@RequestParam注解指定对应的请求参数，包含3个参数

• value: 参数名
• required: 是否必需，默认为true，不存在将抛出异常
• defaultValue: 默认参数名，设置该参数时，自动将required设为false

使用@CookieValue可让处理方法入参绑定某个cookie的值，它和@RequestParam一样有3个参数

使用@RequestHeader绑定请求报文头的属性值

使用命令/表单对象绑定请求参数值

使用Servlet API对象作为入参

使用I/O对象作为入参

    Servlet的ServletRequest拥有getInputStream()和getReader()方法，可以通过它们读取请求的信息。相应的，ServletResponse拥有getOutputStream()和getReader()方法，可以通过它们输出响应信息。

使用HttpMessageConverter

    HttpMessageConverter是Spring的一个重要的接口，它负责将请求信息转换为一个对象（类型为T），将对象（类型为T）输出为响应信息。

    DispatcherServlet默认已经安装了RequestMappingHandleAdapter作为HandleAdapter的组件实现类，HttpMessageConverter即由RequestMappingHandleAdapter使用，将请求信息转换为对象，或将对象转换为响应信息。

HttpMessageConverter的实现类

    RequestMappingHandleAdapter默认已经转配了以下HttpMessageConverter:

1. StringHttpMessageConverter
2. ByteArrayHttpMessageConverter
3. SourceHttpMessageConverter
4. AllEncompassingFormHttpMessageConverter

使用HttpMessageConverter

    SpringMVC提供了两种途径使用HttpMessageConverter将请求信息转换并绑定到处理方法的入参中:

• 使用@RequestBody/@ResponseBody对处理方法进行标注
• 使用HttpEntity/ResponseEntity作为处理方法的入参或返回值

1. 使用@RequestBody/@ResponseBody

    在1处，SpringMVC将根据requestBody的类型查找匹配的HttpMessageConverter，由于StringHttpMessageConverter的泛型类型对应String，所以StringHttpMessageConverter将被SpringMVC选中，用它将请求体信息进行转换并将结果绑定到requestBody入参上。

    在2处，由于方法返回值类型为byte[]，所以SpringMVC根据类型匹配的查找规则将使用ByteArrayHttpMessageConverter对返回值进行处理，即将图片数据流输出到客户端。

2. 使用HttpEntity/ResponseEntity

    和@RequestBody/@ResponseBody类似，HttpEntity不但可以访问请求和响应报文体的数据，还可以访问请求和响应报文头的数据。SpringMVC根据HttpEntity的泛型类型查找对应的HttpMessageConverter。





    在1处使用HttpEntity指定入参的类型，SpringMVC分析出泛型类型为String，使用StringHttpMessageConverter将请求体类型绑定到httpEntity中，返回String类型的值座位逻辑视图名。

    在2处的处理方法返回值类型为ResponseEntity<byte[]>，SpringMVC分析出泛型类型为byte[]，使用ByteArrayHttpMessageConverter输出图片数据流。

处理XML和JSON

    SpringMVC提供了几个处理XML和JSON格式的请求/响应消息的HttpMessageConverter。

• MarshallingHttpMessageConverter：处理XML格式的请求或响应消息
• Jaxb2RootElementHttpMessageConverter：同上，底层使用Jaxb
• MappingJackson2HttpMessageConverter：处理JSON格式的请求或响应消息

    因此，只要在SpringMVC容器中为RequestMappingHandlerAdapter装配好相应的处理XML和JSON格式的请求/响应消息的HttpMessageConverter，并在交互中通过请求的Accept指定MIME类型，SpringMVC就可使服务端的处理方法和客户端透明的通过XML和JSON格式的消息进行通信。

    首先为RequestMappingHandleAdapter装配可处理XML和JSON格式的请求/响应消息的HttpMessageConverter



    控制器相应的方法如下:





    通过以上HTTP请求/响应报文，客户端的User对象被流化为一段对象的XML报文，同时通过报文头属性Accept和Content-Type指定接收的MIME类型和本请求的报文内容均为application/xml。

    将请求报文头属性Accept和Content-Type更改为application/json，User对象的数据以JSON格式进行传递。

查看并行收集线程
/usr/jdk1.8.0_101/bin/java -server -Xmx1024m -Xms1024m -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -version| grep ParallelGCThreads

内存控制参数

-XX参数

-XX后面有部分参数可以跟+或者-,+表示开启,-表示禁用
比如
-XX:+UseGCOverheadLimit,就表示GC时间过长抛OOM
-XX:-UseGCOverheadLimit,就表示GC时间过长不要抛OOM

JDK1.7及以下版本参数
-Xms128m -Xmx512m -Xss256k -server -XX:PermSize=32m -XX:MaxPermSize=256m -XX:NewRatio=1 -XX:-UseBiasedLocking -XX:AutoBoxCacheMax=20000 -XX:-UseGCOverheadLimit -XX:-OmitStackTraceInFastThrow -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:MaxTenuringThreshold=2 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+PrintGCDateStamps -verbose:gc -Xloggc:gc.log

JDK1.8及以上版本参数
-Xms128m -Xmx512m -Xss256k -server -XX:MetaspaceSize=32m -XX:MaxMetaspaceSize=256m -XX:NewRatio=1 -XX:-UseBiasedLocking -XX:AutoBoxCacheMax=20000 -XX:-UseGCOverheadLimit -XX:-OmitStackTraceInFastThrow -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:MaxTenuringThreshold=2 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+PrintGCDateStamps -verbose:gc -Xloggc:gc.log

参考

二叉排序树（Binary Sort Tree）

规则

1. 若左子树不空，则左子树上所有节点的值均小于它的根节点的值
2. 若右子树不空，则右子树上所有节点的值均大于它的根节点的值
3. 它的左、右子树也分别为二叉排序树（递归定义）

说明

二叉查找树查找比较方便，因为每次经过一次节点时，最多减少一半的可能。极端情况下，会出现所有节点位于同一侧的情况，直观上看就是一条直线，这种情况的查询效率比较低。因此需要对二叉树左右子树的高度作平衡化处理，这就是平衡二叉树。

平衡二叉树（Balance Binary Tree）

规则

1. 左右子树的高度差的绝对值不超过1
2. 左右子树都是平衡二叉树（递归定义）

说明

常见的实现方式为：红黑树，平衡二叉查找树（AVL）,替罪羊树，树堆（Treap），伸展树。在这样的平衡树中进行查找，总共比较节点的次数不超过树的高度，查询效率得到提高，时间复杂度为O(logn)。

平衡多路查找树（B树或B-树）

规则

1. 每个节点至多可以拥有m棵子树
2. 根节点，只有至少2个节点
3. 非根非叶的节点至少有Ceil(m/2)个子树（Ceil表示向上取整），例如5阶B树，每个节点至少3个子树
4. 所有叶子节点位于同一层，意思是从根到叶子节点的每一条路径都有同样的长度

说明

B树查询与二叉排序树类似，从根节点依次比较每个节点，因为每个节点中关键字和左右子树都是有序的。

B+树

规则

1. 有n棵子树的节点含有n个关键字，每个关键字不保存数据，只用来索引，所有数据保存在叶子节点
2. 所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接
3. 非叶子节点看成是索引部分，结点中仅含其子树（根节点）中的最大（或最小）关键字

说明

B+树查找过程与B树类似，只不过查找时，如果在非叶子节点上的关键字等于给定值，并不终止，而是继续沿着指针直到叶子节点。因此对于B+树，不管查找成功或失败，每次查找都是走了一条从根到叶子节点的路径。

通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构（双向循环链表）。因此可以对B+Tree进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。

实现

MyISAM索引实现

MyISAM引擎使用B+Tree作为索引结构，叶结点的data域存放的是数据记录的地址。

主索引(主键)

辅助索引

在 MyISAM 中,主索引和辅助索引(Secondary key)在结构上没有任何区别，只是主索引要求 key 是唯一的,而辅助索引的 key 可以重复。

说明

同样也是一颗B+Tree，data域保存数据记录的地址。因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。

InnoDB索引实现

虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。

第一个重大区别是InnoDB的数据文件本身就是索引文件。从上文知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶结点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。

主索引(主键)

辅助索引

说明

InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为10^3）。也就是说一个深度为3的B+Tree索引可以维护10^3 10^3 10^3 = 10亿 条记录。实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2~4层。mysql的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。

InnoDB 要求表必须有主键(MyISAM 可以没有)，如果没有显式指定，则 MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列，则MySQL 自动为 InnoDB 表生成一个隐含字段作为主键,类型为长整形。

同时,请尽量在 InnoDB 上采用自增字段做表的主键。因为 InnoDB 数据文件本身是一棵B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持 B+Tree 的特性而频繁的分裂调整，十分低效,而使用自增字段作为主键则是一个很好的选择。如果表使用自增主键,那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满,就会自动开辟一个新的页。

聚簇索引

InnoDB 使用的是聚簇索引，将主键组织到一棵B+树中， 而行数据就储存在叶子节点上， 若使用”where id = 14”这样的条件查找主键，则按照 B+树的检索算法即可查找到对应的叶节点，之后获得行数据。 若对 Name 列进行条件搜索，则需要两个步骤:

• 第一步、在辅助索引 B+树中检索 Name，到达其叶子节点获取对应的主键。
• 第二步、使用主键在主索引B+树种再执行一次 B+树检索操作，最终到达叶子节点即可获取整行数据。

非聚簇索引

MyISM 使用的是非聚簇索引, 非聚簇索引的两棵 B+树看上去没什么不同, 节点的结构完全一致只是存储的内容不同而已, 主键索引 B+树的节点存储了主键, 辅助键索引B+树存储了辅助键。 表数据存储在独立的地方, 这两颗 B+树的叶子节点都使用一个地址指向真正的表数据, 对于表数据来说, 这两个键没有任何差别。 由于索引树是独立的, 通过辅助键检索无需访问主键的索引树。

含义

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。

解决方案

缓存空对象

存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

缓存空对象会有两个问题：

第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

实现代码：

布隆过滤

对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

例如： 一个个性化推荐系统有 4 亿个用户 ID，每个小时算法工程师会根据每个用户之前历史行为做出来的个性化放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可以将所有有个性化推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户 ID 不存在，那么就不会访问存储层，在一定程度保护了存储层。

有关布隆过滤器的相关知识，可以参考： https://en.wikipedia.org/wiki/Bloom_filter

可以利用 Redis 的 Bitmaps 实现布隆过滤器，GitHub 上已经开源了类似的方案：
https://github.com/erikdubbelboer/Redis-Lua-scaling-bloom-filter

这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

对比

缓存雪崩

含义

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案

思路

预防和解决缓存雪崩问题，可以从以下三个方面进行着手。

1）保证缓存层服务高可用性。

和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。

2）依赖隔离组件为后端限流并降级。

无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部 hang 在这个资源上，造成整个系统不可用。降级在高并发系统中是非常正常的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。

在实际项目中，我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管理，比如如何关闭资源池，开启资源池，资源池阀值管理，这些做起来还是相当复杂的，这里推荐一个 Java 依赖隔离工具 Hystrix(https://github.com/Netflix/Hystrix)

方案

加锁排队

在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法

数据预热

可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

做二级缓存，或者双缓存策略。

A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

缓存永远不过期

这里的“永远不过期”包含两层意思：

1）从缓存上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。

2）从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期.

参考

在数据库的锁机制中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。

乐观并发控制(乐观锁) 和 悲观并发控制（悲观锁） 是并发控制主要采用的技术手段。

无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。

针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。

悲观锁

在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。
悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

含义

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

实现

在数据库中，悲观锁的流程如下：

1. 在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
2. 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。
3. 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
4. 其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

应用（MySQL InnoDB中使用悲观锁）

要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。set autocommit=0;

1
2
3
4
5
6
7
8
9
10

//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;

上面的查询语句中，我们使用了select…for update的方式，这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中，id为1的 那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。

优点与不足

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数

乐观锁

在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。

含义

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

数据版本,为数据增加的一个版本标识。当读取数据时，将版本标识的值一同读出，数据每更新一次，同时对版本标识进行更新。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对，如果数据库表当前版本号与第一次取出来的版本标识值相等，则予以更新，否则认为是过期数据。

实现

实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。

使用版本号时，可以在数据初始化时指定一个版本号，每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新的版本号。

应用（MySQL中使用乐观锁）

1
2
3
4
5
6
7

1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};

优点与不足

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。

说明

KafkaTemplate封装了一个生成器，并提供了方便的方法来发送数据到kafka主题。 提供了异步和同步方法，异步方法返回一个Future。

其构造方法有：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

ListenableFuture<SendResult<K, V>> sendDefault(V data);

ListenableFuture<SendResult<K, V>> sendDefault(K key, V data);

ListenableFuture<SendResult<K, V>> sendDefault(int partition, K key, V data);

ListenableFuture<SendResult<K, V>> send(String topic, V data);

ListenableFuture<SendResult<K, V>> send(String topic, K key, V data);

ListenableFuture<SendResult<K, V>> send(String topic, int partition, V data);

ListenableFuture<SendResult<K, V>> send(String topic, int partition, K key, V data);

ListenableFuture<SendResult<K, V>> send(Message<?> message);

前3个方法需要向Temple提供默认主题

配置

使用Producer配置类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

@Configuration
@EnableKafka
public class ProducerConfig {

@Value("${kafka.producer.servers}")
private String servers;

@Value("${kafka.producer.retries}")
private int retries;

@Value("${kafka.producer.batch.size}")
private int batchSize;

@Value("${kafka.producer.linger}")
private int linger;

@Value("${kafka.producer.buffer.memory}")
private int bufferMemory;

public Map<String, Object> producerConfigs() {
Map<String, Object> props = new HashMap<>();
props.put(Config.BOOTSTRAP_SERVERS_CONFIG, servers);
props.put(Config.RETRIES_CONFIG, retries);
props.put(Config.BATCH_SIZE_CONFIG, batchSize);
props.put(Config.LINGER_MS_CONFIG, linger);
props.put(Config.BUFFER_MEMORY_CONFIG, bufferMemory);
props.put(Config.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
props.put(Config.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
props.put(Config.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
return props;
}

public ProducerFactory<String, String> producerFactory() {
return new DefaultKafkaProducerFactory<>(producerConfigs());
}

@Bean
public KafkaTemplate<String, String> kafkaTemplate() {
return new KafkaTemplate<String, String>(producerFactory());
}
}

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@RestController
@RequestMapping("/kafka/producer")
public class ProducerController {
private static Logger logger = LoggerFactory.getLogger(ProducerController.class);

@Value("${topic.name}")
private String topicName;

@Autowired
private KafkaTemplate<String, String> kafkaTemplate;

@RequestMapping("/send")
public Object sendKafka(String message) {
try {
logger.info("send kafka message: {}", message);
kafkaTemplate.send(topicName, UUID.randomUUID().toString(), message);
return "success";
} catch (Exception e) {
logger.error("发送kafka失败", e);
return "fail";
}
}
}

消费者

说明

可以通过配置MessageListenerContainer并提供MessageListener或通过使用@KafkaListener注释来接收消息。
MessageListenerContainer有两个实现：

配置

使用Consumer配置类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

@Configuration
@EnableKafka
public class ConsumerConfig {

@Value("${kafka.consumer.servers}")
private String servers;

@Value("${kafka.consumer.enable.auto.commit}")
private boolean enableAutoCommit;

@Value("${kafka.consumer.session.timeout}")
private String sessionTimeout;

@Value("${kafka.consumer.auto.commit.interval}")
private String autoCommitInterval;

@Value("${kafka.consumer.group.id}")
private String groupId;

@Value("${kafka.consumer.topic}")
private String topic;

@Value("${kafka.consumer.auto.offset.reset}")
private String autoOffsetReset;

@Value("${kafka.consumer.concurrency}")
private int concurrency;

/**
 * KafkaMessageListenerContainer： 从单个线程上的所有主题/分区接收所有消息

@Bean(initMethod = "doStart")
public KafkaMessageListenerContainer<String, String> kafkaMessageListenerContainer() {
KafkaMessageListenerContainer<String, String> container = new KafkaMessageListenerContainer<>(consumerFactory(), containerProperties());
return container;
}

*/

/**
 * ConcurrentMessageListenerContainer：
 * 委托给1个或多个KafkaMessageListenerContainer以提供多线程消费。
 * 通过container.setConcurrency(3)，来设置多个线程
 */
@Bean(initMethod = "doStart")
public ConcurrentMessageListenerContainer<String, String> concurrentMessageListenerContainer() {
ConcurrentMessageListenerContainer<String, String> container = new ConcurrentMessageListenerContainer<>(consumerFactory(), containerProperties());
container.setConcurrency(concurrency);
return container;

}

public ConsumerFactory<String, String> consumerFactory() {
return new DefaultKafkaConsumerFactory<>(consumerConfigs());
}

public ContainerProperties containerProperties() {
ContainerProperties containerProperties = new ContainerProperties(topic);
containerProperties.setMessageListener(messageListener());
return containerProperties;
}

public Map<String, Object> consumerConfigs() {
Map<String, Object> propsMap = new HashMap<>();
propsMap.put(Config.BOOTSTRAP_SERVERS_CONFIG, servers);
propsMap.put(Config.ENABLE_AUTO_COMMIT_CONFIG, enableAutoCommit);
propsMap.put(Config.AUTO_COMMIT_INTERVAL_MS_CONFIG, autoCommitInterval);
propsMap.put(Config.SESSION_TIMEOUT_MS_CONFIG, sessionTimeout);
propsMap.put(Config.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
propsMap.put(Config.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
propsMap.put(Config.GROUP_ID_CONFIG, groupId);
propsMap.put(Config.AUTO_OFFSET_RESET_CONFIG, autoOffsetReset);
return propsMap;
}

public MessageListener<String, String> messageListener() {
return new CustomMessageListener();
}
}

消息接收

Java实现

直接使用kafka0.10 client去收发消息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

@Test
public void receive(){
    Properties props = new Properties();
    props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, broker);
    props.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
    props.put(ConsumerConfig.CLIENT_ID_CONFIG, clientId);
    props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
    props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");
    props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
    props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
    KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
    try{
        consumer.subscribe(Arrays.asList(topic));
        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(10000);
            records.forEach(record -> {
                System.out.printf("client : %s , topic: %s , partition: %d , offset = %d, key = %s, value = %s%n", clientId, record.topic(),
                        record.partition(), record.offset(), record.key(), record.value());
            });
        }
    }catch (Exception e){
        e.printStackTrace();
    }finally {
        consumer.close();
    }
}

使用MessageListener接口

继承MessageListener接口

1
2
3
4
5
6
7
8
9
10

public class CustomMessageListener implements MessageListener<Integer, String> {
private static Logger logger = LoggerFactory.getLogger(CustomMessageListener.class);

@Override
public void onMessage(ConsumerRecord<Integer, String> data) {
logger.info("received key: {}, value: {}", data.key(), data.value());
}

  //或包含消费者的onMessage方法，以手动提交ofset
}

使用@KafkaListener注解

1
2
3
4
5
6
7
8
9
10
11
12
13

@KafkaListener(id = "foo", topics = "myTopic")
public void listen(String data) {
 ...
}

@KafkaListener(id = "bar", topicPartitions =
        { @TopicPartition(topic = "topic1", partitions = { "0", "1" }),
          @TopicPartition(topic = "topic2", partitions = "0",
             partitionOffsets = @PartitionOffset(partition = "1", initialOffset = "100"))
        })
public void listen(ConsumerRecord<?, ?> record) {
    ...
}

总结

• 对于生产者来说，封装KafkaProducer到KafkaTemplate相对简单
• 对于消费者来说，由于spring是采用注解的形式去标注消息处理方法
  • 先在KafkaListenerAnnotationBeanPostProcessor中扫描bean，然后注册到KafkaListenerEndpointRegistrar
  • 而KafkaListenerEndpointRegistrar在afterPropertiesSet的时候去创建MessageListenerContainer
  • messageListener包含了原始endpoint携带的bean以及method转换成的InvocableHandlerMethod
  • ConcurrentMessageListenerContainer这个衔接上，根据配置的spring.kafka.listener.concurrency来生成多个并发的KafkaMessageListenerContainer实例
  • 每个KafkaMessageListenerContainer都自己创建一个ListenerConsumer，然后自己创建一个独立的kafka consumer，每个ListenerConsumer在线程池里头运行，这样来实现并发
  • 每个ListenerConsumer里头都有一个recordsToProcess队列，从原始的kafka consumer poll出来的记录会放到这个队列里头，
  • 然后有一个ListenerInvoker线程循环超时等待从recordsToProcess取出记录，然后调用messageListener的onMessage方法(即KafkaListener注解标准的方法)

项目源码

参考

git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。git是个工具，在linux里面也就类似gcc这样的工具一样，是一个shell命令。

Git与GitHub区别

Git与CVS、SVN的区别

远程仓库、工作区、版本库和暂存区

远程仓库

就是在github或者在gitlab上的代码。可以用git pull和git push来进行本地仓库和远程仓库的同步操作

工作区（Working Directory）

从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做工作目录，也就是工作区

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

暂存区（Stage）

暂存区就是版本库中的一个区域，具体参见上面的结构图

工作区、版本库、暂存区之间的关系

版本回退

前提条件：已经执行git commit命令了，但是没有push到远程仓库，用以下命令可以回退

其实这个回退就是将本地的HEAD指针移动到某个版本上而已，所以这个操作是非常快的。

回退到上一个版本

1
2

$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed

回退到未来的某个版本

1
2

$ git reset --hard 3628164
HEAD is now at 3628164 append GPL

git log则不能查看已经删除了的commit记录

总结

git reset –-soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可
git reset -–hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容，撤销的commit中所包含的更改被冲掉

撤销修改

含义

场景

git stash

场景:当你接到一个修复一个代号101的bug的任务时，你想创建一个分支issue-101来修复它，但是，当前正在dev上进行的工作还没有提交，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作

git stash list

查看暂存区的所有暂存修改记录

1
2

$ git stash list
stash@{0}: WIP on dev: 6224937 add merge

git stash apply stash@{X}

取出相应的暂存

git stash drop stash@{X}

将记录列表中取出的对应暂存记录删除

git stash pop(推荐)

取出最近一次暂存并删除记录列表中对应记录

分支管理

Bug分支

在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

Feature分支

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：


当有新消息通过 publish 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

实例

以下实例演示了发布订阅是如何工作的。在我们实例中我们创建了订阅频道名为 redisChat:

1
2
3
4
5
6

redis 127.0.0.1:6379> SUBSCRIBE redisChat

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

现在，我们先重新开启个 redis 客户端，然后在同一个频道 redisChat 发布两次消息，订阅者就能接收到消息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

redis 127.0.0.1:6379> publish redisChat "Redis is a great caching technique"

(integer) 1

redis 127.0.0.1:6379> publish redisChat "Learn redis by runoob.com"

(integer) 1

# 订阅者的客户端会显示如下消息
1) "message"
2) "redisChat"
3) "Redis is a great caching technique"
1) "message"
2) "redisChat"
3) "Learn redis by runoob.com"

命令

Redis 事务

Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

实例

以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

redis 127.0.0.1:6379> MULTI
OK

redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED

redis 127.0.0.1:6379> GET book-name
QUEUED

redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED

redis 127.0.0.1:6379> SMEMBERS tag
QUEUED

redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
   2) "C++"
   3) "Programming"

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

命令

具体内容参见事物-官网文档

Redis 脚本

Redis 脚本使用 Lua 解释器来执行脚本。 Reids 2.6 版本通过内嵌支持 Lua 环境。执行脚本的常用命令为 EVAL。

实例

1
2
3
4
5
6

redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second

1) "key1"
2) "key2"
3) "first"
4) "second"

命令

Redis 数据备份与恢复

Redis 提供了不同级别的持久化方式:

RDB

优点

缺点

AOF

优点

缺点

命令

如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

Redis 管道技术

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。这意味着通常情况下一个请求会遵循以下步骤：

更多知识详见官方文档

Remote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

数据类型

String（字符串）

string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。

string类型是Redis最基本的数据类型，一个键最大能存储512MB。

实例

1
2
3
4

redis 127.0.0.1:6379> SET name "runoob"
OK
redis 127.0.0.1:6379> GET name
"runoob"

在以上实例中我们使用了 Redis 的 SET 和 GET 命令。键为 name，对应的值为 runoob。

注意：一个键最大能存储512MB。

Hash（哈希）

Redis hash 是一个键值(key=>value)对集合。

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

实例

1
2
3
4
5
6

redis> HMSET myhash field1 "Hello" field2 "World"
"OK"
redis> HGET myhash field1
"Hello"
redis> HGET myhash field2
"World"

以上实例中 hash 数据类型存储了包含用户脚本信息的用户对象。 实例中我们使用了 Redis HMSET, HGETALL 命令，user:1 为键值。

每个 hash 可以存储 2^32 -1 键值对（40多亿）。

List（列表）

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

实例

1
2
3
4
5
6
7
8
9
10
11

redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

列表最多可存储 2^32 - 1 元素 (4294967295, 每个列表可存储40多亿)。

Set（集合）

Redis的Set是string类型的无序集合。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

sadd 命令

添加一个string元素到,key对应的set集合中，成功返回1,如果元素已经在集合中返回0,key对应的set不存在返回错误。

1

sadd key member

实例

1
2
3
4
5
6
7
8
9
10
11
12
13

redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob

1) "rabitmq"
2) "mongodb"
3) "redis"

注意：以上实例中 rabitmq 添加了两次，但根据集合内元素的唯一性，第二次插入的元素将被忽略。

集合中最大的成员数为 2^32 - 1(4294967295, 每个集合可存储40多亿个成员)。

zset(sorted set：有序集合)

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

zset的成员是唯一的,但分数(score)却可以重复。

zadd 命令

添加元素到集合，元素在集合中存在则更新对应score

1

zadd key score member

实例

1
2
3
4
5
6
7
8
9
10
11
12

redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"

介绍

kaptcha 是一个很有用的验证码生成工具。有了它，你能够生成各种样式的验证码，由于它是可配置的。

kaptcha工作的原理是调用com.google.code.kaptcha.servlet.KaptchaServlet，生成一个图片。

同一时候将生成的验证码字符串放到 HttpSession中。

配置项

组件介绍

结构图如下：

使用

FontGenerator

Font类，用于设置字体的样式和字体随机的大小范围

在com.octo.captcha.component.image.fontgenerator包中包含了几种Font类

Font	作用	示例	效果
RandomFontGenerator	设置随机出现的字体样式和随机的字体大小范围	RandomFontGenerator fonts = new RandomFontGenerator (new Integer(20), new Integer(30));
TwistedRandomFontGenerator	设置字体的随机大小范围，并对字体进行简单的扭曲变形，字体左右倾斜的效果	TwistedRandomFontGenerator fonts = new TwistedRandomFontGenerator(new Integer(20), new Integer(30));
TwistedAndShearedRandomFontGenerator	TwistedRandomFontGenerator的子类，和 TwistedRandomFontGenerator类的构造器参数也相同，显示效果相近，采用的算法有所不同
DeformedRandomFontGenerator	构造器的参数和上两个类相同，采用的方式也类似

BackgroundGenerator

Background设置背景颜色或背景图片、设置图片大小

在com.octo.captcha.component.image.backgroundgenerator包中包含了的Background类

Background	作用	示例	效果
UniColorBackgroundGenerator	设置图片大小和以单一颜色为背景的图片背景，可以设置一个或多个备选颜色。 如果想让颜色更加多变，则可以使用RandomRangeColorGenerator类，设置随机取得的RGB值，让RGB值分别的随机取得，则RGB值随机搭配的颜色将会更加多变	UniColorBackgroundGenerator background = new UniColorBackgroundGenerator(new Integer(200), new Integer(100), Color.BLUE);
MultipleShapeBackgroundGenerator	设置一种多变的背景花纹	MultipleShapeBackgroundGenerator background = new MultipleShapeBackgroundGenerator (200,100,Color.RED,Color.BLUE,10,10,8,8,Color.WHITE,Color.YELLOW,3);
GradientBackgroundGenerator	设置一种渐变颜色的背景，也可以设置多种颜色的渐变背景	GradientBackgroundGenerator background = new GradientBackgroundGenerator(200, 100, Color.BLACK, Color.WHITE);
FunkyBackgroundGenerator	设置四种不同颜色混杂在一起的背景。 如果创建过程中，给SingleColorGenerator类改为使用RandomListColorGenerator或其他类，也可以让四种颜色随机变化	SingleColorGenerator leftUpColor = new SingleColorGenerator(Color.RED); SingleColorGenerator leftDownColor = new SingleColorGenerator(Color.YELLOW); SingleColorGenerator rightUpColor = new SingleColorGenerator(Color.BLUE); SingleColorGenerator rightDownColor = new SingleColorGenerator(Color.GREEN); FunkyBackgroundGenerator background = new FunkyBackgroundGenerator( 200, 100, leftUpColor, leftDownColor, rightUpColor, rightDownColor, 0.5f);
FileReaderRandomBackgroundGenerator	设置从指定目录读取图片作为生成图片的背景，目录中的图片，会在类构造期间就全部读取到内存中	FileReaderRandomBackgroundGenerator background = new FileReaderRandomBackgroundGenerator(200, 100, “E:¥¥testproject¥¥jcaptcha¥¥images¥¥backgrounds”);
EllipseBackgroundGenerator	一种花样的背景，该类到目前为止没有更多的配置选项，只能设置图片大小，颜色和其他相关的值都不能设置

TextPaster

TextPaster可以设置单词的最小和最大长度和设置字的颜色（前景颜色），设置单词在图像中的位置是固定还是随机
在com.octo.captcha.component.image.textpaster包中包含了的常用TextPaster类

TextPaster	作用	示例	效果
RandomTextPaster	最常用的TextPaster，可以设置生成单词的随机长度范围，和设置一种或多种前景颜色，生成的字符串在图像中的位置是随机的	RandomTextPaster textPaster = new RandomTextPaster(new Integer(5), new Integer(10), Color.BLACK); 也可以设置多种随机前景颜色： Color[] colors = new Color[]{Color.RED,Color.YELLOW,Color.BLUE}; RandomListColorGenerator randomColors = new RandomListColorGenerator(colors); RandomTextPaster textPaster = new RandomTextPaster(new Integer(5), new Integer(10), randomColors);
SimpleTextPaster	和RandomTextPaster用法和参数都相同，但是生成的字符串位置不变
NonLinearTextPaster	设置非直线的TextPaster，最后生成的文本成非直线的排列	NonLinearTextPaster textPaster = new NonLinearTextPaster (new Integer(5), new Integer(10), Color.BLACK);
DoubleTextPaster	可以形成两行好像重影效果的文本，单词位置固定	DoubleTextPaster textPaster = new DoubleTextPaster(new Integer(5),new Integer(10), Color.BLACK);
DoubleRandomTextPaster	和DoubleTextPaster类类似的效果，但是单词在图像中出现的位置和第二行字上下位置，是随机的
DecoratedRandomTextPaster	为生成的文本加上修饰，例如干扰线、干扰点	SingleColorGenerator lineColor = new SingleColorGenerator(Color.BLUE); TextDecorator decorator1 = new LineTextDecorator(new Integer(1), lineColor, AlphaComposite.SRC_OVER); TextDecorator[] decorators = new TextDecorator[] { decorator1 }; SingleColorGenerator color = new SingleColorGenerator(Color.RED); DecoratedRandomTextPaster textPaster = new DecoratedRandomTextPaster(new Integer(5), new Integer(10), color, decorators); LineTextDecorator的构造器的最后一个参数是干扰线的类型，在该参数上进行修改，也能取得不错的效果，例如将AlphaComposite.SRC_OVER改为AlphaComposite.CLEAR、AlphaComposite.SRC_IN、AlphaComposite.XOR LineTextDecorator类是线型的装饰器，Captcha还提供了一种点状的装饰类： SingleColorGenerator dColor = new SingleColorGenerator(Color.BLUE); TextDecorator decorator2 = new BaffleTextDecorator(new Integer(1), dColor, AlphaComposite.SRC_OUT); TextDecorator[] decorators = new TextDecorator[] { decorator2 }; SingleColorGenerator color = new SingleColorGenerator(Color.RED); DecoratedRandomTextPaster textPaster = new DecoratedRandomTextPaster(new Integer(5), new Integer(10), color, decorators);

Deformation和ImageFilter

    这两种类，都提供了对图片字体进行进一步变形的功能，Deformation类是Captcha框架中提供的变形类 和接口，ImageFilter是一个使用java提供图形图像方面服务的公司提供的通用的图形变形过滤器，可以实现的效果很多。

    Deformation和ImageFilter都分为3层，一种是在文字级别的，一种是在背景级别的，还有在整个图片级别的，用于在图片生成不同的阶段对图片进行变形。

    Deformation类，当前Captcha只提供了一种选择，就是PuzzleImageDeformation类，该类的效果是将 图片旋转，然后直接贴在原来图片的上面，所以效果不是很好，相信以后Captcha会提供更多的Deformation类，并且会不断完善，但是目前，不推荐使用。

    ImageFilter过滤器，有很多现有的资源可以供选择使用，是目前最好的选择。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// font  
RandomFontGenerator fonts = new RandomFontGenerator(new Integer(20), new Integer(20));  

// background  
BackgroundGenerator background = new UniColorBackgroundGenerator(new Integer(400), new Integer(300), Color.white);  

// textPaster  
RandomTextPaster textPaster =  new RandomTextPaster(new Integer(5), new Integer(5), Color.BLACK);  

// no deformation  
ImageDeformation noneDeformation = new ImageDeformationByFilters( new ImageFilter[] {});

// filter创建过滤器  
ImageDeformation filters =  new ImageDeformationByFilters( new ImageFilter[] { new TwirlFilter() });  DeformedComposedWordToImage cwti =   new DeformedComposedWordToImage(fonts, background, textPaster, noneDeformation, filters, noneDeformation);  

// 设置随机取词范围
RandomWordGenerator words = new RandomWordGenerator("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
GimpyFactory gimpy = new GimpyFactory(words, cwti);  
SimpleListImageCaptchaEngine engine = new SimpleListImageCaptchaEngine();
engine.setFactories(new CaptchaFactory[] { gimpy });  
FastHashMapCaptchaStore captchaStore = new FastHashMapCaptchaStore();

// 创建Captcha服务  
DefaultManageableImageCaptchaService defaultService = new  DefaultManageableImageCaptchaService(captchaStore, engine, 180, 100000, 75000);  
return defaultService;

    上述的代码，是在创建一个Captcha服务器的过程中，将过滤器加入其中，其中使用的font、background、 和testPaster类，都使用了最简单的，没有变形效果的类，意在只查看过滤器对整个图片的映像。

更多过滤器效果，可以参见Java Image Filters

1. Kafka下载

• 下载地址：http://kafka.apache.org/downloads
• wget http://apache.fayea.com/kafka/0.10.1.0/kafka_2.11-0.10.1.0.tgz
• tar -xvf kafka_2.11-0.10.1.0.tgz
  cd kafka_2.11-0.10.1.0

2. Zookeeper安装

Kafka需要Zookeeper的监控，所以先要安装Zookeeper，如何安装请传送至：
hadoop、
zookeeper、
hbase、spark集群环境搭建 ，
安装完成以后依次启动各个节点

3. 配置kafka broker集群

• 首先把Kafka解压后的目录复制到集群的各台服务器
• 然后修改各个服务器的配置文件：进入Kafka的config目录，修改server.properties

  1 2 3 4 5 6 7 8 9 10

  # brokerid就是指各台服务器对应的id，所以各台服务器值不同 broker.id=0 # 端口号，无需改变 port=9092 # 当前服务器的IP，各台服务器值不同 host.name=192.168.0.10 # Zookeeper集群的ip和端口号 zookeeper.connect=192.168.0.10:2181,192.168.0.11:2181,192.168.0.12:2181 # 日志目录 log.dirs=/home/www/kafka-logs

4. 启动Kafka

• 在每台服务器上进入Kafka目录，分别执行以下命令：

  1	bin/kafka-server-start.sh config/server.properties &

5. Kafka常用命令

• 5.1 新建topic

  1	bin/kafka-topics.sh --create --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181 --replication-factor 2 --partitions 2 --topic test

test有两个复制因子和两个分区

• 5.2 查看某个topic主题

  1	bin/kafka-topics.sh --describe --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181 --topic test

其中第一行是所有分区的信息，下面的每一行对应一个分区

Leader：负责某个分区所有读写操作的节点

Replicas：复制因子节点

Isr：存活节点

• 5.3 查看Kafka所有的主题

  1	bin/kafka-topics.sh --list --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181

• 5.4 终端发送消息

  1	bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

• 5.5 终端接收（消费）消息

  1	bin/kafka-console-consumer.sh --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181 --bootstrap-server localhost:9092 --topic test --from-beginning

简介

1. 基本术语

消息

在Kafka中，每一个消息由键、值和一个时间戳组成

主题和日志

Kafka集群存储同一类别的消息流称为主题

主题会有多个订阅者（0个1个或多个），当主题发布消息时，会向订阅者推送记录

针对每一个主题，Kafka集群维护了一个像下面这样的分区日志：

这些分区位于不同的服务器上，每一个分区可以看做是一个结构化的提交日志，每写入一条记录都会记录到其中一个分区并且分配一个唯一地标识其位置的数字称为偏移量offset

Kafka集群会将发布的消息保存一段时间，不管是否被消费。例如，如果设置保存天数为2天，那么从消息发布起的两天之内，该消息一直可以被消费，但是超过两天后就会被丢弃以节省空间。其次，Kafka的数据持久化性能很好，所以长时间存储数据不是问题

如下图所示，生产者每发布一条消息就会向分区log写入一条记录的offset，而消费者就是通过offset来读取对应的消息的，一般来说每读取一条消息，消费者对应要读取的offset就加1，例如最后一条读到offset=12，那么下条offset就为13.由于消费者通过offset来读取消息，所以可以重复读取已经读过的记录，或者跳过某些记录不读

Kafka中采用分区的设计有几个目的。一是可以处理更多的消息，不受单台服务器的限制。Topic拥有多个分区意味着它可以不受限的处理更多的数据。第二，分区可以作为并行处理的单元

分布式

Log的分区被分布到集群中的多个服务器上。每个服务器处理它分到的分区。 根据配置每个分区还可以复制到其它服务器作为备份容错

每个分区有一个leader，零或多个follower。Leader处理此分区的所有的读写请求，而follower被动的复制数据。如果leader宕机，其它的一个follower会被推举为新的leader。 一台服务器可能同时是一个分区的leader，另一个分区的follower。 这样可以平衡负载，避免所有的请求都只让一台或者某几台服务器处理

生产者

生产者往某个Topic上发布消息。生产者还可以选择将消息分配到Topic的哪个节点上。最简单的方式是轮询分配到各个分区以平衡负载，也可以根据某种算法依照权重选择分区

消费者

Kafka有一个消费者组的概念，生产者把消息发到的是消费者组，在消费者组里面可以有很多个消费者实例，如下图所示：

Kafka集群有两台服务器，四个分区，此外有两个消费者组A和B，消费者组A具有2个消费者实例C1-2，消费者B具有4个消费者实例C3-6

那么Kafka发送消息的过程是怎样的呢？

例如此时我们创建了一个主题test，有两个分区，分别是Server1的P0和Server2的P1，假设此时我们通过test发布了一条消息，那么这条消息是发到P0还是P1呢，或者是都发呢？答案是只会发到P0或P1其中之一，也就是消息只会发给其中的一个分区

分区接收到消息后会记录在分区日志中，记录的方式我们讲过了，就是通过offset，正因为有这个偏移量的存在，所以一个分区内的消息是有先后顺序的，即offset大的消息比offset小的消息后到。但是注意，由于消息随机发往主题的任意一个分区，因此虽然同一个分区的消息有先后顺序，但是不同分区之间的消息就没有先后顺序了，那么如果我们要求消费者顺序消费主题发的消息那该怎么办呢，此时只要在创建主题的时候只提供一个分区即可

讲完了主题发消息，接下来就该消费者消费消息了，假设上面test的消息发给了分区P0，此时从图中可以看到，有两个消费者组，那么P0将会把消息发到哪个消费者组呢？从图中可以看到，P0把消息既发给了消费者组A也发给了B，但是A中消息仅被C1消费，B中消息仅被C3消费。这就是我们要讲的，主题发出的消息会发往所有的消费者组，而每一个消费者组下面可以有很多消费者实例，这条消息只会被他们中的一个消费掉

2. 核心API

Kafka具有4个核心API：

1. Producer API：用于向Kafka主题发送消息。
2. Consumer API：用于从订阅主题接收消息并且处理这些消息。
3. Streams API：作为一个流处理器，用于从一个或者多个主题中消费消息流然后为其他主题生产消息流，高效地将输入流转换为输出流。
4. Connector API：用于构建和运行将Kafka主题和已有应用或者数据系统连接起来的可复用的生产者或消费者。例如一个主题到一个关系型数据库的连接能够捕获表的任意变化。
   

3. 应用场景

Kafka用作消息系统

Kafka流的概念与传统企业消息系统有什么异同？

传统消息系统有两个模型：队列和发布-订阅系统。在队列模式中，每条服务器的消息会被消费者池中的一个所读取；而发布-订阅系统中消息会广播给所有的消费者。这两种模式各有优劣。队列模式的优势是可以将消息数据让多个消费者处理以实现程序的可扩展，然而这就导致其没有多个订阅者，只能用于一个进程。发布-订阅模式的好处在于数据可以被多个进程消费使用，但是却无法使单一程序扩展性能

Kafka中消费者组的概念同时涵盖了这两方面。对应于队列的概念，Kafka中每个消费者组中有多个消费者实例可以接收消息；对应于发布-订阅模式，Kafka中可以指定多个消费者组来订阅消息

相对传统消息系统，Kafka可以提供更强的顺序保证

Kafka用作存储系统

任何发布消息与消费消息解耦的消息队列其实都可以看做是用来存放发布的消息的存储系统，而Kafka是一个非常高效的存储系统

写入Kafka的数据会被存入磁盘并且复制到集群中以容错。Kafka允许生产者等待数据完全复制并且确保持久化到磁盘的确认应答

Kafka使用的磁盘结构扩容性能很好——不管服务器上有50KB还是50TB，Kafka的表现都是一样的

由于能够精致的存储并且供客户端程序进行读操作，你可以把Kafka看做是一个用于高性能、低延迟的存储提交日志、复制及传播的分布式文件系统

Kafka的流处理

仅仅读、写、存储流数据是不够的，Kafka的目的是实现实时流处理。

在Kafka中一个流处理器的处理流程是首先持续性的从输入主题中获取数据流，然后对其进行一些处理，再持续性地向输出主题中生产数据流。例如一个销售商应用，接收销售和发货量的输入流，输出新订单和调整后价格的输出流

可以直接使用producer和consumer API进行简单的处理。对于复杂的转换，Kafka提供了更强大的Streams API。可构建聚合计算或连接流到一起的复杂应用程序

流处理有助于解决这类应用面临的硬性问题：处理无序数据、代码更改的再处理、执行状态计算等

Streams API所依托的都是Kafka的核心内容：使用producer和consumer API作为输入，使用Kafka作为状态存储，在流处理实例上使用相同的组机制来实现容错

使用

消费者自动提交

使用如下api自动提交：

1

properties.put("enable.auto.commit", "false");

消费者手动提交

每个消费者和对应的patition建立对应的流来读取kafka上面的数据，如果comsumer得到数据，那么kafka就会自动去维护该comsumer的offset，例如在获取到kafka的消息后正准备入库（未入库），但是消费者挂了，那么如果让kafka自动去维护offset，它就会认为这条数据已经被消费了，那么会造成数据丢失。

但是kafka可以让你自己去手动提交，如果在上面的场景中，那么需要我们手动commit，如果comsumer挂了 那么程序就不会执行commit这样的话 其他同group的消费者又可以消费这条数据，保证数据不丢，先要做如下设置：

1
2

//设置不自动提交，自己手动更新offset
properties.put("enable.auto.commit", "false");

使用如下api提交：

1

consumer.commitSync();

系统： Windows 8.1elasticsearch：5.5.1logstash：2.0.0kibana：5.5.1

注：由于实验性搭建，选择windows系统，但选择Linux系统效果更佳

二、部署方案

1.ELK+Redis

2.ELK+Kafka

注：本次搭建选用第一种方案

三、安装

前提:下载nssm

1. Elasticsearch

下载： download

2. logstash

下载： download

3. kibana

下载： download

注册为windows服务

(a) 将下载的nssm.exe分别拷贝到Elasticsearch、logstash和kibana解压后的bin目录下，然后CMD进入bin执行nssm install 服务名,例如Elasticsearch 的执行nssm install elasticsearch-service..

(b) 分析选择path为各压缩包的bin目录下的elasticsearch.bat、logstash.bat和kibana.bat

(c) Details选项卡设置显示名为Windows名

(d) 最后选择Install service

四、部署

1. 创建Maven项目elk-log(可另外取名)，pom文件为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.suncj</groupId>
<artifactId>elk-log</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>elk-log</name>
<description>elk日志生成项目</description>

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.2.8.RELEASE</version>
</dependency>

<dependency>
<groupId>org.eclipse.jetty.aggregate</groupId>
<artifactId>jetty-all</artifactId>
<version>8.1.19.v20160209</version>
</dependency>

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.12</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>net.logstash.logback</groupId>
<artifactId>logstash-logback-encoder</artifactId>
<version>4.9</version>
</dependency>
<!--实现slf4j接口并整合 -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.7.0</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
</project>

2. 配置logback,logback.xml文件为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="false">

<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
<!-- 格式化输出：%d表示日期，%thread表示线程名，%-5level：级别从左显示5个字符宽度%msg：日志消息，%n是换行符 -->
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %c{1}.%M:%L - %m%n
</pattern>
</encoder>
</appender>

<appender name="stash"
class="net.logstash.logback.appender.LogstashTcpSocketAppender">
<destination>127.0.0.1:9250</destination>
<encoder charset="UTF-8"
class="net.logstash.logback.encoder.LogstashEncoder" />
</appender>

<logger name="com.suncj" level="INFO" />

<root level="INFO">
<appender-ref ref="console" />
<appender-ref ref="stash" />
</root>

</configuration>

3.设置项目定时任务(打日志)

定时任务类LogProducer:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package com.suncj.elk;

import java.util.Random;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * 日志生成器<br>
 * 版权：Copyright (c) 2015-2016<br>
 * 创建日期：2017年8月5日<br>
 */
public class LogProducer {
private static final Logger log = LoggerFactory.getLogger(LogProducer.class);

private Random rand = new Random();

private static int logId = 0;

public void produce() {
log.info("log_id: {} , content:{}", logId, String.format("I am %s", logId + rand.nextInt(100000)));
logId++;
}

}

项目启动类:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package com.suncj.elk;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Application {
private static Logger logger = LoggerFactory.getLogger(Application.class);

public static ApplicationContext appContext;

public static void main(String[] args) {
try {
logger.info("准备加载程序");
appContext = new ClassPathXmlApplicationContext("app-*.xml");
logger.info("加载完成");
} catch (Exception e) {
logger.error("主程序出错:", e);
}

}

}

其他配置文件：app-task.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:util="http://www.springframework.org/schema/util"
xmlns:task="http://www.springframework.org/schema/task" xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

<bean id="logProducer" class="com.suncj.elk.LogProducer"></bean>

<task:scheduled-tasks>
<task:scheduled ref="logProducer" method="produce"
cron="0/5 * * * * *" />
</task:scheduled-tasks>
</beans>

2. logstash配置

(a) run_es.bat，run_redis.bat

1

logstash.bat agent -f logstash_es.conf

(b) logstash_redis.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

input {
tcp {
host => "127.0.0.1"
port => 9250
mode => "server"
codec => json_lines
}
}
output {
redis {
host => "127.0.0.1"
        port => 6379
        db => 1
data_type => "list"
key => "log:es"
}
}

(c) logstash_es.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

input {
  redis {
    data_type => "list"
    key => "log:es"
    host => "127.0.0.1"
    db => 1
    port => 6379
  }
}
output {
  stdout{
    codec => rubydebug
  }
  elasticsearch {
    hosts => ["127.0.0.1:9200"]
    index => "log-es-%{+YYYY.MM.dd}"
    flush_size => 1000
  }
}

注: logstash注册为windows服务时需要
创建两个bat文件，一个用于项目日志存储到redis；另外一个用户读取redis,输出到elasticsearch，因此需要注册两个服务名不同的windows服务

参考资料

https://kibana.logstash.es/content/kibana/index.html

http://blog.csdn.net/tulizi/article/details/52972824

http://udn.yyuap.com/doc/logstash-best-practice-cn/input/redis.html

https://www.elastic.co/guide/en/logstash/current/codec-plugins.html

Apache Shiro是一个功能强大、灵活的，开源的安全框架。它可以干净利落地处理身份验证、授权、企业会话管理和加密。

Apache Shiro的首要目标是易于使用和理解。安全通常很复杂，甚至让人感到很痛苦，但是Shiro却不是这样子的。一个好的安全框架应该屏蔽复杂性，向外暴露简单、直观的API，来简化开发人员实现应用程序安全所花费的时间和精力。

Shiro能做什么呢？

• 验证用户身份


• 用户访问权限控制，比如：1、判断用户是否分配了一定的安全角色。2、判断用户是否被授予完成某个操作的权限


• 在非 web 或 EJB 容器的环境下可以任意使用Session API


• 可以响应认证、访问控制，或者 Session 生命周期中发生的事件


• 可将一个或以上用户安全数据源数据组合成一个复合的用户 “view”(视图)


• 支持单点登录(SSO)功能


• 支持提供“Remember Me”服务，获取用户关联信息而无需登录
  
  …

等等——都集成到一个有凝聚力的易于使用的API。

Shiro 致力在所有应用环境下实现上述功能，小到命令行应用程序，大到企业应用中，而且不需要借助第三方框架、容器、应用服务器等。当然 Shiro 的目的是尽量的融入到这样的应用环境中去，但也可以在它们之外的任何环境下开箱即用。

Apache Shiro Features 特性

Apache Shiro是一个全面的、蕴含丰富功能的安全框架。下图为描述Shiro功能的框架图：

Authentication（认证）, Authorization（授权）, Session Management（会话管理）, Cryptography（加密）被 Shiro 框架的开发团队称之为应用安全的四大基石。那么就让我们来看看它们吧：

• Authentication（认证）：用户身份识别，通常被称为用户“登录”


• Authorization（授权）：访问控制。比如某个用户是否具有某个操作的使用权限。


• Session Management（会话管理）：特定于用户的会话管理,甚至在非web 或 EJB 应用程序。


• Cryptography（加密）：在对数据源使用加密算法加密的同时，保证易于使用。

还有其他的功能来支持和加强这些不同应用环境下安全领域的关注点。特别是对以下的功能支持：

• Web支持：Shiro 提供的 web 支持 api ，可以很轻松的保护 web 应用程序的安全。


• 缓存：缓存是 Apache Shiro 保证安全操作快速、高效的重要手段。


• 并发：Apache Shiro 支持多线程应用程序的并发特性。


• 测试：支持单元测试和集成测试，确保代码和预想的一样安全。


• “Run As”：这个功能允许用户假设另一个用户的身份(在许可的前提下)。


• “Remember Me”：跨 session 记录用户的身份，只有在强制需要时才需要登录。

注意： Shiro不会去维护用户、维护权限，这些需要我们自己去设计/提供，然后通过相应的接口注入给Shiro

High-Level Overview 高级概述

在概念层，Shiro 架构包含三个主要的理念：Subject,SecurityManager和 Realm。下面的图展示了这些组件如何相互作用，我们将在下面依次对其进行描述。

• Subject：当前用户，Subject 可以是一个人，但也可以是第三方服务、守护进程帐户、时钟守护任务或者其它–当前和软件交互的任何事件。


• SecurityManager：管理所有Subject，SecurityManager 是 Shiro 架构的核心，配合内部安全组件共同组成安全伞。


• Realms：用于进行权限信息的验证，我们自己实现。Realm 本质上是一个特定的安全 DAO：它封装与数据源连接的细节，得到Shiro 所需的相关的数据。在配置 Shiro 的时候，你必须指定至少一个Realm 来实现认证（authentication）和/或授权（authorization）。

我们需要实现Realms的Authentication 和 Authorization。其中 Authentication 是用来验证用户身份，Authorization 是授权访问控制，用于对用户进行的操作授权，证明该用户是否允许进行当前操作，如访问某个链接，某个资源文件等。

快速上手

pom.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
<groupId>net.sourceforge.nekohtml</groupId>
<artifactId>nekohtml</artifactId>
<version>1.9.22</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-spring</artifactId>
<version>1.4.0</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
</dependencies>

Shiro 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

@Configuration
public class ShiroConfig {
@Bean
public ShiroFilterFactoryBean shirFilter(SecurityManager securityManager) {
System.out.println("ShiroConfiguration.shirFilter()");
ShiroFilterFactoryBean shiroFilterFactoryBean = new ShiroFilterFactoryBean();
shiroFilterFactoryBean.setSecurityManager(securityManager);
//拦截器.
Map<String,String> filterChainDefinitionMap = new LinkedHashMap<String,String>();
// 配置不会被拦截的链接 顺序判断
filterChainDefinitionMap.put("/static/**", "anon");
//配置退出 过滤器,其中的具体的退出代码Shiro已经替我们实现了
filterChainDefinitionMap.put("/logout", "logout");
//<!-- 过滤链定义，从上向下顺序执行，一般将/**放在最为下边 -->:这是一个坑呢，一不小心代码就不好使了;
//<!-- authc:所有url都必须认证通过才可以访问; anon:所有url都都可以匿名访问-->
filterChainDefinitionMap.put("/**", "authc");
// 如果不设置默认会自动寻找Web工程根目录下的"/login.jsp"页面
shiroFilterFactoryBean.setLoginUrl("/login");
// 登录成功后要跳转的链接
shiroFilterFactoryBean.setSuccessUrl("/index");

//未授权界面;
shiroFilterFactoryBean.setUnauthorizedUrl("/403");
shiroFilterFactoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap);
return shiroFilterFactoryBean;
}

@Bean
public MyShiroRealm myShiroRealm(){
MyShiroRealm myShiroRealm = new MyShiroRealm();
return myShiroRealm;
}


@Bean
public SecurityManager securityManager(){
DefaultWebSecurityManager securityManager =  new DefaultWebSecurityManager();
securityManager.setRealm(myShiroRealm());
return securityManager;
}
}

Filter Chain定义说明：

• 1、一个URL可以配置多个Filter，使用逗号分隔


• 2、当设置多个过滤器时，全部验证通过，才视为通过


• 3、部分过滤器可指定参数，如perms，roles

Shiro内置的FilterChain:

• anon:所有url都都可以匿名访问


• authc: 需要认证才能进行访问


• user:配置记住我或认证通过可以访问

登录认证实现

在认证、授权内部实现机制中都有提到，最终处理都将交给Real进行处理。因为在Shiro中，最终是通过Realm来获取应用程序中的用户、角色及权限信息的。通常情况下，在Realm中会直接从我们的数据源中获取Shiro需要的验证信息。可以说，Realm是专用于安全框架的DAO.
Shiro的认证过程最终会交由Realm执行，这时会调用Realm的getAuthenticationInfo(token)方法。

该方法主要执行以下操作:

• 1、检查提交的进行认证的令牌信息


• 2、根据令牌信息从数据源(通常为数据库)中获取用户信息


• 3、对用户信息进行匹配验证。


• 4、验证通过将返回一个封装了用户信息的AuthenticationInfo实例。


• 5、验证失败则抛出AuthenticationException异常信息。

而在我们的应用程序中要做的就是自定义一个Realm类，继承AuthorizingRealm抽象类，重载doGetAuthenticationInfo()，重写获取用户信息的方法。

doGetAuthenticationInfo的重写

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token)
        throws AuthenticationException {
    System.out.println("MyShiroRealm.doGetAuthenticationInfo()");
    //获取用户的输入的账号.
    String username = (String)token.getPrincipal();
    System.out.println(token.getCredentials());
    //通过username从数据库中查找 User对象，如果找到，没找到.
    //实际项目中，这里可以根据实际情况做缓存，如果不做，Shiro自己也是有时间间隔机制，2分钟内不会重复执行该方法
    UserInfo userInfo = userInfoService.findByUsername(username);
    System.out.println("----->>userInfo="+userInfo);
    if(userInfo == null){
        return null;
    }
    SimpleAuthenticationInfo authenticationInfo = new SimpleAuthenticationInfo(
            userInfo, //用户名
            userInfo.getPassword(), //密码
            ByteSource.Util.bytes(userInfo.getCredentialsSalt()),//salt=username+salt
            getName()  //realm name
    );
    return authenticationInfo;
}

链接权限的实现

shiro的权限授权是通过继承AuthorizingRealm抽象类，重载doGetAuthorizationInfo();当访问到页面的时候，链接配置了相应的权限或者shiro标签才会执行此方法否则不会执行，所以如果只是简单的身份认证没有权限的控制的话，那么这个方法可以不进行实现，直接返回null即可。在这个方法中主要是使用类：SimpleAuthorizationInfo进行角色的添加和权限的添加。

1
2
3
4
5
6
7
8
9
10
11
12
13

@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
    System.out.println("权限配置-->MyShiroRealm.doGetAuthorizationInfo()");
    SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo();
    UserInfo userInfo  = (UserInfo)principals.getPrimaryPrincipal();
    for(SysRole role:userInfo.getRoleList()){
        authorizationInfo.addRole(role.getRole());
        for(SysPermission p:role.getPermissions()){
            authorizationInfo.addStringPermission(p.getPermission());
        }
    }
    return authorizationInfo;
}

当然也可以添加set集合：roles是从数据库查询的当前用户的角色，stringPermissions是从数据库查询的当前用户对应的权限

1
2

authorizationInfo.setRoles(roles);
authorizationInfo.setStringPermissions(stringPermissions);

就是说如果在shiro配置文件中添加了filterChainDefinitionMap.put(“/add”, “perms[权限添加]”);就说明访问/add这个链接必须要有“权限添加”这个权限才可以访问，如果在shiro配置文件中添加了filterChainDefinitionMap.put(“/add”, “roles[100002]，perms[权限添加]”);就说明访问/add这个链接必须要有“权限添加”这个权限和具有“100002”这个角色才可以访问。

参考附录:

Apache Shiro中文手册

Spring Boot Shiro权限管理【从零开始学Spring Boot】

SpringBoot+shiro整合学习之登录认证和权限控制

springboot整合shiro-登录认证和权限管理

Java中线程的同步机制保证了多线程访问共享变量的安全性，通常我们使用synchronized关键字来实现。在多个线程对共享变量进行读写操作时，同步锁保证了同一时间只有一个线程对共享变量进行操作，概括地说，这是一种“以时间换空间”的解决策略。

在JDK1.2中引入了ThreadLocal类来提供了一种“以空间换时间”的同步解决策略。ThreadLocal内部维护了一份类似Map的静态变量ThreadLocalMap，其中key为当前线程，value为共享变量。JDK1.5引入泛型，ThreadLocal也同时支持泛型。

其具体实现如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124

public class ThreadLocal<T> {
  /**
   * ThreadLocals rely on per-thread hash maps attached to each thread
   * (Thread.threadLocals and inheritableThreadLocals).  The ThreadLocal
   * objects act as keys, searched via threadLocalHashCode.  This is a
   * custom hash code (useful only within ThreadLocalMaps) that eliminates
   * collisions in the common case where consecutively constructed
   * ThreadLocals are used by the same threads, while remaining well-behaved
   * in less common cases.
   */
  private final int threadLocalHashCode = nextHashCode();

  /**
   * The next hash code to be given out. Accessed only by like-named method.
   */
  private static int nextHashCode = 0;

  /**
   * The difference between successively generated hash codes - turns
   * implicit sequential thread-local IDs into near-optimally spread
   * multiplicative hash values for power-of-two-sized tables.
   */
  private static final int HASH_INCREMENT = 0x61c88647;

  /**
   * Compute the next hash code. The static synchronization used here
   * should not be a performance bottleneck. When ThreadLocals are
   * generated in different threads at a fast enough rate to regularly
   * contend on this lock, memory contention is by far a more serious
   * problem than lock contention.
   */
  private static synchronized int nextHashCode() {
      int h = nextHashCode;
      nextHashCode = h + HASH_INCREMENT;
      return h;
  }

  /**
   * Creates a thread local variable.
   */
  public ThreadLocal() {
  }

  /**
   * Returns the value in the current thread's copy of this thread-local
   * variable.  Creates and initializes the copy if this is the first time
   * the thread has called this method.
   *
   * @return the current thread's value of this thread-local
   */
  public T get() {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null)
          return (T)map.get(this);

      // Maps are constructed lazily.  if the map for this thread
      // doesn't exist, create it, with this ThreadLocal and its
      // initial value as its only entry.
      T value = initialValue();
      createMap(t, value);
      return value;
  }

  /**
   * Sets the current thread's copy of this thread-local variable
   * to the specified value.  Many applications will have no need for
   * this functionality, relying solely on the {@link #initialValue}
   * method to set the values of thread-locals.
   *
   * @param value the value to be stored in the current threads' copy of
   *        this thread-local.
   */
  public void set(T value) {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null)
          map.set(this, value);
      else
          createMap(t, value);
  }

  /**
   * Get the map associated with a ThreadLocal. Overridden in
   * InheritableThreadLocal.
   *
   * @param  t the current thread
   * @return the map
   */
  ThreadLocalMap getMap(Thread t) {
      return t.threadLocals;
  }

  /**
   * Create the map associated with a ThreadLocal. Overridden in
   * InheritableThreadLocal.
   *
   * @param t the current thread
   * @param firstValue value for the initial entry of the map
   * @param map the map to store.
   */
  void createMap(Thread t, T firstValue) {
      t.threadLocals = new ThreadLocalMap(this, firstValue);
  }

  .......

  /**
   * ThreadLocalMap is a customized hash map suitable only for
   * maintaining thread local values. No operations are exported
   * outside of the ThreadLocal class. The class is package private to
   * allow declaration of fields in class Thread.  To help deal with
   * very large and long-lived usages, the hash table entries use
   * WeakReferences for keys. However, since reference queues are not
   * used, stale entries are guaranteed to be removed only when
   * the table starts running out of space.
   */
  static class ThreadLocalMap {

  ........

  }

}

从中很清晰的可以看出，多个线程拥有自己一份单独的ThreadLocalMap，共享变量对于每个线程都是单独的一份，因此不会造成线程的安全问题。

JDBC的ConnectionManager类就是以这种方式来实现数据库连接Connection对象线程隔离。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class ConnectionManager {

private static ThreadLocal<Connection> connectionHolder = new ThreadLocal<Connection>() {
@Override
protected Connection initialValue() {
Connection conn = null;
try {
conn = DriverManager.getConnection(
"jdbc:mysql://localhost:3306/test", "username",
"password");
} catch (SQLException e) {
e.printStackTrace();
}
return conn;
}
};

public static Connection getConnection() {
return connectionHolder.get();
}

public static void setConnection(Connection conn) {
connectionHolder.set(conn);
}
}

但是，有些情况ThreadLocal可能并不适用，例如存储大量数据的共享变量，或共享变量只能被创建一次时，就只能通过synchronized来实现了。

推荐阅读

Spring Cloud官网

Spring Cloud中文网

一、Spring Cloud Netflix

二、服务提供与调用

三、熔断器Hystrix

四、熔断监控Hystrix Dashboard和Turbine

五、配置中心git示例

    从15年11月份以来，这一年多在企业工作的日子里，我收获许多。作为一个渴望学技术的程序员，我慢慢摆脱了学校的那种安逸的生活，开始走上了技术宅的道路。

    在企业中，前几个月的时间里，我每天都像是海绵一样吸收着养分，学习企业的架构，项目的开发，部署，优化以及维护工作。我每天都痛苦并快乐着，虽然加班，但是我能感觉到自己一点一点的在往上爬。我学会SpringMVC架构，学会使用Maven构建项目，用Ant来实现自动部署项目，用Groovy脚本来编写告警任务。学会了很多软件，诸如MongoDB，Redis等常用开发软件。这个过程中，我很快乐，并且每天都在进步。

    但是到了17年的3,4月份，我熟悉了团队的各种业务，也明白了项目中所用到的框架和各种技术。我每天做的除了日常的开发和维护，似乎陷入了重复造轮子的困境。虽然在这过程中，我学会了怎样去考虑到新业务或新场景的设计流程和后续的维护过程，但是我始终感觉到了自己的进步慢慢的缓下了，这是我不希望看到的，我渴望进步和成功。

    最终，我看到了一句话，“种一棵树，最好的时间是十年前，其次，是现在”，我开始领悟到我必须改变点什么。我开始看基础的JAVA进阶等书籍，开始每天看技术博客或推文，培养自己的兴趣，并且从现在开始，写博客。我以前似乎总在犹豫，我常常害怕自己的技术不够好，但是，从另外一个方面想，这又有什么关系，那就学吧。

    为什么写博客，因为它是对你看到，用到知识的升华。在写博客的过程中，不仅会让你review以前的代码，考虑更好的设计方案，也会让你对知识的理解更上一层楼，并记忆深刻。

    写代码的时候，往往避免不了遇到各种BUG和技术难点，但是没关系，多请教别人，大多数人愿意和你分享自己的所得。和优秀的人多交流，你们会相互收益。最后，最重要的是，告诉自己不要怕，并且时刻保持一个谦卑的心。